Why most AI projects fail, and what makes a good one

Most AI projects that fail were not wrong about where AI could help. They were wrong about what got built, in what order, at what scope, and against what counted as finished.

Picking the work is the easy half. A project can be aimed at a workflow AI genuinely suits and still fail, because the build started from the tech rather than the work, or the scope widened until nothing shipped, or what did ship never reached the people whose week it was meant to change.

A project starts from a workflow, not from the tech

Projects that work start from a workflow. Projects that don’t start from the tech.

“We have this workflow that’s painful, let’s see if AI helps” is a project. Someone owns the workflow. There is a record of how it runs now, which is what any later claim of improvement gets read against (see measuring AI results). One person’s week visibly changes if it works.

“Let’s build something with AI” is a hunt for a problem to fit a solution to, and the problems found that way tend to be aspirational. The success criterion arrives after the build, which means it arrives shaped to whatever was built.

Described pain and observed pain are different things

Ask a team which part of a job hurts and they name the part that takes attention. The part that takes the time has often stopped registering as work at all. Opening 3 systems, scrolling back through a history, reading a screen to find one field: none of it feels like the job, so none of it gets described, and a pilot scoped from the description automates the small half.

The cure is cheap. Whoever decides what gets built watches the work happen for a morning first, and scopes from what they saw rather than from what they were told.

Example

Let’s say Northwind Industrial, the invented 200-person distributor from how to find AI use cases, comes out of its scan with one pilot picked: AI-drafted outbound emails for the sales team. 45 minutes a lead, around 200 leads a month, a rep reading every draft before it goes out. It passes the fit screen cleanly, and nobody enjoys doing it.

Everyone in the meeting hears “writing the email takes 45 minutes”, so the obvious pilot is a drafting tool. Watching 2 reps work through a morning gives a different breakdown. About 10 of the 45 minutes is writing. The other 35 is assembly: opening the order system to see what the account last bought, checking the CRM for who the contact is and whether anyone has spoken to them this year, reading the last support ticket so the email doesn’t open by congratulating someone on a product that failed on them.

A drafting tool takes 10 minutes off a 45-minute task, and gets reported back as a disappointment.

The smallest useful version ships first

The temptation is to build the whole picture before anything is in use. The shape that holds runs the other way: the smallest version that does something useful goes out, and the rest gets built from what that version teaches.

What the first version leaves out is usually longer than what it includes, and each omission is a decision rather than an oversight. It can wait until the thing has been used enough to say whether it should exist.

AI is unusually punishing of plans made in the abstract. The model is not predictable the way ordinary software is, the workflow has edges nobody articulated, and people use the tool in ways nobody at kickoff guessed. A full version designed without those lessons usually misses.

Example

Let’s say the first version at Northwind reads the order system, pulls 2 years of order lines for one account, and produces a short brief plus a draft email. The rep reads both, edits, sends.

It does not write back to the CRM. It does not send. It does not cover the second country, whose catalogue and language are different. It handles first approaches only, with no follow-up sequences. Every one of those is on a list of things to decide later, not a list of things forgotten.

Most of the work lands after the first version ships

A working but imperfect tool the team uses is worth more than a polished one nobody has touched. It is what shows where the hard problems actually are, and they are rarely the ones predicted at kickoff.

As a rule of thumb rather than a law, 30 to 50% of total effort comes after the first version is in use. That is not overrun. That is where the value gets built, and 4 things account for most of it.

• Inputs the prompt never saw. Real work arrives in shapes the pilot data never contained, and the model answers confidently anyway.
• The review step nobody designed. Someone spots a wrong figure in a draft, and there is no agreed answer to what happens next.
• The system with no way in. A system in the chain offers no way for another program to read it, so the tool works from whatever that system exports, as often as it exports it.
• The second team that wants it slightly different. The same job against a different catalogue, in a different language, with different conventions.

Example

Let’s say Northwind hits all 4 inside the first 2 months. New prospects have no order history, and the first version writes a confident brief about a buying relationship that does not exist. A rep spots a wrong part number in a draft, and nobody has said whether to fix it quietly, report it somewhere, or stop using the tool for that kind of account. The freight quoting tool exports a spreadsheet once a week and offers no other way in, so the pilot works from a week-old file whatever the plan said. And the reps in the other country want the same thing against a different catalogue, in a different language, with a different opening convention.

Building for workflows that don’t exist yet

A company sets out to automate one workflow, and somewhere in scoping the conversation widens. Why build for one when a configurable system could handle this one and 100 more?

The configurable version takes far longer to build. Nobody knows what the other 99 workflows look like, because they do not exist yet. The one that does exist, with a real owner and a real record of how it runs today, gets served badly by a system designed to serve 100. The other 99 never arrive.

The version that holds is one thing, built cleanly. If a second workflow turns up later that genuinely overlaps, there is something working to extend. If it doesn’t, what exists is still a working thing rather than a half-built system no second team ever committed to using.

The same mistake sits one step earlier in build vs buy: a custom build commissioned for work an off-the-shelf tool already does.

Why the length of a project matters

Length is not a virtue in itself. It matters because a project’s assumptions decay while the project runs, and 3 things move underneath it.

The models move. A capability that needs careful work at kickoff can arrive as a default in the tool a few months later, and the part of the build that solved it becomes maintenance the business owns for no reason.

The team’s idea of what it wants moves, and it moves most the moment it sees version one. Everything specified before that is a guess about something nobody had used.

The people move. The person who wanted the work changes role, and a project that outlives its sponsor lands in a business that no longer remembers why it asked.

