The dashboard says yellow. The math says you're already underwater.
Here is the scene I've walked into more than once: a steering committee, fifteen people deep, spending its fourth consecutive Thursday debating a 2% scope variance on a stalled ERP rollout. Meanwhile the program is burning roughly $180,000 a week on contractors logging hours against deliverables nobody can test. The status report on the screen is yellow. Everyone in the room knows it's red. Nobody wants to be the one to change the color, because changing the color means a conversation with the board.
That gap — between the color on the dashboard and the color in the bank statement — is where enterprise IT projects go to die. When a CIO tells me a project is "yellow," I assume it's red that hasn't been audited yet. The reason is structural, not emotional. McKinsey's analysis of large-scale IT project overruns found that projects above $15M systematically run 45% over budget and deliver 56% less value than the business case promised. Those aren't projects that drifted. Those are projects whose delivery model collapsed early and kept reporting "on track" because the reporting cadence rewarded optimism over evidence.
The instinct in the room is to add oversight: more reporting lines, a weekly risk-register review, a fresh PMO escalation path. That's the trap. You cannot supervise your way out of a broken build. More governance on a failing project just adds witnesses to the bleed. PMI's 2025 Pulse of the Profession report pegs roughly 11.4% of strategic investment as outright waste, and the largest single driver is the same one I see on the ground: operators wait too long to intervene because the dashboard gave them permission to wait. The first honest act of a 90-day turnaround is repainting the square red — out loud, in front of the people who'd rather not hear it.
Days 1–30: freeze the build, shrink the committee that broke it
The first thirty days are not about fixing anything. They're about stopping the damage long enough to see it. We freeze the build cold: no new code to production, no new vendor change orders, no recurring status meetings. The team's reflex will be to keep coding — to "make progress" — and that reflex is exactly what Gartner's 2025 ERP Implementation Success Metrics identifies as a top failure pattern: roughly 75% of major integrations fail because organizations course-correct without ever pausing the clock. You're tuning the engine mid-dive. Stop diving first.
Inside the freeze, run a 14-day forensic audit of the backlog. Not a retrospective, not a blameless post-mortem — an accounting exercise. Which committed scope has working, testable output? Which is vapor that's been marked "90% complete" for three sprints? Freeze billing on any external consultant whose deliverables can't be demonstrated in a sandbox. When a vendor warns you that pausing breaches the master services agreement, let them send the letter. Legal friction is cheap. Compounding integration debt on a deployment that doesn't work is not.
Then comes the part that makes the room go quiet: you dissolve the steering committee. The fifteen people who consensus-managed the project into red status will not consensus-manage it out. Replace them with a three-person decision cell — executive sponsor, technical lead, financial controller — with binding authority and no veto-by-attrition. The case for this isn't ideology; it's throughput. BCG's Digital Transformation Success Database shows programs that enact a formal 14-day hard stop to realign architecture carry a 68% higher probability of eventual on-time delivery than those grinding through rolling fixes. By day 30 the backlog is purged, the vendor contracts are repapered to tie payment to recovery milestones instead of logged hours, and the surviving scope is rewritten down to the minimum that actually has to ship.
Days 31–90: cut scope until it ships, then defend the decision
With the build frozen and authority concentrated, the back sixty days have exactly one job: get a stable, narrow thing into production. That means swapping the founding question — "what did we promise?" — for a colder one: "what is the smallest set of features that lets this system go live and stay live?" Everything else is a candidate for the cutting-room floor, including the demos that play beautifully in a board deck and do nothing in production. Harvard Business Review's 2025 study on enterprise IT sunk costs found that aggressively pruning around 20% of "nice-to-have" scope during recovery pulls final delivery in by an average of 4.2 months. The math favors the knife.
The expensive enemy in this phase isn't engineering — it's latency. Every approval that sits in someone's inbox costs real money and quietly tells the recovery team that nobody upstream is serious. This is why the three-person cell earns its keep: MIT Sloan Management Review's Agile at Scale metrics show that collapsing decision-making to three accountable people cuts decision latency by 83%. Run a daily cadence check where blockers get resolved in the room, not deferred to next week's standing meeting that you've already cancelled. Treat each scope decision like a trade on a desk: immediate, binding, logged, and not relitigated tomorrow.
What goes live on day 90 will be smaller than what was sold. It will be missing the feature someone fought for in the original charter. And it will be in production, stable, and no longer setting cash on fire every Friday. That is the whole trade. If you want a Monday-morning starting point: pull your current status report, list every committed deliverable, and put a single honest mark next to each — "demonstrable in a sandbox today" or "not." The length of that second column is your real status, regardless of what color the square is.
