Issue #10 was an admission: we shipped a chatbot, watched eight weeks of usage data, and turned it off. The question is, what told us it was time? But the honest follow-up question isn’t what — it’s who.
WHO had the standing to say “kill it” in week eight instead of week twenty, or never?
Most orgs never answer that question in writing, and the research puts a number on what that costs. RAND Corporation finds AI projects fail at roughly twice the rate of ordinary IT projects — more than 80% by their count, with misaligned purpose and no shared definition of success as the leading root cause. Gartner’s April 2026 survey of 782 infrastructure and operations leaders found just 28% of AI use cases meet ROI expectations and 20% fail outright — and of the leaders who saw a failure, 57% blamed teams expecting too much, too fast.
None of that describes a technology problem. It describes an authority problem — and the eight-week kill in issue #10 only happened because somebody outside the project team already had the standing to make that call.
Ask most IT leaders who can kill a live AI project and you’ll get a pause, then an org-chart answer: ”well, ultimately, steering committee,” or ”I guess whoever sponsored it.” Both answers are technically true and functionally useless. A steering committee is a quorum, not a decision-maker. A sponsor has the worst possible conflict of interest for this specific call — they’re also the person who has to explain, to their own boss, why the thing they championed didn’t work.
That conflict isn’t a character flaw. It’s structural. Ask the sponsor to be the one who pulls the plug and you’re asking them to write their own bad performance review. Most people, reasonably, delay. The project doesn’t die. It just stops being discussed in the room where it would need to be killed, and starts limping along on residual budget and inertia — a zombie project, still funded, that nobody will admit is finished.
The Framework
A real kill authority needs three things, and it almost never has all three by default:
Named at kickoff, not after trouble starts
If the first time anyone says out loud “who decides if we stop” is during a crisis, the answer will be whoever is loudest in that meeting — not whoever should actually own the call.Not the sponsor
The person with kill authority has to be someone whose performance review doesn’t depend on the project’s outcome. A CFO, a portfolio owner, a peer director outside the reporting line — anyone structurally distant enough from the win to be trusted with the loss.Tied to a pre-agreed threshold, not a vibe
“We’ll know it when we see it” is not a threshold. Issue #10’s chatbot had one: usage data that was unambiguous by week eight. Set the number, the metric, and the review date before the project ships — not after it’s underperforming and everyone’s incentivized to explain it away.
The Cost of Not Naming It
This is where RAND’s finding on misaligned purpose earns its keep. Without a named owner and a pre-agreed threshold, “is this working” becomes a matter of opinion, and opinion loses to whoever’s most invested in the project surviving. The metrics get reframed instead of the project getting killed: usage figures get scoped down to “the users who matter,” the timeline quietly extends to “give it two more quarters,” and the original success criteria get replaced with new ones the project can actually meet.
S&P Global’s 42% abandonment figure, reported last year, is mostly not the eight-week kills like issue #10’s. It’s mostly the slow ones — the projects that finally get killed eighteen months in, after two more headcount cycles were spent maintaining something the data already condemned back at month three.
The Artifact
One document, built at kickoff, not after: The Kill Criteria Sheet.
The metric that decides it — usage, revenue, error rate, whatever the project actually exists to move
The threshold number, set before launch
The review date it gets checked against
The name of the person who can say stop — someone outside the project’s own reporting line
What happens next if the threshold isn’t met — not “we’ll discuss,” a default action
It reads like paperwork. It functions as insurance — for the project, and for the sponsor who championed it. A named kill authority and a clear threshold don’t just make it easier to end a bad project. They make it safer to start ambitious ones, because everyone in the room knows there’s a clean exit if the data says no.
Issue #10 could kill a feature in eight weeks because somebody outside the project team already had the authority to say stop, and a number that told them when. That’s not a lucky coincidence — it’s a decision made in writing, before launch, by someone willing to be the answer to a question most orgs never ask out loud:
Who gets to say when this is over?
Plant Floor to Cloud goes out every Tuesday.
Who has kill authority on your current AI project? If you can’t name them, that’s the answer. Reply, I read every one.