Why most transformation programmes fail before they start

The majority of transformation programmes that fail do so predictably. Not because of unforeseeable complexity, not because of technology risk, and rarely because of a lack of budget. They fail because the conditions for failure were established before the programme was formally launched — in the way the problem was framed, in the governance structure that was designed, and in the assumptions that were never tested.

This matters for boards and executive sponsors because the window to change those conditions is narrow. By the time a programme is in flight, the structural issues that will eventually cause it to struggle are already load-bearing. Unwinding them mid-delivery is far more costly than resolving them at the start.

In this briefing:

• The three planning decisions that most commonly predict programme failure

• What effective programme governance looks like at board level

• The questions to ask before approving a business case

• How to create conditions for honest programme reporting

The planning decisions that matter most

Most programme planning is concerned with outputs — the project plan, the resource model, the technology selection, the delivery roadmap. These things matter, but they are downstream of three decisions that most frequently determine whether a programme will succeed.

The first is problem definition. Programmes that begin with an ambiguous or internally contested problem statement spend their early months relitigating scope rather than making progress. The question "what problem are we actually solving?" sounds straightforward. In practice, it is rarely answered clearly before the programme is approved.

The second is accountability structure. The governance model that is designed for a transformation programme should reflect the nature of the change being undertaken — not simply mirror the existing organisational hierarchy. When accountability is diffuse, decision-making slows, escalation becomes political, and the programme's momentum stalls.

By the time a programme is visibly in trouble, the structural issues that caused it are usually six to twelve months old.

The third is the realism of the business case. Business cases are typically optimised for approval rather than accuracy. Contingency is underestimated. Dependencies are understated. The benefits realisation timeline is compressed to make the return look better. Boards that approve business cases without stress-testing the assumptions create the conditions for the disappointment they will experience later.

What board-level governance should look like

The board's role in transformation is not to manage the programme — that is the executive's responsibility. The board's role is to ensure that the executive is managing the programme honestly, and that the organisation has the capability to deliver what it has committed to.

Effective programme governance at board level has three characteristics.

It creates conditions for honest reporting. Boards that respond to bad news with blame, or that allow programme sponsors to present selective updates, will receive the information they deserve. The programmes that surface problems early are the ones that have established genuine psychological safety around programme reporting — where raising a risk is valued, not penalised.

Key principle: The quality of information a board receives about a transformation programme is almost always a function of the culture it has created around delivering that information.

It maintains an independent perspective. Boards should have access to an independent view of programme health — not filtered through the programme team or the executive sponsor. This can be a formal independent assurance function, or it can be an experienced non-executive with relevant delivery expertise. Either way, the board needs a view that isn't subject to the same optimism bias as the programme itself.

It asks different questions at different stages. The questions that matter at programme initiation — is the problem well-defined? is the business case realistic? does the organisation have the capability to deliver this? — are different from the questions that matter during delivery — is the programme tracking against its key milestones? are the dependencies being managed? is the benefits realisation model still valid?

Questions to ask before approving a business case

The five questions below will not guarantee a programme succeeds. But they will surface the assumptions that most commonly prove to be false — and they will change the nature of the conversation between the board and the executive before the programme is approved.

1. What problem are we solving, and how will we know if we've solved it? If the answer is vague, the programme will struggle to maintain focus.

2. Who is accountable for delivery, and what authority do they have? Accountability without authority is theatre.

3. What does the contingency in this business case assume? Probe the assumptions behind the numbers, not just the numbers themselves.

4. What dependencies does this programme have on other parts of the organisation, and are those parts aware? Cross-functional dependencies are the most common source of programme delay.

5. What does failure look like, and what would we do if we saw it? Programmes that have never articulated their failure conditions are poorly equipped to recognise them.

Creating conditions for honest reporting

The single most impactful thing a board or executive sponsor can do for a programme in flight is make it safe to report bad news. This sounds obvious. It is surprisingly rare in practice.

Programmes that report honestly tend to be programmes where the sponsor has explicitly modelled the behaviour they want to see — by responding constructively to early warnings, by asking questions that invite risk disclosure rather than suppress it, and by making clear that their job is to remove blockers rather than reassign blame.

The inverse is also true. Boards and sponsors that punish bad news get good news — right up until the point where the programme cannot be recovered. By then, the honest reporting they needed six months ago is no longer available.

If you are overseeing a transformation programme and you are not hearing about problems, that is not evidence that there are none. It is evidence that the reporting environment doesn't make it safe to surface them.