Why AI projects run aground in mid-sized companies

AI projects rarely fail loudly. There is no outage, no crash, no moment when someone establishes that it does not work. They go quiet. The demo was good, everyone was enthusiastic, and six months later nobody uses it and nobody can say exactly when that stopped.

A widely discussed 2025 study by MIT's Project NANDA concluded that roughly 95 percent of the enterprise generative AI pilots reviewed had no measurable effect on profit and loss. That figure is not peer-reviewed and rests partly on self-reporting, so do not build policy on it. The direction is recognisable, though, and the question that matters is not exactly how high the percentage is but where it goes wrong.

In a company of fifty to three hundred and fifty people it goes wrong in five places. None of the five is a technical problem, and that is not a rhetorical opening. We have rarely encountered a trajectory that ran aground because the model was not good enough. We have encountered plenty that ran aground because nobody was responsible after delivery, or because the system fell over on exactly the cases people needed it for.

That distinction matters, because it decides where you put your attention and your budget. Believe it is a technology problem and you buy better technology. Know it is an organisational problem and you arrange four things up front that cost nothing.

What running aground actually means

The word failure does not fit well. Almost every project we encounter produced something that worked. The problem comes afterwards.

Running aground means: it works, and it does not become a way of working. There is a system doing its job and an organisation carrying on around it exactly as before. That is more expensive than a project stopped halfway, because you paid the bill and did not get the change.

One colleague explaining something to another. Whether the knowledge transfers is decided during the build, not after it.

The five places

One: the project that never got an owner

At delivery there is a project lead, a supplier and an enthusiastic group of users. Three months later the project lead has moved on to something else, because that is what project leads do.

The question nobody asked: who owns this from next month? Not who uses it, but who maintains it, who decides when a new exception appears, and who notices when quality slips.

A system without an owner does not collapse suddenly. It degrades slowly, because the world changes and the system does not. After six months it is wrong just often enough for people to fall back on the old way, and it happens gradually so nobody experiences it as a decision.

Two: the process nobody had written down

Every process in a company with history has exceptions. The customer always invoiced differently. The supplier whose lead time you routinely pad by three days. The rule in the handbook that has been wrong for three years.

That knowledge is recorded nowhere. It sits in the heads of people who have been there twelve years, and they find it so obvious they do not mention it when asked. Build on the description rather than the practice and the system works perfectly for the seventy percent standard cases and falls over on the rest.

And that is precisely the thirty percent where the work is. People do not then experience a system that saves seventy percent. They experience having to check it every time, and a system you always check is more expensive than no system.

What helps: the people who know the exceptions are not the sounding board, they are the source. Budget tens of hours from exactly those people, and schedule them before you start.

Three: the supplier who left with the knowledge

This is the core, and it is why we treat AI Capability as a separate category.

A party builds something, it works, the party leaves. Three months later something changes in your process and an adjustment is needed. Nobody internally can do it, so the supplier returns, at a rate, with a waiting time. The second request takes longer than the first, because the builder has since started another project.

That is not bad faith. It is the logical outcome of a brief that read: build this for us. Ask for that and you get exactly that, and not the ability to take it further yourself.

That ability is not something you add afterwards with a manual and a handover session. It only develops if your own people build alongside during the build, hands on the work rather than sitting in. That makes the build slower and it makes the difference between a system you have and a capability you are.

Strikingly, the MIT research points the same way but with a less obvious conclusion: of the trajectories run with an external partner, roughly 67 percent reached actual deployment, against roughly 33 percent of what companies built entirely themselves. So buying it in alone does not work, and doing it alone does not either. What works is building together and keeping the knowledge inside.

A stack of paper. The most expensive outcome of an AI project is not a failure, it is a document nobody opens.

Four: the success nobody could measure

Ask six months after delivery whether it delivered and you get a story rather than a number. People are pleased with it. It saves time. That feeling is real and it does not survive a management meeting where something has to be cut.

The problem was created up front. It was never agreed what you would measure it by, and inventing a measurement afterwards no longer works, because you have no baseline.

It need not be complicated. Hours spent on a process per month, order lead time, number of errors reported back. One number, recorded once, in advance. That is the difference between a project that gets budget next year and a project nobody raises again.

Five: the sponsor who changed jobs

Most first AI trajectories in mid-sized companies hang on one person. There is a director or manager who considers it important and who makes sure people get time.

That person changes jobs, gets a different portfolio, or has to solve something more urgent for a quarter. The moment the pressure lifts, the trajectory falls back on its own weight, which is usually not enough to overcome a ten-year-old habit.

Something else plays a part here: a first trajectory almost never has its own budget line. It rides along on an existing pot, which makes it invisible the moment money has to move. A trajectory that appears in a budget gets discussed before it dies. A trajectory that appears nowhere disappears without anyone taking a decision about it, which is exactly why nobody can point afterwards to when it stopped.

The test that exposes this is strict and fair: does this way of working survive the departure of the person who championed it? If it hangs on one enthusiast, it is not anchored, it is borrowed. Anchoring means at least two people can carry it without the first being in the room.

How it unfolds over time

Running aground has a recognisable rhythm. Knowing the pattern means seeing it coming while something can still be done.

The tipping point is month three, and it is almost always the same event: one exception that goes wrong and that nobody inside the organisation can repair. From that moment the question is no longer whether the system works well, but whether people still trust it. That is a far harder gap to close.

The practical conclusion: the most important week of an AI trajectory is not the delivery week. It is the week the first real exception turns up. Have someone in-house who can adjust it themselves at that moment and the trajectory survives. Have to raise a support ticket instead and it is lost.

What the companies who do get it right actually do

The exceptions do not stand out for their technology. They do three things differently, and all three are free.

They start small somewhere a mistake is awkward rather than damaging. Not out of caution, but because they know the organisation has to learn to trust something new, and you do not build that trust on a process where an error costs a customer.

They put their own people to work during the build, not after it. That makes the build slower and it means that in month three there is someone who knows where to look.

And they write down one number in advance. Not a dashboard with twenty indicators, one number. That is enough to have a conversation about facts six months later.

Why more technology fixes none of the five

Look back at the five. Ownership, knowledge of exceptions, transfer, measurement, anchoring. Not one improves with a better model, a more expensive licence or an extra integration.

Which also explains why the companies that do get it right are rarely the companies with the most technology. They are the companies that wrote down in advance who owns what.

It also explains a figure that looks odd at first: around 60 percent of trade and logistics companies express interest in AI, while only 7 percent have a defined strategy. That gap is not a shortage of technology. It is a shortage of decisions.

The five questions you ask up front

Ask them before you sign, of your supplier and of yourself.

1. Who owns this in three months, by name?
2. Who in our company knows the exceptions, and how many hours do they get?
3. Who of ours builds alongside, and what can that person change independently afterwards?
4. Which number do we measure today so we can measure it again in six months?
5. What happens to this trajectory if the sponsor changes jobs?

The third is the sharpest. A supplier made uncomfortable by it is selling you a system instead of a capability. A good party will actually welcome the question, because a client who can adjust things themselves calls less often about trivia and more often about something new.

Where to begin

The cheapest way to dodge these five is to take them into the diagnosis rather than the evaluation. The AI Readiness Scan ranks opportunities not only on return but on feasibility, and feasibility is precisely the sum of ownership, knowledge and mandate.

If you would rather see where your organisation stands on these points with no commitment, the AI Photo takes ten minutes and costs nothing.