These are patterns, not statistics
You have probably heard a number for how often AI projects fail. We are not going to quote one, because the figures in circulation come from other people's surveys of other people's projects and we have not run one ourselves.
What follows is what we have watched go wrong, described so you can recognise it before it happens, not afterwards. Each one has a tell, and the tells are visible early.
The tool arrived before the decision was made
A platform gets bought because it demonstrated well, and then the business tries to find work for it. Six months later the licence renews and somebody asks what it is doing.
The tell, early: nobody can say which process it replaces, in one sentence, without using the word efficiency.
The wrong step got automated
The visible step gets automated, usually the one that annoys someone most, while the actual constraint sits two steps upstream and is untouched. The annoying step gets faster and the process does not, because it was never the bottleneck.
The tell, early: the step was chosen because somebody complained about it, not because anyone measured where the time goes.
Nobody owned it, and nothing was measured
The project has a sponsor rather than an owner, and nobody wrote down what the number was before it started. It cannot be judged, so it is judged on impressions, and impressions of software are generous in month one and harsh in month six.
The tell, early: asked what success looks like, the answer is a description rather than a number.
The prototype was mistaken for the product
Something works impressively on a laptop, so the timeline and the budget get set from that. Then it has to run against real client data, on a schedule, with staff who must adopt it and obligations that must be met, and every one of those is work nobody costed.
This is the one we see most often and it is the least anyone's fault. The demo was real. It just measured the wrong thing.
The tell, early: the plan has a build estimate and no line for adoption, review or what happens when the system is not confident.
Nobody used it
The build is correct, the tests pass, and the team keeps doing it the old way. Usually because the new way is slower for them personally even though it is faster for the business, and nobody checked that before shipping.
Adoption is a design constraint from day one, not a training session at the end. The projects that stick are the ones where the people doing the work were better off on day one, not eventually.
The tell, early: the people who will use it have not been asked anything, and the business case is written in terms of what it saves rather than what it changes for them.
One of these was ours, and it was the number
Every failure above is somebody else’s, which makes them easy to publish. So here is one of ours, on the exact thing this site keeps sending you towards.
The readiness assessment was built to end in a score. It did. It returned 49 out of 100 on a real set of answers, and reading back through the questions that produced it made one thing obvious: no honest arithmetic got you from those answers to that number. The score was not wrong by a few points. It was a number wearing the clothes of a measurement.
It was removed. What the assessment returns now is a written view of where AI would pay in the business and where to leave things alone, and there is no number on it anywhere.
Why a score is so hard to give up
It is the single most persuasive thing a diagnostic can output. It compares, it ranks, it fits in an email subject line, and everyone asks for one. That is exactly why it survives in products where nobody can explain how it was calculated. If somebody scores your business, ask them to derive it in front of you.
What these have in common
Not one of them is a technology failure. Every one is a decision that was left until after the build, when it was expensive, instead of being taken before it, when it was free.
That is also why we are cautious about how quickly anyone can tell you what something will cost. The build is the predictable part.