The Status Was Green for Nine Months. Then It Wasn't: A CIO's Project Reset Playbook

Nine months of green, then three weeks of free fall

The steering committee deck said the same thing every month: on track, on budget, green across the board. The ERP migration was the company's biggest bet of the year, the thing the board approved over the objections of two division presidents. Then, eighteen days before go-live, your program lead asks for "a quick sidebar." Integration testing against the order-to-cash module is failing at a rate nobody put in a slide. The status flips to red. And the number that comes out of that room isn't "three more weeks." It's "we're looking at Q3."

If you've sat in that chair, you know the gravity of it. The deck wasn't lying out of malice. Green was the only color anyone felt safe reporting, so green is what rolled up — until the gap between the slide and the commit history got too wide to paper over. That's not an engineering miss. It's a reporting incentive that hid the truth until hiding stopped working.

The data on what happens next is brutal. In Bent Flyvbjerg's analysis of more than 5,000 IT projects, roughly 1 in 6 becomes a "Black Swan" — an outlier that runs 200% over budget and 70% over schedule. On a $10M transformation, that's not a slip. It's a $20M event with your name on the P&L. And these failures cluster precisely in the kind of large, cross-functional ERP and platform programs that land on a CIO's desk under board scrutiny.

What the recovery-budget reflex gets wrong

The reflex is to throw mass at the deadline: more contractors, mandatory weekends, "one more sprint and we're there." It feels decisive. It is mathematically the wrong move on a software program this late, because every new engineer has to be onboarded into a codebase and a dependency map by the people who are already underwater — and that ramp tax compounds. McKinsey's study of large IT projects found they run, on average, 45% over budget while delivering 56% less value than the business case promised. A "recovery budget" that funds more of the same plan doesn't close that gap — it widens it faster.

So here's what I actually do when I'm brought in to reset a stalled enterprise program. Not a generic three-phase chart — a sequence built for the specific failure mode of a late, multi-stakeholder migration.

First, I stop reporting status and start measuring reality. I ignore the RAG deck entirely. I pull the defect arrival rate against the close rate. If you're finding new defects faster than you're closing them, you are not stabilizing — you are deteriorating, and no amount of "we're 90% done" survives that arithmetic. I read the commit history and the QA backlog, not the summary. Then I declare amnesty in writing: nobody gets fired for telling me the real timeline today, but anyone who keeps hiding it after today is gone. You cannot fix a program you can't see, and fear is what's blinding you.

Second, I run the scope to ground feature by feature. On almost every six-months-late ERP program I've touched, a thin slice of the scope — a custom workflow, a bespoke reporting layer, an integration to a system three people use — is eating the majority of the remaining effort and protecting almost none of the revenue. I make every stakeholder defend their feature with a dollar of protected revenue, a compliance requirement, or a core operational dependency. "The CFO wants it" is not a defense. Most resets I run cut 35–40% of remaining scope, and the cut features go to Phase 2, not the trash — which is how you get a yes instead of a fight. This is the same triage logic behind our 30-day project rescue approach.

Third, I retire the steering committee. The fourteen-person SteerCo that meets monthly is the structure that let green roll up unchallenged for nine months; it cannot be the structure that gets you out. I replace it with three people who can say yes in the room: the technical owner (what's feasible), the finance sponsor (what's affordable), and the operational lead who actually has to run the new system (what's usable). They meet fifteen minutes a day. Decisions happen on the spot. Nothing waits for next month's deck.

How to put the reset in front of your board without losing the room

The hardest sentence in this whole process is the one where you tell the board the old plan was fiction. Here's the thing — they suspect it already. What they're waiting on is whether you'll name it and lead, or keep selling green until it detonates. So don't frame the reset as a confession. Frame it as a capital decision you're making on their behalf.

Not this: "We're behind because the integration partner underdelivered." That's a blame story, and it leaves you looking like a passenger. Instead: "I'm rebaselining to guarantee the core order-to-cash and financial modules launch in Q3. I've cut $500K of low-value scope — the custom warehousing build moves to Phase 2 — so we hit a date the business can plan around." One version asks for forgiveness. The other demonstrates command of the asset. Boards fund command.

I've watched this exact move work. A logistics portfolio company had a migration stuck in committee for two quarters; we cut roughly a third of the scope, pushed the custom warehousing module to a later phase, and shipped the core financial engine on its original date. The win wasn't just a recovered project — it was a CIO who walked back into the boardroom with credibility instead of excuses. If you want the language for that first hard conversation, we wrote it down: how to tell the board a project is behind.

One caution from the Standish Group's CHAOS research: agile programs succeed roughly 3x more often than waterfall ones, but only when scope is allowed to flex. Try to lock time, budget, and scope all at once and the variable that quietly gives way is quality — which on an ERP cutover means corrupted financials and a board that trusts you even less. Let scope move so the date and the numbers hold.

This Monday: pull your defect arrival-versus-close rate and look at it without the RAG filter. If arrivals are winning, you don't have a staffing problem you can spend your way out of — you have a deadlock, and you need to reset before the next deck does it for you. If the gridlock is between functions rather than inside the code, start with breaking the cross-functional deadlock. Reset the program now, or write the explanation later.