The short version
If a project is going to fail, it usually has by the end of the second week — long before anything is built. The failure is decided when the problem is described as a solution, when the awkward data source is assumed away, when nobody agrees what accuracy would be good enough, and when no one is named as the person who maintains it.
Failure one: the problem was described as a solution
“We want a chatbot” is not a problem. It is a shape, chosen before anyone examined the work. The project then delivers exactly that shape, correctly, and nobody uses it — because the actual cost in the business was somewhere else.
The tell is early. If the brief names a technology before it names a process, a person and a number of hours, the scoping has not happened yet. A useful brief says what happens today, who does it, how often, and what it costs in time or errors. That framing leaves the solution open, which is the only way the right one gets chosen.
Failure two: the data could not actually be reached
Nearly every process worth automating touches at least one system that resists. The warehouse tool with a nightly CSV export and no API. The supplier invoices arriving as email attachments in forty different layouts. The spreadsheet three people maintain that is the real source of truth.
These are known at the start and mentioned in passing, and they are almost always where the time goes. A project that budgeted two weeks for integration and six for modelling has it backwards. Ask, before anything is agreed, what the hardest data source is and what happens if it cannot be reached at all — if the answer is “the project doesn’t work”, that is the first thing to prove, not the last.
Failure three: nobody defined what “working” meant
This is the one that kills projects after they technically succeed. Something gets built, it does roughly the right thing in a demo, and then the argument starts: is 88% good enough? Nobody agreed a threshold beforehand, so the answer becomes a matter of opinion, and the loudest sceptic wins.
A definition of working has three parts and all of them need writing down before the build: the measurement, the threshold, and what happens to the cases that fall below it. “Extracts the correct total from 95% of invoices, and routes the rest to a human queue” is a specification you can pass or fail. “Automates invoice processing” is not.
The exception handling matters more than the accuracy figure. A system that is right 95% of the time and clearly flags the other 5% is deployable. A system that is right 99% of the time and gives no indication which 1% is wrong is not, because every output now needs checking — which is the work you were trying to remove.
Failure four: nobody owned it afterwards
The consultant leaves. The prompts live in a document nobody can find. Six weeks later a model version changes, the output shifts, and the person who understood why it was built that way is no longer available. The system quietly stops being trusted, then quietly stops being used.
Ownership is a contractual question, settled at the start: who holds the prompts, the configuration and the code; who is paid to maintain it; and what the handover contains. If the answer to any of those is vague at kick-off, it will be worse at handover, when the incentive to be helpful has gone.
What about the companies rehiring people they replaced?
It is a real pattern, and it is the four failures above compounding. The sequence is almost always the same: cost reduction chosen as the goal, headcount removed on the strength of a demo, no threshold agreed for when the system is trustworthy, and no owner to catch the drift. When the output turns out to need checking, the people who used to do the checking have gone.
The lesson is not that the technology cannot do it. It is that removing capacity before proving reliability inverts the order of operations. Deployments that hold up tend to run alongside the existing process until the numbers justify the change — which costs more up front and far less in total.
How do you avoid all four?
By treating the first two weeks as the deliverable rather than the overhead:
- Write the problem as a process, a frequency and a cost — not as a technology.
- Name the hardest data source out loud and prove access to it before anything else.
- Agree a measurement, a threshold and an exception path, in writing.
- Name the owner and settle who holds the code and prompts, at contract stage.
- Run in parallel with the existing process until the numbers say otherwise.
None of that is technical, which is why it gets skipped in favour of the interesting part. It is also where every failure above is decided.
Is the technology ever the reason?
Occasionally, and it is worth naming the cases honestly. Problems requiring guaranteed arithmetic rather than probabilistic judgement belong in ordinary software. Problems where being wrong once is catastrophic and no human review is possible are a poor fit. And problems where the necessary knowledge simply is not written down anywhere cannot be solved by a system that reads.
Those are genuine limits, and a practitioner who identifies one early has saved you a great deal of money. What they are not is the usual explanation. When a project fails, the far more common story is that it was aimed at the wrong thing, or nobody could agree it had worked.
How do we know if ours is going wrong?
Four signals, all visible well before delivery:
- The integration keeps slipping. Whatever is blocking access to that system is the project, and it is being deferred rather than solved.
- Nobody can state the accuracy threshold. If you ask three people and get three answers, the argument at the end is already scheduled.
- Demonstrations use curated examples. Ask to see it run on a random sample from a bad week.
- The people who do the work today have not been asked anything. The exception rules live in their heads and nowhere else.
Any one of those is worth pausing for. All four together mean the failure has already happened and has not yet been noticed.
What should we do if it has already failed?
Work out which of the four it was before commissioning anything else, because a second attempt that does not know why the first one failed usually fails the same way. In practice this is an afternoon: look at whether the problem was scoped as a process, whether the data was ever reachable, whether a threshold existed, and who owned it after handover.
The encouraging part is that all four are recoverable and none requires starting from nothing. Most rescued projects reuse the integration work and throw away the scope.