The Standish Group has been measuring IT project failure rates for three decades. The numbers have improved since the catastrophic results of the 1994 Chaos Report, but the picture remains sobering: a significant proportion of large IT programmes fail to deliver on time, on budget, and to specification, and a meaningful minority are cancelled or restarted before reaching their objectives. In financial services, where programmes routinely run to tens or hundreds of millions of euros and are subject to regulatory deadlines that cannot be negotiated, the consequences of programme failure are particularly severe.

Despite this, the body of practical knowledge about how to recover a failing programme — as distinct from how to prevent failure in the first place — is surprisingly thin. Most project management literature is written for people running programmes from inception. Very little of it addresses the specific, different challenge of arriving at a programme that is already in trouble, diagnosing what is actually wrong rather than what people say is wrong, making the sometimes-devastating recommendation that follows from an honest diagnosis, and then leading the recovery. This article is about that challenge, and it draws on direct experience of doing exactly that — several times, in different organisations, under different kinds of pressure.

Why Organisations Admit Failure Late

Before discussing how to recover a failing programme, it is worth understanding why the failure is so often recognised late. The dynamics are consistent across organisations and sectors, and understanding them is essential to doing the diagnostic work correctly.

Programme teams in difficulty have powerful incentives to present optimistic reports upward. The programme manager's career prospects are tied to the programme's success. The team's morale depends partly on believing that the problems are temporary and manageable. The sponsor's credibility is invested in the original business case. Each of these individuals has rational reasons to minimise, explain away, or simply not look too closely at the evidence of serious difficulty. This is not dishonesty in the conventional sense — it is the predictable consequence of how programmes are governed and how performance is assessed.

The result is a consistent pattern: problems that are visible at the programme level are filtered and softened before they reach the steering committee; problems that reach the steering committee are filtered and softened before they reach the board; and the board receives reassurance until the point at which the situation has deteriorated to the extent that it can no longer be managed upward. By that point, the window for low-cost intervention has almost always closed.

"The moment a programme is officially declared in trouble and an independent review commissioned is almost never the moment the trouble began. It is, typically, the moment the trouble became impossible to conceal. The actual crisis usually started six to twelve months earlier."

The Warning Signals That Precede the Crisis

The practical implication of this pattern is that effective early intervention requires knowing what to look for at the level below the formal programme reporting. The following signals — observable before a programme is formally in difficulty, and frequently present six to twelve months before the crisis becomes visible — are drawn from direct experience across multiple recovery situations.

Governance Signal
Steering committee meetings increasingly focused on explaining the past rather than deciding the future. Agenda items are informational rather than decisional. Escalations are rare — not because there are no problems, but because the escalation path has become culturally blocked.
Velocity Signal
The programme's planned velocity — story points delivered, milestones reached, deliverables accepted — has been consistently below plan for multiple consecutive reporting periods, with explanations that change each period. The trend line, if you draw it, points clearly to a delivery date well beyond what the plan shows.
Scope Signal
The programme scope is described differently by different stakeholders. The sponsor's understanding of what will be delivered, the programme manager's understanding, and the technical team's understanding have diverged — sometimes significantly. Nobody has noticed, because nobody has recently asked all three parties the same question and compared the answers.
Team Signal
Turnover among experienced team members has accelerated. The people who understood the original design decisions have left, taking institutional knowledge with them. Their replacements are capable but are spending disproportionate time understanding what exists rather than building what is needed.
Dependency Signal
The programme's critical path runs through a dependency — a third-party supplier, a parallel workstream, a regulatory approval — that is behind schedule, and the programme plan has not been formally revised to reflect this. The assumption that the dependency will catch up is implicit rather than evidenced.
Quality Signal
Defect rates in testing are high and not declining as testing progresses. Workarounds are being accepted into the codebase to keep velocity metrics looking acceptable. Technical debt is accumulating faster than it is being repaid, and there is no formal plan to address it before go-live.

None of these signals, individually, proves that a programme is unrecoverable. Each of them, if present and unaddressed, substantially increases the probability that a formal recovery intervention will eventually be required. Their value is as early indicators that justify closer scrutiny — not as grounds for immediate escalation, but as reasons to ask harder questions.

The Independent Programme Audit

When the signals have accumulated to the point where leadership can no longer be reassured, the standard response is to commission an independent programme audit. Done well, a programme audit is one of the most valuable interventions available to a programme sponsor. Done poorly — which it frequently is — it produces a report that describes what everyone already knows, makes recommendations that are too generic to act on, and provides political cover for decisions that have already been made rather than genuine insight that informs new ones.