Nobody has established a right length for an AI project. A range quoted without evidence behind it describes how someone likes to work rather than something known about the field, and this hub has no better number to offer. The direction is not in doubt: the longer the plan, the more of it rests on conditions that have already changed by the time it ships. Some long plans are genuinely long problems, with heavy data work, regulated workflows, or retraining a model on the company’s own material. More often a long plan is a short pilot with an unscoped second phase attached that nobody owns.

What a project needs in people

Three jobs have to be covered, whatever the size of the business.

Someone who can see the whole workflow, including the parts that happen outside the team that owns it. That is usually the person who knows which system exports on Fridays and which one nobody has logged into since March.

Someone who can build: the prompts, the connection to the source system, the thing the user actually opens.

Someone whose week visibly changes if it works. Without that person, nobody tells the project that the drafts have started to sound the same.

Those can be 3 people or one, employees or a contractor or a vendor’s team, and the arrangement says nothing about whether the project is shaped well. One thing does not vary. After launch, someone inside the business owns the thing, because the workflow belongs to the company that runs it, and a system nobody inside owns stops being maintained the first time it breaks.

What “shipped” means

Shipped means in production. In the systems the team already works in. Used by the team whose work it serves. Documented well enough that someone other than whoever built it can keep it running.

Not a demo. Not a slide deck. Not “the prototype works on my machine”. Not “it’s built, it just needs rolling out”.

A short test of whether a model can do the task at all, usually tried on examples of past work, is called a proof of concept. It answers whether the idea can work. Shipped answers whether the work now runs differently.

The line being crossed is from “we built something” to “the work runs differently now”, and it is usually crossed quietly, in a week when an old habit stops.

Example

Let’s say Northwind crosses that line the week the reps stop opening the old template folder. Nobody announces it. They just stop going there.

What happens after that line, the running costs and the quiet drift, is its own subject.

Why most of them fail

The figure usually quoted for how many fail comes from The GenAI Divide, a July 2025 report from Project NANDA at MIT. It found that 95% of the organisations it studied were getting zero return from their spending on generative AI. Of AI tools built for a specific task, custom or bought from a vendor, 60% of the organisations had looked at one, 20% had run a pilot, and 5% had one in production with a lasting effect on productivity or profit. Among the causes it names are tools that do not fit how the work is done day to day. The report calls its numbers directional: they come from interviews with 52 organisations, a survey of 153 senior leaders and a review of over 300 public AI projects, the return was measured 6 months after the pilot, and each company defined success its own way.

None of the failures is exotic. A project anchored to the tech instead of a workflow cannot answer whether it worked, so it gets judged on whether people liked it. A project scoped from the described pain builds a tool for the part of the job that was described and leaves the part that took the time untouched. A project that widens into a configurable system serves the one real workflow badly and never reaches the rest. A project that never crosses into production stays a demo people remember fondly. A project nobody inside owns survives until its first bad week.

One outcome sits outside that list. Sometimes the work does not suit AI, the pilot runs honestly, and the answer is no. That is not a failed project. That is a pilot doing its job at pilot cost, on a question that gets far more expensive to answer later.

Common questions

Why do AI projects fail?

Most fail because of how the project is run, not because AI could not do the work. The common causes are starting from the technology instead of one specific workflow with an owner, building from what people say is painful instead of watching how the work is actually done, widening the project into a system for many workflows before one works, never getting past a demo into the tools the team uses every day, and nobody inside the company owning it after launch.

What share of AI projects fail?

The most quoted figure is 95%, from The GenAI Divide, a July 2025 report by Project NANDA at MIT, which found that 95% of the organisations it studied were getting no return from their spending on generative AI. It counted organisations rather than projects, and found that only 5% had an AI tool built for a specific task in everyday use with a lasting effect on productivity or profit. The report calls its figures directional: they come from interviews with 52 organisations, a survey of 153 senior leaders and a review of over 300 public AI projects, and each company judged success its own way.

What is an AI proof of concept?

An AI proof of concept is a short, small test of whether a model can do one specific task well enough to be worth building properly, usually tried on examples of past work. It shows whether the idea can work, not whether a team will use it every day. That only shows once a first version runs inside the tools the team already uses, and many AI projects stall between the two.

How do you implement AI in a business?

Start with one workflow that has an owner and a record of how it runs today, and watch the work being done before deciding what to build. Release the smallest version that does something useful, inside the tools the team already uses, and expect a third to a half of the total effort to come after it is in use. Someone inside the company has to own it once it is running, whoever built it.

Key takeaways

• A project starts from a workflow with an owner and a record of how it runs today. A project that starts from the tech invents its success criterion afterwards, shaped to whatever got built.
• What people describe as the painful part is the part that takes attention. What takes the time has often stopped registering as work at all.
• The smallest useful version ships first, and what it leaves out is a decision rather than an oversight.
• Roughly a third to a half of total effort lands after the first version is in use: inputs the prompt never saw, the review step nobody designed, the system with no way in, and the second team that wants it slightly different.
• A configurable system built for 100 workflows usually serves the one that exists badly, and the other 99 never arrive.
• Length matters because assumptions decay while a project runs: models move, the team's idea of what it wants moves the moment it sees version one, and the person who asked for the work moves on.
• Shipped means in production, in the systems the team already works in, used by that team, documented well enough that someone else can keep it running. A demo is not shipped.
• Whoever builds it, someone inside the business owns it after launch. A system nobody inside owns stops being maintained the first time it breaks.