Blog
AI projects do not fail at launch. They stall in month three.
Launch day usually goes fine. The thing works, somebody demonstrates it, a few people say it is impressive, and the invoice gets paid.
What happens next is quieter. Around week eight the person who does the work reopens the old spreadsheet, only for this one awkward case. By week twelve the spreadsheet is open every day. Nobody announces anything. Nobody files a report saying the project failed, because from the outside it did not: it was delivered, on time, to specification.
That is the failure mode this industry has, and it is well enough documented that nobody should be surprised by it any more.
ABOUT AN 11 MINUTE READ SOURCED TO PUBLIC RESEARCH NAMED, NOT PARAPHRASED
READ
What the published research says
Three findings, all public, all from people who are not selling you anything. We did not run this research. We are citing it, and you can go and read it.
Most pilots produce nothing measurable. MIT's NANDA work put the share of generative AI pilots producing no measurable return at roughly 95%. Not that the models failed. That nothing showed up in the accounts.
The failures are organisational, not technical. RAND's interview research with people who ran these projects found the causes sit in how organisations work, not in what the technology could do. Wrong problem chosen, no owner, no change to how anyone spends their day.
The gap is integration, not capability. BCG's analysis of where the money now goes points at the same place: the platforms sell the capability, and what is scarce is the work of getting it into the systems and the habits a business already has.
Put those three together and you get an uncomfortable summary. The technology is mostly not the reason your project stopped being used. The technology is the part that arrived.
The five ways it stalls
Written as scenes, because you will recognise the one you are in faster than you will recognise a category.
-
It had a sponsor and never had an owner
Somebody senior approved it. Nobody was ever named as the person who keeps it working, answers questions about it, and decides what changes next.
Sponsors approve. Owners maintain. A system with no owner has no route for a small problem to become a small fix, so small problems accumulate until people route around them permanently.
-
It was built on the clean case
Pilots run on the tidy version of the work. The well-formed enquiry, the invoice in the standard layout, the customer whose name is spelled the same way in both systems.
The messy cases are where the hours go, and they were never shown to anyone building it. So the system handles the tidy cases, the person still handles the awkward ones by hand, and since they are back in the old spreadsheet for the awkward ones anyway, doing all of it there is one less context switch.
-
Nobody agreed in advance what working would mean
No test written before the money moved. So at month three there is no way to settle whether it succeeded, and the question is decided by whoever is most confident in the meeting.
This is a survival problem for the project. An unmeasured system is defended by enthusiasm alone, and enthusiasm decays on a predictable curve.
-
The output needed a checker and the checker was not staffed
Anything that writes, drafts, classifies or summarises needs a person who reads it. That person is a real cost on a real calendar.
If nobody was given the time, one of two things happens. Either the output waits unread and the system is slower than the old way, or it ships unread and one embarrassing week later everybody quietly stops using it. The second one does more damage, because it also poisons the next attempt.
-
It rested on one enthusiast
One person championed it, learned it properly, worked around its rough edges and kept it alive. Then they changed jobs, or went on holiday, or got a busy quarter.
Adoption that depends on one person's attention lasts exactly as long as that attention. This is the most common single cause we see, and it is the easiest to prevent and the least often prevented.
The five things that prevent each one
ONE FIX PER FAILURE ALL FIVE ARE DECISIONS, NOT PURCHASES
- Name the owner in the room where the budget is approved. Not afterwards, and not "the operations team". A person, who knows they are it, and who has time allocated for it.
- Map the messy cases first. Ask for the last ten real examples, not a description of the process. The description is always tidier than the reality, and the gap between them is the project.
- Write the pass or fail test before the money moves, in the business's own terms, and sign it. "Ninety per cent of standard enquiries acknowledged within ten minutes, checked over a fortnight" is a test. "Improves efficiency" is a hope.
- Fund the review step inside the scope. Not in somebody's evening. If the review cannot be afforded, the system is smaller than you thought, and it is better to find that out at scoping.
- Train more than one person, on their own work. Two people minimum, on their real cases rather than a demo dataset, plus a written handover that exists on day one rather than on request.
None of the five is a purchase. All five are decisions somebody has to make out loud, early, when it is still cheap to make them.
READ
The uncomfortable one
Sometimes the right answer after mapping is to change how the work is organised and automate less of it than anyone expected.
That conversation is awkward for a supplier, because it produces a smaller invoice, and it is awkward for whoever approved the budget, because it means the problem was closer to home than the pitch implied. It is still usually the right answer.
A faster bad process is a bad process with a running cost attached. If the reason a task takes four hours is that it is done twice, in two places, by two people who do not know about each other, no system fixes that. It only makes both copies faster.
We say this on our own approach page.
Four signs, in month two, that yours is stalling
The useful part of all of the above is that it is visible early, if you know what to look at. None of these needs a dashboard.
The old spreadsheet is still open. Not as an archive. Open, on somebody's second screen, being edited. That is the single clearest signal there is, and it is usually visible weeks before anybody says anything.
There is a workaround and it has a name. When the people doing the work have developed a shared piece of folklore about how to get around a part of the system, that part is not going to be fixed, it is going to be routed around permanently.
A report goes out that nobody reads. Ask the recipient what was in the last one. If they cannot say, the reporting is theatre, and reporting theatre usually sits on top of a system nobody is watching either.
Nobody has asked for a change in six weeks. This is the counterintuitive one and it is the strongest. A system in genuine daily use generates requests, complaints and small ideas, constantly. Silence is not contentment. Silence means nobody is touching it.
If two of those four are true, you have about a month before it is easier to abandon the system than to revive it. It is worth spending a week on right now, and the week does not have to involve the original supplier.
What we do about it, since we are the ones writing this
Our method is built around this failure mode rather than around the build, and it is published in full so you can hold us to it or copy it.
The short version. Every paid step has a pass or fail test written and signed before that step starts. Training and thirty days of adoption support are inside the scope rather than sold as an upgrade. The written handover is delivered by default at go live, not on request, so you are not dependent on us to understand your own system. And the process map is built with the people who do the work, not only with the person who signed.
What we will not tell you is a number for your revenue, your traffic or your leads. There is no baseline in your market to promise against, and promising one anyway is a well documented way to lose a client in month four.
Read the method, not the pitch
If you have a system that is going quiet, the four signals above are worth an hour this week. If you are about to commission one, the five preventions are worth arguing about before you sign anything, with whoever is building it.
Six phases, real timelines, what we need from you, the risks we can already name, and what happens when a paid step fails its test. If after reading it you would rather talk, book a call.
Read next
- Our method, in full, including the exits from every paid step and the four things we will not do.
- Two languages, one inbox, a worked example of deciding the process before buying the software.
- The blog index, with the three strands and the questions we have not answered yet.
- Contact, to book a conversation or send a short message instead.