Why do AI projects fail?

Most AI projects don't fail because the model was wrong. They fail because the business couldn't, or wouldn't, change the decision the model was trying to improve.

That's the one-line answer. The longer version is that there are about five predictable ways an AI initiative dies, and four of them are not technical. Understanding which one your project is heading toward, before the kickoff ideally, is the single highest-leverage thing a sponsor can do.

The five ways AI projects die

1. No one is accountable for the decision the model changes

This is the most common failure mode, and it's almost always baked in before a line of code is written. Someone in the business says "we want to use AI to improve churn." A data team builds a churn-risk model. The model works. It genuinely predicts churn better than the current heuristic. Then the model gets handed to the retention team, who already have a playbook, an SLA, a quarterly target, and no slack in their week for a new source of noisy signals.

The model becomes a dashboard. The dashboard doesn't get opened. Six months later the sponsor cancels the project and says "the model didn't deliver." The model delivered fine. The organisation never promoted anyone to act on it.

If you can't name the specific human, making the specific decision, whose week changes on the day the model ships, you don't have an AI project. You have a science experiment with a budget.

2. The success metric is a model metric, not a business metric

Accuracy, F1, precision, AUC. These are engineering metrics. They tell you whether the model is internally coherent. They tell you nothing about whether the business is better off. A churn model at 92% AUC that reduces churn by 0.3% costs more to build than it earned back. A demand-forecast model at 71% MAPE that cut stockouts in half paid for itself in a quarter.

The right success metric is stated in the currency the sponsor's P&L is stated in. Dollars. Margin points. Hours of skilled labour. Customer lifetime value. If a project's success criteria are phrased in engineering terms, the engineers will hit them and the business will still be disappointed.

3. The data foundation is pretending to be finished

Every AI project in a business over 50 people has a moment about two months in where someone says "the data isn't as clean as we thought." This is almost always understated. "Not as clean" usually means definitions differ between systems, the customer ID in the CRM isn't the customer ID in the ERP, there's no change-data-capture on the core table so the historical training data is a smoothed fiction, and nobody knows when the last join key broke.

The failure mode here isn't that the data is dirty. All data is dirty. It's that the team proceeds as if it isn't, trains on flawed data, deploys a model that works in the lab and decays immediately in production. Six weeks later the model is abandoned, blamed on "drift," and the real underlying issue (the data never supported the problem in the first place) goes unfixed.

A data readiness assessment before the build, not six weeks into it, is the best unit of insurance money can buy. It's what makes the difference between a project that ships and a project that generates a post-mortem.

4. The build team doesn't include anyone who'll run it next year

Consultancies love to ship. So does a good in-house engineering team. What neither does automatically, without being asked to, is design for the person who inherits the system in twelve months. The person who has to monitor drift, retrain when the world changes, explain the output to a regulator, debug when a new CRM field breaks the feature pipeline.

A project that ships beautifully and can't be operated cheaply is a failed project on a delay. You find out at month nine, when the first retrain is due, nobody on the team remembers how the feature store was built, and the model quietly gets turned off because nobody is willing to own it.

The fix: at kickoff, name the post-delivery operator. Not the sponsor, the operator. Design review goes through them. Budget for 15% of build cost in year-one ops, baked into the business case from day one.

5. The organisation hasn't decided whether it's doing AI, or doing a portfolio of AI projects

These are not the same thing. A business "doing AI" has a governance model, a prioritisation mechanism, a shared data platform, a clear decision rights framework for "when do we build vs buy," and an executive who owns the overall P&L of the AI portfolio. A business doing "a portfolio of AI projects" has eleven independently kicked-off initiatives, each with its own vendor, each rebuilding the same customer-360 from scratch, each showing green on their own scorecard, and collectively delivering less than the sum of the parts.

The first kind ships. The second kind fills a quarterly board slide and slowly gets deprioritised when the budget tightens. The difference is almost always one role. A senior leader whose job it is to kill duplicate initiatives, consolidate the stack, and say "no" more often than "yes."

So what actually works?

Three things, in order.

One: name the decision before you name the model. Every AI initiative should open with a sentence that reads "This project changes how [specific human role] decides [specific recurring decision] by [specific amount], measured by [specific business metric]." If you can't write that sentence, you're not ready to start. Write it, get the sponsor to sign it, and pin it above the Jira board.

Two: treat data readiness as a phase, not a footnote. A proper readiness assessment (schema, quality, lineage, access, governance) takes four to six weeks for a typical mid-market business. Budget it. Don't skip it. The teams that skip it pay for it tenfold at month three.

Three: design the operating model first, the technology second. Who owns the decision? Who monitors the model? Who signs off on a retrain? Who gets paged at 3am when the feature pipeline breaks? Every one of those questions has an answer the day the project launches, or it will have an answer the day the project dies. Pick the order.

These are unsexy moves. They're also the reason the same consultancies ship production AI quarter after quarter while others produce nothing but pilot decks.

Getting unstuck

If you're reading this partway through a project that's stalling, the playbook is similar but compressed. Stop the build. Go back to the decision. Rename the owner. Rewrite the metric. Rebaseline the data. If all four pass, the project restarts. If any fail, the most senior-level favour you can do for everyone involved is kill the project cleanly and redirect the budget.

We run that process on stalled initiatives as a specific engagement. It's usually faster and cheaper than people expect, and the hardest part isn't the diagnostic. The hardest part is telling the sponsor which of the five failure modes they're in.