When milestones keep moving, the pressure to make a dramatic change can be intense. A reset is a significant decision. Before choosing a new deadline, team, or architecture, establish a shared understanding of what the business needs and what is actually preventing delivery.
Return to the business outcome.
Ask the people who will use the system to describe a successful working day. Which tasks must they be able to complete? What information must they trust? Which exceptions need to be handled before the business can operate?
Compare those answers with the current scope. Some requirements may remain essential; others may reflect priorities that have changed. Make those differences visible so that the recovery plan is built around an agreed outcome.
Understand what can be kept.
Review completed work in context: the design decisions, data, integrations, tests, and documentation behind it. A demonstration can show that a feature exists. It does not, by itself, show that the end-to-end business process is ready.
For each part of the solution, record whether to retain it, investigate it, change it, or replace it. Explain the evidence behind that recommendation. This gives stakeholders a way to discuss the tradeoffs without reducing the decision to sunk cost or frustration.
Make decisions and ownership visible.
Identify who can resolve the issues blocking progress. Delivery ownership, business decisions, data readiness, testing, and adoption all need named responsibilities. A task can have an owner and still stall if the person authorized to make the underlying decision is unclear.
Keep a short decision log with the question, the owner, the date needed, and the consequence of delay. Use it in the recovery discussion so that the critical path is a shared responsibility.
Choose the next useful milestone.
Define a milestone that demonstrates a complete business workflow with representative data and realistic exceptions. Agree the acceptance criteria with the people who will use and support it. Make dependencies and unresolved questions explicit.
A credible recovery plan explains both what will be delivered and how the team will know it works. The first milestone should create evidence for the next decision, alongside renewed confidence in the project.
Turn the questions into a practical next step.
Explore Project Rescue
