How to recover a failing technology programme

Step one: get an independent diagnosis

The programme team's view of what is wrong is almost certainly incomplete. Not because they are incompetent, but because they are inside it. They see the symptoms. They may not see the structural causes. A programme director who has been managing a troubled delivery for twelve months has adapted to the dysfunction. What looks normal from the inside looks alarming from the outside.

An independent diagnosis examines the programme across five dimensions: governance (are decisions being made effectively?), people (does the team have the right capability?), delivery (are plans realistic and progress verifiable?), technology (are configuration and architecture decisions sound?), and commercial (is the vendor relationship functioning as intended?).

This is not a lengthy consulting exercise. A structured health check can be completed in two to three weeks, and the output should be blunt: what is working, what is broken, and what needs to change for the programme to have a credible path to completion. In an HRIS programme where payroll cutover is at risk, or an ERP programme burning significant monthly costs, those two to three weeks are an investment in clarity.

Step two: stabilise before you replan

The instinct in a failing programme is to replan. Reset the timeline. Produce a new schedule. Present it to the steering committee as the recovery plan. This almost never works, because the new plan is built on the same structural foundations that caused the old plan to fail.

Stabilisation comes first. Stop all non-essential activity. Identify the three to five things that must be true for the programme to have a viable path forward. These are usually structural: governance needs to be reset, the programme team needs to be strengthened, a critical vendor issue needs to be resolved, or a fundamental scope question needs to be answered.

Stabilisation is uncomfortable because it means acknowledging that the programme cannot do everything it was supposed to do on the original timeline. It means having hard conversations with the steering committee, the sponsor, and potentially the board about what has gone wrong and what it will take to fix it. Those conversations are the price of credibility. A recovery plan that avoids them is not a recovery plan. It is a deferral.

Step three: rebuild the plan from verified facts

Once the programme is stabilised, replanning can begin. But the new plan must be built from verified facts, not inherited assumptions. Every milestone in the previous plan needs to be validated. Configuration that was reported as complete needs to be checked. Data migration that was scoped needs to be re-estimated based on actual data quality findings. Testing that was planned needs to be re-sequenced against the new reality.

This is where most recovery efforts fail. The pressure to show progress means the new plan inherits assumptions from the old one. If the original plan assumed data migration would take four months and it actually requires eight, the recovery plan must reflect eight. If integration testing was compressed to fit a go-live date that no longer exists, the recovery plan must allocate the time that testing actually requires.

The credibility of a recovery plan is entirely dependent on whether it is based on what is true, not what people want to be true. This applies to HRIS programmes where payroll data reconciliation timelines are routinely underestimated, to ERP programmes where configuration rework is not factored into revised schedules, and to AI deployments where model validation timelines are treated as flexible.

Step four: reset the vendor relationship

In most failing programmes, the vendor relationship has deteriorated. The client has lost confidence in the SI. The SI has become defensive. Change requests have accumulated. The commercial relationship is strained. Trust is low on both sides.

Recovery requires resetting this relationship. Not with goodwill meetings and relationship repair exercises, but with structural clarity. What does each party owe the other from this point forward? What does "done" look like for each remaining milestone? How will disputes be escalated and resolved? What are the commercial implications if the vendor does not meet its revised commitments?

This reset should be documented. Not as a new contract (although contract amendments may be necessary), but as a clear, written understanding of what the recovery requires from each party. The vendor needs to know that the client has regained control. The client needs to know that the vendor is committed to the recovery, not just to completing their contracted scope.

In some cases, the vendor relationship is beyond repair. If the SI has lost the capability or willingness to deliver, replacing them may be the only viable path. That is a significant decision with schedule and cost implications, but continuing with a vendor that cannot deliver is not a cheaper alternative. It is a slower and more expensive failure.

Step five: rebuild organisational confidence

A failing programme does not just damage the delivery timeline. It damages the organisation's confidence in the transformation itself. Stakeholders who were engaged become sceptical. Business leaders who were supportive become resistant. The executive sponsor who championed the investment starts distancing themselves. This erosion of confidence is as dangerous as the delivery problems, because without organisational support, even a technically successful recovery will fail at adoption.

Rebuilding confidence requires two things. First, transparent communication. The steering committee, the sponsor, and the broader organisation need to know what went wrong, what is being done to fix it, and what the realistic path forward looks like. Pretending that a recovery plan is just a "revised schedule" does not fool anyone. It confirms that leadership is not being honest about the situation.

Second, early visible wins. The recovery plan should identify two or three deliverables that can be completed quickly and visibly. Not because they are the most important things, but because they demonstrate that the programme is moving again. In an HRIS programme, this might be completing a successful payroll parallel run. In an ERP programme, it might be resolving a long-standing integration issue. In an AI deployment, it might be delivering a working proof of concept that the business can see and validate. These wins do not recover the programme. They create the organisational permission to continue recovering it.