How to Kill a Project That Leadership Loves

I watched a project that everyone knew was failing. The data pipeline didn't work reliably. The model accuracy is below the threshold we set at kickoff. The business unit that was supposed to adopt it built a workaround in the second month and hasn't looked back. Usage is technically non-zero because the QA team runs test queries, but nobody is using the outputs for actual decisions.

The SVP who championed it presented progress to the board two quarters ago. It's in the divisional OKRs. There's a vendor contract with eighteen months remaining. Three teams have people allocated to it.

Everyone knows. Nobody says it.

This is the hardest problem in enterprise AI, and it has nothing to do with technology.

Why killing projects is so hard

Failing projects in large organizations don't die. They enter a twilight state — officially alive, practically dead, consuming resources that could go to something that works. They persist because the incentive structure rewards continuation over confrontation.

The executive who championed the project has their credibility attached to it. Killing it means admitting the initial judgment was wrong, or at least premature. That's a cost most executives won't voluntarily pay, especially if the failure isn't dramatic enough to force their hand. A quiet underperformer can be managed. A public cancellation raises questions.

The PM or director managing the project has their career trajectory linked to it. They were given this initiative because someone believed in them. Raising the flag that it's failing feels like raising the flag that they failed. The instinct is to find a way to make it work — to adjust the metrics, redefine success, find a new use case, anything except the conversation that starts with "this isn't working."

The teams allocated to the project have adapted their work around it. They've built processes, hired contractors, made commitments. Unwinding that creates disruption and leaves people without a clear next assignment. Continuation, even unproductive continuation, is organizationally easier than discontinuation.

So the project continues. The status reports get vaguer. The metrics shift from outcome-based to activity-based. "Model accuracy" becomes "number of iterations completed." "User adoption" becomes "number of users with access." The dashboard shows green because the indicators were redefined to ensure green. And resources keep flowing to a dead initiative because nobody will say the obvious thing out loud.

The evidence you need

You can't walk into a room and say "this project is failing" based on intuition. The executive who championed it will ask for data. If you don't have it, the conversation becomes about your judgment versus their judgment, and you'll lose that fight.

Before you have the conversation, build the case. Not to be political — to be right, and to be able to prove it.

Original success criteria vs. actual performance. Go back to the kickoff. What did we say success looked like? What metrics did we commit to? Show the gap between the target and the current state, using the project's own definitions. This is the most powerful evidence because it's not your framework — it's theirs.

Resource consumption vs. value delivered. How much has been spent — not just budget, but people-hours, opportunity cost, the other work that didn't happen because these teams were allocated here? What has that investment produced? If the answer is "a model that nobody uses," the math speaks for itself.

Trajectory, not snapshot. A single bad quarter can be explained away. A trend can't. Show the trajectory. If accuracy has been flat or declining for three months despite active development, that's not a rough patch. That's a signal. If adoption peaked at launch and has declined steadily, that's not a training gap. That's rejection.

The conditions that would need to change. This is the most important part. Don't just say it's failing — say what would need to be true for it to succeed, and be honest about whether those conditions are achievable. The data quality would need to improve by X, which requires Y months of pipeline work that isn't funded. The business unit would need to change their workflow, which requires executive mandate they haven't received. The model would need to be retrained on data we don't have access to. Lay out the path to success, and let the gap between that path and current reality make the argument.

The framing that works

The Army taught me something about delivering hard assessments: candor without a path forward is just complaining. Assessment without recommendation is incomplete.

Don't frame it as failure. Frame it as conditions.

"The conditions that would make this initiative successful don't exist today. Here's what would need to change, here's what that would cost, and here's the timeline. Given those realities, I recommend we either restructure the initiative around achievable conditions or reallocate the resources to [specific alternative] where the conditions for success already exist."

This framing does three things. It depersonalizes the decision — you're not saying someone was wrong, you're saying the environment didn't cooperate. It demonstrates rigor — you've thought through what success requires, not just what failure looks like. And it gives leadership a choice, which is what they actually need. Kill the project, restructure it, or fund the prerequisites. Those are real options. "Keep going and hope" is not.

The executive who championed the project needs an off-ramp that doesn't feel like a public admission of failure. "We've learned from this initiative that our data infrastructure needs investment before this class of AI application is viable, and I recommend we redirect these resources to that foundational work" is an off-ramp. It reframes the cancellation as a strategic pivot. It preserves the executive's narrative that the initiative was directionally right, even if the timing was wrong. And it's probably true.

Why this is a leadership act

Killing a bad project is not a career risk. Letting it continue is.

The PM who raises the flag with evidence and alternatives demonstrates judgment, courage, and organizational awareness. Those are leadership qualities. The PM who lets a failing project consume resources for another two quarters because the conversation was uncomfortable demonstrates the opposite.

I've seen both outcomes. The people who raised the flag early — who built the case, presented it clearly, and offered alternatives — were trusted more afterward, not less. Leadership remembers who told them the truth when it was hard. They don't remember who kept the status report green while the project burned underneath it. Or rather, they do remember, and it's not favorable.

The worst outcome isn't killing a project that could have been saved. The worst outcome is the one that actually happens in most organizations: the project runs for another year, consumes another round of budget, produces nothing, and gets quietly shelved in a reorganization. Nobody learns anything. The resources are gone. And the next AI initiative starts with the same organizational scar tissue and the same reluctance to try.

Kill it early. Kill it with evidence. And redirect the energy toward something that can actually work.