The difference between a useful audit and a useless one lies almost entirely in the quality of the diagnostic work. A useful audit does not begin with the programme documentation. It begins with conversations — structured, probing, conducted separately with the sponsor, the programme manager, the technical lead, key team members, the client or business representative, and, where possible, team members who have recently left. The divergences between these accounts — the things each person emphasises, the things each person avoids, the things that appear in one account and not in others — are where the actual diagnosis lives.

The documents — the plan, the risk register, the status reports, the change log — are examined after the conversations, not before. Their value at this stage is not as sources of information about the programme's status (which will be filtered and optimistic) but as evidence of the programme's governance: whether decisions are being documented, whether risks are being actively managed or merely listed, whether the change control process is functioning, and whether the plan is a living document or an artefact produced at inception and not subsequently maintained.

From Practice: The BCA EuroAIS Audit

In 2002 I was engaged to audit a pan-European core system development programme for a major automotive auction group, originally scoped as a four-week exercise. The programme was described to me as experiencing "some difficulties." What I found was a programme that had fundamentally lost its way: the architecture was inappropriate for the requirements, the team lacked the skills needed for the technical choices that had been made, working practices had broken down, and the relationship between the development team and the client had deteriorated to the point where productive collaboration was no longer possible. The 64-page report and board presentation recommended that the existing programme be stopped entirely. That recommendation was accepted. I was subsequently engaged to restart the programme — with a different methodology, a rebuilt team, and an architecture designed from the client's actual requirements rather than inherited from the previous attempt. The project delivered, on time and to budget. The core architecture built by that team became the foundation for all future systems within the group.

The Hardest Recommendation: When to Stop

The most important — and most frequently avoided — conclusion of a programme audit is the recommendation to stop. It is avoided for understandable reasons. It is expensive, embarrassing, and career-limiting for everyone associated with the programme. The sunk cost feels like a powerful argument for continuing. And the auditor who recommends stopping a programme that the organisation's leadership has publicly committed to is making an enemy.

Nevertheless, in some situations it is the correct recommendation, and making it clearly and with full supporting evidence is one of the most valuable services an independent reviewer can provide. The conditions under which stopping is the right answer are specific: when the programme's fundamental architecture cannot support the requirements it is intended to meet; when the relationship between the programme and its key stakeholders has broken down beyond what a change of personnel can repair; when the original business case has been overtaken by events to the extent that the programme, even if completed, would not deliver the value it was funded to provide; or when the accumulated technical debt is so large that completing the programme would produce a system that cannot be maintained, scaled or extended.

In these situations, the honest recommendation is not "stop this programme and abandon the objective" but "stop this programme and restart with a clear-eyed assessment of requirements, a methodology appropriate to the actual constraints, and a team with the right skills." The objective is typically still valid. The approach that was being used to achieve it is not.

The Five Dimensions of Recovery

When the recommendation is not to stop but to recover — to restructure and continue — the recovery work needs to address five distinct dimensions. Programmes that focus on only one or two of them, typically the most visible technical or schedule problems, consistently fail to sustain the recovery. The underlying issues reassert themselves within months.

Governance — Restore the Decision-Making Structure
Failed programmes almost always have failed governance: steering committees that meet infrequently, receive filtered information and make no decisions; escalation paths that are culturally blocked; and a programme board whose members do not feel genuinely accountable for outcomes. Recovery begins with rebuilding governance — not adding process overhead, but ensuring that the right people are making real decisions based on accurate information, at the right frequency, with clear accountability for follow-through.
Scope — Establish a Single Agreed Definition of Done
Scope divergence — the gap between what different stakeholders believe the programme will deliver — is present in almost every failing programme and is almost never addressed directly. Recovery requires bringing all key stakeholders into the same room, establishing what is actually in scope and out of scope, and producing a documented, signed-off scope statement that is subsequently enforced by a functioning change control process. This conversation is usually uncomfortable. It is also usually the most important conversation of the recovery.
Team — Assess Capability Honestly and Act on the Assessment
Team capability problems are the most politically sensitive dimension of programme recovery, and the one most often handled inadequately. The recovery leader must assess, honestly and individually, whether each key team member has the capability and motivation to contribute to the recovery. Where they do not, the decision must be made and implemented quickly — not because the individuals are at fault, but because a recovery programme cannot carry capability gaps that are impeding delivery. Alongside this, the knowledge gaps created by team turnover must be addressed through documentation, mentoring and structured knowledge transfer.
Stakeholder Trust — Rebuild Credibility Through Consistency
By the time a formal recovery is commissioned, stakeholder trust has usually been significantly damaged. Sponsors have been told things that did not happen. Business representatives have been promised delivery dates that were missed. The recovery leader's primary credibility tool is consistency: commit only to what will be delivered, deliver what is committed, and report accurately on both progress and problems. This sounds straightforward. It requires resisting the same pressures that caused the original programme team to over-promise, and it requires the courage to bring bad news promptly rather than managing it upward.
Technical Foundation — Address the Debt Before Building Further
Failing programmes accumulate technical debt — shortcuts, workarounds, deferred decisions and unresolved architectural questions — that makes everything more difficult as the programme progresses. Recovery requires an honest assessment of the existing technical foundation: what can be built on, what needs to be redesigned, and what needs to be discarded. The temptation to continue building on a flawed foundation — because it preserves the appearance of progress — is one of the most powerful forces working against a genuine recovery, and resisting it is one of the recovery leader's most important responsibilities.

