Rescue a Failing Project: The First 30 Days

The hardest project a tech lead can inherit is the one that was already failing when they got it. The team is exhausted, stakeholders have lost trust, and the original plan is fiction. This case study walks the 30-day rescue plan that the chapters of this series compose into when applied at once.

When does a project actually need rescue?

Three signals together, each from earlier chapters.

Status stuck red. Status reports amber or red for 3+ weeks with no plan to recover. The trend is the data; one bad week is normal.

Dates slipping multiplicatively. Original commit was 3 months; current ETA is 6+ months; new ETA appears every sprint. Estimation is broken; replanning is required.

Team morale visibly dropping. Engineers quiet in retros, 1-on-1s showing burnout signs, attrition risk in the team. Heroics are not sustainable.

If only one signal is present, normal project hygiene fixes it. All three together is rescue territory.

What is the cost of letting a failing project drift?

Three failure modes worse than rescue itself.

Trust collapse. Stakeholders stop attending demos because they no longer believe the dates. Recovering trust takes 6+ months even after the project ships.

Engineer attrition. The strongest engineers leave first because they have options. By the time leadership notices, the team is missing the people who could have rescued it.

Sunk cost trap. "We're 70% done" on a project that will take another year. The rescue conversation surfaces whether to finish, descope, or kill. Without it, the project drags forever.

What is the 30-day rescue playbook?

gantt
    title 30-Day Rescue Plan
    dateFormat YYYY-MM-DD
    section Week 1 Diagnose
    Stakeholder interviews          :a1, 2026-06-20, 4d
    RAID review                     :a2, 2026-06-22, 3d
    Team 1-on-1s                    :a3, 2026-06-20, 5d
    Diagnosis doc                   :a4, after a3, 2d
    section Week 2 Plan
    Scope cut workshop              :b1, 2026-06-29, 3d
    Re-baseline with sponsor        :b2, after b1, 2d
    section Week 3 Stabilise
    Install daily standup           :c1, 2026-07-06, 1d
    Install weekly status           :c2, 2026-07-06, 1d
    Ship visible win                :c3, 2026-07-09, 4d
    section Week 4 Reset
    First normal-cadence retro      :d1, 2026-07-17, 1d
    Sponsor review                  :d2, after d1, 1d
    Hand back the wheel             :d3, after d2, 1d

Four weeks, four phases. Diagnose before doing anything; re-plan with stakeholder buy-in; stabilise the cadence; hand the project back to a healthy rhythm. The rescue ends when normal cadence is sustainable - not when the project is shipped.

What does week 1 (diagnose) look like in artifacts?

# Project {{ Name }} — Diagnosis

## Stakeholder summary (from interviews)
- Sponsor: wants X by Y; willing to flex scope, not date
- Tech Lead: estimates were wrong; dependency Z slipped
- 3 engineers: morale low; mid-sprint scope adds; no retro acted on

## Current state
- Original Must items: 12; shipped: 4; in progress: 5; not started: 3
- Original date: 2026-08-15; current trajectory: 2026-12-01
- Top blockers: vendor SDK, infra capacity, design lag

## RAID highlights
- 8 open risks, 3 issues, 2 dependencies blocked
- 6 risks > 30 days old without status update
- No mitigation tracked for 4 of the 3 issues

## Team observations
- Standup runs 45 min, unfocused
- No retro held in last 6 weeks
- Pull request review queue averaging 5 days
- 2 engineers on weekend recovery work last 3 sprints

## Diagnosis
This project is failing because (a) original scope exceeds
capacity by 2x, (b) cadence has decayed, (c) stakeholder comms
have become defensive.

## Recommendation
Cut scope to 6 Must items, re-baseline date to 2026-09-30,
restart standup/retro/status discipline, ship one visible win
in week 3 to rebuild trust.

The diagnosis is the artifact for the week-2 conversation with the sponsor. Without it, the rescue conversation is opinions; with it, it is data.

What scope cut looks like for a rescue?

The MoSCoW framework applies ruthlessly:

# Rescue Scope Cut — Project {{ Name }}

## Original Must (12 items)

| Item | Status | Decision | Rationale |
|------|--------|----------|-----------|
| Refund flow | 80% | KEEP MUST | Customer-promised |
| Multi-currency | 0% | DEFER to Q4 | No customer asking yet |
| Subscription billing | 30% | DEFER to Q4 | Bigger than estimated |
| Admin audit log | 60% | KEEP MUST | Compliance |
| Stripe webhook idempotency | 100% | KEEP MUST | Already done |
| Customer support runbook | 0% | DEFER 2 weeks | Quick to do later |
| Performance dashboard | 0% | DEFER to Q4 | Internal-only |
| ... | | | |

## New Must list (6 items)
[items kept above]

## New date
2026-09-30 (was 2026-08-15; +6 weeks)

## What sponsor approves
- Date slip 6 weeks
- Scope reduction (6 deferred)
- No scope additions during rescue period

## Communication
- Sales: revised launch communication; no public date until
  sponsor approves
- Customer success: refund flow remains promised by date X
- Eng team: focused goal for next 6 weeks

The trade is honest: 6 items deferred for 6 weeks bought back. Sponsor signs the trade or the project does not have a path forward.

How does week 3-4 install discipline?

flowchart LR
    Day0[Week 3 Day 0] --> Standup[Daily standup<br/>15 min, blocker-focused]
    Standup --> Status[Friday status report<br/>RAG, top 3 risks]
    Status --> Retro[Week 4 retrospective<br/>blameless, action items]
    Retro --> Win[Ship visible win<br/>refund button live]
    Win --> Sponsor[Sponsor review<br/>handover]

Discipline = the artifacts from the lifecycle chapters running on time. The rescue is over when the team can sustain standups, status reports, and retros without the rescuer driving them.

What failure modes does the rescue itself introduce?

• Heroic rescuer. The PM works 60-hour weeks during rescue. Mitigation: rescue plan must be sustainable from day 1; if it requires the rescuer to burn out, it is not a plan.
• Scope cut later reversed. Sponsor agrees to cut, then asks for items back the next week. Mitigation: written agreement; reverting requires the same conversation as cutting.
• Team uncertainty. Engineers don't know if the rescue succeeded or they're still failing. Mitigation: explicit reset milestone (week 4) where rescue is declared complete and normal cadence resumes.
• Permanent rescue mode. The project never leaves rescue. Mitigation: 30-day timeline; if not stable by then, the project should be killed, not perpetually rescued.

When is rescue not the right answer?

Two cases.

Project should be killed. Sometimes the diagnosis reveals that the project no longer has business value, or that the remaining work exceeds reasonable investment. The honest answer is to recommend killing, not rescuing. Sunk cost is sunk.

Underlying team needs leadership change. Sometimes the problem is the manager, not the project. A rescue PM cannot fix that; HR partnership is required.

The rescue playbook applies when the project is salvageable with discipline and scope cuts. Below that threshold, different intervention is needed.

Where should you go from here?

Next case study: greenfield MVP launch - the opposite shape, a brand-new project with no baggage. After that, legacy modernisation and vendor managed project complete the case-study group.