“Rescuing” a project could mean many things, but the overarching objective is to get a stalled initiative back on the right path regardless of its history or how much has already been spent on it.
Projects can go off the rails at any time for any number of reasons, but if there is business value that can be captured, the only thing that matters is how things move forward from that point.
Initiatives can be too big and too important to let fail, but they could also turn out to look like different bets in hindshight and with the benefit of new information.
This inflection point may actually turn out to be an opportunity to cut losses and realign resources to new bets that have higher probabilities of returning business value.
So before starting down the path to revive a stalled project, first determine if the initiative is worth continuing or if there are better allocations for resources
Be mindful of the Sunk Cost Bias to ensure decisions are being made objectively and with all available information.
If the decision is made to shut an initiative down, then it is important to capture as much knowledge as possible and preserve intellectual property for potential future use.
Any immediately usable artifacts or concepts can be repurposed to support current priorities or initiatives planned for the near term.
If the decision is made to continue forward with an initiative, then time is of the essence.
There is no time for a complete post mortem of the events that led to this decision having to be made, but it is important to be able to trace decisions just enough to understand how things got to where they are in the current moment to ensure history does not repeat.
Once sense has been made of the current situation, a new mapping from the updated current state to the intended future state needs to be made as the basis for planning and design activities.
Addressing blockers and mitigating potential risks removes friction and enables greater visibility into how things will play out moving forward.
All work in progress will need to be reevaluated and reprioritized, and any known design gaps will need to be addressed before development continues.
Obviously the goal would be to avoid lengthy disruptions, but jumping back into things too soon may have significant unintended consequences.
Developers will be able to work on refactoring and paying down technical debt while new requirements are drawn up.
Once the root cause issues are resolved and new structure is implemented, we can start turning the flywheel and building momentum again - this time with the confidence of a strong foundation and distraction-free focus.
The lessons learned from the experience would be captured in a retrospective and applied to the appropriate knowledge management systems, delivery processes and workflows, and future state systems or application architecture.