Why AI projects fail in small companies, and it is rarely the tool

5 days ago
3 min read

Updated: 3 days ago

Introduction

The failures are remarkably consistent, which is encouraging, because a consistent failure pattern is avoidable. Very few of them involve the technology not working. The tool does what it was sold as doing, and the project produces nothing because of a decision made before it started or a condition nobody checked.

Reading the list in advance is worth more than any amount of technical evaluation. Each item is a question that can be answered in an afternoon, and answering them honestly will either substantially improve the odds or tell you not to proceed, which is also a good outcome and a much cheaper one.

1. Why AI projects fail in small companies rarely involves the technology

Adjust the diagnosis.

The product usually works. What fails is the data underneath it, the process around it, the ownership of it, or the honest need for it. Evaluating tools while ignoring these is the standard mistake. A useful habit is to spend as long on the four conditions as on the product comparison, which almost nobody does.

2. The data was not there

The most common single cause.

A business wants to predict something it has never recorded, or analyse a history that was never kept consistently. This is checkable in an afternoon and it is checked after purchase far more often than before. Where the data is missing, the correct project is six months of recording discipline.

3. Nobody owned it

The second most common.

Bought by the owner, championed for a month, and then nobody is responsible for the exceptions, the corrections or the questions. Tools without an internal owner are abandoned regardless of quality. The owner does not need to be technical; they need to be accountable and to have time allocated.

4. It was solving a problem nobody had

Enthusiasm ahead of need.

Adopted because it was interesting rather than because a specific cost or constraint existed. The test is whether anybody was complaining about the process before the tool appeared.

5. There was no baseline, so nothing could be proved

The quiet killer.

The tool may well have worked. Without a before measurement nobody can demonstrate it, so at renewal the decision is made on impressions, and impressions favour whoever speaks last.

6. The scope was too large

Ambition as a failure mode.

Attempting to transform five processes at once means none are finished, everyone is disrupted, and the project is remembered as a failure. One process, completed, changes the odds for everything afterwards.

7. The people using it were not consulted

The adoption failure.

A system imposed on the people who do the work meets resistance that has nothing to do with whether it is good. They also know the exceptions that will break it, and they were not asked.

8. The output was trusted without checking

The dangerous failure.

Not a project that produced nothing, but one that produced confident errors that reached customers. This is worse than a failed pilot and it is a consequence of skipping the training on when to distrust output.

9. Nobody wrote down what happened

Why the same failure recurs.

Without a record, the organisation repeats the attempt in two years with the same assumptions. A one-page note on what was tried and why it stopped is the cheapest institutional memory available.

Be careful about concluding from one failure that the whole category does not work. The far more common situation is that a particular application was attempted without the conditions for it, and a different application with the conditions present would have succeeded.

Conclusion

Check the conditions rather than evaluating tools, because the tool is rarely what fails.

Confirm the data exists and is consistent before buying anything, give the project a named internal owner, make sure it addresses a problem somebody was already complaining about, record a baseline so the result can be demonstrated, keep the scope to one process, involve the people who do the work because they know what will break it, train people on when to distrust the output, and write down what happened either way.