Two weeks in.
The steering committee received a green status last Friday. Slides showed a programme on track, procurement progressing, no critical path issues.
On site, the structural drawings are not frozen. The main supplier has flagged a six-week lead time nobody put in the schedule. The works supervisor has already started sequencing around a constraint that does not exist in the plan.
Two plans are running. The deck. And the real one. Nobody told leadership.
“By the time the gap between the deck and the site becomes undeniable, it is already expensive to close.”
The assumption that splits every programme in two
Most programme governance is built on a version of the same belief: if the master schedule exists and the stage gates are defined, the plan is real.
It is not. A plan is only real if the people doing the work recognise it as the operating truth. If the site supervisor runs a different sequence, if procurement has a different assumption about lead times, if engineering has resolved a constraint that is still open in the schedule — then you have two plans, not one.
Two plans mean two versions of what was committed. Two versions of what is possible. Two versions of what went wrong when the gap surfaces.
Governance that exists only in a deck is not governance. It is documentation of an intention.
How the two plans diverge — and how to collapse them into one
On a cross-border energy infrastructure programme, the master schedule showed commissioning in month fourteen. The site team had already moved the electrical installation sequence by three weeks to accommodate a ground constraint discovered in month two. The revised sequence was never reflected in the master schedule.
By month eight, the client, contractor, and site team were discussing three different versions of the same milestone. Each one was real to the party holding it. None of them matched the others.
When the client queried the milestone, neither side could point to one authoritative version of the plan. The dispute was not about the change. It was about what the original commitment had been.
The fix was not a schedule update. It was a governance reset: a single operating plan, updated weekly, with a defined owner for each interface.
Disputes about what was committed: zero after the reset.
Forecast revisions in the final six months: zero.
Programme delivered within 2% of the reset budget.
The fix: not a new tool. A new operating discipline.
How to build one plan everyone actually uses
There is one document. Not a deck version, a site version, and a procurement version. One. Every function references this document. It is updated weekly. It is the authority.
The plan is built by walking the site logic: what is the actual sequence, what are the real constraints, what are the handoff dependencies on the ground. Then the schedule reflects that.
Any change to the operating sequence must be in the plan within 48 hours. Not eventually. Not after the next steering committee. This is the mechanism that prevents the two plans from re-diverging after the reset.
The weekly control meeting is not a status update. It is a plan review. The question is not “what has happened?” but “what has changed, why, and what does the plan now say?”
When the site deviates from the plan, the deviation is recorded, the impact is assessed, and the recovery option is named. A deviation is not a failure. An invisible deviation is.
The objections I hear before every plan reset
“We already have a master schedule. This is what we use.”
The test is not whether a master schedule exists. The test is whether the site supervisor can tell you what the plan says is happening this week — and whether the answer matches. If it does not, you have two plans.
“Updating the plan every week will consume too much time.”
A plan that diverges from site reality and then has to be reconciled in a steering committee consumes far more time. The weekly update is fifteen minutes if the change protocol is working. The reconciliation is three hours if it is not.
“Our tool does this already.”
The tool is not the issue. The question is whether everyone is using the same version of the same plan — and whether deviations are captured before they compound. Most tools can support this. Most projects do not configure them to.
The pattern holds across scales
On a major gas pipeline programme in Denmark — €850M+, cross-border, hostile contracting environment — the commercial position was maintained through intense contractual pressure because there was one operating plan both sides recognised. When disputes arose, both sides could point to the same document.
“When there is one plan, disputes are about deviations. When there are two, disputes are about what was agreed in the first place.”