Recover a failing software project: the first two weeks

The first two weeks of project recovery should produce a credible picture of the product and a workable next decision.

An indigo replacement block being fitted into a dark structure with scaffolding.

The first two weeks of project recovery should produce a credible picture of the product and a workable next decision. They cannot guarantee that every delivery problem will be repaired. Protect essential operations, expose uncertainty and reduce the number of simultaneous commitments before writing another optimistic roadmap.

Days one to three: establish facts

Name a recovery owner and agree how decisions and updates will be recorded. Identify critical customer journeys, current incidents, contractual commitments and available budget. Secure access to repositories and operating accounts. Demonstrate the current build and deployment path. Separate working behaviour from unfinished claims and record important unknowns without assigning blame.

Days four to seven: stabilise a narrow path

Select the failure with the clearest business consequence and assign a small team to it. Preserve a rollback path and add focused checks around the repair. Freeze unrelated high-risk changes where necessary, while keeping essential operations moving. Map dependencies that block progress, including missing decisions, unavailable environments and supplier access.

Days eight to ten: compare recovery options

Build a prioritised register of defects, delivery obstacles and evidence gaps. Compare stabilising the current product, reducing scope, replacing a bounded component or pausing work. Include migration and operating costs in each option. Ask the team to demonstrate one end-to-end increment rather than reporting completion percentages for disconnected tasks.

End the fortnight with a decision

Publish what is now known, what changed and which risks remain. Agree the next outcome, owner, acceptance evidence and checkpoint. A recovery plan should show capacity and dependencies rather than silently assuming overtime. If the product cannot be recovered within business constraints, making that visible early is a useful result. Continue with short evidence-based commitments until delivery becomes predictable again.

Frequently asked questions

Should we replace the whole team immediately?

First identify whether the constraint is capability, ownership, scope, access or the system itself.

Can two weeks guarantee recovery?

No. It is a useful diagnostic and stabilisation window, not a universal completion promise.

Should all feature work stop?

Prioritise by risk and dependency; essential work may continue while destabilising changes are paused.

What belongs in the first update?

Current impact, verified facts, immediate actions, unknowns and the next decision time.

How do we measure progress?

Use restored capabilities and accepted end-to-end outcomes rather than activity counts alone.

Bring the scope. We will help make it buildable.

Share the user journey, integrations and launch constraints. We can clarify the scope and prepare an estimate with assumptions and exclusions.

Explore the delivery scope →