Why most AI projects in SMBs fail — and what we do differently

Last autumn, the managing director of a mid-sized company showed me, with some pride, what they had done about AI. They had bought licences for one of the well-known AI assistants — for every office employee. They had run a workshop: external trainer, four hours, good feedback. Then he showed me the internal usage statistics: after three months, five people out of forty were using the tool regularly. Three of them worked in IT support.

"I don't get it," he said. "We did everything right."

They didn't do anything wrong. They did too little — and in the wrong order. This isn't the story of one company. It's the most common story I encounter. AI projects in small and mid-sized businesses rarely fail loudly, with a broken contract and bad blood. They fail quietly: the tool is bought, the workshop is held, and then daily work carries on exactly as before.

This essay contains no statistics from industry reports. I'm writing from experience — from companies where I've watched these projects up close, including the ones that didn't make it. The patterns repeat. Here are the six most common.

1. The project starts as a purchase, not a process change

The most fundamental mistake hides in the very first sentence a project starts with. "We're going to buy an AI tool" is a different project from "we're going to cut proposal preparation from two days to two hours." The first one ends with a signed contract. The second one ends only when proposals actually get produced faster.

When the goal is a purchase, the purchase is also the moment everyone responsible ticks their box. The tool is here, so we're done. But a tool by itself changes nothing — the proposal process is still the same, people work the way they always have, and the new tool waits for someone to "start using it." Nobody does, because nobody has a reason to.

A working AI project always starts with the process: which specific piece of work should become faster, cheaper, or less painful. The tool comes later — and is often the least important decision in the whole story.

2. A pilot without an owner

Nearly every failed AI project I've seen up close had one thing in common: nobody in the company was personally responsible for making it succeed. The project belonged "to management," which in practice means to no one. Management is too busy to track adoption. Employees sense a top-down initiative that will pass like all the previous ones. And it does.

The counter-example: in one of the companies I work with, the head of sales took over AI-assisted proposal writing herself. Not because anyone told her to, but because the bottleneck was personally suffocating her. Within six weeks she had a working routine — and then three colleagues adopted it from her, because they could see it working for her. That is the only way a new practice actually spreads: from the person who needs it to the people who see the result.

A pilot without an owner isn't a pilot. It's an alibi.

3. The wrong first process

For their first AI project, companies surprisingly often pick the hardest possible thing: a process that is business-critical, where mistakes are expensive, and where half the company is involved. The logic is understandable — "if we're going to invest, let's do it where the stakes are highest." But the first project has a different job than all the ones that follow: it has to build trust.

A good first process has three properties. A human reviews every output before it goes anywhere — so an AI mistake can't cause damage. The result is visible in weeks, not months. And the benefit lands with a specific person in their daily work, not with "the company" as an abstraction. Proposal drafts, meeting summaries, briefing materials before client visits, first-pass answers to routine enquiries — these are processes where trust gets built. Automated pricing or inventory decisions are a year-three process, not a week-three process.

4. The boring foundations get skipped

Nobody likes writing about this part, because it doesn't sell: a large share of AI projects actually get stuck on things that have nothing to do with AI. Data is scattered across spreadsheets only one person understands. The core system is fifteen years old and has no interface to connect to. The process that's supposed to be improved isn't described anywhere — it exists only in the heads of two employees, each of whom does it slightly differently.

AI on messy foundations doesn't build order. It builds faster mess.

That's why a serious transformation almost always starts with steps that don't look like an "AI project" at first glance: mapping the processes, cleaning up the key data, finally doing the system upgrade that's been postponed for years. That's not a detour. That is the road. Companies that skip this part come back to the starting line six months later — with less budget and less patience.

5. Training as an event, not a habit

A four-hour workshop is fine as a start. The problem is what follows — usually nothing. Skill with AI tools, like any skill, is built through repetition on real work. A single event with no follow-up produces a short wave of enthusiasm and then silence.

What works is short cycles: every month, one concrete task from people's actual work, a shared review of what worked and what didn't, and one new technique. Half an hour to an hour per employee per month. It isn't much — but after six months, people have six real examples from their own work behind them, not one demo from someone else's.

And one thing that gets underestimated: people need permission for bad first attempts. If the culture treats a failed experiment with a new tool as wasted time, everyone will quietly go back to the old way. A safe space to practise isn't a soft topic. It's a precondition.

6. Measuring the impression, not the effect

The last pattern is the most insidious, because it looks like success. The project gets judged by how convincing the demo was in the management meeting — not by how many hours of work are actually saved three months later. Demos are always convincing. So weak projects get declared successful, and good ones don't get funded, because their value doesn't look spectacular: "proposals get done faster" just isn't as photogenic as a talking robot.

The measure has to be set before, not after. How long does this process take today? How long should it take in three months? Who will measure it, and when? Three questions, ten minutes of conversation — and the project suddenly has a very clear definition of success that everyone can point to.

So what do we do differently

None of the above is rocket science — and that's precisely the point. AI projects don't fail because the technology isn't advanced enough. They fail because the basics get skipped.

So the sequence I use with clients is always similar. First, an inventory: where time and money actually leak in the company — not where AI seems interesting. Then a selection of small, fast wins: processes where a human reviews the output and the benefit shows within a few weeks; each one approved individually, none bigger than a few days of work. In parallel, foundations get fixed where needed, and the team runs monthly learning cycles on real work. Every step with a success measure agreed in advance.

And the goal — perhaps the most unusual part: that the company stops needing us as soon as possible. A transformation hasn't succeeded when the consultant leaves behind a nice report. It has succeeded when the team finds the next process on its own, improves it on its own, and measures the result on its own.

If you recognise any of the six patterns in your own company — you're not the exception, you're the rule. The good news is that every one of them is fixable, and usually without a big investment. It starts with one process, one owner, and one measure.