Most failed digital transformations were not derailed by technology.

They were derailed by a gap between what was promised at the start and what was achievable in reality. That gap existed from day one, embedded in the business case, and neither the sponsors nor the delivery team chose to address it directly until the programme was already in trouble.

The stakeholder expectation problem in digital transformation is routinely framed as a communication challenge. Better updates. More frequent steering committee engagement. Clearer reporting. These are sensible practices. They are also, in most cases, insufficient, because the problem is not that stakeholders were not kept informed. It is that they were kept informed using numbers and timelines that were not honest about the uncertainty behind them.

That is an honesty problem, not a communication problem. And the fix for it happens at the beginning, not during delivery.

The Business Case That Everyone Signed Off On

Digital transformation business cases are almost universally optimistic. Not because the people who write them are dishonest, but because the incentive structure in most organisations rewards ambition and penalises conservatism. A realistic business case, one that acknowledges uncertainty ranges, models downside scenarios, and commits to fewer benefits with higher confidence, is harder to get approved than an ambitious one. So the ambitious one gets written.

The consequence is that the business case becomes a set of commitments rather than a set of hypotheses. By the time the programme moves into delivery, the numbers in the original document are treated as targets rather than as estimates, even when the assumptions underlying them have already been revised. The expectation gap was always there. It was just papered over.

BCG’s analysis of more than 850 companies found that only 35% reach their stated digital transformation goals. Gartner’s October 2024 survey of more than 3,100 CIOs found only 48% of digital initiatives meet or exceed their business outcome targets. The gap is not primarily a delivery capability problem. It is a framing problem.

Scope at Altitude

The second structural cause of expectation gaps is scope defined at too high a level of abstraction. Transformation programmes are typically scoped during a phase when the delivery architecture is not yet understood, which means scope boundaries are drawn based on intent rather than on a detailed model of what delivery will actually require.

Both sides, sponsor and delivery team, leave the scoping phase with genuine but different understandings of what is included. Neither party is misrepresenting anything. They simply have not gone deep enough to discover the ambiguity. That ambiguity is then carried into the contract, into the programme plan, and eventually into the steering committee deck, where it will surface as a scope dispute at the moment least convenient for everyone involved.

The fix is not to define scope more tightly in the abstract. It is to define scope at a level of specificity that forces the ambiguity into the open before commitments are made. That is harder and slower than moving quickly to contract. It is also significantly less expensive than managing the dispute six months into delivery.

What the Programme Board Actually Hears

Stakeholder management, in practice, often means giving senior sponsors the confidence to remain supportive rather than giving them the information they need to make good decisions. Status reporting in large programmes tends to converge toward reassurance. RAG ratings stay amber longer than conditions warrant, because the consequences of going red feel disproportionate in the moment. Risks that have materialised are carried as risks rather than re-classified as issues. Forecasts are revised gradually rather than reset to reflect the actual picture.

This is not cynical. It is human. Nobody wants to be the person who delivers bad news. The programme team has worked hard. The delays feel temporary. There is always a reasonable argument for holding the line a little longer.

The problem is that by the time the gap between expectation and reality is reported honestly, it is too large to close without a significant reset. The reset conversation is much harder than it needed to be, because the sponsor was not kept informed of how the gap was developing.

The Expectation Reset Conversation

When the gap surfaces, and it always surfaces, the response that preserves the programme is not to defend the original business case. It is to reframe the conversation around what is still achievable, with what degree of confidence, on what timeline. That requires the delivery team to be willing to put a revised view in front of the sponsor, acknowledge that the original framing was overoptimistic, and propose a credible path forward.

That conversation is significantly easier when the relationship between sponsor and delivery has been built on honest reporting from the start. It is significantly harder when the sponsor has been receiving optimistic status updates and now feels misled, not because anyone intended to mislead them, but because the communication was shaped by the desire to maintain confidence rather than the obligation to maintain accuracy.

Less Ambiguity, Earlier

The conditions that produce the stakeholder expectation problem are well understood: optimistic business cases, scope defined at altitude, and status reporting shaped by the incentive to maintain confidence. None of these are inevitable.

The organisations that manage stakeholder expectations well are not the ones with the best communication strategies. They are the ones with the discipline to be specific about uncertainty before programmes begin, to define scope at a level of detail that surfaces ambiguity early, and to build reporting practices that give senior sponsors the information they need to make real decisions rather than the reassurance they want to maintain support.

Less ambiguity earlier. Fewer numbers presented as certain when they are estimated. Fewer commitments made before the delivery architecture is understood.

That is the fix. It is harder to sell at the outset and significantly easier to live with throughout delivery.