Managing a Project in Trouble: A Practical Recovery Guide
Every experienced project manager has faced it: the schedule slippage that keeps growing, the budget variance that cannot be explained away, the team that has gone quiet, and the stakeholder emails that feel increasingly pointed. A project in trouble has a recognisable texture — and the sooner you name it, the sooner you can do something about it.
How to Recognise a Project in Trouble
The warning signs rarely arrive all at once. They accumulate. Schedule slippage that was two days last month is now two weeks. Cost variance is creeping in a direction that cannot be traced to a specific event. Velocity is declining, or the team has stopped tracking it. Stakeholders are asking for more frequent updates, which is rarely a sign of confidence.
Accelerating schedule slippage — tasks that were almost done last week are still almost done this week
Cost variance growing without a clear cause — money is leaving without a corresponding deliverable
Team morale declining — conversations are shorter, humour has left the room, people avoid one-on-ones
Stakeholder confidence eroding — questions shift from "how is it going?" to "when will this actually be done?"
Risks that were logged are now issues — the probability column in the risk register has become irrelevant
One of these alone is not always cause for alarm. Three or more together, especially if the trend is worsening week over week, is a clear signal that the project needs active intervention rather than continued monitoring.
Triage First: Assess Actual Status, Not Reported Status
The single most dangerous thing in a troubled project is optimistic reporting. Teams under pressure tend to report what they hope will be true rather than what is true. Tasks get marked as "90% complete" and stay there for weeks. Your first job as the recovery lead is to separate reported status from actual status.
Go to the source. Look at the actual artefacts: working code, completed deliverables, signed approvals. Count what is genuinely done, not what is in progress. Ask team members directly, one on one, what they would need to finish their current task. The gap between the official plan and those answers is your real variance.
This is not about assigning blame. Frame it as a problem-solving exercise: "I need to understand where we actually are so I can figure out how to help." People will tell you the truth if they believe you are trying to fix the situation rather than identify a scapegoat.
Recovery Options: What You Can Actually Do
Once you have an accurate picture, you have a limited set of levers. There is no magic option that restores the original plan without trade-offs. Every recovery path costs something — the question is which cost is most acceptable to the sponsor and the organisation.
Re-baseline the schedule — accept the revised reality, update the plan, and recommit to the new dates. This is appropriate when the original baseline was unrealistic and the work itself is still achievable with the current team and scope.
Descope — reduce what the project must deliver. Identify the minimum viable outcome and protect that; defer the rest to a subsequent phase or release. This is the most underused recovery lever because it feels like failure when it is actually pragmatism.
Add resources — carefully. Brooks's Law ("adding manpower to a late software project makes it later") is real. New people need onboarding time that the current team must spend. Use this lever only when there are discrete, separable tasks that additional people can pick up without significant knowledge transfer.
Extend the timeline — negotiate with the sponsor for more time. Come with a revised plan, not just a request. Show what you will deliver by when, and what the consequences of not extending would be.
Cancel — sometimes the right answer is to stop. If the original business case no longer holds, if the cost to complete exceeds the value of the outcome, or if the team and stakeholders have lost confidence beyond recovery, cancellation is a legitimate and responsible choice.
Building the Recovery Plan
A recovery plan is not the original plan with new dates. It is a new plan built from first principles: what must be done, in what order, by whom, with what dependencies. It must be realistic enough that the team believes in it and ambitious enough that it addresses the sponsor's legitimate expectations.
Include explicit assumptions and risks. State clearly what must be true for the recovery plan to work. If a key assumption fails — a dependency arrives late, a resource becomes unavailable — you need a pre-agreed response rather than another round of emergency planning.
Managing Stakeholder Expectations During Recovery
Stakeholders in a troubled project are often already managing their own concerns upward. They need honesty, not spin. Give them a clear summary of the situation, the recovery options you considered, the path you are recommending, and the earliest point at which you will have a better view of whether it is working.
Frequent, short updates during recovery build confidence. A brief written summary twice a week is more effective than a detailed monthly report. It signals that the situation is being actively managed, even while it remains uncertain.
When Cancellation Is the Right Answer
Project cancellation feels like defeat. In practice, continuing to invest in a project that cannot succeed is the more costly mistake. If the cost to complete has grown beyond the value the project will deliver, if the strategic context has changed so the outcome no longer matters, or if the team is so depleted that recovery is not credible, stopping cleanly preserves resources for work that can succeed.
Frame cancellation as a decision, not a failure. Document what was learned, what was delivered, and why the decision was made. That record is useful for future projects and for the team members who put real work into it.