The usual explanation for a failed AI project is that the technology wasn't ready. That is seldom what happened. The technology worked fine in the demo. It is why the project got funded in the first place. What went wrong happened earlier, in the fortnight before anyone opened an editor.
The decision gets made backwards
A typical sequence runs like this. Someone sees a compelling demonstration. A conversation starts about where the business could use something similar. A budget appears. Then, and only then, does anyone go looking for a problem that fits the solution already chosen.
This is backwards, and it is hard to spot from the inside because every individual step feels reasonable. The tool is impressive. The enthusiasm is real. But the question being answered is “where can we use this?” rather than “what is costing us money?” Those two questions rarely have the same answer.
Nobody asked the people doing the work
Leadership knows the strategy. They rarely know which specific step in a process gets redone three times a week because a form field is ambiguous, or which report exists only because someone asked for it once in 2021 and nobody cancelled it.
The people doing the work know where the friction is. They can usually tell you in about twenty minutes. The problem is that they are seldom asked before the direction is set. By the time anyone consults them, the scope is fixed and the budget is committed.
The root cause was never found
A lot of manual work exists to compensate for something else that is broken. If two systems don't share data, someone re-keys it. If a form allows ambiguous input, someone cleans it up downstream. If a handoff is unclear, someone chases it.
Automating the compensating work leaves the original fault in place and adds a new system that depends on it. Sometimes the honest answer to “can you automate this?” is that you shouldn't. Fix the upstream form, or connect the two systems, and the work disappears entirely. That answer is cheaper and more durable. It rarely gets reached because nobody went looking for it.
Success was never defined in numbers
“Improve efficiency” cannot be verified. If the target is not stated as a number before the work begins, there is no way to know afterwards whether it worked, and the project gets judged on how impressive it feels instead. That is a poor standard. Impressive systems get abandoned all the time.
Something checkable looks more like this:
- Quote turnaround drops from two days to under four hours for eighty percent of enquiries
- Invoice reconciliation stops requiring a person except for flagged exceptions
- The team stops spending Monday mornings rebuilding the same report
Each of these can be measured. Each of them can also fail visibly, which is the point.
What to do instead
Start with the operation, not the technology. Spend real time with the people doing the work. Map how things happen rather than how the process document says they happen. Find where value is being lost, then ask what the cheapest durable fix is. Sometimes that is AI. Sometimes it is an integration, and sometimes it is deleting a step.
Then rank what is left by impact and feasibility, attach a number to the top item, and be willing to conclude that nothing on the list justifies the spend right now. A discovery process that cannot return “not yet” is not an audit. It is a sales process with extra steps.