How Do You Recover a Failing IT Project? Warning Signs and Recovery Steps

The short answer

To recover a failing IT project, stop the bleeding first, get an independent and evidence-based view of where the project really stands, then make an explicit decision to continue, reset, re-scope or stop, and re-baseline with stronger governance before restarting. The hardest part is usually admitting the problem early. Every month of delay spends money and goodwill that recovery needs.

How do you know a project is in trouble?

Projects rarely fail suddenly. They drift, and the signs are visible to people close to the work well before they reach the board. Watch for:

• Milestones slipping repeatedly, each time with a new explanation
• Spend running ahead of demonstrable progress
• Change requests piling up, or scope quietly expanding
• Decisions waiting weeks for business input
• Testing being shortened or overlapping with build
• Rising defect counts that are not closing
• Key people on either side leaving or disengaging
• The vendor and the business blaming each other in meetings
• Status reports that stay green while the team privately says otherwise

If three or four of these are present, treat the project as troubled, whatever the status report says. Our article on why ERP implementations fail explores the root causes behind many of these symptoms.

Step 1: Stabilise

Before analysing, create space to think clearly:

1. Pause non-essential work that would create rework, such as new configuration on unstable foundations
2. Protect critical operations so the business keeps running while the project is assessed
3. Freeze new scope and change requests except for urgent fixes
4. Communicate calmly with the team, vendor and executives that a structured review is under way

The aim is not to stop everything, but to stop making the hole deeper.

Step 2: Assess the real position independently

An independent assessment is essential, because the people running the project are understandably invested in their own view. A structured review typically covers:

Interview people at every level, review the evidence directly and test claims against reality. A short demonstration of supposedly finished functionality often tells you more than a status report.

The output should be a short, plain-English report: what is true today, the main causes, a realistic range for cost and time to complete, and the options available. Avoid assigning blame at this stage. The goal is a shared, factual baseline that the business, the delivery team and the vendor can all work from.

Step 3: Decide the path forward

With a clear picture, set out the options and their implications. Typical options are:

• Continue with corrections: the approach is sound but execution needs fixing
• Reset: keep the solution but rebuild the plan, team or governance
• Re-scope: deliver a smaller, high-value release first and defer the rest
• Change partner: where the delivery partner cannot perform, accepting transition cost
• Stop: where the remaining value no longer justifies the cost and risk

Compare options on remaining value, cost to complete, risk and time. Ignore money already spent; it is gone whichever path you choose. Stopping can be the right answer, and choosing it deliberately is a sign of good governance, not failure.

Step 4: Re-baseline and restart properly

If the project continues, restart with a new baseline:

• Revised scope with clear priorities and a defined first release
• A realistic, bottom-up plan with explicit contingency
• Decision gates with evidence-based exit criteria
• An empowered business sponsor and a steering committee that decides
• Owner-side leadership separate from the delivery partner
• Reporting based on evidence, such as tested scenarios and reconciled data, rather than percentages

Our article on CIO-led technology transformation governance explains what effective structures look like.

Step 5: Reset the vendor relationship

Troubled projects often involve a strained relationship with the vendor or partner. Recovery usually works better through firm, structured engagement than through immediate dispute. Agree the facts first, then renegotiate scope, milestones, acceptance criteria and commercial terms where needed. Our guide to executive vendor management covers how to keep leverage and accountability without derailing delivery.

Step 6: Keep the board informed honestly

Boards dislike surprises more than bad news. Give them a clear account of what went wrong, the options considered, revised cost and timeline ranges, and the decision gates at which they will be asked to approve further funding. Our board technology risk review service helps directors get an independent view.

What not to do

• Add more people to a late project without fixing the plan
• Promise a new go-live date before the assessment is finished
• Hide problems in the hope the next phase will catch up
• Let the delivery partner conduct its own review and mark its own work

Independent leadership when a programme is in trouble

Recovering troubled programmes is one of the things The Technology Office does best. We step in as independent, owner-side leadership, often as an interim CIO or through our IT crisis management service, to stabilise the situation, establish the facts and lead the recovery. We sell no software and take no implementation margin, so we can give you an unvarnished assessment of the project, the partner and the path forward.

We work with businesses of any size and industry across Australia, and through our technology and systems transformation service we stay involved until the recovered programme is delivering the outcomes it was meant to.