Recovering a troubled project

Why it matters

Sooner or later you will lead a project that is in trouble, or be asked to take over one that is. The signs are familiar: dates keep slipping, the budget is mostly spent but the product is not close to done, the team is exhausted, and the sponsor has stopped believing the status reports. Recovering a troubled project is a distinct skill. It is not about working harder: it is about stopping the slide, finding out what is really happening, making hard trade-offs openly and rebuilding trust with a plan people believe.

Signs a project is in trouble

• Repeated milestone slips, each "just two more weeks".
• CPI and SPI well below 1 and not improving.
• Scope that keeps growing without change control.
• Rising defect counts and falling team velocity.
• Key people leaving or burned out.
• Status reports that are green while everyone privately knows otherwise ("watermelon" status).

A recovery process in five steps

1. Stabilise. Stop making the situation worse. Freeze new scope. Pause any work that is not clearly valuable. Agree with the sponsor that you have, say, two weeks to assess before committing to new dates. Do not promise a date before you know the facts.

2. Assess. Find out what is true. Talk to the team, the sponsor, users and vendors one to one. Review the plan, the backlog, the defect list, the budget and the contracts. Ask:

• What is actually finished, tested and usable?
• What is the real remaining work, estimated by the people who will do it?
• What are the root causes: unclear scope, poor estimates, technical problems, missing skills, weak governance, vendor issues?
• Is the business case still valid?

3. Decide. Present the facts and options to the steering committee. Typical levers, often combined:

• Reduce scope to a minimum viable release: what must launch, what can wait.
• Move the date.
• Add budget or people (be careful: adding people late often slows things down at first while new people learn).
• Change the approach, for example switching the build to short iterations with demos to rebuild visibility.
• Stop the project if the business case no longer holds.

4. Re-plan. Create a new baseline from bottom-up estimates, with contingency, clear milestones and tighter tracking. Fix the root causes, not just the symptoms: if the problem was uncontrolled change, put change control in place.

5. Rebuild trust. Report honestly and frequently. Hit the first few new milestones, even small ones. Celebrate progress with the team. Trust comes back from evidence, not promises.

Worked example: rescuing the Northside integration

Imagine that by month 6, the records integration has slipped three times, the vendor and the in-house team blame each other, and CPI is 0.78. You are asked to take over.

• Stabilise: you freeze two "nice to have" portal features and agree a two-week assessment with the sponsor.
• Assess: interviews show the root cause: the fixed-price SOW never specified who provides test data, so each side waited for the other. Only two of six interfaces are fully tested. Bottom-up estimates put the rest at seven weeks.
• Decide: you present three options. The committee chooses option B: launch with four interfaces (booking, cancellation, reminders, patient lookup) and deliver the two reporting interfaces one month after launch. Go-live moves by three weeks instead of seven.
• Re-plan: a contract amendment names Northside as the provider of anonymised test data within five days of each request. Weekly integration demos replace monthly status calls.
• Rebuild trust: the first interface passes testing on the new date, and you report it with evidence.

The recovery plan document

Keep it short. A useful structure:

1. Current situation: honest summary with data.
2. Root causes.
3. Options considered and the recommended option.
4. New scope, schedule and budget baseline.
5. Changes to how the project is run (governance, change control, reporting cadence).
6. Top risks of the recovery itself.
7. Decisions needed now.

Common mistakes

• Announcing a new date before assessing.
• Blaming individuals instead of fixing causes.
• Keeping full scope and "working harder": that is how the project got here.
• Adding many people at once.
• Hiding the recovery from the sponsor until it is "under control".

Quick recap

• Recovery follows stabilise, assess, decide, re-plan, rebuild trust.
• Base decisions on facts and root causes, gathered one to one.
• Trade scope, time, budget and approach openly; stopping is a valid option.
• Trust is rebuilt by hitting small, honest milestones.

Try it

Open the Do tab and write a recovery plan for a troubled project.