Topic Hub

Project Failures

What project failure means

Project failure sounds binary — the bridge collapsed, the system was cancelled — but in practice it is a spectrum, and the ambiguity is itself part of the problem. A programme can miss its date and budget and still deliver enduring value: the Sydney Opera House, examined in our Sydney Opera House investigation, took roughly fourteen years instead of the projected six and cost approximately fourteen times its original estimate, yet became one of the most recognised buildings on earth. Conversely, a project can be delivered "on time" against a re-baselined schedule and still represent a profound failure of governance and estimation.

PIA works with a practical definition: a project has failed when the outcomes delivered diverge materially from the outcomes the approving authority was promised, in cost, time, capability or safety — and where that divergence was foreseeable with the information available at the time. That last clause matters. It separates genuine surprise from predictable failure that governance chose not to see.

Key questions the topic raises

Why do organisations repeat estimation errors that are documented in their own archives?
What distinguishes honest optimism from strategic misrepresentation in business cases?
How does a failing project sustain institutional support long after the evidence turns?
Which early-warning signals are reliable, and which are noise?
When is cancellation the right decision, and why is it so rarely taken in time?

The recurring causes

Across the investigations PIA has published — construction, healthcare IT, aerospace, financial trading systems — the causes of failure cluster into a small number of recurring patterns, which the Project Failure Pyramid organises from foundation to apex.

Estimation failure. Baselines are set before design maturity justifies them, and are shaped by the politics of approval. The NHS National Programme for IT, covered in our NHS NPfIT investigation, was dismantled after roughly a decade and expenditure reported in the region of £10 billion, having delivered only part of its original vision of a single national care records system.

Integration failure. Programmes composed of individually competent components fail at the interfaces. Denver International Airport's automated baggage system, examined in our Denver baggage investigation, worked in test conditions and failed in the complexity of the live airport; the conventional system eventually replaced it and the automated scheme was abandoned.

Governance failure. Assurance functions captured by the delivery organisation report reassurance rather than fact. This is the pattern behind Crossrail's late revelation, examined in our Crossrail delay investigation, that a December 2018 opening was not achievable — a conclusion that became clear to the public only months before the planned opening.

Integrity failure. Some projects fail because the premise was false. Our Theranos investigation examines a programme in which the technology did not perform as represented and governance failed to test the claim — a failure of due diligence by boards, partners and investors as much as of the company itself.

Why failed projects survive so long

Sunk-cost reasoning is usually blamed, but the mechanism is more institutional than psychological. Cancellation redistributes pain immediately and visibly: write-offs, inquiries, political accountability. Continuation defers the pain and spreads it. Every actor in the governance chain — sponsor, delivery body, contractor, funder — typically faces better personal incentives from continuing than from stopping. The Decision Quality Model addresses this directly by separating the quality of the decision from the comfort of the decision-maker, and by forcing explicit re-examination of continue/stop choices at defined evidence gates rather than allowing drift.

Reading the risk signals

The pre-failure signals are consistent enough to be used as a checklist: scope stable in documents but growing in conversation; contingency consumed early and re-labelled; experienced delivery staff leaving and being replaced by consultants; independent reviews commissioned and then narrowed in scope; success being redefined downward in increments. None of these is proof of failure. Three or more together, in PIA's experience, almost always are.

Featured investigations

Related frameworks

Project Failure Pyramid — the layered structure of failure causes
Decision Quality Model — re-testing decisions against evidence
Leadership Blind Spot Matrix — diagnosing what leadership cannot see

Frequently asked questions

What percentage of large projects fail?

Figures vary widely by definition and sector, and PIA cautions against quoting any single statistic as definitive. The robust finding across major studies is that overruns on cost and schedule are the norm for large capital and IT programmes, while outright cancellation is rarer but not rare.

Is project failure getting rarer as methods improve?

The evidence does not support comfortable optimism. Agile methods have improved software delivery at team scale, but large programmes still fail at the interfaces — integration, procurement, governance — where methodology has least reach. Crossrail and Berlin Brandenburg are twenty-first-century failures using modern management machinery.

What is the difference between a challenged project and a failed one?

A challenged project is over budget or late but delivering its intended capability; a failed one has either been abandoned, delivered materially less than promised, or met its targets only after re-baselining that concealed the original divergence. The honest test is comparison against what the approver was originally told.

Can a failing project be recovered?

Sometimes — Crossrail ultimately delivered an excellent railway, years late. Recovery typically requires a change of leadership, a reset baseline that is allowed to be honest, and governance restructured so that assurance is independent of the delivery team. Recovery without those three conditions is usually a slower route to the same outcome.

What should a board do when it suspects failure?

Commission genuinely independent assurance with a mandate to report to the board directly, not through the programme; freeze new commitments until the review lands; and explicitly rehearse the stop option so that continuation is a decision, not a default.

Last reviewed: 1 August 2026 · Author: Ramesh Dixit