Skip to content

Lesson 6 — Project Recovery and Corrective Action

At a glance

Learning objectives

By the end of this lesson you should be able to:

  1. Detect a project in trouble from leading indicators, before the cost and schedule measures have caught up.
  2. Triage a failing project by cause — plan, estimate, scope, capacity, or business case — and explain why the cause determines the response.
  3. Assemble a recovery plan with a stabilisation phase, a prepared scope-cut list, and a cadence that can hold the recovery together.
  4. Re-baseline honestly: what a revised baseline must record, and what it must never erase.
  5. Prepare a stop case as deliberately as a recovery case, and state what stopping costs.
  6. Recognise recoveries that cannot work, and say so — including the ones caused by underfunding, key staffing, or a business case that has failed.

Prerequisites

  • Module 11 Lesson 2 — monitoring, variance, and corrective action at the project level.
  • Lesson 5 — compression, debt, and cost of delay, because a recovery is usually built out of those trades.

Introduction

Recovery is the moment a project manager's judgement is most visible and least supported. The pressure runs one way: reassure, promise, and buy time. Every experienced practitioner has watched a project do exactly that for three months and then fail in public, and every one of them can name the moment when an honest report would have changed the outcome.

Two ideas make recovery tractable. First, the cause determines the response, and most recovery attempts fail because they treat the symptom — lateness — rather than the cause. Second, early bad news is cheap and late bad news is not, so the credibility arithmetic favours disclosure even when disclosure is uncomfortable. That arithmetic is worth working through explicitly, because it is the part people doubt.

1. Detection: leading indicators, not lagging ones

By the time earned value shows a schedule problem, the opportunity to absorb it has usually gone. The leading indicators of trouble are mostly about the pattern of work, and most of them cost nothing to collect:

Indicator What it looks like before the problem is visible Why it matters
Rising unplanned work "Must-do" items appearing mid-iteration, unlogged Committed work is being displaced, so future forecasts are unreliable
Blocked or waiting items The same items waiting across two checkpoints Capacity is idle while appearing busy
Test cycle time growing Tests take longer each cycle, or queues form before testing The system is becoming harder to verify
Defect escape Defects found after their phase, repeatedly The verification step is not working, so "done" is not done
Milestone slips accumulating Each milestone slips a little, and each is absorbed without a decision The absorbing capacity — float, goodwill, overtime — is finite
Scope change volume Change requests rising, or arriving earlier than expected The requirements were not agreed, or the stakeholder environment has moved
Single-person dependency Critical path blocked whenever one person is unavailable Schedule fragility that no plan shows
Decision latency Escalations sitting for weeks The project is being slowed by governance rather than by work
Reporting that is never bad All green, for months, in a project with obvious difficulty The reports are unusable, which is the most serious indicator of all

That last row is the one to act on quickly. A project with no reported problems is either genuinely fortunate or has stopped producing honest information, and the second is far more common.

2. Triage by cause

Recovery options follow from the cause, and choosing the wrong cause guarantees an expensive failure.

Cause Evidence Response
The plan was wrong Activities were understood; the sequence, dependencies, or calendar were not Re-plan: recompute the network, fix the calendar, and check for missing work
The estimate was wrong Work took systematically longer than estimated, for reasons that were knowable Re-estimate with a range; look for optimism in the original basis
The scope was not agreed Requirements arriving late, changing, or contradicting each other Fix the boundary: agree what will not be done, and apply change control
The capacity is not there Availability below what the plan assumed, shared people, unplanned absence Resolve the resource shortfall with the owner of the resource, not with the team
The approach does not fit Unknown requirements, long feedback loops, repeated redesign Change the delivery approach — smaller increments, more frequent contact with users
The business case has failed The window closed, the market moved, the mandated constraint changed Stop, or re-authorise on a new case; do not "recover" a project whose reason has gone
The organisation is the constraint Decisions unmade, environments unavailable, testing blocked by another department Escalate as a governance problem with a date and a consequence

A diagnosis is credible when it explains the pattern, not just the variance. "We are four weeks late because the scope grew by six requirements and the two critical-path activities were resequenced twice" is a diagnosis. "We are late because the team is slow" is an attribution, and it usually points at the wrong fix.

3. Building a recovery plan

