Recover a slipping project
Recover by replacing optimism and activity reporting with a sharp picture of reality: what is blocked, what still matters, what can move, and what must be cut or re-sequenced.
- Situation
- A project is falling behind and confidence is degrading.
- Goal
- Restore credibility and control before the project turns into managed disappointment.
- Do not use when
- the project is exploratory by design and not being treated as a fixed delivery commitment
- Primary owner
- delivery lead
- Roles involved
delivery leadengineering managertech leadproduct leadsponsor or decision-maker for trade-offs
Context
The situation
Deciding whether to reach for this playbook: when it fits, and when it doesn't.
Use when
Conditions where this playbook is the right tool.
- Milestones are slipping repeatedly
- Status sounds healthier than the team feels
- Scope is moving while dates remain fixed
- Stakeholders are losing trust in the plan
Stakes
Why this matters
What this playbook protects against, and why skipping or half-running it tends to be expensive.
Projects rarely recover through more pressure alone. They recover when reality becomes explicit, trade-offs become visible, and the team stops pretending all commitments still fit together.
Quality bar
What good looks like
The observable qualities of a team or system that is actually doing this well. Not just going through the motions.
Signs of the playbook done well
- Current project state is described without status theater
- Scope, risk, and dependencies are re-baselined honestly
- The team knows what the next credible milestone is
- Stakeholders understand the trade-offs behind the recovery plan
- The plan gets simpler, not merely louder
Preparation
Before you start
What you need available and true before running the procedure. Skipping this is the most common reason playbooks fail.
Inputs
Material you'll want to gather first.
- Current milestone plan
- Actual progress state
- Dependency and blocker list
- Scope inventory
- Risk log
- Team capacity picture
Prerequisites
Conditions that should be true for this to work.
- Permission to surface bad news honestly
- Access to true current status, not only reports
- Someone with authority to make trade-offs
Procedure
The procedure
Each step carries its purpose (why it exists), its actions (what you do), and its outputs (what you produce). Read the purpose. It's what keeps the step from degenerating into checklist theatre.
Stop optimistic reporting
Replace summary comfort with operational truth.
Actions
- Review what is actually complete versus merely in progress
- Separate visible work from blocked work
- Strip out vague status labels and force evidence-based status
Outputs
- Current-state snapshot
Rebuild the critical path
Find the real drivers of delay.
Actions
- Identify true dependencies, decision bottlenecks, and unresolved risks
- Remove work that is important but not schedule-defining
- Map what must happen next for confidence to improve
Outputs
- Revised critical path
Force trade-offs explicitly
Stop the team from carrying impossible combinations of scope, date, and quality.
Actions
- Name what can move: scope, timeline, quality bar, sequence, rollout shape
- Put trade-off options in front of actual decision-makers
- Record what was chosen and why
Outputs
- Recovery options
- Decision log
Create a narrower recovery plan
Rebuild trust through smaller truths.
Actions
- Define the next credible milestone
- Reduce scope to what can actually be defended
- Assign visible owners to blockers and dependencies
Outputs
- Recovery plan
- Owner-by-blocker list
Operate on short feedback loops
Make recovery visible and adaptive.
Actions
- Run more frequent short status reviews tied to evidence
- Surface new slips immediately
- Keep recovery metrics focused on exit, not activity
Outputs
- Recovery cadence
- Evidence-based status updates
Judgment
Judgment calls and pitfalls
The places where execution actually diverges: decisions that need thought, questions worth asking, and mistakes that recur regardless of good intent.
Decision points
Moments where judgment and trade-offs matter more than procedure.
- What is truly fixed and what only looked fixed politically?
- What can be cut without collapsing the purpose of the project?
- Which dependencies need escalation rather than hope?
- What is the next believable milestone?
Questions worth asking
Prompts to use on yourself, the team, or an AI assistant while running the procedure.
- What is actually done versus merely active?
- What must move for this project to become believable again?
- What are the real options if the date does not move?
Common mistakes
Patterns that surface across teams running this playbook.
- Asking the team to work harder without changing commitments
- Keeping original scope while rewriting the status language
- Using more reporting detail instead of better trade-offs
- Treating all delays as execution problems instead of structure problems
Warning signs you are doing it wrong
Signals that the playbook is being executed but not landing.
- Status packs get more polished while delivery confidence falls
- Everything remains priority one after the recovery reset
- The team still cannot explain what will actually be delivered next
- Stakeholders hear reassurance but no real trade-offs
Outcomes
Outcomes and signals
What should exist after the playbook runs, how you'll know it worked, and what to watch for over time.
Artifacts to produce
Durable outputs the playbook should leave behind.
- Current-state snapshot
- Revised critical path
- Recovery options brief
- Recovery plan
- Decision log
Success signals
Observable changes that mean the playbook landed.
- The project becomes simpler to explain
- Risk and dependency visibility improves quickly
- One or more commitments are explicitly adjusted instead of silently carried
- Teams and stakeholders describe the project in more similar language
Follow-up actions
Moves that keep the playbook's effects compounding after it finishes.
- Review what created the slippage pattern originally
- Remove temporary reporting layers once the project is stabilized
- Carry the same honesty into future planning rather than reverting to optimism
Metrics or signals to watch
Longer-horizon indicators that the underlying problem is receding.
- Blocked work ratio
- Critical-path stability
- Milestone confidence trend
- Scope change rate
- Number of unresolved external dependencies
AI impact
AI effects on this playbook
How AI-assisted and AI-driven workflows help execution, and the ways they can make it worse.
AI can help with
Where AI tooling genuinely reduces the cost of running this playbook well.
- Summarizing blockers and plan deltas from project artifacts
- Drafting recovery options and communication packs
- Extracting repeated risk themes from status history
- Building dependency and scope comparison tables
AI can make worse by
Distortions AI introduces that make the underlying problem harder to see.
- Making weak status reporting sound more credible
- Creating polished but non-binding recovery plans
- Increasing activity noise when the real need is prioritization
Relationships
Connected playbooks
Failure modes this playbook tends to address, decisions behind the situation, red flags that motivate running it, and neighboring playbooks.