There is a document that exists in almost every procurement transformation programme. It is produced early, approved enthusiastically, and then — quietly, without anyone explicitly deciding this — never looked at again.
The business case.
Not the project plan. Not the risk register. Not the governance framework. Those get updated constantly. The business case — the document that justified the investment, named the benefits, and set the expectations against which success would eventually be measured — gets filed. And stays filed.
This is one of the most expensive habits in transformation.
How the gap opens
Business cases are written to get approval. That's their primary function, and everyone in the room knows it. The numbers are ambitious. The assumptions are optimistic. The risks are acknowledged but not dwelt upon. The timeline is aggressive in ways that experienced people in the room privately doubt but don't say out loud.
Then the programme starts. Reality arrives. The ERP landscape is more complex than the discovery phase suggested. Key stakeholders are less available than the RACI assumed. The data migration takes three times longer than planned. The first phase slips.
None of this is unusual. It is, in fact, normal. What is unusual — and should not be — is that the business case is never revised to reflect any of it.
Why nobody revisits it
The reasons are understandable, even if the consequences are not. By the time the programme is in delivery, the people who wrote the business case have moved on to other priorities. The sponsor is focused on go-live. The programme team is focused on the plan. Finance is focused on the budget, not the benefits.
There is also a political dimension. Revisiting the business case means acknowledging that the original numbers were wrong. That's uncomfortable for the people who approved it, the people who wrote it, and the people whose careers partly rested on it. Silence is easier. And silence, in most organisations, is what happens.
The benefits tracking workstream — if one exists at all — tends to be the first thing that loses resource when the programme gets into trouble. Which is precisely when it would be most useful.
What happens instead
Activity gets substituted for outcome. The programme reports on milestones delivered, modules live, users trained, purchase orders processed through the new system. These are real things. They are not the same as the benefits that were promised.
The savings figure in the business case was specific. The savings figure in the programme update is vague, or absent, or described in terms of "potential" and "run rate" that don't connect clearly to what was originally claimed. Nobody explicitly decides to obscure this. It just happens, gradually, as the gap between the promised and the real becomes too wide to bridge without a difficult conversation.
What good looks like
The programmes that get this right treat the business case as a living document — not as a contract to be honoured exactly, but as a commitment to be revisited honestly as reality changes.
That means building benefits tracking into the programme structure from the start, with named owners and defined measurement methodology. It means creating space — deliberately, in governance — for the honest conversation about whether the original assumptions are holding. It means being willing to revise the numbers when they need revising, and to explain why, rather than hoping nobody notices the gap.
It also means asking the question that almost never gets asked: was the value delivered by this transformation worth what it cost? Not the budget. The total cost — the internal resource time, the opportunity cost, the distraction from other priorities, the impact on the people who lived through the change.
Most organisations don't know the answer to that question. They should.
The transformation is over when the benefits are realised — not when the project is closed. Treating those as the same event is the most expensive assumption in procurement transformation.