A recovery plan is different from a project plan. It is shorter, it has a stabilisation phase, and it is built around one or two decisive moves rather than a general commitment to try harder.

  1. Stabilise first — two weeks, not zero. Stop taking on new work, close the open items, get the test environment and data sorted, and get the defects under control. A recovery that starts while the team is still firefighting usually fails within a month.
  2. Choose one or two decisive moves. Typically: cut scope to a defensible launch scope, and fix the single bottleneck (test environment, decision latency, one missing skill). Ten small improvements read as a general instruction to work harder, and have the same effect.
  3. Prepare the contingent scope cut in advance. Decide now what comes out if the recovery slips by a given amount — before the pressure is applied. A cut decided under pressure is decided by whoever applies the most pressure.
  4. Increase the decision cadence, not the reporting volume. Weekly (or twice weekly) short decision meetings with the people who can decide; fewer, better papers, with the numbers in one place.
  5. Track actuals against the recovery baseline, and state plainly when the plan is not working. A recovery plan that cannot fail on paper simply fails later in reality.

4. Re-baselining honestly

Re-baselining is legitimate: when the situation has materially changed, a revised baseline is the only way to measure anything useful. What makes it honest or dishonest is the record:

Honest re-baselining Dishonest re-baselining
Records the original baseline alongside the revised one Replaces the original, so the variance disappears
States the cause and the date of the change Says "revised following review"
Gets the sponsor's approval with the trade-off stated Is agreed in a corridor
Adjusts the risk register and reserve with the new date Leaves reserve sized for the old plan
Names what was cut or deferred Quietly reduces quality or acceptance criteria
Keeps the change in the change log Loses the traceability

The original baseline is the reference point for learning: comparing the outcome against the original business case is what makes future business cases credible, and it is why the project closure report compares against the original promise rather than the latest revision.

5. The stop case

Stopping is a legitimate project outcome and it deserves the same rigour as a recovery case. A stop case covers:

  • Remaining cost against remaining benefit. Past spend is irrelevant — it is the sunk-cost error to include it, and it is the single most common reason failing projects continue.
  • The value of freed capacity. The people released can deliver something else; that alternative is part of the case.
  • The cost of stopping. Contractual exit, sunk licences, work that must be finished anyway for compliance or safety, reputational and team effects, and the cost of restarting later if the need returns.
  • The condition that would justify restarting. Written down now, while the reasoning is fresh.
  • Recovery reliability. How likely is the recovery to succeed, and what would you know at the end of the stabilisation phase that you do not know now? A decision deferred to that point, with a real checkpoint, is often the best available answer.

6. What recovery cannot do

  • It cannot create capacity. If the project needs more people, or a different skill, the decision belongs to whoever owns those people. A recovery plan that assumes the team will find more hours is a plan to burn out the team.
  • It cannot fix chronic underfunding. A project whose budget never matched its scope will keep being late until the scope or the budget changes.
  • It cannot repair a failed business case. If the window has closed, recovery restores the wrong thing to life.
  • It cannot substitute for capability. If the team cannot test or estimate, recovery needs a capability intervention — training, pairing, an experienced hire — and that costs time before it saves any.
  • It cannot be guaranteed by documentation. A recovery plan with fifty actions is a description of hope. One or two decisive moves and a prepared cut list is a plan.

The most honest sentence in recovery is often this: "The plan now requires more capacity than we have. The decision is which of these three things to stop." Saying it early is what preserves the credibility needed to say anything else later.

Key terms

Term Meaning
Leading indicator A measure that changes before the outcome, such as blocked items or defect escape
Lagging indicator A measure of the outcome, such as cost variance or a missed date
Triage Assigning the failure to its cause, because the response depends on it
Stabilisation phase A short period of stopping new work and fixing the immediate blockers
Recovery baseline A revised plan against which the recovery is measured
Contingent scope cut Work identified in advance as the first thing to remove if recovery slips
Stop case The analysis supporting a decision to stop, on remaining cost versus remaining benefit
Decision cadence How often decisions are made during a recovery, as distinct from how often reports are issued

Worked example

Task: recover the analytics dashboard at week 14 of a 16-week project. Figures are invented for teaching.

Step 1 — Read the leading indicators before the measures. Three things changed in weeks 11–13: unplanned "must-do" items rose from two to nine per fortnight, one performance defect (the list screen timing out above 500 records) was found only when realistic data arrived, and two milestones slipped by three and four days and were absorbed without any decision being taken. Cost and schedule measures still look Amber. The pattern — rising unplanned work, late discovery, absorbed slips — says the remaining absorbing capacity is nearly gone. That is the finding, and it is available three weeks before the earned value graph turns Red.

