Why AI projects in SMEs fail

Quite a few AI projects in SMEs have run aground by now. Usually not with a bang, but silently: the pilot is still running, nobody uses it, and six months later nobody mentions it any more.

The causes are remarkably dull. Below are the six we come across most often, and what you can do about them before you start.

The data was messier than everyone thought

This is number one by a wide margin. Customers who are in the system three times, products with different spellings, fields that were once used for something else and are now full of notes. A person can make sense of that. A system can’t.

What to do about it: include the clean-up in the project instead of denying it. It is dull work, it takes time up front, and it is the reason some projects take twice as long as promised. A supplier who doesn’t bring it up hasn’t looked.

There was no owner inside the business

If the project belongs to the managing director and the managing director is busy, nothing happens. If it belongs to the external party, it stops as soon as the invoices stop. A project needs someone who is actually inconvenienced day to day when it doesn’t work, and who gets the time to pick it up.

What to do about it: appoint someone, give that person hours, and accept that those hours really do come off other work. If that isn’t possible, postpone the project until it is. That is cheaper than stalling halfway.

The pilot never ended

A trial without an end date and without a criterion becomes a trial that runs forever. Nobody dares to say it doesn’t work, and nobody dares to scale up. That is the most common form of failure: it never officially failed.

What to do about it: agree in advance when you evaluate, what you measure and what the outcome means. Write down what a disappointing outcome looks like, so you recognise it when it arrives.

People were asked for form’s sake, not for real

The people on the shop floor are informed instead of involved. Then a system arrives that doesn’t fit how the work really goes, and people start working around it. You only notice when you ask why the numbers don’t add up.

What to do about it: build with the people who are going to use it, not for them. A technician who works with gloves on is not going to operate a screen with small buttons. He knows that, and you’ll hear it if you ask.

Too much was promised at once

Projects with a big scope and a story about the whole organisation rarely make it to the finish line in an SME. There is no room for a change that takes months while the ordinary work carries on.

What to do about it: pick one link in the chain that has value on its own, and make sure people notice within weeks that something has changed. After that you have the credibility for the next step.

Nobody talked about maintenance

An integration that works today breaks on an update of your package. An agent that performed well behaves slightly differently after a model change. If there is nobody keeping an eye on that, trust disappears faster than it was built.

What we misjudged ourselves

To be honest: we run into these things ourselves too. What we underestimate most is how many exceptions a process has that “basically always” goes the same way. That is why these days we build the narrow version first, let it run alongside the old way for two weeks, and only then decide the rest. It feels slower and is faster on balance.

A project you deliberately stop after six weeks is not a failure. A pilot that simmers on for a year and a half is.

When you need us and when you don’t

If you have an owner, a clear scope and a package that can simply do it, you don’t need an external party. Most of the six problems above are solved with discipline, not with hired help.

We are useful when an earlier project has run aground and you want to know why, when integrations and custom-built work are involved, or when you want someone who dares to say up front that a plan is too big. That last one is not a pleasant conversation, but it is cheaper than the alternative.