The demo everyone applauds
It drafts the thing beautifully. It also skips the four steps before the drafting, which are where the three days went.
Why AI projects fail
Nothing exploded. It just stopped mattering.
Company AI projects almost never fail with an incident. They fail by becoming optional. The demo lands, a few people keep using it for email, and two quarters later nobody can name a piece of work that moved. Four reasons, none of them the model.
What failure actually looks like
The pilot doesn’t get cancelled. It gets forgotten.
Ask around a company six months after an AI rollout and you rarely hear it went badly. You hear it went fine. People liked it. It writes decent drafts. Nobody changed how a single piece of real work gets done.
That is the failure, and it is hard to see because there is no wreckage to point at. No budget owner has to admit anything. The project slides from initiative to utility, and the 10x never shows up.
The four causes below are in the order they occur. Each one is enough to end a project on its own, and the later ones only get their chance because the earlier ones went unfixed.
Failure 1 of 4 · Before a line is written
It automated work nobody actually does.
The project starts with a tool that needs a use, so somebody picks the use in a conference room. What gets built is a plausible-sounding version of the job rather than the job. The team goes back to doing the job.
How it shows up
How it shows up
Usage that peaks in week one
Everyone tries it because it is new. Almost nobody comes back, and nobody asks why in a way that produces an answer.
How it shows up
The workaround nobody reports
People run it, then quietly redo the output by hand. On paper adoption is fine. In practice the work got longer.
A real week of the job it was built for
What the pilot automatedEverything else in the week
The shape we find most often. The automated slice is real, and nowhere near where the hours are. Nobody built the wrong thing on purpose. They built it from a description of the work instead of from the work.
- The root cause is a missing week. Nobody sat with the people doing the job and watched it happen at the speed it actually happens.
- Descriptions of work are wrong in a predictable direction. They keep the interesting part and drop the waiting, the re-keying, and the four systems the task crosses on its way to done.
- The fix is unglamorous and cheap. A week of shadowing produces a ranked list with the hours behind each line — and a second list of what to leave alone.
This is the failure that makes the other three worth having. No amount of connections, rules or rollout can rescue a system that is automating the wrong twelve percent.
Failure 2 of 4 · During the build
It couldn’t reach the systems the work lives in.
Real work crosses six systems. Most projects connect the three that ship with a connector and stop. Every chain runs until it hits the billing platform, then waits for a person. That work didn’t get automated. It got interrupted.
Request lands
Connected
Pull the account
Connected
Check what they were billed
No connector — stops here
Draft the reply
Never reached
Send and log it
Never reached
One missing system, and the two steps after it never run. The dark stage is a gap rather than a safety checkpoint anybody chose. Somebody now has to notice the work is sitting there.
01
“We integrated with Slack and Drive”
The tools with an official connector go in during the first week and integration is declared finished. Those are rarely the systems the money moves through.
02
The vertical software gets a pass
The platform your industry runs on has an API and no connector. Building one is a week of work nobody scoped, so it becomes out of scope, so the chain breaks there permanently.
03
The internal tool is declared impossible
The dashboard your team built two years ago will never have an off-the-shelf integration. It is also where three of the answers live.
04
Setup is left to each person
A connection guide goes out and half the team never finishes it. The same workflow now works for some people and silently doesn’t for others.
- Partial access is worse than none. A workflow that completes eighty percent of the time still needs somebody watching the other twenty — which is most of the supervision cost and none of the relief.
- “No API” is not the end of it. When a vendor offers nothing, the browser is the integration — signed in, driving the same screens your team does.
- Connected once, for the team. Not a setup task each person works through alone on their own laptop.
Failure 3 of 4 · At handover
Nobody was ever allowed to trust it with anything that mattered.
With no stated limits, every manager sets their own by instinct, and instinct says keep the important work. The system gets the low-stakes end of the job, the value stays small, and the pilot never justifies a next phase.
| The work | Handed over? | The reason, when you ask |
|---|---|---|
| Internal summaries | Yes | Nobody outside sees it, so nobody had to decide anything. |
| First-draft emails | Yes, then rewritten | “It doesn’t sound like us” — and nobody ever told it how you sound. |
| Anything with a price in it | No | It might guess, and a customer will hold us to the number. |
| Anything a customer receives | No | There is no rule about who it may contact, so the answer defaults to nobody. |
| Anything that spends money | No | No limit exists, so the only limit is the one in the manager’s head. |
| Anything auditable later | No | Nobody could say afterwards what it did or why, so nobody risked it. |
- This reads as caution and behaves as failure. Every individual decision is defensible. The sum of them is a system that only touches work nobody was worried about — which is work with very little time in it.
- Rules are not a brake, they are the permission slip. Spend caps, a contact list, brand voice, a written list of what it must never guess at, and a named person it stops and asks. Those are what let a manager hand over something real.
- Written down beats hoped for. A policy nobody enforces produces exactly the same caution as no policy at all, because nobody believes it.
- Logged and attributable. If a manager can find out why something went out on Tuesday, they will approve more on Monday.
The tell for this failure is that nothing ever went wrong. A pilot with no incidents and no impact was not being run carefully. It was being kept away from the job.
Failure 4 of 4 · After it works
It never got past the person who built it.
This is the hardest one to watch, because the thing works. Somebody is getting genuine leverage. They spent a hundred hours to get there. It lives in their account, their prompts, their head. The other forty people have none of it.
Your power user
Proposal workflow daily
Month-end close monthly
Ticket triage daily
Account research weekly
Two more who figured it out
Ticket triage sometimes
Proposal workflow heard about it
The other forty people
Drafting emails occasionally
Everyone hired since
Nothing installed
The same rollout, counted by person instead of by feature. A pilot reported as a success is usually this picture with only the first column on the slide.
- A pilot of volunteers proves the wrong thing. It proves motivated people can get value from it. The question was whether the median person on the team will, and volunteers cannot answer that.
- Training built for the enthusiast excludes the people who needed it. The person who has never opened an AI tool is the one with the most slack in their week.
- The gap reopens the moment you stop. If the setup is not part of onboarding, every hire after the rollout starts at zero and the average slides back down.
- It compounds. Every month the difference between your best person and everybody else stays a hundred hours of private effort, it gets wider and more expensive to close.
The pattern
Four failures, four steps that prevent them.
None of these is a model problem, and none of them is solved by a better prompt. Each has a specific, boring step that stops it, which is why our process runs in the order it does.
| The failure | What actually went missing | The step that prevents it |
|---|---|---|
| Wrong work automated | A week of watching the job before anything got built. | Step 1 — Shadow |
| Couldn’t reach the systems | The connectors nobody ships: your vertical software, your internal tools, the vendor with no API. | Step 2 — Connect |
| Nobody trusted it | Enforced limits a manager set on purpose, and a log that answers for what it did. | Step 4 — Rules |
| Never left one laptop | The whole team installed and trained, and kept current as people join. | Step 5 — Roll out |
The five steps in full, week by week
Step 3, encoding how your team actually does the work, isn’t on this list because it is not where projects fail. It is what the other four steps exist to make possible.
Worth saying plainly
One thing that looks like failure isn’t.
Deciding a piece of work isn’t worth automating is a correct outcome. Some jobs are judgement the whole way down, some run four times a year, some are already fast. Automating those costs more than it returns.
We come back from a week of shadowing with two lists: what is worth building, and what to leave alone. The second is shorter, usually unwelcome, and usually contains the thing somebody was most excited about.
A project that built four things and said no to the fifth on purpose is not on this page. That is what the process is supposed to produce.
Recognise more than one of these?
Thirty minutes. Tell us what happened with the last one and we will tell you honestly which of the four it was, and whether it is worth another run.