Step 2 — Triage the cause. Three candidate explanations are tested against the pattern: the estimate was optimistic for data-heavy work; the plan did not include a realistic-data activity; and the requirements were never agreed well enough to be testable. Evidence supports the second and third — the data dependency appears nowhere in the WBS, and the acceptance criteria for two reports are a sentence each. The estimate is not the primary cause: effort was close to estimate, but verification arrived far later. The response follows: add the missing activity, fix the criteria, and stop assuming that verification can be compressed.

Step 3 — Stabilise for two weeks. No new work is accepted. The two-week phase closes fourteen open items, gets realistic data volumes into the test environment, and fixes the pagination defect. The stabilisation is presented as a deliberate cost, not a pause: it converts an unpredictable flow of work into a predictable one, which is the precondition for any recovery plan being believable.

Step 4 — Choose two decisive moves and prepare the cut list. Move one: reduce scope to a defensible launch — three of five reports, with the remaining two deferred and named. Move two: fix the single bottleneck, which is verification, by having the developer run the automated regression suite while the tester works on the new acceptance criteria (the substitution already prescribed in Lab 21). The contingent cut list is written before it is needed: the export feature and the drill-down come out if the recovery slips by more than five days.

Step 5 — Re-baseline with the full record. The revised plan shows a new finish date, the three reports in scope, the resourced verification activity, and a re-sized reserve. The record keeps the original baseline beside the revised one, states the cause and the date, and notes that the original promise of five reports in 16 weeks was not met. The sponsor approves the revised plan and explicitly accepts the two deferred reports. Nothing is erased: the project's history is the raw material for its lessons.

Step 6 — Present the stop option alongside recovery. The stop case is prepared as well, because the sponsor is entitled to see both. Remaining cost is compared with remaining benefit; the value of freed capacity is stated (two developers for three months); the cost of stopping includes two reports that are regulatorily required and must be finished anyway, which makes stopping more expensive than it first looks. The recommendation is to continue, because the remaining work includes an obligation that cannot be avoided — a reason worth stating explicitly, since the alternative reason ("we have spent a lot already") is the sunk-cost error.

Step 7 — Set the recovery cadence and the failure condition. A 30-minute weekly decision meeting with the product owner and the technical lead, with a single one-page status. The plan states in advance what would show that the recovery is not working — two consecutive weeks without closing the planned scope-cuts — and what happens then, which is to invoke the cut list rather than to re-plan again.

Common misconceptions

“A recovery plan should show we will catch up”

A recovery plan that restores an unrealistic promise has not recovered anything; it has postponed the honest conversation. The plan should show what will be delivered, when, and what has been given up — and the honest answer sometimes includes a date later than the original one.

“We cannot stop now, we've invested too much”

This is the sunk-cost error, and it is the commonest reason for expensive failures. The only relevant comparison is remaining cost against remaining benefit, plus the value of the capacity that would be freed. Money already spent is identical whether the project continues or stops.

“Re-baselining hides the problem”

Re-baselining without a record hides the problem. With the original baseline retained, the cause stated, and the sponsor's decision recorded, it is the mechanism that makes honest measurement possible again — and it is the only way the organisation learns what its plans are actually worth.

“Adding people will recover the date”

Late in a project, adding people usually costs more than it saves: onboarding takes weeks, communication overhead rises, and the critical path rarely runs through a task that extra hands can split. Where more capacity is genuinely the answer, it needs to arrive early, or it needs to be a different skill rather than more of the same one.

Practical activity

Run a recovery on a project you know, or on the analytics dashboard with your own numbers.

  1. List the leading indicators you would collect weekly on your project, and for each say what pattern would worry you. Include "reports that are never bad".
  2. Triage: state the cause you believe, the evidence for it, and one alternative you ruled out and why.
  3. Write a two-week stabilisation phase: what stops, what gets closed, and what gets fixed.
  4. Choose two decisive moves. Then write a contingent scope cut of at least two items, with the trigger that would invoke it.
  5. Write a one-page stop case using remaining cost versus remaining benefit, including the value of freed capacity and the cost of stopping. State whether you recommend continuing, and why.

What "good" looks like: at least two leading indicators that would have fired before the cost measures did, a triage that explains the pattern rather than the variance, a stabilisation phase with real stopping, a cut list prepared before it is needed, and a stop case reasoned forward rather than backward from sunk cost.

