One Project Plan, Not Ten Separate Plans

A project management plan is often assembled the way a binder is assembled. One person owns the schedule, another writes the quality approach, procurement supplies the sourcing section, finance provides the budget, and the risk lead contributes a risk management plan. Every part is competent on its own terms. Every part gets approved. Then delivery starts and the parts stop agreeing with each other.

Integration is the work of holding one consistent set of project commitments instead of several. It is not achieved by storing the documents in the same folder or giving them a common cover page. It happens when a decision taken in one part of the project visibly changes the others, and when nobody is able to promise something on behalf of the project that contradicts a promise already made somewhere else.

The PMBOK® Guide Eighth Edition places Integrate and Align Project Plans at Section 2.1.6, inside the Governance Performance Domain, alongside authorisation, oversight, change and closure. That puts integration with the mechanisms that keep a project decidable: who agrees what, on what basis, and what has to move when something shifts.

How ten plans drift apart

Subsidiary documents are usually produced at different moments by people answering different questions. The schedule owner is asked when the work finishes. The resource owner is asked who is available. The procurement lead is asked how the supplier will be engaged. Each answers well within their own frame, and the frames carry assumptions that are never compared. The contradiction is rarely visible in the text of any document. It sits in the assumptions underneath.

A schedule assumes an integration engineer for six weeks whom the resource plan has half-committed elsewhere. A quality approach needs a stable test environment in a fortnight the release plan has reserved for a data refresh. A communications plan promises a monthly benefits report that nobody has agreed to measure. A change process assumes a board meeting every four weeks while the team delivers every two, so any change waits longer than the work it affects.

A utilities company replacing its billing platform approved five plans within the same month. The cutover weekend in the schedule was realistic. The resource plan was realistic too, and it committed the same three integration engineers to a regulatory reporting change in the fortnight before cutover. The training plan booked four hundred users into the week the test environment was scheduled for its final refresh. No individual plan was wrong. Together they described a fortnight that could not happen, and the collision surfaced six weeks out as an argument about whose date should move, at exactly the moment nobody had the time to hold that discussion properly.

Every plan can be correct on its own and still be wrong together.

Testing whether the plans agree

Two questions will usually expose whether a project is running one plan or a collection of them, and both can be asked without opening a document.

Take a change that is plausible rather than catastrophic: the delivery date moves two weeks, or a supplier delivers a month late, or a key specialist leaves. Now name every commitment that has to move with it and every person who has to agree. If the honest answer is that the schedule changes and everything else stays as written, the project has one document doing all the reconciling and several more describing a world that no longer exists. Tracing a change through the plans takes twenty minutes and tells you more about integration than any review of the plans themselves.

The second question concerns authority. Who is entitled to make a commitment on behalf of the project without consulting anyone else? If the procurement lead can agree a delivery date with a supplier, the test manager can agree an environment window with operations, and the sponsor can agree a demonstration date with a customer, all in the same week and without sight of each other, then the project is running three plans whatever the binder says. Integration is as much about where commitments are made as about where they are recorded.

The instrument that does most of the practical work here is usually the assumption and dependency record rather than the plans. Plans agree in their text and disagree in what they took for granted: available capacity, environment stability, decision cadence, supplier lead times, the availability of the people who have to accept the output. Reconciling assumptions is far cheaper than reconciling finished plans, and it is where genuine integration tends to happen.

For a PMP candidate, integration is easy to meet as a process name and much harder to recognise inside a scenario. The 2026 Examination Content Outline places it in the Process domain, in the task on developing an integrated project management plan and planning delivery, where one of the enablers is assessing consolidated plans for dependencies, gaps and continued business value. The useful preparation habit is noticing when a situation describes an inconsistency between plans rather than a scope, schedule or stakeholder problem, because the first sensible move is to reconcile the commitments and establish who has to agree, not to push a single date.

Integration in adaptive and hybrid delivery

None of this depends on having ten documents. An adaptive team may carry a roadmap, a release plan, a product backlog, a funding envelope, a dependency board and a set of working agreements. That is six planning artefacts under different names, owned by different people, and they drift apart in exactly the same way.

What changes with the approach is the mechanism. Predictive work integrates largely through baselines and a change process, so the reconciliation is deliberate, recorded and periodic. Adaptive work integrates through cadence, shared prioritisation and dependencies made visible, so the reconciliation is frequent and lighter. The failure modes differ accordingly: predictive projects tend to hold plans that agree with each other on paper and no longer match reality, while adaptive projects tend to hold a delivery plan that matches reality and a governance commitment nobody has updated since the business case.

Hybrid delivery is where most real integration effort sits, because the seam is permanent. A governed milestone plan promising defined scope at a fixed date and a backlog reprioritised by value every fortnight will diverge within a few iterations unless somebody reconciles them on purpose and on a rhythm. Hybrid is not made to work by writing a document that describes both. It works when there is a regular point at which the iterating plan and the governed commitment are compared, and a named person who can say that one of them has to change.

Keeping the plan integrated after approval

Approval is the moment the documents are most consistent with each other, and the decay starts immediately. Integration is therefore a standing activity with an owner and a cadence, not a task completed during planning. On a small project that might be twenty minutes in an existing weekly meeting. On a large programme it might be a monthly reconciliation across workstream leads, supported by the dependency record.

The instinct when integration fails is to write a larger plan. It is usually the wrong response, because the length of the document has very little to do with whether its parts agree. The better response is to shorten the plans and give the joins more attention: assumptions, dependencies, decision rights, escalation thresholds and the commitments that different people are allowed to make outside the room. Reading a situation for plan inconsistency, then working out who has to agree before anything moves, develops faster against varied scenarios than against one live project, which is part of what structured PMP® Exam Preparation is for.

The benefit on a real project is not tidiness. It is that the awkward conversation happens in month two, when three or four options are still open, rather than in the week before cutover, when there is only one option and it is expensive. There is a professional dimension as well. Being the person who identified in March that two approved commitments could not both hold is a very different position from being the person who discovered it in September.

The test is small enough to run this week. Pick a change that might plausibly happen in the next month, and list every commitment that would have to move with it. If that list is short and obvious to everyone who owns a piece of the plan, the project has one plan. If assembling it takes an afternoon and produces surprises, it has ten.

Andre Malowney

Interested in going further?

Recognising a plan inconsistency, and knowing who has to agree before anything moves, is the kind of judgement that scenario-based questions are built to examine and that is difficult to practise on a single live project. Structured preparation gives you repeated exposure to those situations across predictive, adaptive and hybrid contexts.

Integrate and Align Project Plans sits in the Governance Performance Domain of the PMBOK® Guide Eighth Edition, which is where to read how integration connects to authorisation, change and closure.

Ad · Amazon affiliate link.

References

A090: Project Governance Explained: Who Decides What, and Why
A091: Project Governance vs Organisational Governance: What's the Difference?
A092: How Projects Create Value Through Governance
A093: Choosing a Project Governance Model
A094: Governance Metrics That Actually Tell You Something

PMP and PMBOK are registered marks of the Project Management Institute, Inc.