Why most transformations fail (and the few things that actually work)

I have been involved in transformation programmes for most of my career. I have seen some work. I have seen more fail. The ratio is not flattering.

The post-mortems on failed transformations tend to blame the same things: lack of executive sponsorship, poor change management, technology that didn’t deliver. These are true, as far as they go. But they’re symptoms. The root causes are less comfortable.

The transformation is the strategy, not a programme of it

Most organisations treat transformation as a discrete programme with a start and end date. The technology gets delivered. The “change” gets managed. The programme closes. Six months later, people are using the old spreadsheets again.

The organisations where transformation actually takes hold treat it as a continuous operating model shift — not a project to be delivered and signed off. The difference in framing changes everything: governance, resourcing, measurement, and what success looks like.

The business case is written to get approval, not to guide delivery

I have reviewed hundreds of business cases. Almost all of them are written to get investment approved. The benefits are optimistic. The risks are understated. The delivery assumptions are best case.

Then the programme starts and the real world arrives. But the governance framework is still tied to that original business case — so you spend the next two years managing against projections that were never realistic, explaining variances rather than making decisions.

Good transformation governance separates the investment case from the delivery framework early. The case gets you started. The delivery framework has to evolve with what you learn.

The people who know where the bodies are buried aren’t in the room

Every organisation has people who know how things actually work — which processes are workarounds, which dependencies aren’t documented, which teams will resist and why. They’re usually not the people in the transformation steering group.

The organisations that avoid the worst delivery surprises invest heavily in operational discovery before they start designing solutions. Not a two-week current-state assessment. A genuine, sustained effort to understand how work actually gets done, by the people who do it.

Change management is an afterthought, always

I know this because I have said “we need to bring in change management resource” at roughly the midpoint of every programme I have ever worked on. By then, the design decisions are made. The technology choices are locked. The change manager is handed a solution and asked to make people want it.

This doesn’t work. Change capability needs to be in the room when you’re deciding what you’re building and why — not when you’re trying to land it.

The few things that actually work

A clear problem statement that people believe in. Not a transformation vision. A specific, honest articulation of the problem you’re solving and why it matters.

Governance that makes decisions, not reports on status. A steering group that meets to resolve issues and make calls — not to receive RAG updates.

A delivery team with real authority. Programme managers who can say no, change scope, and escalate effectively. Not coordinators.

Measurement of outcomes, not outputs. Not “we delivered the system.” What changed because of it?

And the thing nobody wants to hear: time. Real organisational change takes longer than any business case will tell you. Build that into your expectations from the start.