The Plan That Gets Rewritten the Day It Is Approved

The medium term plan takes months. Departments are asked what they need over the next three to five years. They put forward projects, cost them, argue for them. Business units consolidate the requests, find they add up to twice the available money, send them back, and get a second version. Eventually a number is agreed, a plan is signed off, and everyone goes back to work.

Then the year starts. Within a quarter, the plan being delivered is not the plan that was approved. Not because anyone overturned it. Because the approved plan was a document, and the delivery was happening somewhere else.

Approval is a moment. Delivery is a process.

The approved plan exists at one instant: the day it is signed. From that day forward two things run in parallel. The plan, frozen in a slide deck or a workbook, and the estate, which keeps moving.

A project starts late. Another one is scoped up because the platform it was refreshing turned out to be in worse shape than the plan assumed. A third is quietly dropped because the person who championed it left. A fourth appears that was never in the plan at all, funded from whatever was left over.

None of these are governance failures on their own. They are ordinary delivery. The failure is that nothing records the divergence as it happens, so by mid year the organisation is running on two versions of the truth. One it approved. One it is paying for.

The cycle is fine. The handover is missing.

The submit, review, return and accept cycle is worth defending. It forces departments to prioritise before the money exists. It gives the business unit a consolidated view of demand against a ceiling. It produces a plan that people have argued about and agreed to.

What most organisations do not have is the step after acceptance. The plan is locked, and then it is expected to somehow become the roadmap and the budget by itself.

In practice this means someone retypes it. The approved projects are keyed into a portfolio tool. The approved spend is keyed into a finance workbook, phased across months by hand. The roadmap is drawn from a different copy. Three transcriptions of the same decision, done by three people, at three different times, with three sets of small differences.

The plan did not drift because delivery changed. It drifted at the moment of transcription, before delivery had started.

What release should actually do

The missing step has a name. Release.

When a plan is released it should stop being a document and start being a set of records. Every project line in the approved plan becomes, or is joined to, a real project. Every year of approved spend becomes a roadmap line with a value against it. The next year’s spend is phased across months and lands in the finance tracker as the committed budget that actuals will be measured against.

Three things follow from doing it this way.

The approved plan and the delivered plan are the same object. When a project slips, its roadmap line moves and its forecast moves, and the variance from what was approved is visible on the same screen, not discovered at a quarterly review.

The lock means something. Locking a plan is only useful if the locked version is the one being executed. If the executed version lives in a separate workbook, the lock protects a copy nobody is using.

Additions are visible as additions. A project that was not in the approved plan shows up as unfunded against it. That is not a block. It is a prompt to go back and ask where the money is coming from, at the point the question is still cheap to answer.

Why department ownership matters here

There is a second reason plans drift, and it is structural rather than procedural.

Many planning processes treat the plan as one organisation-wide list, ranked centrally. This is tidy on a slide, but it strips out the people who actually know what each platform needs. A department that owns a set of platforms knows which ones are approaching end of support, which contracts are up for renewal, and which projects are already half done. A central list does not.

When the department owns its plan, submits it against a ceiling set by the business unit, and gets it back with a decision, the plan carries that knowledge with it. And when the department’s platforms are recorded as its platforms, the released projects attach to the right things automatically. The refresh project for a given platform is linked to that platform instance, its lifecycle dates and its running cost, because the plan already knew which department owned it.

That is what stops the released plan from being generic. It is not a list of projects. It is a list of projects against named platforms with known owners, which is a very different thing to track.

The test

Take last year’s approved plan. Pick five projects from it at random. For each one, try to answer three questions from a system rather than from a person.

Did it start? What has it spent against what was approved? Where is it on the roadmap now?

If the answers come from three different tools, or from the project manager’s memory, the plan was rewritten the day it was approved. It just took until now to notice.

The bigger point

Planning cycles are not broken. They produce good decisions. What they mostly lack is anything that carries the decision forward intact.

A plan that is released into records rather than transcribed into documents cannot drift silently, because there is nothing to drift from. The approved version is the working version. Variance is a fact about the same object, not a discrepancy between two.

---

DemandFlow runs the medium term plan as a department-owned cycle: submit, review, allocate, lock and release. Release turns every approved project into roadmap lines and a phased budget in the finance tracker, against the platforms the department owns. AI Medium Term Planning covers the cycle, and FinOps is where the released budget is tracked against actuals.