- 1 Most transformation programme failures are caused by leadership and accountability gaps, not technology or vendor problems
- 2 Distributed ownership creates the appearance of governance without the substance of it
- 3 The conditions for failure are almost always visible before a programme starts — and rarely addressed
The failure rates attached to large technology and transformation programmes are one of the most frequently cited and least acted-upon facts in business management.
McKinsey’s research has consistently shown that a significant majority of large-scale IT and transformation programmes do not achieve their intended objectives. Other studies produce similar findings. The pattern is so consistent and so well documented that it is now the default expectation rather than a cautionary exception.
And yet businesses continue to launch significant transformation programmes with roughly the same governance structures, the same optimism, and the same avoidable mistakes that explain the failure statistics. The lessons are well known. They are not well applied.
Understanding why requires looking honestly at what these programmes actually fail on — because it is almost never what the programme’s subsequent narrative suggests.
What post-mortems typically say versus what they mean
When a transformation programme is wound down or significantly restructured, the stated explanations tend to focus on external factors: the vendor did not deliver, the technology was more complex than expected, the market changed, the original requirements were not clear enough.
These explanations are usually partially true. Vendors often do disappoint. Technology is often more complex than initially scoped. Requirements often are not clear enough at the start.
What these explanations obscure is the underlying governance failure that allowed those problems to destroy the programme rather than being managed within it.
Vendor delivery problems are manageable under strong programme governance. Technology complexity can be navigated with good architectural decision-making and appropriate contingency. Unclear requirements are surfaced and resolved more quickly in programmes with clear ownership and effective escalation. The external factors cited in most post-mortems are not the cause of failure. They are the points of entry for failure that was already waiting.
The actual cause, in the majority of cases, is that the programme lacked the leadership capability and the governance structures to manage the inherent complexity of transformation.
The distributed ownership trap
The most common structural failure in transformation programmes is distributed ownership.
Distributed ownership looks like governance. There is a steering committee with representatives from all affected parts of the business. There are workstreams, each with a named lead. There is a programme manager coordinating activity across the workstreams. There is a project board that meets regularly to review progress.
But in distributed ownership structures, the most important function of leadership — making difficult decisions quickly, under pressure, when the stakes are high and people disagree — is not assigned to any individual. It sits with the collective, which means it sits nowhere.
When a difficult decision arises — as it always does, in any complex programme — the steering committee needs to reach consensus. Consensus requires negotiation. Negotiation takes time. In the interim, the programme waits. Or, worse, the programme continues on assumptions that are not fully validated, and the disconnect compounds.
Multiply this pattern across the dozens of significant decisions that a major programme generates, and the result is consistent delay, escalating cost, and degrading quality.
The fix is not a better governance framework. It is a named individual with the authority, the accountability, and the capability to make those decisions. That person is usually the programme’s senior responsible owner — but in name only in many organisations. Making it real requires the individual having genuine authority to override departmental interests, resolve conflicts between workstreams, and maintain the programme’s direction under pressure.
Why ambiguity in objectives is so destructive
One of the patterns we see most consistently in programmes that struggle is that the original business case contains statements of intent that read as objectives but cannot actually be used to make decisions.
“Improve operational efficiency.” “Modernise the customer experience.” “Create a single source of truth for data.” These are aspirational directions, not objectives. They cannot be used to decide whether a specific design option is acceptable. They cannot be used to assess whether the programme is on track. They cannot be used to make the trade-off decisions that emerge when scope conflicts with budget or timeline.
Without objectives that are specific enough to create decision criteria, every significant design and delivery question becomes a negotiation about what the programme was actually for. Those negotiations are expensive, slow, and politically charged. They recur throughout the programme, each time draining energy and eroding momentum.
Getting objective clarity at the start — which requires more time and more difficult conversations than most programmes invest in it — is one of the highest-leverage interventions available. It is also one of the most consistently skipped.
The point at which recovery becomes very expensive
There is a point in every struggling transformation programme at which recovery becomes substantially more expensive than it would have been if the underlying issues had been addressed earlier.
That point is usually 12 to 18 months in, when significant investment has been made, when stakeholder patience is beginning to wear thin, and when the gap between the programme’s current trajectory and its original commitments has become undeniable.
Before that point, the governance failures that are driving the struggle are usually visible — in delayed decisions, in scope changes that receive insufficient challenge, in workstream leads who are reporting green while the underlying situation is amber or red. The challenge is that those signals are often managed upward as narrative rather than escalated as problems.
Leadership in the business needs to create environments in which problems are surfaced early and addressed honestly, rather than managed politically. That requires a level of psychological safety around programme reporting that many organisations have not established.
What good looks like
The transformation programmes that deliver against their objectives are not distinguished by having better technology or better vendors. They are distinguished by clearer ownership, more specific objectives, more honest reporting cultures, and — critically — the presence of someone at a senior level who maintains genuine accountability for the outcome from start to finish.
That person is rarely a full-time programme manager. They are an executive who has both the authority to make the decisions the programme requires and the technical understanding to evaluate whether the programme is making sound choices. In growing mid-market businesses, that is often the CTO function — either full-time or fractional, depending on scale.
Relevant service CTA: CTO as a Service — experienced technology leadership to own direction, manage delivery complexity, and hold transformation programmes accountable to the original business case.
Related posts: Why Mid-Market Businesses Struggle to Turn Tech Spend Into Results | How to Tell When Technology Is Starting to Hold the Business Back | What a Good CTO Should Fix in the First 90 Days
Sources
McKinsey – Delivering large-scale IT projects on time, on budget, and on value
HM Treasury – Orange book: management of risk — principles and concepts