Field Notes · Transformation

Why do transformation programmes fail?

Around 95% deliver nothing of significance. Everyone blames execution. Almost every time, the programme was doomed by a diagnosis made in week one.

Nick Ayton · 13 August 2026 · 7 min read

The short answer: the programme was wrong before anyone started work. Not badly run — wrongly aimed. The diagnosis was made in the first fortnight, usually by people with an interest in a particular conclusion, and everything after that was expensive, competent delivery of the wrong thing.

Execution gets the blame because execution is visible. Diagnosis is invisible, happens early, and by the time the programme is failing nobody wants to reopen the question that would invalidate two years of work and several careers.

Misdiagnosis is the whole story

Here is the sequence in almost every business I have seen. Performance softens. The board wants an answer. Someone produces a hypothesis quickly, because a slow answer looks like weakness. The hypothesis is usually one of four: we need a new system, we need to restructure, we need to cut cost, or we need better people in sales.

Notice that all four are actions, not diagnoses. Nobody has yet established what is actually slowing the business down. But the hypothesis now has momentum, a sponsor, and within a month a budget. From that point on, every piece of analysis commissioned is analysis in support of the chosen answer.

Then comes the part that guarantees failure: the organisation asks the party who will deliver the work to confirm the diagnosis. A systems integrator asked whether you need a new system has never once said no.

Optimising the dysfunction

The second failure mode is subtler and more common. The programme succeeds at what it set out to do, and the business gets worse.

This happens when you improve a process that should not exist. The approval step that was added after an incident in 2019 gets streamlined from eleven days to four — celebrated as a 64% improvement — when the honest answer was that the step served no purpose and should have been removed entirely. Multiply that across two hundred process improvements and you have paid a great deal of money to make a badly designed operating model run more efficiently.

You end up with a slicker version of the thing that was already killing you. It reports beautifully.

The system-as-answer trap

Technology programmes fail more often than any other kind, and always for the same reason. Systems encode the operating model you already have. They do not create one.

When you implement a new platform on top of a flow that nobody designed, one of two things happens. Either you configure the system to match your existing mess — in which case you have bought a very expensive photograph of the problem — or you adopt the system's standard process and discover halfway through that your business genuinely does need some of the things you were about to remove, at which point the customisation begins and the budget goes.

Every ERP horror story you have heard follows that fork. It is not a software problem and it is not an implementation partner problem. It is a sequencing problem: they fixed the system before they fixed the flow.

Governance theatre

By month six the programme has a steering committee, a RAID log, a benefits tracker and a weekly status report that is green. It stays green for a long time. It goes amber shortly before it goes red, and it goes red about four weeks before someone senior leaves.

This is not dishonesty, mostly. It is that the reporting measures activity — milestones hit, workstreams delivered, adoption percentages — and activity is not the same as outcome. Nobody in the governance structure is incentivised to ask the only question that matters, which is whether the underlying number has moved.

Ask it anyway. At every steering meeting: what has changed in the actual business metric since we started? If the answer requires a paragraph, nothing has changed.

What a good one looks like

Short. Aimed at constraints rather than processes. Measured against a baseline that existed before the work started.

• The diagnosis is independent of the delivery. Whoever tells you what is wrong should have nothing to gain from the answer.
• The problem is stated as one number. Not "improve customer experience" — the specific measure, its current value, and what it will be.
• The baseline is established first. If you cannot measure it before, you cannot claim it after. Most programmes cannot prove their benefits because nobody wrote down the starting position.
• It removes things. Good programmes delete steps, approvals, handoffs and reports. If the scope is entirely additive, it will add cost.
• It runs in quarters, not years. A hundred days is long enough to move something measurable. Anything longer and the business changes underneath the plan.

95% deliver nothing of significance, for the same reason: the diagnosis was never done.

Five questions before you sign anything

1. What number does this move, and what is it today? If nobody can state the current value, stop here.
2. Who produced that diagnosis, and what do they gain if we proceed? Independence is not a nicety.
3. What happens to that number if we do nothing? Some problems are self-correcting. Some are already accounted for.
4. Which constraint does this remove? Not which process it improves. Which bottleneck disappears.
5. How will we know in ninety days? If the first checkpoint is at month nine, you have already lost control of it.

The honest version of this conversation is usually short and slightly deflating, which is exactly why it does not happen. Everybody in the room would rather approve something than admit the problem has not been found.

If you want the diagnosis done properly and independently before you commit budget, that is the CCV Diagnostic — two to three weeks, fixed fee, and the findings are yours whether you like them or not.