WHY PROJECTS FAIL BEFORE THEY START

When a multi-million-pound transformation collapses eighteen months after launch, post-mortems inevitably focus on execution failures: vendor underperformance, architecture complexity, or testing defects. But in over two decades of running large-scale, transformation programmes, I have found that often the root causes for failure go back to oversights during the project initiation.

1. The Polite Lie of Consensus

At initiation, nobody wants to be the party pooper. Business sponsors present an aggressive timeline driven by external market promises or board expectations. The delivery leads recognize inwardly that the date is unachievable given legacy technical debt, but rather than stating so directly, they accept the mandate with mental caveats: "We'll flag it in the risk log later."

A risk log is not a shock absorber for delusion. Once an unrealistic deadline is canonised in an executive deck, the organisation arranges itself around an impossibility.

2. Confusing Solutions with Problems

A surprising number of charters begin with the answer: "Implement Platform X across six business units." But Platform X is an intervention, not an objective. When pressed on the underlying problem, business units give contradictory answers:

• Division A believes the goal is cost reduction through automated headcount reduction.
• Division B believes the goal is premium customer experience requiring bespoke manual exceptions.
• Technology believes the goal is decommissioning legacy infrastructure.

Because the charter specified the tool rather than the problem, all three divisions believe they are aligned. The collision is simply deferred until the functional design phase.

3. Anti-Scope: What We Are NOT Doing

Every competent charter defines scope. Very few define anti-scope. In complex organisations, the default behaviour of stakeholders is to treat a new programme as an open cargo train onto which every deferred departmental pet project can be loaded.

If your initiation pack does not contain a brutal, explicitly agreed list of items that will not be delivered in Release 1, your scope is already unbounded.

The Cure: The Honest Pre-Mortem

Before approving the budget, gather the primary sponsors and delivery architects. Ask them one question:

The reasons people write down in that room are the actual risks of your programme. If you don't have the stomach to solve them on day one, think again before making large commitments.