Project recovery starts by checking what exists: working software, accessible source code and accounts, recorded decisions, known dependencies and a clear statement of the business result still needed.
Key takeaways
- Secure the code, accounts and working demonstrations before accepting a new timeline.
- Test complete workflows, not percentage-complete claims.
- Choose whether to continue, repair or restart based on future value—not sunk cost.
Secure access and project knowledge
Confirm the code repository, infrastructure, accounts, contracts, credentials, data and decision records before changing the plan. Recovery cannot depend on one unavailable person or an account only the vendor controls.
Test what actually works
Follow representative workflows from the user action through the backend, data and staff administration. Separate finished work from partial features, known defects and unsupported claims of completion.
Reconnect the project to the business result
Troubled projects often keep adding features after the original problem has been forgotten. Restate who will use the product, what they must accomplish and the smallest useful launch that solves the priority problem.
Choose whether to continue, repair or restart
Keeping past work is not always economical, but restarting can also discard useful knowledge. Compare the options by future cost, risk, ownership, maintainability and time to a usable result.
Review working results on a regular schedule
Use small accepted milestones, named owners, decision deadlines and an honest list of risks. Progress means demonstrated working capability—not hours consumed or percentage-complete reports.
What should leadership verify in the first week?
Recovery begins with project assets and working behaviour the organization can inspect. Establish what is available, working and incomplete before making new scope, supplier or timeline decisions.
| Decision area | Useful evidence | Warning sign |
|---|---|---|
| Access | The business can reach its code, infrastructure, accounts and data | Critical access remains with one person or supplier |
| Capability | Representative workflows can be demonstrated end to end | Progress is reported only through tickets or percentages |
| Scope | Required launch outcomes and exclusions are explicit | The backlog grows without an agreed release boundary |
| Decisions | Owners, risks and decision dates are clear | Unresolved questions quietly become development assumptions |
Example: test one complete workflow before estimating the remaining work
Choose a representative user action and follow it through the interface, backend, data, staff administration and failure handling. This reveals missing connections and unclear responsibilities that isolated screens cannot show. The result helps leadership decide whether the current architecture can be repaired and what belongs in the next useful release.
Use this in your next decision
Bring the decision, supporting records and result you need. A focused conversation can identify the risks, options and actions that matter most.
For help with this decision, see Get a difficult project back under control.