What makes a good AI project (and why most fail)

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 where AI can help, 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”.

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

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.