How to Rescue a Failing IT Project

Most technology projects do not fail suddenly. They fail gradually, then all at once.

The warning signs accumulate over months - milestones that slip by a week, then two, then a month; cost variances that get explained away in steering committee reports; vendor relationships that have become transactional and adversarial; a delivery team that has stopped being honest with its sponsors because honesty stopped being safe.

By the time a program is formally declared to be in trouble, the problems that caused the crisis are usually six to twelve months old. The immediate trigger - a missed go-live, a budget blowout, a sponsor who has lost confidence publicly - is rarely the root cause.

This matters because recovery planning that focuses on the immediate trigger, rather than the underlying causes, does not work. It produces a plan that addresses the symptom while the disease continues to progress.

The first thing to do: stop digging

The most important decision in the early days of a recovery engagement is to stop committing to things you cannot deliver.

Failing programs have usually accumulated a backlog of commitments - dates, deliverables, cost estimates, scope items - that were made optimistically or under pressure and cannot actually be met. Each new commitment that is missed erodes a little more of the stakeholder confidence that the recovery depends on.

The hard conversation that must happen early is with the program sponsor: the current plan is not achievable, and continuing to report against it is making the situation worse. This conversation is difficult, but it is necessary before any other recovery work can proceed.

Conduct a structured health assessment

Before you can build a recovery plan, you need an honest picture of where the program actually is. This means working through a structured assessment across five dimensions:

Delivery confidence. What is the realistic probability of the current plan being achieved? What are the specific blockers? What assumptions are being made that are not supported by evidence?

Governance health. Are the governance structures actually working? Is the steering committee receiving accurate information? Are decisions being made at the right level? Is there a clear line of accountability?

Stakeholder alignment. Who still has confidence in the program? Who has lost it? What do the critical stakeholders actually need to see to re-engage? What has damaged their confidence specifically?

Financial position. What has actually been spent? What is committed? What is the realistic cost to complete? How does that compare with the approved envelope?

Vendor performance. Are vendors meeting their contractual obligations? Are there contractual remedies available that have not been used? Is the relationship recoverable, or does it need to be restructured?

The output of this assessment is a written finding. Not a set of slides, not a verbal summary - a written document that sets out the actual state of the program, the causes of the current situation, and what recovery will require. This document becomes the basis for every subsequent conversation.

Be honest about the options

Recovery planning is not the same as schedule compression. You cannot fix a program that is twelve months behind schedule and twenty percent over budget by asking the team to work harder or the vendor to reduce their rates.

The honest options are usually three:

Rescope and replan. Reduce the program to what can actually be delivered within the remaining budget and a credible timeframe. This requires decisions about what is in scope and what is not, and those decisions need to be made by the sponsor, not the delivery team.

Extend and refinance. Seek additional funding and time to complete the original scope. This requires a supplementary business case and a credible explanation of why the original estimates were wrong and why the new estimates should be trusted.

Stop. Acknowledge that the program has failed, close it down in a controlled manner, preserve what value can be preserved, and decide whether the underlying business need still exists and how to address it differently.

None of these options is easy. But they are the real options, and a recovery plan that does not acknowledge them is not a recovery plan - it is a continuation of the wishful thinking that created the problem.

Reset stakeholder confidence

Stakeholder confidence in a failing program does not recover automatically. It requires a deliberate communication strategy that is different from the normal program status reporting cycle.

The key elements are:

Acknowledge what went wrong. Stakeholders who have been receiving optimistic reports for months are not going to trust a new version of the same reporting unless there is an explicit acknowledgement that the previous reporting was not accurate. This does not mean apportioning blame - it means being clear that the picture is now being presented accurately.

Present the honest current state. Use the health assessment findings. Show the actual delivery position, the actual financial position, the actual risks. Do not soften the findings for the audience.

Present a credible plan. The recovery plan needs to be conservative. It needs to be based on what has actually been demonstrated, not on what would be needed to close the gap. A plan that requires perfect execution from a team that has been unable to achieve perfect execution is not credible.

Define what success looks like now. The original success criteria for the program may no longer be achievable. Redefining success is not the same as accepting failure - it is being clear about what the program can now deliver and why that still has value.

Governance decisions that matter

Program recovery requires governance decisions, not just delivery decisions. The delivery team cannot recover a program without the authority to make the changes that recovery requires.

The governance decisions that are typically needed in a recovery situation:

Scope decisions. What is in scope for the recovery plan? What has been deferred or removed? Who has the authority to make this decision, and has it been formally made?

Contract decisions. Does the vendor contract need to be renegotiated? Are there contractual remedies that should be exercised? Does a contract extension need to be approved?

Reporting decisions. Is the current reporting giving the steering committee accurate information? Does the reporting framework need to be reset?

Resourcing decisions. Does the program team have the right people? Are there capability gaps that need to be addressed before the recovery plan can proceed?

These decisions need to be made by people with the authority to make them. The recovery plan cannot proceed if the decisions are deferred or delegated to people who cannot make them.

Common recovery mistakes

Starting the recovery before the assessment is complete. The pressure to show progress is real, but starting a recovery plan without completing the health assessment means building on a diagnosis that may be wrong.

Committing to a recovery timeline before it has been tested. Recovery plans need to be based on demonstrated delivery capacity, not on what would be convenient. An aggressive recovery timeline that is not achieved is worse than a conservative one that is.

Treating the recovery plan as a one-time exercise. Recovery is a continuous process. The plan needs to be updated as new information becomes available, and the governance structure needs to be able to respond when the plan needs to change.

Losing the sponsor. Program recovery requires executive support. If the sponsor has already decided that the program is too far gone, the recovery work cannot succeed. Securing the sponsor’s genuine commitment before the recovery begins is essential.

---

The Project Recovery Pack includes structured templates for health assessment, stakeholder reset communications, recovery roadmap planning and risk re-baselining. See the templates page for details.