Why 95% of AI projects return nothing, and the one-page test that fixes it
Most AI failure has nothing to do with model quality. It tracks with where you point it. Here's the one-page test that finds the part worth automating.
Every few weeks a version of the same number lands in my inbox, usually with a question mark after it: 95% of AI projects return nothing. It comes from MIT's Project NANDA, whose July 2025 report The GenAI Divide: State of AI in Business 2025 reviewed more than 300 public AI deployments, interviewed 52 executives and surveyed 153 leaders, then found that only about one organisation in twenty was pulling measurable value out of what it had spent. The other nineteen had something running. It just wasn't paying for itself.
Read that as proof the technology is overblown and you'll draw the wrong lesson, because the same report found a minority getting real returns out of the same models everyone else had access to. Whatever separates the 5% from the 95%, it isn't better AI.
Why AI projects fail has almost nothing to do with the models
The failure rate holds up in other people's research too. RAND puts AI project failure above 80%, roughly twice what it measures for IT projects that don't involve AI. IDC found that 88% of AI proofs of concept never reach production. BCG's 2025 work puts the share of companies generating substantial value at scale at 4%.
If model quality were the binding constraint, those numbers should have moved as the models improved, and they haven't. MIT's own explanation is what the report calls the learning gap, which in practice means the organisation never absorbed the thing it bought: the tool sat outside the workflow, nobody's job description changed, and the data it needed stayed locked in someone's head or someone's spreadsheet. The pilot worked fine. Nobody's Tuesday looked any different.
After watching a few of these up close I'd put it less politely. Most AI spending is tool shopping dressed up as strategy, where a company buys a capability first and then goes looking for somewhere to install it.
Speeding up the wrong step changes nothing
A business is a chain of steps, and its output is set by the slowest step in that chain rather than the average speed of all of them. Eliyahu Goldratt worked this out for factories in The Goal in 1984, and the logic transfers intact: improve anything other than the constraint and total throughput sits exactly where it was.
That applies to a 12-person agency as cleanly as it applied to a plant. Say quotes take nine days to go out because one person has to price every job by hand. An AI that drafts your proposals 40% faster will not win you a single extra job, because drafting was never what the queue was waiting on. You will feel more productive, and the revenue line won't notice.
Throughput is set by the constrained step, so an improvement anywhere else shows up as a nicer-looking process and an identical revenue line.
Humberto Inciarte formalised this for AI specifically in a 2026 paper called "Bottleneck-First Implementation" (DOI 10.5281/zenodo.20017463). It's a single-author, self-published piece, so take the framework rather than the authority, but the framework matches what turns up in every audit we run. Nick Saraev makes a similar argument from the build side: before you automate anything, check that it produces a tangible deliverable, that it hits a real revenue or founder-time pain, and that it's templatable rather than bespoke. His audience skews toward people building AI agencies, but the test travels fine to an operator.
Pointed at the wrong step, AI goes negative
This is the pair of numbers I'd put on the wall. Research out of Stanford and Carnegie Mellon, reported through BCG in 2025, compared two ways of applying AI to complex workflows.
Badly placed AI drags the work backwards, because you've handed a machine a process that a person was quietly holding together with judgement. The 42-point spread between those two numbers is the entire argument for doing the diagnostic work first.
MD Anderson spent $62 million and shelved it
The best-documented failure is still MD Anderson Cancer Center's attempt to build an oncology advisor with IBM Watson. Around $62 million in, the project was shelved without reaching clinical use. It demoed well for years without ever surviving contact with how the hospital actually ran.
The everyday version is smaller and far more common: a process that was already broken gets automated, and now it's broken faster and at higher volume. McKinsey has a line about this that I keep coming back to, that speeding up a low-productivity assembly line just gets you a faster low-productivity assembly line. Automation amplifies whatever you point it at, mess included.
Narrow beats broad by about two to one
There's a finding buried further down the MIT report that deserves more attention than the 95% does. Implementations that were vendor-led and narrowly scoped succeeded roughly 67% of the time, while broad internal build-it-ourselves programmes came in around 33%. Same companies, same models, double the hit rate from deliberately doing less.
One well-placed automation beats fifteen scattered ones, and it isn't close.
Five questions that find the constraint
Before you buy anything, answer five questions. They fit on a single page, and if you can't answer the second one, you're not ready to spend money yet.
- What is the single number that decides whether this quarter is good?
- Which step in the chain gates that number?
- What happens to that step when volume doubles?
- How long does work sit waiting at that step?
- If you removed the constraint entirely, what would the number become?
Here is the same page filled in for a 12-person commercial roofing company, so you can see what a usable answer looks like.
Question four is the one that pays for the exercise. Six days of waiting is a queue, and no amount of faster drafting shortens it.
Question four is where most owners go wrong, so it's worth being precise. The instinct is to hunt for slow tasks: the thing that eats three hours, the report nobody enjoys writing. The constraint usually turns out to be a queue rather than a task, a place where work sits waiting on one person, one approval or one decision. Ask where work piles up, not where work takes a long time.
Question five matters for a different reason. It sizes the prize, which is what tells you how much you're allowed to spend fixing it. If clearing the constraint is worth $40,000 a month, a $25,000 build is an easy decision. If it's worth $900 a month, you have just saved yourself a project.
Two of the most common answers, in our experience, are lead response time and anything that queues behind a single person's approval. If it's the former, the build is well understood and you can read exactly how we wire it up. If you'd rather interrogate your own data before you trust my guess, you can point Claude at your CRM and Slack and ask it where the pipeline stalls.
"But everyone says start small with quick wins"
They do, and small is fine. Random is the problem. A quick win somewhere away from the constraint is precisely how a company ends up inside the 95%: three tidy automations, a few hours saved, and a P&L that looks exactly like last year's. Pick something small if you want, as long as it sits on the step that decides your number.
The 5% aren't doing anything exotic. They found the one place the business genuinely jams, put something narrow on it, and made sure the people around it changed how they worked. That's available to a 12-person company as much as it is to a bank, and it costs a lot less than the tool shopping does.