Most AI projects stop before the technology is the problem

I get asked fairly often why so many AI programmes end without anything to show. Not cancelled exactly. The meetings just get rescheduled twice and then stop appearing.

In my experience it is almost never because the technology failed. Most of them stop long before anybody finds out whether it would have worked, and they stop for three reasons that have nothing to do with AI.

Nobody owns the information

Every one of these projects needs information out of a system that somebody else looks after. The sales history. The maintenance logs. Six years of scanned documents in a folder on a shared drive that four departments quietly rely on.

The moment you ask for it, a question surfaces that has never had to be answered before: who decides whether this data can be used for this purpose. Often nobody knows, because until now the only people reading it were the people who created it. The request goes upward, sits, comes back with conditions, and a quarter is gone.

The fix is not technical and it is not interesting. Before the project starts, name the individual who can say yes to each source of information, and have them say it. If you cannot put a name against one of them, you have found your first problem, and it is better found in week one than month five.

Nobody agreed what success means

Ask five people in the room what this project is for and you will get five answers. Reduce headcount. Answer customers faster. Catch the errors before they reach an invoice. Look modern to a client who asked an awkward question. Give the board something to report.

None of those are unreasonable and they imply different builds. Because none of them was written down as the target with a number against it, there is nothing that can ever be declared finished. A project without a measure cannot succeed. It can only continue, and eventually somebody's budget cycle ends and it stops continuing.

The number has to exist before you start, because it has to be taken from the current way of working. Days to process an invoice. Share of quotes that go out the same day. Errors caught per hundred. Measure it while the old process is still running. If you only start counting after the new system is live, there is no comparison, and the question of whether it worked gets settled by whoever is most senior in the room.

It was only ever built to be shown

This is the expensive one. A pilot gets built to demonstrate what is possible. It works in the meeting, everybody is pleased, and somebody asks how soon it can go into daily use.

Then it emerges that it ran on a copy of the data taken in March, on one person's laptop, with the awkward records removed so the demonstration would run clean. None of it can go into production. The real thing is a different build at full price, and the budget was spent proving a point that was not seriously in doubt.

If you are going to build a pilot, build it against live data, on something a real user can log into, with the messy records left in. It will be less impressive in the room. It will be worth something the following month.

The same failure three times

All three are one pattern. Something everybody assumed had already been settled turns out to have been nobody's job. Who owns the data. What good looks like. Whether this is meant to survive the meeting it was built for.

None of that needs a specialist to spot. It needs somebody to ask out loud, early, and to be willing to hear an answer that pushes the start date back.

Three things to get in writing first

Before you commit a budget: the name of the person who can release each set of data, a single number that defines success measured on today's process, and a plain statement of whether what you are building is meant to run in the business or to be shown to people.

That takes an afternoon and it separates the programmes that finish from the ones that fade. If you would rather talk one of the three through before you put it in a document, my details are on this site.