Why do most AI projects stall after the pilot?

Most AI projects stall after the pilot because the pilot was the easy part. A demo proves the tool can work. Production asks whether the organisation will change how it works, and that is a different question with a different owner. Adoption tends to dip before it lifts, and most efforts quit in the dip.

The pattern is now well documented. What is less understood is that the stall is rarely a technology problem. It is a change problem wearing a technology costume, and it responds to the things change problems have always responded to: a clear owner, a changed workflow, an honest measure and real training.

Is it the technology that fails, or something else?

Almost never the technology. The models are good enough for a great many tasks, which is exactly why the pilot goes well. The trouble starts when a working tool meets an unchanged process.

Boston Consulting Group put a number on this in October 2024. In its survey, 74 per cent of companies were struggling to achieve and scale value from AI, with only 26 per cent moving beyond proof of concept to something that generated tangible value. BCG's own breakdown of where the difficulty lives is the useful part: it attributes around 70 per cent of the challenge to people and process, 20 per cent to technology and data, and only 10 per cent to the algorithms themselves.

That ratio is the whole story. When a firm spends its budget in the reverse order, most of it on the model and a sliver on the people, it is funding the 10 per cent and starving the 70. The pilot still works, because a pilot only has to prove the 10 per cent. The rollout stalls, because the rollout is the other 90.

What is the J-curve, and why does it catch teams out?

Productivity from a new way of working does not rise in a straight line. It dips first. People are learning, old habits are still in the muscles, the new tool sits awkwardly beside the old process, and for a while the team is slower than it was before. Then, if the effort holds, it climbs past where it started. Drawn out, the shape is a J.

The dip is normal and predictable, and it is also where nerve fails. A leader who expected a quick win sees output fall in month three and reads it as proof the thing does not work. The plug gets pulled at the lowest point on the curve, which is the one moment the curve was always going to look worst.

David Luria's book Flatten the AI J-Curve is built around this exact trap. It names the difficult middle stretch the "kill zone" and argues that the job of a leader is not to avoid the dip, which cannot be avoided, but to shorten it and to hold the organisation's nerve while it plays out. The teams that cross the dip are not the ones with better models. They are the ones who knew the dip was coming and planned for it.

Why does a pilot succeed and the rollout stall?

A pilot is a controlled experiment run by volunteers. It has a keen sponsor, a small motivated group, a narrow task and a lot of attention. Of course it works. None of those conditions survive contact with a company-wide rollout.

The Massachusetts Institute of Technology's State of AI in Business 2025 report found, in coverage by Forbes, that 95 per cent of generative AI pilots were failing to deliver a return, with only around 5 per cent of custom tools making the jump from pilot to production. The report's diagnosis is worth sitting with. Pilots stalled, it argued, because the tools could not retain feedback, adapt to context or improve over time, and because companies layered the technology on top of existing processes rather than redesigning how the work was done.

That last point is the one that separates a pilot from a rollout. In the pilot, an enthusiast bends their own habits around the tool and makes it sing. In the rollout, you are asking hundreds of people who did not volunteer to change a process they never chose, using a tool they did not pick, to hit numbers that have not moved to reward them for the trouble. The tool is identical. The conditions are opposite.

There is a quieter reason too. A pilot is forgiven its mistakes because everyone knows it is an experiment. A rollout is not. The moment a tool is company policy, its first wrong answer is held against it, and a single visible error can undo weeks of goodwill. Pilots earn trust in a room full of believers. Rollouts have to earn it in a corridor full of sceptics, and sceptics keep score.

What does redesigning the workflow actually mean?

The phrase gets repeated until it loses its edge, so it helps to be concrete. Redesigning a workflow means changing who does what, in what order, with what checks, so that the tool's strength is used and its weakness is caught. It is not adding an AI step to a process that already had ten steps. It is asking which of those ten steps still need a human, which can be handed over, and which should disappear.

Take a team that drafts customer replies. Bolt a writing tool onto the old process and you get the same ten steps plus a new one, so the work is slower, and everyone concludes the tool is useless. Redesign it and the shape changes: the tool drafts, a person edits and approves, the separate quality-check step folds into the edit, and the sign-off that used to take a day now takes an hour. Same tool, opposite result. The difference is that someone was allowed to change the steps.

