One of the hardest decisions a technology leader can make is to stop a programme that has already consumed significant investment. The sunk cost is real. The organisational commitment is deep. The reputational consequences of admitting failure feel significant.
And yet, in more than twenty years working inside and around large technology programmes, some of the best decisions I've seen leaders make were to stop, reset, or fundamentally restructure a programme that was no longer viable in its current form.
The difficulty is knowing when you've reached that point — and having the evidence to act on it.
The three options
When a programme is in serious trouble, there are broadly three paths available.
- Stop means terminating the programme entirely. The investment is written off, the team is stood down, and the organisation accepts that the original objective will not be met in this way. This is the right decision when the underlying business case has fundamentally changed, when the technical approach has been proven unworkable, or when the cost of continuing clearly exceeds any realistic return.
- Reset means pausing delivery, re-examining the foundations, and restarting with a clearer scope, stronger governance, and more realistic expectations. This is the right decision when the programme's original direction is still valid but the current execution has drifted too far from it to recover incrementally. A reset is not failure — it's a recognition that continuing on the current trajectory is more expensive than stopping and starting again more carefully.
- Rescue means intervening in a running programme to address specific, identified problems without stopping delivery entirely. This is the right decision when the programme has genuine momentum and value, but specific structural issues — governance gaps, dependency problems, vendor performance — are threatening outcomes that are otherwise achievable.
Why these decisions happen too late
The most common failure in this area is not making the wrong choice between stop, reset, and rescue. It's making the right choice six months too late.
Programmes drift into unviability gradually. Each individual decision to continue seems defensible. The next milestone is close. The vendor has committed to recovery. The team just needs more time. And so the investment continues, the options narrow, and the eventual intervention — when it finally happens — is more disruptive and more costly than it needed to be.
The reason decisions happen late is almost always the same: the information reaching leadership doesn't accurately reflect the programme's true trajectory. Reporting is filtered. Risks are underestimated. The gap between reported status and delivery reality widens over time until it becomes impossible to ignore.
By then, the window for a clean reset has often passed. What could have been a structured pause and restart becomes a crisis response.
What good decision-making looks like
Organisations that make these decisions well — at the right time, with the right evidence — tend to do a small number of things differently.
They maintain a realistic view of delivery trajectory rather than point-in-time status. A programme can be hitting its current milestones while clearly heading toward a significant problem three months out. Status reporting captures the former. Trajectory analysis captures the latter.
They separate the investment decision from the delivery narrative. The people running a programme have a natural incentive to continue it. The people funding it need an independent basis for deciding whether to do so. When those two things are conflated — when the investment decision is made primarily on the basis of information provided by the team seeking continued investment — the conditions for late, costly intervention are almost guaranteed.
And they act on early signals rather than waiting for certainty. By the time it is completely certain that a programme needs to stop or reset, the cost of that decision has usually already escalated significantly. The leaders who intervene most effectively are the ones who act when the signals are clear but the outcome is still uncertain — when there is still time to shape what happens next.
The role of independent assessment
Independent delivery assurance is particularly valuable in situations where stop, reset, or rescue is a possibility — precisely because it removes the conflict of interest that makes internal assessment unreliable in these circumstances.
An independent view of programme health provides the evidence base for a difficult decision. It separates what is genuinely working from what isn't. It identifies whether the problems are structural and fundamental or specific and addressable. And it gives leadership the confidence to act — either to intervene decisively or to continue with a clearer understanding of what needs to change.
Some of the most valuable work we do at Performance Radar is not telling leaders that their programme is in trouble. It's giving them the evidence and the clarity to act on what they already suspected — at a point when acting still makes a meaningful difference.
A question worth asking
If you are running a programme that has been in flight for a significant period without clear progress into production, or where leadership confidence has been quietly declining for some time, it is worth asking a direct question: if we were starting this programme today, with what we now know, would we start it in the same way?
If the honest answer is no — that's usually the signal that a reset conversation is overdue.
Performance Radar provides independent delivery assurance for technology leaders running complex programmes. To discuss your situation, schedule a 15-minute introduction.