Project Rescue
Help someone work out why their project is in trouble, what the real options are, and how to say it plainly to the people who must decide.
Troubled projects usually get one of two bad responses: optimism ("we will catch up") or a generic list of best practices. Neither helps. This skill is built around three commitments:
- Evidence before opinion. Every finding points to something in the project's own documents or the person's account. Where evidence is missing, the finding is labelled a hypothesis, with what would confirm it.
- Causes, not symptoms. "We are six weeks late" is a symptom. The plan has to act on why.
- Honest options, including the uncomfortable ones. Reducing scope and stopping are real options and are always considered.
1. Get the picture
Ask for whatever exists; work with what is available and say what is missing.
Documents that help: the original plan or charter, the latest status report, schedule and budget against actuals, the risk and issue logs, the list of changes made since the start.
Ask at most six questions in one message, only those not already answered:
- What was the project supposed to deliver, by when, and for how much?
- Where is it now: what is done, what has been spent, what date is realistic today?
- When did it start to go wrong, and what changed around then?
- What has already been tried to fix it?
- Who is the sponsor, how much do they know, and what do they care about most: date, cost, or what gets delivered?
- What can and cannot move (a fixed date, a budget cap, a contractual commitment)?
If the person is under pressure and has given enough to start, begin the diagnosis and list the missing information at the end rather than holding everything for answers.
2. Diagnose
Read references/diagnostic.md for the cause areas and the signs of each.
- List the symptoms as the person and documents state them, with numbers.
- Size the gap. Calculate time, cost and scope variance from the figures given, and show the working. Do not estimate a figure that was not supplied; say it is unknown.
- Trace each symptom to causes. Ask "why" until you reach something that could be changed. One symptom often has several causes, and one cause often explains several symptoms.
- Mark each cause as
Supported(state the evidence) orHypothesis(state what would confirm or rule it out). - Pick the few that matter. Two or three causes usually account for most of the trouble. Name them and say why these.
- Check whether the plan was ever achievable. A project that was under-estimated from the start needs a new baseline, not more effort against the old one.
Describe causes in terms of work, decisions and conditions. Do not blame named individuals: it is rarely the whole truth, and it makes the plan harder to adopt.
3. Options
Always set out the realistic options, not only the preferred one:
| Option | When it fits |
|---|---|
| Recover within the current plan | The gap is small and the causes are removable |
| Reduce scope | The date or budget is fixed and some deliverables matter less |
| Add time or money | The full scope is needed and the sponsor can fund it |
| Pause and re-plan | The causes are unclear or the plan was never realistic |
| Stop | The remaining cost exceeds the remaining benefit, or the need has gone |
For each option that applies: what it requires, the effect on date, cost and scope (calculated where the figures allow), the main risk, and what must be true for it to work. Money already spent is not a reason to continue; say so when it is clearly driving the thinking.
Then give one recommendation, labelled as a recommendation, with the reasoning. The decision belongs to the sponsor.
4. Recovery plan
For the recommended option:
- Stabilise (first two weeks): stop the damage growing. Typical moves: freeze new changes, confirm the true status of every open task, fix the reporting so the numbers can be trusted, settle the one or two decisions that are blocking work.
- Re-plan: a revised scope, schedule and budget that the team believes, with the assumptions written down. Mark it as a proposed new baseline needing sponsor approval.
- Change what caused it: one concrete change for each main cause (a decision rule, a review, a role, a supplier term).
- Early warning signs: three to five measurable signals that would show the recovery is slipping, with the level that triggers action and who watches each.
- Check-in rhythm: how often progress is reviewed with the sponsor until the project is stable.
Every action has an owner and a date. Where the person has not named one, write Owner: to be assigned rather than inventing a name.
5. Sponsor brief
One page, in this order: where we are (the gap in numbers); why (the two or three main causes); options with their effect on date, cost and scope; recommendation; the decision needed and by when; what happens next.
Write it plainly. Do not soften the numbers, bury the request, or promise a recovery date that depends on things not yet agreed. Offer a spoken version (what to say in the first two minutes) if the person has to deliver it in a meeting.
6. Language and tone
Write in the person's language. For Arabic, write right-to-left in clear Modern Standard Arabic with the English term in brackets on first use. Match the person: plain words for someone without project training, standard terms for a practitioner. Someone running a failing project is usually stressed; be direct about the project and decent to the person.
7. Boundaries
- A diagnosis from documents and one person's account is a starting view. Say what you could not see.
- Contract disputes, penalties, termination of suppliers or staff, and legal exposure need the organisation's legal, commercial or HR people. Flag them; do not advise on them.
- Do not help present a project's status as better than the evidence shows. Help say the true thing well.