Start with the number everyone quotes
“Around 70% of digital transformations fail” turns up in board papers, vendor decks and conference keynotes so often that it has become background noise. Before building anything on it, it’s worth knowing how thin it is.
The figure is older than digital transformation. A similar number was attached to business process reengineering in the 1990s, and to organisational change in general long before anyone said “digital”. In 2011, Mark Hughes went looking in the Journal of Change Management for the empirical evidence behind the 70% change-failure claim and found nothing that held up. Consultancies have since produced their own survey-based estimates, and BCG’s 2020 research put the share of digital transformations falling short of their objectives at around 70%. Useful, but survey results like these depend heavily on who answers and on what counts as “falling short”.
So I won’t lean on the number. The failures it points at are real, though, and anyone who has sat near a large programme will recognise how alike they look. In my experience most of them are lost well before delivery gets going. The design decides the outcome, and delivery is where it becomes visible.
A programme going nowhere
The programme below is a composite, drawn from several I’ve seen or been asked to look at, with identifying details changed.
A manufacturing group is eighteen months into a three-year modernisation, sold to the board as a new ERP core, a customer platform, a data warehouse and an automation layer sitting on top. It is well funded, with a senior sponsor, a credible integrator and a capable programme director who looks tired.
The steering committee runs like clockwork. The ERP migration is “amber, trending green”. The data platform is “green with dependencies”. The automation pilots are “green in principle, pending integration”. Each status is defensible on its own terms. And yet no part of the business operates any differently than it did eighteen months earlier. The old systems are still running. The new ones are being built alongside them, rehearsing for a go-live that keeps slipping further out.
By every input measure the programme had what it needed, and the board had done what boards are told to do: fund it properly, appoint a senior owner, and step back. The committee spent its time on resourcing, vendor performance and adoption. All three were problems in the usual quantities. None of them explained why nothing was moving.
Failing, or never viable?
Post-mortems tend to blame execution: the budget overran, scope crept, the vendor underdelivered, people resisted change. These things happen, and they’re usually symptoms.
The distinction that matters is between a transformation that is failing and one that was never viable. A failing transformation had a coherent design that eroded during delivery. A non-viable one contains a contradiction in its design that no amount of delivery discipline can resolve. Most of the struggling programmes I’m asked about are the second kind being treated as the first.
The two need opposite responses. A failing programme needs tighter delivery: clearer ownership, better governance, faster escalation. A non-viable programme needs its design reopened, and tightening the grip on delivery only gets it to the wall sooner. When a steering committee meets a stall with more status reporting, more oversight and more delivery rigour, it is prescribing the right medicine for the wrong illness. The organisation ends up optimising the descent.
I write a lot about execution accountability, so I want to be careful here. Accountability matters. It also only works when the thing people are held to can actually be delivered. Holding teams to a plan that can’t reach its destination burns out good people and teaches the organisation that transformation is a punishment.
The confusion survives because structural flaws can’t be seen from where transformations are governed. A board sees budget, timeline and RAG status. It doesn’t see the dependency architecture underneath, or that three workstreams have each made a sensible local decision that makes the whole undeliverable, or that the target operating model was written by people who will never have to run it.
A quick test
Three questions can separate the two conditions early, without waiting eighteen months to find out:
If every workstream delivered exactly to plan, would the outcome in the business case happen? If the honest answer depends on something nobody owns, the design is the problem.
What has the business stopped doing? If, a year in, the answer is “nothing”, look closely at the first pattern below.
What decision has been circling longest, and what kind of decision is it? Failing programmes tend to get stuck on how. Non-viable ones get stuck on what or who.
Four structural failure patterns
Risks are things that might happen. The four patterns below are properties of the design, and left alone they make failure close to certain however well the programme is run.
1. The deferred cutover
The most common pattern is the one in that steering committee: new systems built alongside the existing operation, with a single decisive cutover planned for the end. It feels safe because the running business is left undisturbed.
The trouble is that a parallel build has no forcing function. Nothing is switched off, so nothing has to be finished. The old world keeps working, so the new one never carries real load. All the value is deferred to a go-live that everyone has good reason to postpone, because so much now rides on it.
The alternative is to sequence the transformation as a series of irreversible steps, each of which moves a real slice of the business onto the new footing and retires the old one for that slice. Software engineers know a version of this as the strangler fig pattern, after the vine that grows around a host tree until the tree can be removed. The same logic works for processes and teams as well as code. This pattern is about sequencing: when value actually lands.
2. Unowned seams
Large programmes are divided into workstreams (ERP, data, customer, automation), and each gets an owner accountable for its own delivery. The dependencies between workstreams almost never get one, and that is where transformations are won or lost.
Every lead can report green on their own scope while the integration surface between them quietly becomes undeliverable. The individual systems are increasingly commodity work. The value sits in how they connect. A design with owners for the boxes and no owner for the arrows has been built for local success and systemic failure.
3. The borrowed operating model
A transformation is a change to how the organisation works. The target operating model is the real product, and the technology is the substrate it runs on.
In many struggling programmes, that operating model was designed by a strategy function or an outside consultancy, handed to a technology programme to implement, and never genuinely owned by the people who would run it. It is coherent on paper and unrecognisable on the shop floor. When it meets the exceptions, edge cases and local knowledge that never made it into the design, it gets quietly set aside, and the organisation goes back to working the way it always did, now with more expensive tools. A borrowed operating model is a rented conviction, and it rarely survives the first hard week.
4. Unfunded subtraction
The first pattern is about sequencing. This one is about budget and names.
Even programmes that plan incremental cutovers often fail to fund and staff the removal of what they replace. Switching off old systems, processes and integrations is hard, unglamorous and politically awkward, so it is assumed to happen by itself. With no budget line and no accountable person, it doesn’t. The organisation settles into a permanent hybrid: new capabilities delivered, old ones still running. Cost goes up. Complexity compounds. The integration debt the programme was meant to clear doubles, because every point-to-point connection now exists in two worlds. At that point the organisation has expanded its estate, and called it transformation.
What ties the four patterns together is timing. Each is a decision made, or left unmade, at the design stage. Each is cheap to fix in a planning document and ruinous to fix in year two. And each sits outside the view of a governance layer built to watch execution.
The same patterns, now with AI
This would be a history lesson if organisations weren’t running the same playbook again with AI.
Pilot purgatory is the deferred cutover under a new name. Dozens of proofs of concept run alongside existing processes, each promising, none carrying real load, none retiring a single step of the old way of working.
Agentic workflows reproduce unowned seams at machine speed. One agent drafts, another checks, a person approves, a system of record updates. Each component has an owner. The handoffs between them usually don’t, and when an agentic workflow goes wrong, the fault is almost always at a handoff.
Workflows imported wholesale from a vendor’s reference design are a borrowed operating model. And AI layered on top of human processes, without removing the human steps it was meant to replace, is unfunded subtraction: the organisation pays for both and gets the speed of neither.
The good news is that the questions transfer directly. Before approving an AI programme, ask what it will switch off, who owns the handoffs, whose workflow it really is, and what has been budgeted for removal.
Turning the programme around
Back to the composite. Restarting the programme would have been the wrong move, as it usually is. A restart throws away accumulated knowledge and re-triggers the same design flaws with fresh enthusiasm.
The programme director’s first reaction to the diagnosis was defensive, which was healthy and fair. The decisions that sank the programme had been made before he arrived, in a business case written to be approved rather than delivered.
Three things changed. First, the team found the smallest slice of the business that could move entirely onto the new footing (one product line in one factory, with its order-to-cash flow) and set a fixed date to switch off the old systems for that slice. For the first time, something had to be finished because something else was being turned off.
Second, a dependency owner was appointed: a single senior engineer with no delivery scope of her own, accountable only for the integration surface between workstreams. The arrows finally had a name attached.
Third, the borrowed operating model went to the people running that factory, to rewrite in their own terms while keeping the strategic intent. Less than half of the original survived. The rest had been fantasy.
The date did most of the work. Decisions that had circled for months were made within a fortnight, because the alternative was operating with nothing.
The dependency owner was harder. Two workstream leads saw her role as an intrusion into their authority, and it took an uncomfortable intervention from the sponsor to make clear that owning the seams meant something different from second-guessing the boxes. The technical design was accepted long before the people around it were.
Risks and trade-offs
These four patterns close off the most common ways to fail. They don’t guarantee success. A transformation can get all four right and still be derailed by a market shift, an acquisition or a new CEO with different priorities. Structural soundness makes success possible, and that’s all it does.
The approach also has a real cost. Incremental, decommissioning cutovers show headline progress more slowly than a parallel build, and they disturb the running business sooner. A genuine cutover, even at small scale, means operational risk on a real date. Boards that want the appearance of momentum will often prefer the parallel build, right up until it fails. Choosing the sound path takes political capital, and not every sponsor has enough.
The dependency owner role has its own failure mode. Given to someone without the seniority to hold their ground, or allowed to grow into a coordination bureaucracy, it becomes one more layer of overhead that slows delivery and owns nothing. The intervention is one credible person accountable for the seams. Organisations that hear “set up a dependency function” instead reliably make things worse.
Finally, much of this is overkill for a genuine like-for-like modernisation, a technology upgrade with no change to how the business operates. Telling the two apart matters, and many organisations get it wrong in the other direction, labelling a tooling upgrade a transformation to justify the budget. That mislabelling is itself a design problem.
Where the scrutiny belongs
Most transformation failure is settled in the room where the business case is approved. Once a programme is in flight, execution largely determines how quickly and how expensively the design plays out. That is why extra governance so rarely rescues a stalled programme: governance acts on execution, and the problem sits upstream of it.
For senior leaders, this means moving scrutiny earlier. The instinct is to govern hardest during delivery, when money is being spent and risk feels closest. The hour that matters most comes before approval, spent interrogating the design with four questions:
What will this switch off, and when?
Who owns the seams between workstreams?
Whose operating model is this, really?
What have we funded and staffed to remove?
The organisations that beat the odds, whatever the real odds are, tend to be the ones willing to send a business case back.