The project that worked and changed nothing
August 22, 2026
The model beat the accuracy target it was given. The dashboard shipped on time and on budget. Six months later, nobody's Monday looks any different. This is the most expensive kind of failure, because from the inside it looks exactly like a success.
Everything went right
The brief was to predict which customers were about to leave. The team did that. They assembled the history, handled the class imbalance honestly, resisted the temptation to leak the answer into the features, and shipped something that beat the target it had been set. There was a demo. It went well. Somebody used the word “transformative”.
Then the list of at-risk customers began arriving each Monday in the inbox of a retention team that has capacity to call about forty people a week, has no discretion over pricing, and cannot offer anything a customer would change their mind for. The list is accurate. It is also inert. After a while it stops being opened, and nobody raises it, because raising it would mean saying that the transformative project produced nothing.
This is the elephant we call Mirage: solving the wrong business problem, perfectly. Note the adverb. Mirage is not the story of a project that collapsed. Those get post-mortems. It is the story of a project that met every requirement it was given, where the requirements were the mistake.
The evidence
Not a technology failure. A comprehension failure.
#1
root cause of AI project failure: misunderstanding — or miscommunicating — the problem that needs to be solved
RAND Corporation, The Root Causes of Failure for AI Projects, 2024 — from interviews with 65 experienced AI practitioners. A ranked finding, not a prevalence rate.
How can a project fail when everything worked?
RAND put the question to 65 people who had actually run these projects, and what came back top of the list was not compute, not data volume, not model choice, not talent. It was misunderstanding or miscommunicating the problem to be solved. Before any model. Before any data.
It is worth being precise about what that kind of finding is and is not. It is a ranking drawn from practitioner interviews, not a percentage of projects. Nobody is claiming a measured failure rate here, and anyone who quotes it as one is overreaching. What it does tell you is where experienced people, looking back at their own wreckage, locate the decisive error. They locate it at the start, in a conversation, before anyone opened a notebook.
That matters because it is the one cause that no amount of downstream excellence can compensate for. A weak model solving the right problem gets improved next quarter. A strong model solving the wrong one is finished the day it ships.
Why is the wrong problem so easy to pick?
Because the wrong problem is usually the legible one. It already has clean data, an agreed metric, and a shape the tooling recognizes. Churn prediction is a well-worn path with tutorials attached. “Our retention team has nothing to offer the customers it calls” is a messy organizational question with no obvious owner and no dataset.
So the available data quietly selects the problem. This is the mechanism worth naming, because it operates without anyone deciding anything: the team scopes toward what can be built, the sponsor approves what can be scoped, and the result is a project that is technically ambitious and strategically beside the point. Everyone behaved reasonably at every step.
Generative AI has widened this, not narrowed it. When almost anything can be prototyped in a fortnight, the constraint stops being capability and becomes judgement. Judgement is the part no tool supplies. The easier it becomes to build the wrong thing quickly, the more the choice of thing is the whole job.
How do you know the Mirage is in your room?
It is invisible while the project is going well, which is most of its life. These are the tells that show up before the ending.
- Nobody can name the person whose Monday changes if this works.
- The success criteria are all properties of the model: accuracy, latency, coverage. None are properties of the business.
- The problem was chosen after the dataset was found, rather than before.
- Asked what happens if the output says something inconvenient, the room has no answer because nobody has authority to act on it.
- The project is described by what it is (“a churn model”) rather than by the decision it changes.
What question would have caught it?
One, asked out loud at the start, and it is not a technical one: who does something different on the morning this works, and what is it? If the room cannot answer with a person and an action, there is no problem being solved. There is an artifact being produced.
The follow-up is harder and more useful: what would have to be true for that person to actually do the different thing? In the churn case the honest answer was that the retention team would need something to offer, which was a pricing decision nobody had made. That is the real project. It was never scoped, because it did not look like an AI project, and the thing that did look like one was cheaper to say yes to.
This is why Mirage is a strategy elephant rather than a technology one. The failure is upstream of every technical choice, which is also the good news: catching it costs a conversation, not a platform.
How do you get the Mirage out of the room?
The same three moves we bring to any elephant, pointed at this one.
Map
Start from decisions, not from data. List the handful of recurring decisions that actually move the result, and for each one ask what is currently deciding it and what it is missing. A backlog built this way is shorter than the usual one and every item has a named beneficiary. That is precisely what the usual one lacks.
Prove
Pick one, and define done as the decision changing, not as the model performing. Write the success criterion in the language of the business before any data is pulled, and agree who will be in the room to act on it. If nobody will change what they do, you have learned that in a week instead of two quarters.
Scale
Extend only what altered a decision, and keep the question attached to it. The habit that prevents the next Mirage is not a methodology. It is that “whose Monday changes?” becomes a normal thing to ask out loud, early, by people who are expected to ask it.
Find out which of your projects is a Mirage
The Elephant Safari names your herd in ten questions and ranks them by what they cost you. Or start from the business problem instead: nobody agreeing on what AI can actually do for you. Get the Mirage out of the room. Ask whose Monday changes.
Every figure in this article traces to a primary source. See it in Knowledge