Why you need a reset, not a rescue

When a programme is in trouble, the instinct is to rescue it. Bring in help, stabilise the delivery, get the existing plan back on track. It is the natural response, and sometimes it is the right one. But it rests on an assumption that often goes unexamined: that the thing you set out to build was the right thing, and the only problem is that the building went wrong.

A rescue keeps the premise and fixes the execution. The goal stays fixed; you change the people, the sequencing, the resourcing, the delivery approach. This is the correct move when the original idea was sound and the failure is genuinely operational — the wrong team was assigned, the work was sequenced badly, a vendor underdelivered, the plan was reasonable but the execution was not. In those cases, rescue is faster and cheaper than starting over, and tearing the whole thing down would be an expensive overreaction to what is, at bottom, a delivery problem.

A reset does something different. It goes back to the premise itself and asks whether it was ever right. Was the problem correctly understood? Is the thing being built still the thing the business needs? Did the original scope reflect how the company actually works, or how someone hoped it worked? A reset can keep some of the work and discard the rest, or it can change the destination entirely. It is more disruptive than a rescue, it costs more, and it requires someone to say out loud that the original decision was flawed — which is precisely why it is avoided.

Here is the failure, and it is not choosing rescue. It is defaulting to rescue without ever asking the question. A rescue is the comfortable choice. It preserves everyone’s original decision, it does not require an executive to admit that the premise was wrong, and it frames the trouble as a delivery problem to be managed rather than a judgement to be revisited. So the organisation reaches for it by reflex — more resource, a recovery plan, a tighter grip on the existing scope — and pours effort into delivering, competently this time, something that was the wrong thing to build in the first place. That is the most expensive outcome available: not a programme that failed, but a programme that succeeded at the wrong objective.

The test is therefore not “how do we get this back on track.” It is one question asked before any recovery plan is written: if we were deciding today, with what we now know, would we still set out to build this? If the answer is yes — the goal is still right, the premise still holds, the trouble is in the execution — then rescue, and rescue hard. If the answer is no, or even an uncertain maybe, then no amount of delivery discipline will fix it, because the problem is not delivery. Recovering the schedule of the wrong programme just gets you to the wrong place on time.

I should be straight about something here, because the incentive is obvious. Someone in my position has every reason to tell you that you need a reset rather than a rescue — a reset is the larger, deeper, more involved piece of work. So treat the recommendation with appropriate suspicion, and notice that the error runs both ways. In my experience, organisations over-rescue far more than they over-reset, because rescue is the path of least resistance. But the opposite mistake is real: tearing down and rebuilding something that only needed its execution fixed, mistaking a delivery problem for a premise problem, and paying for a reset when a rescue would have done. The point is not that reset is the braver, truer answer. It is that the choice should be made by honestly testing the premise — not defaulted to in either direction because one option is more comfortable, or more profitable to whoever is advising you.

There is a third answer that the rescue instinct hides from view entirely, and it deserves naming. Sometimes the honest conclusion is that the programme should not continue at all — that the premise is gone, the conditions that justified it have changed, and the right decision is to stop and redirect the money to something that matters now. This is the hardest call of the three, because so much has already been spent, and the spent money argues loudly for continuing. But money already gone is gone whether you continue or not. The only question that matters is whether the next pound is better spent finishing this or starting something else. A good adviser will tell you when the answer is to stop. In my experience, most will not — because stopping ends the engagement.

So when a programme is failing, resist the reflex to rescue before you have earned the right to. Ask the premise question first. If the goal still holds, rescue it properly. If it does not, reset — and accept the disruption, because the alternative is to spend more money arriving more efficiently at a destination you no longer want. And if neither is honest, stop. The most expensive programmes are not the ones that fail loudly. They are the ones that are rescued, again and again, toward an outcome nobody would choose if they were deciding today.