The Reset: When to Declare a Clean Start

One of the most effective tools in programme recovery is the formal reset — a declared break between the old programme and the new one, with a new name, a new plan, a new baseline and, where necessary, a new team. The reset is not a cosmetic exercise. Its purpose is to create a moment at which the accumulated weight of the previous programme's failures — the damaged relationships, the broken commitments, the contested history — can be set aside and replaced with a new set of commitments made on the basis of current understanding rather than original optimism.

The conditions for a formal reset, rather than a continuation with modifications, are: when the programme's reputation with its key stakeholders has been damaged beyond what incremental improvement can repair; when the original plan is so far from reality that it has ceased to serve as a useful reference point; or when the programme needs to adopt a fundamentally different methodology from the one it has been using. In all these cases, the clean break serves a practical purpose — it allows the recovery to be assessed on its own merits rather than against the accumulated history of the previous programme.

The BCA EuroAIS experience illustrates this clearly. The original programme was not modified or redirected. It was stopped, its findings documented with full honesty, and a new programme was started with a different methodology — a bespoke combination of Extreme Programming, Rapid Application Development and DSDM, designed specifically for the commercial constraints of the project — a rebuilt team, and a clean architecture. The new programme delivered. The distinction between the two programmes was maintained throughout, because conflating them would have allowed the old programme's problems to contaminate the new one's credibility.

The First Thirty Days

The immediate actions of the first thirty days of a recovery engagement are more important than any plan for the months that follow. The recovery leader's credibility — and therefore their ability to lead the recovery at all — is established or undermined in this period. The priorities are: to conduct the diagnostic work personally and thoroughly, not through intermediaries; to have direct conversations with every key stakeholder, understanding their perspective and their concerns; to make a small number of commitments that can be met within the thirty-day period, demonstrating by delivery rather than assertion that the new approach is different; and to establish the governance structures through which the recovery will be managed before making public commitments about delivery.

What the first thirty days is not for: announcing a new plan, making delivery commitments, or communicating a recovery narrative to the wider organisation before the diagnosis is complete. Recovery leaders who arrive with a predetermined plan, derived from their experience of other recoveries rather than a diagnosis of this specific programme's problems, consistently produce recoveries that address the wrong things.

Questions for Boards and Programme Sponsors

Conclusion: The Programme That Admits Its Difficulty Is Already Recovering

The greatest obstacle to programme recovery is not the technical complexity of the problems, the scale of the rework required, or the difficulty of rebuilding stakeholder trust. It is the organisational and psychological resistance to admitting that a programme is in serious trouble — resistance that is built into the incentive structures of most programme governance models and that delays intervention until the cost of recovery is far higher than it needed to be.

The organisations that manage this best are those that have created environments in which early, honest reporting of programme difficulty is rewarded rather than penalised — where the programme manager who escalates a serious problem in month three is treated differently from the one who conceals it until month nine, and where independent review is treated as a governance tool rather than a signal of organisational failure. Building that environment is a leadership responsibility that sits well above the programme level.

For the recovery leader brought in when the difficulty can no longer be concealed, the work is what it has always been: listen before acting, diagnose before recommending, commit only to what will be delivered, and have the integrity to say what is true even when it is not what the organisation wants to hear. The programmes that recover are the ones where someone, at some point, was willing to do that.

Written by Peter Pitkin · Senior IT Consultant & Enterprise Architect · Germany
Views reflect practical experience of programme audit, recovery and turnaround across multiple sectors and organisations.