Self-assessment

  1. Why are leading indicators more useful than cost and schedule variance during a recovery?
  2. Why does the cause of a failure determine the response? Give two examples with different responses.
  3. What must an honest re-baseline record, and what must it never do?
  4. Under what circumstances should a project be stopped, and what is irrelevant to that decision?

  5. A sponsor says "recover it, whatever it takes". What three questions do you ask before agreeing?

  6. Apply it — recovery. A six-month project reports green for five months. In month four, unplanned work rose sharply, three items have been blocked for over two weeks, and the test suite has not run since month three. At month five the cost and schedule reports are still within tolerance. The sponsor proposes hiring two contractors for the final month.

    Hint: A strong answer triages by cause and names the indicators that warned before the reports did.

Show answers
  1. Because variance reflects work already done, so by the time it is visible the opportunity to absorb the problem has mostly gone. Leading indicators — blocked items, unplanned work, growing test cycle time, defect escape, accumulated small slips — change while the outcome can still be influenced, which is what a recovery needs.
  2. Because each cause requires a different intervention, and applying the wrong one costs time you do not have. For example: an incorrect plan needs the network and calendar corrected, because no amount of scope-cutting fixes a dependency that was never modelled; whereas unagreed scope needs a boundary and change control, because re-planning will not stop the scope moving. Similarly, missing capacity needs the resource owner, not the team, and a failed business case needs authorisation rather than any recovery at all.
  3. It must record the original baseline beside the revised one, the cause and date of the change, the sponsor's approval with the trade-off stated, and the consequential changes to scope, risk, and reserve. It must never erase the original, because that removes the reference point that allows the outcome to be compared with the promise — and it must not quietly reduce quality or acceptance criteria without that reduction being the explicit subject of the decision.
  4. When remaining cost exceeds remaining benefit, including the value of capacity that would be freed and the cost of stopping; or when the reason the project existed has gone — the window closed, the mandate changed, the benefit has been achieved another way. What is irrelevant is how much has been spent: that money is the same in both branches of the decision, so including it can only push toward the wrong answer.
  5. What is being given up — because "whatever it takes" must be paid for in scope, quality, or other work, and that choice belongs to the sponsor; what capacity will actually be made available in writing, since a recovery plan that assumes unspecified extra effort is a plan to exhaust the team; and what the pre-agreed point is at which we stop — the condition and the date at which the recovery is judged, so that continuing becomes a decision rather than a default.
  6. The leading indicators were already visible: rising unplanned work, a growing blocked queue, and a test suite that has stopped running are all early signals that lagging cost and schedule measures cannot show yet. A report still green at month five in this situation is itself a risk item. Triage by cause before choosing a response, because the cause picks the remedy: if the estimate was wrong, no amount of effort fixes the date and the response is a re-baseline; if scope grew unmanaged, the response is change control; if capacity is unavailable (blocked items, an environment, a dependency), the response is unblocking and sequencing; if the plan was unachievable, replanning. Hiring two contractors for the final month is rarely one of those remedies — it adds onboarding and coordination cost in the last, most expensive month, and cannot help a project whose problem is that it is building the wrong thing or has an impossible date. If a recovery plan is built, it must be explicit about what is cut, who owns what, and the point at which the honest answer becomes stop.

Summary

  • Watch leading indicators — rising unplanned work, blocked items, growing test cycle time, defect escape, absorbed slips, decision latency, and reports that are never bad.
  • Triage by cause. Plan, estimate, scope, capacity, approach, business case, and organisational constraints each need a different response.
  • A recovery plan has a stabilisation phase, one or two decisive moves, a prepared contingent scope cut, and an increased decision cadence rather than a larger reporting volume.
  • Re-baseline with the full record: original baseline retained, cause stated, sponsor's approval recorded, consequences updated. Never erase the history that makes learning possible.
  • Prepare the stop case as deliberately as the recovery case, using remaining cost against remaining benefit, and treat past spend as irrelevant.
  • Recovery cannot create capacity, fix chronic underfunding, repair a failed business case, or substitute for capability. Saying so early is what preserves the credibility to say anything else later.

Further learning

For the measurement material referenced in section 1, Nicole Forsgren, Jez Humble, and Gene Kim's Accelerate (2018) reports the research programme behind the four delivery measures; treat its findings as evidence about the populations studied rather than as a guarantee for any single team.