The Quarterly AI Kill Review That Saves You Millions

Every enterprise I have worked with has at least three AI projects that should have been killed six months ago. They persist because nobody wants to be the person who pulled the plug. The result is predictable: budget bleeds, talent gets trapped on dead-end work, and the projects that actually matter get starved. Here is the quarterly review framework I built after watching $14M evaporate across two failed AI programs at a Top 5 bank.

Why Your Current Review Process Fails

Most AI portfolio reviews are status meetings dressed up as decision forums. The project lead presents slides showing 'progress' measured in completed sprints, models trained, or data pipelines built. The steering committee nods, asks a few questions, and moves to the next project. Nobody asks the question that matters: should this project still exist?

I tracked 23 AI initiatives across three fiscal years at one bank. Seventeen of them had a moment, usually around month four, where the team quietly knew the project was in trouble. Data quality was worse than expected. The business sponsor lost interest. A vendor delivered something that solved 60% of the problem for 10% of the cost. But the project kept going because the review process was designed to measure activity, not outcomes.

The average time between 'the team knows this is dead' and 'leadership officially kills it' was 7.2 months. At a loaded cost of $180K per quarter for a mid-size AI team, that delay cost roughly $370K per failed project. Multiply that across three or four zombie projects and you are burning over a million dollars a year on work that your own people have already given up on.

The fix is not better status reports. The fix is a review process designed to produce kill decisions, not comfort.

The Four-Signal Kill Framework

Every quarter, each AI project gets evaluated on four signals. Not KPIs. Not OKRs. Signals. The distinction matters. KPIs tell you how a project is performing against its plan. Signals tell you whether the plan itself still makes sense. A project can hit every KPI and still be a bad bet.

Signal 1: Business Sponsor Engagement. Measure it simply. Has the business sponsor attended the last two sprint demos? Have they responded to the last three decision requests within 48 hours? Have they personally tested the latest prototype? If the answer to two of these is no, the project has lost its buyer. It does not matter how good the model is. Without an engaged sponsor, there is no path to production adoption. Score this red, yellow, or green.

Signal 2: Data Reality vs. Data Assumption. Every AI project starts with assumptions about data availability, quality, and access. By quarter two, you know whether those assumptions were right. Ask the data engineer, not the project manager. What percentage of the originally scoped data sources are actually connected and usable? In my experience, projects that are below 60% data realization by month six never recover. They just keep discovering new data problems.

Signal 3: Production Path Clarity. Can the team draw, on a whiteboard in under five minutes, the exact path from current state to production deployment? Not a roadmap. Not a Gantt chart. The literal sequence: model finalized, testing complete, IT security review, infrastructure provisioned, change management done, users trained, go-live. If they cannot draw that path clearly, they do not have one. I have seen teams build impressive models that sat in notebooks for 18 months because nobody planned the last mile.

Signal 4: Competitive Obsolescence. Has a vendor, open-source project, or API emerged in the last 90 days that delivers 70% or more of this project's target capability? This is the signal most teams refuse to acknowledge. You started building a custom document classification model 10 months ago. Three months in, a major cloud provider released a service that does exactly that for pennies per call. Your team knows about it. They have probably tested it quietly. But nobody wants to say that their year of work just got commoditized. You need to create space for that conversation.

How to Run the Review Without Politics Killing Honesty

The framework above only works if people tell the truth. And people will not tell the truth in a room where killing a project means someone loses headcount, budget, or face. You have to design the incentives.

Rule 1: Killing a project is a success metric. I started tracking 'projects killed before waste threshold' as a positive metric for the AI leadership team. The waste threshold was defined as spending more than 150% of the originally scoped Phase 1 budget without a production deployment. Every project killed before that threshold counted as a save, and the recovered budget was reallocated to the team's remaining projects. Suddenly, the incentive flipped. Teams wanted to surface problems early because it meant more resources for their surviving work.

Rule 2: Separate the review from the reviewee. The project team presents the four signals, but they do not make the recommendation. A separate review panel of three people, one from finance, one from the business unit, and one technical leader not involved in the project, scores the signals and makes the call. This removes the impossible position of asking someone to recommend killing their own project.

Rule 3: Pre-wire the kill criteria. Before the review, publish the thresholds. Two red signals in a single quarter triggers a mandatory deep-dive. Two consecutive quarters with any red signal triggers a kill-or-restructure decision. No exceptions. No 'let us give it one more quarter.' The criteria are public and automatic. This takes the personal element out of it. Nobody killed your project. The criteria did.

Rule 3 alone cut our average kill delay from 7.2 months to 2.1 months. That single change recovered an estimated $2.8M in one fiscal year across a portfolio of 11 active AI projects.

What to Do With the Wreckage

Killing a project is not the end. It is a reallocation event. And how you handle the aftermath determines whether your team trusts the process or learns to hide problems even deeper next time.

First, run a 90-minute post-mortem within one week of the kill decision. Not a blame session. A structured review with three questions: What did we learn about the data that we did not know at project start? What did we learn about the business problem that changed? What assets from this project (models, data pipelines, cleaned datasets, vendor relationships) can be reused? At one bank, a killed fraud detection project produced a data pipeline that became the foundation for three other projects. The project failed. The infrastructure it built did not.

Second, reassign the team within two weeks. People who just had their project killed are watching closely to see if they get punished. If they end up on the bench or in a dead-end role, every other team in the portfolio learns the lesson: never be honest about project health. Instead, move them to the highest-priority surviving project. Make the reassignment visible and positive.

Third, update your AI investment thesis. Every killed project should change how you evaluate the next proposal. If three projects failed because of data quality assumptions, your intake process needs a mandatory data quality assessment before any project gets funded. If two projects got obsoleted by vendor releases, your quarterly review needs a competitive scan built in. I maintained a simple spreadsheet called 'Kill Reasons' with a row for every terminated project. After two years, the patterns were impossible to ignore and they completely reshaped how we evaluated new proposals.

The goal is not to kill fewer projects. The goal is to kill them faster and learn more from each one. A portfolio where nothing gets killed is not a sign of good selection. It is a sign of bad governance.

Actionable Takeaway