A few years back, I was sitting across a boardroom table from a COO at a 250-person consulting firm. Six figures already spent. A delivery partner who kept sending their apologies. An internal sponsor who'd moved to a different role three months earlier and hadn't been replaced - not formally, not informally, not in any way that mattered. And a Gantt chart on the wall that had stopped reflecting reality so long ago it was basically decorative.
She looked at me and said, "Do we just start again?"
I've been asked that question more times than I'd like. And the honest answer - the one that's harder to give than either "yes" or "no" - is that it depends. But not on what most people think it depends on.
When a programme stalls, the instinct is binary. Fix it or kill it. Throw more resource at it, or cut your losses and walk away. I understand that completely - you've been burning political capital and actual capital, and you want a clean answer.
We need to either fix it or kill it. We can't keep throwing resource at something that isn't working.
But that framing misses a third option that's often the right one, and it also oversimplifies the first two.
Restart with a fundamentally different approach. This is appropriate when the original goals were sound but the governance, delivery approach, or partner was wrong - and when there's still enough institutional appetite to try again. The key word is "fundamentally." A restart that changes the logo on the status reports but keeps the same decision-making structure isn't a restart. It's a repeat.
Restructure what you have. This works when meaningful progress has been made that's worth preserving - data models, workflow changes, institutional learning, even just hard-won clarity about what doesn't work. I worked with a financial services firm where the platform migration was actually 70% complete and technically sound. The problem was that nobody had been empowered to make decisions about content, so the editorial team had been waiting for approvals that never came. That didn't need a restart. It needed someone with authority and a clear remit.
Cut losses and begin again with a different scope. Sometimes this is the right call. When the original project was solving the wrong problem, when the scar tissue inside the organisation is too deep to work through, or when the cost of recovery genuinely exceeds the value of what could be recovered - you stop. But you stop deliberately, capturing what was learned, not just walking away in frustration.
The diagnostic here isn't primarily about the project's technical state. It's about the organisational conditions for each option to succeed. I've seen technically disastrous projects recovered because the leadership team was aligned and motivated. And I've seen technically decent projects abandoned because the politics made forward progress impossible. The technology is usually the easier part to fix.
Before you decide which path to take, there are four questions that need honest answers. Properly honest, not "honest in a way that's comfortable for the people in the room."
One: what was the original goal, and is it still the right goal? This sounds obvious, but you'd be amazed how often a programme drifts so far from its original purpose that nobody can articulate what it was actually meant to achieve. I sat in a review meeting once where I asked this question and got four different answers from four different stakeholders. That's not a delivery problem. That's an alignment problem, and it probably existed from day one.
Two: who was accountable for delivery, and why did that accountability fail? Not "who was on the steering group" - who was actually accountable? Could you name them? Could they name themselves? In partnerships especially, accountability gets diffused across committees until it effectively belongs to nobody. In the recoveries I've been involved in, the ones with clear individual ownership succeeded. The committee-run ones didn't. Every time.
Three: what's salvageable? Data, integrations, workflow changes, vendor relationships, institutional learning about what your users actually need - some of this has real value even if the programme as a whole has stalled. But be ruthless about distinguishing "salvageable" from "sunk cost we're emotionally attached to." I've seen firms cling to six months of custom development that should have been scrapped because it felt wasteful to let it go. Sometimes the most expensive thing you own is the thing you refuse to throw away.
Four - and this is the hard one: what did you do that made success harder?
Not what the delivery partner got wrong. Not what the technology couldn't handle. What did the organisation do - or fail to do - that contributed to the stall? Was the internal team available when they needed to be? Were decisions made in a reasonable timeframe? Did requirements keep shifting because different partners kept adding their wish lists? Did anyone actually read the documents they were asked to review?
I've delivered this message to rooms where the temperature dropped noticeably. It's not a comfortable conversation. But a recovery that doesn't address the client-side failure conditions will reproduce them. I've written separately about why digital projects fail, and this is one of the recurring themes - the delivery partner gets blamed for an outcome that was co-created. If you're arriving at this piece after a painful stall, that companion article is worth reading, because the patterns are remarkably consistent.
You've done the diagnosis. You've picked your path. Now comes the structural change that makes this time different.
If you skip this - if you restart or restructure without changing the governance - you will end up back here in six months. I've seen it happen enough times that I'd put money on it.
The person accountable for the recovery should ideally be different from the person who owned the original programme. Not because they necessarily did a bad job - sometimes they did, sometimes they didn't - but because the programme needs a fresh mandate, not a continuation of an old one. If changing the owner isn't possible, then at minimum the existing owner needs a new, explicit mandate. Written down. Agreed by the partnership. Not just an assumption that they'll "carry on but do it differently this time."
The cadence needs to change too. Not a monthly steering committee where fifteen people dial in, half of them haven't read the papers, and the actual decisions get deferred to a follow-up meeting that never happens. A short, regular conversation - weekly or fortnightly, thirty minutes maximum - between the delivery lead and the most senior internal sponsor. The purpose is simple: surface problems before they become crises. When a programme stalls, it's almost never because of one catastrophic event. It's because small problems accumulated while nobody was paying close enough attention.
And you need new measures. Not a dashboard with forty metrics. Three or four specific, measurable outcomes that will determine whether the recovery is working, agreed before the restart begins and reviewed honestly at regular intervals. I worked with a law firm where the measures were: enquiry form completion rate, time from content creation to publication, and the number of support tickets related to the CMS. Simple. Clear. Hard to argue with.
Here's something it took me a few painful experiences to learn properly.
The fastest way to rebuild internal confidence in a programme that has consumed goodwill is to deliver something visible within thirty days. Not a strategy document. Not a revised project plan. Something that users can actually see and touch and use.
The quick win has to be credible, though. Not tokenistic. I've seen teams scramble to deliver a superficial change just to tick the box, and it backfires spectacularly. If the partnership has been waiting eighteen months for a functioning client portal and you show them a redesigned homepage banner, you haven't rebuilt confidence. You've confirmed their suspicion that nobody understands the actual problem.
The quick win needs to connect to the core frustration. At one firm we worked with, the stalled programme had been meant to fix a broken enquiry-to-onboarding handoff. The thirty-day deliverable was a rebuilt enquiry form with inline validation and an automated acknowledgement email. Not glamorous. But the managing partner could see enquiries coming through properly for the first time in two years, and suddenly the sceptics were a little quieter in meetings.
Selecting the right quick win is genuinely a skill. It needs to be small enough to deliver in thirty days, visible enough to matter, and connected enough to the programme's goals that it feels like progress rather than distraction. If you want to understand what a recovery engagement actually involves - what was found, what was done differently, and what the outcome was - the next piece in this series walks through a real example in enough detail to be genuinely useful.
In professional services partnerships, the politics of a recovery are often harder than the technical work. Most recovery frameworks treat this as a footnote. It's not. It's the thing that determines whether the governance reset actually holds or quietly reverts to the old patterns within eight weeks.
There are three audiences you need to manage, and each needs something different.
The backers - the people who championed the original programme. Their credibility is tied to it. If the recovery feels like a repudiation of their judgement, they'll either actively resist it or passively undermine it, sometimes without realising they're doing it. Your job is to frame the recovery as building on their original investment. "The vision was right, the execution model needed to change" is a message that lets them stay invested. "We're starting again because the last attempt failed" makes them defensive. Same facts, very different politics.
The sceptics. Every programme has them. The partner who said it was too ambitious. The operations lead who warned about the timeline. They were at least partly right, and they know it. If you ignore them, they'll watch from the sidelines waiting to say "I told you so" again. If you engage them early - specifically by showing that the governance failures they predicted have been genuinely addressed, not just renamed - you can turn them from critics into allies. Or at least into people who aren't actively working against you. Giving a vocal sceptic a specific role in the governance cadence - not a veto, but a voice - can shift the whole dynamic.
The board or partnership. They approved the budget. They've seen it stall. They're now asking pointed questions, which is fair enough. They need a clear, honest account of what went wrong - not a sanitised version - a specific explanation of what has structurally changed, and a revised investment figure with a defined decision point. That last part is critical. Don't ask for the full recovery budget upfront. Ask for enough to deliver the thirty-day win and the first phase, with a clear review point where the partnership can decide whether to continue. You're essentially saying: give us ninety days to prove this is different, and then we'll have an honest conversation about the rest. That's a much easier ask than "trust us again with the same budget."
If your recovery requires a fresh board approval, I'd recommend reading the piece on what every board should know before approving a digital transformation budget - it covers the questions that well-prepared boards are now asking, and knowing them in advance will make your pitch significantly stronger.
I mentioned earlier that I've been in the room when these conversations happen. I should be honest that I've also been part of programmes that stalled. Not always as the delivery partner - sometimes as an adviser, sometimes brought in after the fact. But I've been close enough to know that recovery isn't a clean, linear process. It's messy. People's feelings are hurt. There's blame that hasn't been fully processed. There are relationships that need repairing before any framework can work.
The five warning signs that a transformation is about to stall - which I've written about separately - are worth reading even if your programme has already stalled. Not because you can go back in time, but because recognising which warning signs you missed helps answer question four in the diagnosis: what did we do that made success harder?
The approach I've laid out here - diagnosis, governance reset, thirty-day win, political management - isn't a guarantee. Nothing is. But in my experience, it's the difference between a recovery that actually recovers and one that just delays the same outcome by another twelve months. And after everything you've already invested, you deserve better than a repeat.