This is why an owner without authority over the process is worse than no owner at all. They can only ever add the eleventh step, because the other ten are not theirs to touch. Redesign needs a person who can retire work, not merely add it, and retiring work means telling people their old task has changed. That is a conversation, not a configuration.

Who is supposed to own an AI project after the pilot?

This is where most efforts quietly die. During the pilot there is an owner, usually the person who championed it. When it becomes everyone's tool, it becomes no one's project, and a thing that belongs to no one drifts.

An AI rollout needs a single accountable owner with authority over the workflow it touches, not merely over the software. If the tool is meant to change how invoices are approved, the owner has to be able to change how invoices are approved. Hand the project to someone who can deploy the tool but cannot alter the process, and you have installed a faster way of doing the old thing badly.

Ownership also means someone whose job it is to hold the line through the dip. Without that person, the first bad month becomes an open question in every meeting, and open questions in meetings are how initiatives get starved. The owner's real work is not technical. It is keeping the decision made after it has already been made.

It matters, too, that the owner is senior enough to be listened to and close enough to the work to be trusted. Too junior and they cannot change the process or defend the budget. Too remote and they do not know what the work actually feels like on the floor, so their reassurances ring hollow to the people living the dip. The right owner is unusual precisely because they sit in both places at once, and firms that cannot find such a person often discover that is the real reason the project failed.

How do you measure whether it is working?

Badly measured, an AI project can look like a triumph and deliver nothing. This is the trap McKinsey keeps pointing at. Its 2025 State of AI report found that around 44 per cent of organisations were scaling AI across the enterprise, yet only about 37 per cent could attribute any earnings impact to it, and just 6 per cent qualified as high performers drawing significant value. McKinsey's phrase for the mood was that conviction in AI is growing faster than the returns firms can actually attribute to it.

The gap between adoption and impact is a measurement failure as much as anything. Counting seats, logins and prompts tells you the tool is being touched. It tells you nothing about whether the work got better, faster or cheaper. Those are the only numbers that matter, and they are the harder ones to collect, so they are the ones that get skipped.

Set the real measure before the rollout starts. Pick the outcome the tool is meant to move, take a clean baseline while the old process is still running, and be willing to see the number dip before it climbs. A measure you only invent after launch will always flatter the launch.

Why is training the first thing to get cut, and why is that a mistake?

Training is treated as a memo. A link goes round, a recording is posted, a lunch session is offered, and the box is ticked. Then everyone is surprised when adoption is thin.

Adopting an AI tool is not learning where the buttons are. It is learning to think differently about a task: what to hand over, what to keep, how to check the output, when to distrust it. That is a genuine shift in working habits, and habits do not shift because a memo told them to. They shift with practice, with a colleague to ask, and with permission to be slow while learning.

McKinsey's finding that around 80 per cent of employees report personal productivity gains from AI, set against how few firms convert that into earnings, is the training gap in one line. People are teaching themselves the tool for their own tasks. What they have not been taught, and what almost no memo can teach, is how the team's shared work is meant to change. That is a coaching job, and coaching costs time that a project running scared of its own dip is least willing to spend.

There is a cheaper version that works better than the memo and costs less than a training programme: make the good early users visible. Every team has two or three people who cross the dip fast and quietly rework their day around the tool. Give them a little time to show the others how, and adoption spreads along the lines people already trust. The memo asks a stranger to change. A trusted colleague showing their own screen asks far less, and gets far more.

So what actually gets a project across the dip?

The projects that cross the dip share a short list of unglamorous things. There is one owner who can change the workflow, not merely deploy the tool. The process itself is redesigned around what the tool does well, rather than the tool being bolted onto the old steps. There is an honest measure of the real outcome, baselined before launch and read patiently through the decline. And training is treated as a change in how people work, funded like one, coached like one.

None of that is about the model. All of it is about the organisation deciding, in advance, that the dip is the price of the climb and refusing to panic at the bottom of the J. That decision is cheap to say and expensive to keep, which is precisely why so few keep it.

The pilot was never the hard part. The hard part is the ordinary, human work of helping people change, and it starts the morning the demo ends.

So the question to ask before the next pilot is not whether the tool works. It will. The question is whether the organisation is ready to change the way it works once the tool has proved it can. If the answer is no, the pilot will be a pleasant afternoon that leads nowhere. If the answer is yes, the pilot is almost a formality, and the real project begins where most people think it ends.

← All posts