Not Every Troubled Project Should Be Rescued
There is a dangerous assumption in project management:
If a project is in trouble, the answer is to save it.
That is not always true.
- Sometimes a troubled project should be recovered.
- Sometimes it should be reset.
- Sometimes it should be reduced in scope.
- Sometimes it should be paused.
And sometimes the best project management decision is to stop it.
That can be uncomfortable for leaders because projects create momentum. Money has already been spent. Teams have invested months of effort. Executives have made commitments. Customers may have expectations. Nobody wants to admit that the original plan no longer makes sense.
But continuing a project simply because the organization has already invested in it is not project leadership.
It is sunk-cost thinking.
Project recovery should begin with a decision, not an assumption.
The first question should not be:
“How do we get this project back on schedule?”
The better question is:
- “Is this project still worth recovering?”
- That changes the entire conversation.
- A recovery decision should start with business value.
- Why did the organization start this project?
- What business outcome was expected?
- Does that outcome still matter?
- Has the market changed?
- Has the strategy changed?
- Has the customer need changed?
- Has the cost of achieving the outcome become greater than the value of the outcome itself?
Projects should exist to create value.
If the value proposition has disappeared, recovering the delivery plan may only help the organization complete the wrong project more efficiently.
The second question is whether the project is recoverable.
There is a major difference between a project that is struggling and a project that is structurally broken.
A struggling project may have schedule delays, resource gaps, governance problems, vendor issues, or stakeholder conflict. Those conditions can often be corrected.
A structurally broken project may have no viable business case, impossible requirements, irreparable stakeholder conflict, severe technical limitations, or a cost profile that no longer makes sense.
Throwing more resources at a structurally broken project does not create recovery.
It creates a more expensive failure.
The third question is what specifically caused the project to lose control.
Recovery should never begin until leadership understands the root cause.
- Was scope poorly defined?
- Were requirements unstable?
- Did the organization underestimate complexity?
- Did leadership delay key decisions?
- Was the implementation approach wrong?
- Were resources overallocated?
- Did the vendor underperform?
- Was the business process never clearly defined?
- Did stakeholders disagree on what success meant?
- Was change management ignored?
Without understanding the cause, the organization risks rebuilding the recovery plan on top of the same problem.
The fourth question is what must change.
Real recovery usually requires tradeoffs.
That is where many organizations struggle.
- Leadership wants the original scope.
- The original deadline.
- The original budget.
- The original staffing model.
- And better results.
That combination may no longer be possible.
A credible recovery plan requires leaders to decide what matters most.
If the deadline cannot move, scope may need to change.
If the full scope must remain, the timeline may need to move.
If quality cannot be compromised, testing cannot be compressed simply to protect a date.
If the organization lacks capacity, additional resources may be required.
If stakeholder adoption is critical, change management may need more time and attention.
Recovery requires choices.
The fifth question is whether leadership is prepared to make those choices.
A project cannot recover if the same governance problems that created the crisis remain in place.
- If decisions took four weeks before the recovery effort, they cannot continue taking four weeks afterward.
- If the executive sponsor was absent before recovery, that sponsor must become active.
- If the steering committee avoided hard tradeoffs, the steering committee must change how it operates.
- If nobody had clear authority, decision rights must be established.
Project recovery is not simply a revised schedule.
It is often a temporary change in how the project is governed.
The sixth question is whether the process itself needs to be redesigned.
This is especially important in software implementation and business transformation projects.
Organizations often assume the project is failing because implementation is difficult.
- Sometimes implementation is difficult because the underlying business process is broken.
- The workflow may be inconsistent.
- Roles may be unclear.
- Departments may perform the same activity differently.
- Approvals may be unnecessary.
- Handoffs may be slow.
- Exceptions may dominate the normal process.
In those cases, the project recovery effort should include business process optimization.
Automating a broken process does not fix the process.
It simply makes the dysfunction move faster.
The seventh question is whether the team still has the confidence and capacity to recover.
Troubled projects can exhaust people.
Teams may have spent months working overtime.
Project managers may have lost credibility with stakeholders.
Business users may have stopped believing the dates.
Vendors may have become defensive.
Executives may have lost confidence in reporting.
Recovery requires rebuilding trust as much as rebuilding the plan.
That means creating a realistic baseline and then delivering against it consistently.
- Small wins matter.
- Clear decisions matter.
- Transparent reporting matters.
- Honest communication matters.
A recovery plan that immediately begins missing commitments will destroy confidence even faster than the original project.
Finally, leadership should establish explicit recovery criteria.
What does “recovered” actually mean?
It should not simply mean that the project is no longer red on a dashboard.
Recovery might mean:
- Scope is stable.
- The schedule is credible.
- Major risks have owners.
- Critical decisions are current.
- The vendor is meeting commitments.
- Stakeholders agree on priorities.
- The team has adequate capacity.
- Financial forecasts are realistic.
- The next major milestone is achievable.
- Governance is functioning.
Those criteria create a measurable point where the project can leave recovery mode and return to normal delivery.
There is another important possibility leadership must be willing to consider.
Stopping the project.
Stopping a project is not necessarily failure.
Continuing a project that no longer creates value can be a much larger failure.
Strong project leadership requires the courage to recognize when the business case no longer works.
The goal of project management is not to finish every project.
The goal is to help the organization invest resources in work that creates value.
That is why project recovery should always begin with three options:
- Recover.
- Reset.
- Stop.
Recover when the business case is still strong and the problems can reasonably be corrected.
Reset when the business outcome still matters but the original scope, schedule, approach, governance, or process no longer works.
Stop when the expected value no longer justifies the investment required to continue.
That is not pessimism.
It is responsible portfolio and project management.
A good project recovery consultant does not arrive with a predetermined answer.
The job is to establish the truth.
- What is the actual condition of the project?
- What caused the problem?
- What would recovery require?
- What tradeoffs must leadership accept?
- What value remains?
- What happens if the organization continues?
- What happens if it stops?
Those questions give executives something more valuable than another status report.
They give them a decision.
And sometimes the most valuable project recovery decision is recognizing that the project should not be recovered at all.
