Why most transformations fail at execution — not strategy

The uncomfortable number

Across large-scale operating and procurement transformations, roughly six or seven out of ten programs don’t deliver the intended outcomes within the original scope or timeline. Not because the strategy was wrong — but because execution drift quietly accumulates until the original intent is unrecognisable.

What’s interesting is that most of these programs still “finish”. They just finish as something smaller, slower, and more fragmented than designed. The strategy was agreed. The budget was spent. The workstreams closed. And yet the results aren’t there.

The most common question we hear from leadership teams is some version of: “We’ve invested heavily in this — why isn’t it working?” The answer, almost universally, is execution architecture.

The three breakdowns I’ve actually seen

1. Decision latency disguised as governance

Everything looks controlled on paper. But in practice, decisions sit in inboxes or steering committees for weeks. By the time approval comes, the operational context has already changed. The governance structure that was meant to provide control becomes the thing that kills momentum. Teams stop bringing decisions forward because they know nothing will happen quickly.

2. Local optimisation beating system optimisation

In a multi-site or trans-Tasman setup, teams in different regions naturally optimise for their own constraints. The result isn’t resistance — it’s divergence. Processes slowly fork until the “standard model” becomes theoretical. Nobody is sabotaging the transformation. Everyone is just solving their local problem. After 12 months, you have six regional variations of a model that was supposed to be one.

3. Systems integration debt underestimated early

The transformation is designed around the process, not the actual data and system friction underneath it. When the workflows hit real systems, manual workarounds quietly reappear and scale with the program. What was meant to be automated ends up more complex than before. The workaround becomes the process.

What leaders almost never understand upfront

Most leaders assume transformation is a design problem. It’s not. It’s a behavioural and decision-speed problem under operational pressure.

If you don’t actively design for how fast decisions will actually be made at the edge of the organisation — not how fast they should be made in theory — the strategy will degrade no matter how strong it looks at the top.

The organisations that execute well don’t have better strategies. They have better execution architecture: clearer accountability, faster decision rights, and governance that enables rather than blocks.

Three questions to ask before you start

• How fast can a decision actually be made at the operational level — not in theory, but in practice?
• What happens when two regions interpret the same process differently? Who resolves it, and how fast?
• Where are the real system integration constraints — not the assumed ones?