How to Recover a Project on the Brink of Failure

Four months into a software rollout, the weekly report is still amber. The team has stopped asking for decisions and started asking for patience. The sponsor has heard “we are catching up” three times. Everyone close to the work can feel that this project is not going to land where it was supposed to, and nobody wants to be the person who says so out loud.

That silence is what turns a recoverable project into a lost one.

Budget and people are assigned to a piece of work because the expected result is worth it. Committing them to a fruitless task carries a twofold cost: the resources burned on work that will not produce the intended result, and the work elsewhere that never receives those resources. Deciding to rescue a project, or to close it in time, is one of the harder calls in a well-run organization and one of the most valuable.

Recognize the failure while there is still time

The first step is the obvious one, which is exactly why it gets skipped. When a project is going wrong, someone has to acknowledge it.

Recognition is far easier in projects that were set up to produce early warnings. Three habits do most of that work:

• Risks identified with their response planned in advance. Knowing that a supplier might be late is not useful on its own. Knowing what happens on the day the supplier is late is. The six phases of risk control cover how to get from one to the other.
• Intermediate milestones with a defined result. A milestone that only marks a date tells you nothing. A milestone that has to produce something tells you, while there is still time to react, whether the end result will satisfy what the customer expects.
• Monitoring that forecasts deviations rather than reporting them. The point of tracking is to see the deviation coming. Tell the client what your current estimates are, through regular reports and whenever something significant changes, instead of confirming the bad news once it has already happened.

The first habit is the one most often reduced to a label:

A mitigation plan lowers how likely a risk is. A contingency plan does not change the probability at all. It prepares the response that limits the impact if the risk materializes anyway.

You can record both plans on the same risk in ITM Platform, and when a mitigation plan fails you can escalate the risk into an issue, whose resolution keeps a record of what the event cost the project in schedule, cost or scope. Risk and issue management explains how the two records connect.

Acknowledging a problem is also the starting point for analysis, at the level of the company or the individual, in search of what can be improved. There is no single right moment for it. If the risk is imminent, it is worth running the analysis during execution even though it slows the work down. If the damage is already done, a post-mortem gives a calmer and more complete picture.

Decide whether to continue, and let the decision be governed

Once you know the project is likely to fail, the next question is whether it still makes sense to run it. An active project consumes resources whether or not it is going to deliver.

The opportunity cost of a failing project is not the budget already spent. It is the results other projects cannot produce because the resources are tied up here.

That leaves three honest options, and the choice between them should be made on evidence rather than on who has the most to lose.

Option	When it fits	What it costs
Continue as planned	The deviation is explained, bounded, and already shrinking	Nothing extra, provided the diagnosis is right
Rescope and replan	The objective still has value but the current plan or scope does not	A replanning cycle and a renegotiation with the sponsor
Cancel	No realistic version of the project produces a result worth the remaining effort	The work already done, minus whatever can be reused elsewhere

A defeat in time can be a final victory. What makes it a victory rather than a rumor is that the decision is made openly, by the people entitled to make it, and recorded where everyone can see it. Otherwise the project does not really stop. It just stops being discussed while it keeps drawing resources.

This is the part most organizations leave informal. In ITM Platform the status of a project moves through a workflow your organization defines, and a transition can be made to require an approval: moving a project into a discarded status can be restricted to members of the technical project office, for example. The cancellation then has an owner, a date and a trail. Project status workflows and approvals describes how those rules are configured.

Bring in someone who did not build it

Finding your own mistakes is hard. Whether it is pride or self-indulgence, we tend to assume that what we produced is right, and we look past the parts we would rather not reopen.

Software teams learned this early. Programs are not tested only on the machine they were written on, and rarely only by the person who wrote them, because review turns out to be more thorough and more objective when someone outside the work performs it. Self-evaluation tends to be benevolent and easily satisfied.

An outside reader, especially an experienced one, brings the thing a team deep in the work cannot supply: distance. A team occupied by the superficial problems in front of it often misses the deeper ones underneath, which are the problems that deserve the attention. The trees stop you from seeing the forest, and that is exactly what an outside review is for.

It does not have to be a formal audit. Three lightweight versions work:

• A project manager from another unit runs a short review against the plan and the current status.
• The PMO compares the project as it stands today with the business case that justified it.
• The sponsor is asked a single question: knowing what we know now, would you approve this project today?

Break the recovery into small daily wins

Completing a whole project can look overwhelming, and a project in trouble looks worse. Recoveries are rarely built on extraordinary measures, though. A small victory every day can add up to the final result.

Good engineers mastered this. Faced with something as overwhelming as a bridge, an aircraft carrier or a new piece of software, they analyze the end goal, break it into the smallest components they can, and organize the work around those parts. Instead of an unintelligible objective several months away, the project leader and the team have the day in front of them, with the tasks that correspond to it.

That also makes motivation manageable. Concentrating on the work of the day removes much of the anxiety about the complexity of the project as a whole, and it gives people something they can finish.

The one condition is that the wins have to be real. A daily victory measured by optimism is a daily illusion, and a project in recovery cannot afford one. Compare what was estimated with what actually happened: the difference between estimated and actual progress is what tells you whether the recovery is working or whether it is only being reported that way.

More resources rarely fix a failing project

Think of attention and motivation as the psychological capital of an organization. The rule that follows is easy to state and hard to apply: what matters is not how much you can mobilize, but how you distribute and control it.

A team spread across the whole project cycle, juggling its own deliverables and another unit’s responsibilities, produces less than a team with a clear scope and the energy to spend on it. Focus is not a personality trait. It is a consequence of how the work was allocated.

The same holds for financial, material and human resources. Organizations that get more out of their projects are not necessarily the ones that started with more means. Google’s first office was a garage.

So before adding people to a project in trouble, look at where the people you already have are going. Resource analysis sets each person’s capacity against their estimated and actual effort across every project and service, which is where the discrepancies between planned and real work become visible. Very often the failing project does not need more people. It needs the people it already has to stop being pulled into three other things.

Resources are not what separates an organization whose projects succeed from one whose projects fail. How those resources are managed is.

Next steps

• Start a free ITM Platform trial and set up risks, milestones and status rules on the project you are most worried about right now.
• See what project management in ITM Platform covers, from planning and monitoring through to risk, issues and resource control.
• Check the approval rules your organization would need in place before a cancellation could be recorded properly.