How to Kill an AI Project That Already Has Budget Approval

The hardest AI decision you will make this year is not which project to fund. It is which funded project to kill. I have shut down four AI initiatives that already had six-figure budgets approved. Every single time, someone told me I was wasting the investment. Every single time, killing it saved us more than continuing would have cost.

Why Approved Projects Are Harder to Kill Than Bad Ideas

An AI project with budget approval has organizational gravity. Someone championed it. A committee reviewed it. Finance allocated the dollars. Killing it means telling all of those people they were wrong. That is why most executives let bad projects limp along for 6 to 12 months past the point where anyone privately believes they will succeed.

At one bank I worked at, we had an AI-powered fraud detection project that got $1.2M approved in Q1. By the end of Q2, the model's false positive rate was 34%. The vendor kept saying they needed more training data. The project sponsor kept saying we were 'almost there.' We did not kill it until Q4, after burning through $890K. The remaining $310K we clawed back funded two smaller projects that actually shipped.

The math is straightforward. Every month you keep a failing AI project alive, you are spending between $40K and $120K in direct costs (compute, vendor fees, internal team hours) and an unmeasurable amount in opportunity cost. Your best people are stuck babysitting something that will not work instead of building something that will.

But nobody gets promoted for killing projects. That is the real problem. The incentive structure in most organizations rewards launching and completing. Not stopping. You have to decide whether you want to look decisive in the moment or look smart in 18 months.

The 3-Signal Test: When to Pull the Plug

I developed this after my third project kill. It is not complicated, but it forces honesty. If any two of these three signals are present, the project should be shut down or fundamentally restructured. Not 'monitored closely.' Not 'given another quarter.' Shut down.

Signal 1: The success metric has moved. When the project was approved, there was a target. Maybe it was 20% reduction in manual review time, or 15% improvement in prediction accuracy. If that target has been quietly revised downward, or if the team has started talking about 'learnings' instead of 'results,' that is Signal 1. At a top-five bank, I watched a team redefine success three times in nine months. The original goal was $2.4M in annual savings. By month nine, the team was celebrating that the model 'worked in a controlled environment.' That project cost $1.8M and saved zero dollars in production.

Signal 2: The timeline has extended past 1.5x the original estimate with no production deployment. AI projects run late. That is normal. But if you are 50% past your original go-live date and nothing is in production, the project has a structural problem, not a timing problem. The vendor needs more data. The compliance review found issues nobody anticipated. The integration with your core systems is harder than the architecture diagram suggested. These are not delays. These are the project telling you it was scoped wrong.

Signal 3: The internal champion has stopped defending it in public. Pay attention to body language in steering committee meetings. When the person who fought for this project starts saying 'the team is working through some challenges' instead of 'we are on track,' they already know. They just cannot say it because their credibility is attached. Give them an exit. Frame the kill as a strategic reallocation, not a failure. You will be surprised how quickly they agree.

The Kill Process: How to Shut It Down Without Creating Enemies

Killing a project badly is worse than not killing it at all. Do it wrong and you create political enemies, spook your vendor relationships, and make your team afraid to propose anything new. Here is the process I have used four times, and it has worked every time.

Step 1: Separate the people from the project. Before any announcement, have a private conversation with the project sponsor and the technical lead. Tell them directly: 'This is not about your performance. The conditions changed, or the assumptions were wrong. I need your help winding this down professionally.' In three out of four kills, the technical lead actually thanked me. They knew it was failing. They just needed someone with the authority to say it.

Step 2: Document what you learned, not what you spent. Write a one-page summary that focuses on three things. What did we learn about our data readiness? What did we learn about this vendor or technology? What adjacent use case did this work reveal? At one bank, a failed natural language processing project for customer complaints revealed that our complaint categorization taxonomy was broken. Fixing that taxonomy (a $40K effort) improved routing accuracy by 22% without any AI at all.

Step 3: Reallocate the budget within 30 days. If you kill a project and the money just goes back to the general fund, you have wasted the political capital it took to get that budget approved. Move the remaining funds to a specific, named initiative within 30 days. This turns 'we failed' into 'we pivoted.' I redirected $310K from that fraud detection kill into two projects: an automated document extraction tool ($180K) and a customer churn prediction model ($130K). Both shipped within six months. Both are still running.

Step 4: Tell the story publicly. In your next all-hands or leadership update, mention the kill. Say what you learned. Say where the money went. This does two things. It signals that you make hard calls. And it tells every other project team that delivering results matters more than protecting budgets.

The Real Cost of Not Killing: A $3.1M Example

In 2023, I watched a peer at another institution let an AI project run for 14 months past the point where it should have been killed. The project was an AI-driven credit risk scoring model. Original budget was $1.6M. Original timeline was 10 months.

By month 10, the model could not meet regulatory validation requirements. The team requested an additional $800K and six more months. Leadership approved it because $1.6M was already spent, and nobody wanted to write that off. By month 16, the model still could not pass validation. They brought in a second vendor to 'augment' the approach. Cost: another $700K. By month 20, the project was quietly shelved. Total spend: $3.1M. Total value delivered: zero.

If they had applied the 3-Signal Test at month 10, all three signals were present. The success metric had been revised twice. The timeline was at 1.5x. The original sponsor had moved to a different role and nobody was championing it. A kill at month 10 would have saved $1.5M and freed a six-person team for 10 months.

The sunk cost fallacy is the most expensive bias in enterprise AI. The money you already spent is gone whether you continue or stop. The only question that matters is: given what we know now, would we fund this project today? If the answer is no, kill it today. Not next quarter. Today.

Actionable Takeaway