Why stalled projects stay stalled
Once trust drops, teams often add meetings and status reports. That increases activity but rarely removes ambiguity. The plan still mixes facts, assumptions, unresolved decisions, invisible dependencies, and work that was reported “almost done” without agreed acceptance criteria.
A seven-day triage sequence
Day 1: establish the outcome and decision owner
Write the commercial outcome, non-negotiable constraints, and the person authorized to make scope, budget, and launch decisions. If authority is fragmented, recovery will be too.
Days 2–3: inspect evidence, not percentages
Review working software, environments, repositories, integrations, contracts, data readiness, test results, and deployment capability. Replace “80% complete” with demonstrable acceptance criteria.
Day 4: map the critical path
Identify the smallest sequence required to produce a safe business outcome. Separate launch-critical work from improvements that can follow. Name every external dependency and its owner.
Day 5: quantify options
Compare at least three paths: recover the current plan, reduce scope, or re-plan a component/vendor. Show timing, cash, operational risk, and opportunity cost—not just development effort.
Days 6–7: reset governance
Agree on milestones, acceptance evidence, decision deadlines, escalation rules, and a reporting cadence. Publish the first two weeks of actions with one accountable owner per outcome.
What not to do
- Commit to a new date before inspecting the current state.
- Preserve sunk work that no longer supports the required outcome.
- Add people without clarifying ownership and interfaces.
- Let the same party both report and independently validate progress.
- Hide commercial trade-offs inside technical language.
Deliverables that survive the recovery
Even if the project changes direction, the client should retain a current-state assessment, dependency map, risk register, prioritized recovery backlog, acceptance criteria, governance cadence, and an executable 30/60/90-day roadmap.