9 Reasons Transformation Programmes Fail After Approval
The board said yes to a set of outcomes. What gets delivered is a set of capabilities. The gap between those two things is where the money goes.
- Programmes that underdeliver usually deliver everything they were asked to build. What they do not deliver is the outcome the board approved, which was never anyone’s job.
- The nine reasons below all take hold after approval, in the space between a case that promised benefits and a plan that only tracks delivery.
- The position worth holding is not “the programme is on track”. It is “the benefits are being tracked separately, by someone who is not the delivery lead”.
The board approved a case that promised specific commercial outcomes. Eighteen months later the programme has delivered, and those outcomes have not arrived.
This is not usually a delivery failure. The technology works, the milestones were met, the team was competent. What was delivered is a set of capabilities. What was approved was a set of results, and nobody was made accountable for the distance between them.
That distance opens after approval, quietly, through a sequence of individually reasonable decisions. Scope gets managed. Difficult things get deferred. Governance tracks what is easy to track. The programme succeeds on its own terms while the case it was funded against quietly stops being the measure.
The nine reasons below describe how it happens. Each one is visible while a programme is running, if anyone is looking for it.
Governance tracks delivery, because delivery is what can be tracked
The steering group meets. The pack shows milestones, spend against budget, risks and issues, resource position. All of it accurate and all of it about delivery.
What the pack rarely shows is progress against the benefits the case promised. That is harder to report, because benefits arrive later and depend on things outside the programme’s control.
So the programme is steered on the measurable thing rather than the important one. A programme can be entirely green for eighteen months and still land nothing the board recognises. The fix is a benefits section in every pack from the first meeting, even when the honest entry is “not yet visible”.
The benefits belong to functions the programme cannot direct
The case promised improvements in sales conversion, service cost, working capital. Those numbers belong to the sales director, the operations director and the finance director.
The programme cannot make any of them happen. It can deliver a capability those functions could use. Whether they change how they work, adopt it properly and hold themselves to the number is entirely up to them.
Yet the programme is held accountable for the benefits. That accountability is misplaced and everyone knows it, which is why it quietly gets dropped. The fix is a named functional director committed to each benefit line, tracked separately from delivery.
Scope gets managed by deferring the hard, valuable parts
Every programme runs into pressure. The response is to protect the date by moving things out. What moves is what is hardest and least visible — the integration nobody wants to touch, the process change that needs organisational effort, the reporting layer.
Those are frequently the parts the benefits depended on. The easy, demonstrable scope survives; the load-bearing scope goes to phase two.
Phase two arrives with an exhausted team, a spent budget and an organisation needing stability. It gets deferred, then quietly stops being discussed. The fix is to identify the benefits-bearing scope at approval and protect it explicitly, so that something else has to give instead.
The programme delivered what it was asked to build. Nobody was asked to deliver what the board actually approved.
Nobody designed how the business would actually run
The technical design is documented in detail. Platforms, integrations, data flows, sequencing. It is specific enough to build from.
The description of how the business will operate afterwards is usually at vision level — principles, target capabilities, strategic intent. Nothing like the same standard.
So the technology gets built to specification and the way of working gets built by accumulation, through hundreds of small decisions made during configuration and delivery. Eighteen months later the business is running in a way nobody designed. This is the reason most of the others exist.
The change budget was set before anyone counted who was affected
The change line in the case was sized early, often as a percentage of the total, before anyone worked out how many people would have to work differently.
What that number has to cover is substantial: new decision rights, changed measures, jobs that alter shape, managers coached on running a different kind of team, and the people who do not want any of it. Training is the smallest part.
Under-funded, the change work happens thinly and adoption stays shallow. People use the parts that suit them and work around the rest, which is a rational response. The fix is to size this against the number of people affected, and to do it before the board sees a total it will later have to increase.
A programme can be green for eighteen months and still land nothing the board recognises.
A free Executive AI Opportunity Assessment. Forty-five minutes, online, with your leadership team. We arrive with a model of how firms in your sector make money and where AI has moved those numbers — and you tell us where it is wrong.
Book a free assessmentGo-live becomes the objective, and it was only ever the halfway point
Once a date exists, everything organises around it. Steering tracks readiness. The board asks whether it will hold. The whole programme is measured on arriving.
Reaching it is a genuine achievement and it is not what the money was for. The benefits arrive months later, if the process changes stuck and people adopted them.
But at go-live the team disperses, the budget closes, and accountability ends. The fix is to keep a named owner and a small budget alive for twelve months afterwards, reporting benefits against the case. Almost no mid-market firm does this, which is why almost none know what their programmes returned.
Milestones, spend, risks and resources. Reported fortnightly and largely accurate.
Harder to report, arriving later, depending on functions outside the programme.
Moved to phase two under pressure. Frequently the part the benefits depended on.
Team disperses, budget ends, and the benefits arrive months later with nobody watching.
This describes a pattern rather than a measured dataset. The test worth running is your own: take your last completed programme and ask what it returned against the case that funded it. If nobody can answer within a day, that is the finding.
The case was optimistic and nobody said so at the time
Cases are written to be approved. Benefits get stated at the top of the plausible range. Costs at the bottom. Timelines assume things go well. Everyone in the room knows this and nobody says it, because saying it makes you the obstacle.
So the programme starts against a case it was never realistically going to meet, and the variance that follows gets attributed to delivery rather than to the estimate.
The fix is a stated confidence range at approval rather than a single figure, and a board culture where saying “this looks optimistic” is treated as diligence rather than obstruction. That is a cultural change more than a process one, and it starts with the chair.
Three questions for the next programme review
- Show us the benefits section of the pack. If there isn’t one, the programme is being steered on delivery alone.
- For each benefit in the original case, who is the functional director committed to it — not the sponsor? If the answer is the same name each time, nobody is.
- What has moved to phase two, and which benefits depended on it? That is where the case quietly changed.
The people who would have to work differently were consulted, not committed
Workshops happened. Directors were engaged. Their input shaped the design. Everyone signed off the approach.
What rarely exists is a written commitment from each director to the specific changes their team will adopt, the timing, and what they will be measured on afterwards. Consultation gathers opinion; it does not create obligation.
So eighteen months later functional teams discover they are being asked to work in a way they never agreed to, and the resistance that follows gets read as a change management problem. It is an approval problem arriving late.
Nobody owns the outcome once the programme ends
The most structural of the nine. The sponsor is accountable until go-live. The delivery lead until handover. After that the line organisation runs it.
But nobody is made responsible for watching whether it is still being run as designed, spotting the drift back to old habits, or deciding what to do about it. Six months on, the way the business works differs materially from the way it was meant to, and no single decision caused it.
The fix is custodianship: a named owner of the new way of working, with authority, for at least a year after the programme closes. It is a small appointment and it is the difference between a change that holds and one that quietly reverses.
What this means
None of these nine are delivery failures. Most programmes deliver competently what they were asked to build. The problem is that what they were asked to build and what the board approved were never the same thing, and nothing in the governance closed that gap.
The pattern is consistent. Benefits belong to functions the programme cannot direct. Governance tracks what is easy to track. Scope gets protected in the wrong order. Accountability ends at go-live, months before the outcomes were ever going to appear.
The economics of fixing it are unusually favourable, because almost none of it costs money. Naming a director per benefit line takes a meeting. Adding a benefits section to the pack takes a template change. Keeping an owner alive for a year after close costs a fraction of the programme.
Which is the argument in one line. Change the work before you change the technology — and make somebody accountable for the outcome rather than the output, because those are not the same job and only one of them was in the plan.
What did your last programme return, against the case that funded it?
Forty-five minutes with your leadership team, online, at no cost. We bring a working model of how firms in your sector make money and where AI has moved those numbers. You tell us where it is wrong. Then we tell you what we think — including “don’t invest”, if that is the honest answer.
Book a free assessment45 minutes · online · no cost · nothing to prepare
Continue reading
10 Questions Boards Should Ask Before Approving the Next Transformation
The same gaps, caught while the answers are still cheap.
For finance and IT10 Reasons ERP Programmes Stall in the Mid-Market
The same pattern, in the programme type where it costs most.
For finance directors7 Governance Failures Quietly Undermining AI Returns
Why the return is rarely defensible when someone checks properly.
