Why most change programmes fail

A programme I watched up close spent two quarters replacing a Slack channel and a Monday stand-up that already worked, and lost the goodwill of the two teams who had built the fix themselves. Nobody in the steering committee called it a failure. That is why most change programmes fail: not resistance, not weak sponsorship, not thin communication, but a change designed against the operating reality instead of the one the deck described.

Why change programmes fail before the kickoff deck

Change programmes are designed against the operating story, not the operating reality. The story is what leadership believes is true. The reality is what an engineer in the third sprint of a delayed migration actually does on a Tuesday, and the two are almost never the same document.

The story says the new process improves handoffs between product and engineering. The reality is that those two teams already solved their handoff problem eighteen months ago with a Slack channel and a stand-up nobody put in a deck. The programme rolls in, replaces the working fix with a ticketing workflow nobody asked for, and files the resulting slowdown under "change fatigue".

It is not fatigue. It is friction, and friction has a cause. Somebody designed a solution to a problem that had already been solved, by people who were never asked what they had already solved. This is why post-mortems on failed programmes read the same way every time. Sponsorship was there. Comms were "extensive". The deck had a burning-platform slide and a RACI. And it still failed, because none of that touches the actual defect: the programme was built from an org chart and a model of how work happens, not from how work actually happens. A carpenter does not argue with the wood. They read it first. This is the whole of the grain metaphor for reading your organisation, applied to the one moment it matters most.

The number is a diagnosis problem wearing a communications costume. You do not lower it with a better comms plan or a stronger sponsor. You lower it by reading the operating reality before you design the change. Three patterns account for most of the failures, and each one is a way of skipping that read.

Pattern one: the cut runs against the grain

Every organisation has a grain: the informal paths trust and tacit knowledge actually travel along. It rarely matches the org chart. The account manager who quietly resolves four in five escalations does it through a personal relationship with someone two levels down in ops, not through the process map. The engineer everyone routes the hard problems to is not the team lead. She is the person who has been there nine years and remembers why the third microservice exists.

Restructures cut against this constantly, because the grain is invisible to anyone reading a chart from the top. You move the account manager to a different vertical to "balance capability", and the escalation path that quietly held a client relationship together for three years leaves with her. Nobody documented it, because it was never a process. It was trust, and trust does not show up on a slide.

The tell for this pattern is simple. If the design started from an org chart, it has almost certainly missed the grain, because the grain is the part the chart cannot draw.

Pattern two: scale arrives before craft is earned

The second pattern is rolling out a process before it has earned the right to exist. A pilot works in one team, in one context, with one particularly capable manager holding it together through sheer competence. Leadership sees the pilot metrics, likes them, and mandates the same process across twelve teams next quarter.

What actually made the pilot work rarely makes the slide. It was the manager's judgement calls, the exceptions she quietly allowed, the version of the process that existed in her head and never got written down because writing it down felt like overhead when the thing was still small. Scale that process without her judgement embedded in it and you have scaled the paperwork, not the outcome. This is the same failure that kills AI programmes, where a demo that worked in October is dead by January. It is worth reading how AI pilots stall at production for the same shape in a different costume: the pilot proves a thing can be done once, and production proves the organisation can absorb it happening every day.

Craft has to be earned before it is replicated. That means running the pilot long enough to know which parts are genuinely portable and which parts are one person's competence disguised as a system. Most programmes skip this because the fiscal year has a Q3 deadline and the pilot has six weeks of runway. The rollout happens on the calendar's schedule, not the process's. The demo worked. The rollout didn't.

Pattern three: the deck stands in for the decision

The third pattern is mistaking a deck for a decision. Leadership teams will spend six months and a six-figure fee producing a beautifully sequenced roadmap, complete with workstreams, milestones, and a target operating model diagram with arrows pointing in all the satisfying directions. Then nothing changes, because the deck was never a decision. It was a description of a decision someone hoped to make later, dressed up to look finished.

A real decision closes off options. It says: we are doing this, which means we are explicitly not doing that, and here is who owns the trade-off when the two collide in week four. A deck that has not forced anyone to give something up is an inventory of possibilities, and inventories do not survive contact with a delayed migration or a client escalation. You can tell the difference in the room. A real decision produces at least one person unhappy about what they are losing. A deck produces universal nodding, because nobody has actually been asked to give anything up yet. The board wants a roadmap. You don't have one. What the roadmap is standing in for is the difference between strategy and operating reality: the deck is a story about the future, and a story is not a plan until it has cost someone something in the present.

Laid side by side, the three patterns share one spine. Each is a way of designing from the story and skipping the read.

What reading the grain before the cut looks like

None of this is an argument against structure, process, or ambition. It is an argument about sequence. Diagnose before you design. That is the whole move, and it is boring, which is exactly why programmes skip it in favour of a burning-platform slide.

Reading the grain means interviews with the people actually doing the work, not their managers describing it secondhand. It means tracing where decisions really get made under pressure, not where the process map says they should. It means running the pilot long enough to tell the difference between the process and the person carrying it. Done properly, the read surfaces the informal fixes that already work, the relationships the chart cannot see, and the constraints the operators live with daily and nobody wrote down.

This is slower at the start. It is faster everywhere else, because you stop paying the rework tax that eats every programme built on the operating story instead of the operating reality. The £2,000 Grain Audit exists for exactly this reason: two weeks, one process read end to end at click level, before anyone designs the cut. It is the cheapest insurance against joining the 70%. And it is the same discipline the best operators run continuously, not just at kickoff, which is what separates a one-off transformation from real operating leadership.

Before you approve the next programme

Most change programmes are approved on the strength of the deck, which is the one artefact guaranteed not to tell you whether the design read the grain. Run the programme through this before you sign the kickoff, not after the first slipped milestone.

Resistance, when it comes, is the cheapest diagnostic you will ever get. It is usually telling you the programme missed something the operators on the ground already know. Read it as information, not obstruction, and it points straight at the part of the grain the design cut across. The programmes that clear the 70% are not the ones with the best comms. They are the ones that read the wood before they made the cut.