Five ideas that stop
AI projects from finishingNone of them is a technical problem
Mistakes
5
Points where projects die
3
Preconditions before starting
4
Any of them technical
No
The five
Each one with what actually happens, and what to do instead
“With AI we can cut staff”
What gets said
The arithmetic looks clean: three support people a year costs this, the system costs that, payback in so many months.
What follows
Once the repetitive actions are taken away, what's left is all the hard parts — complaints, exceptions, judgement calls — and those consume more people, not fewer. What actually happens is the same people handling more, or people moving from moving things around to deciding things. The other end is worse: in a project aimed at reducing headcount, staff correctly conclude they're feeding data to their own replacement, and this system's rollout depends on exactly them — surfacing their experience, labelling exceptions, confirming knowledge entries. When cooperation hits zero, the project stops in week three.
Instead
Write the objective as “the same people absorb three times the volume”rather than “two fewer people”. The first can be said out loud and the second can't — and an objective that can't be said out loud gets quietly resisted during rollout.
“Do it all at once”
What gets said
If we're doing this, let's do the whole thing and avoid repeating the approval and procurement process.
What follows
Five lines starting together means five problems arriving together, with nobody able to tell which layer failed; diagnosing one means getting five groups into a room. Meanwhile nothing usable exists in the first month, so budget and patience run out first — and on the day these projects die, every line is usually nearly working.
Instead
Do one, run it two months, and let the real run logs choose the second. A single workflow module exists for exactly this: built from the start so the next thing attaches to it, so the first one is never wasted.
“Our process is messy — the AI will help us sort it out”
What gets said
Things are admittedly a bit chaotic internally, so we'll tidy it up as part of putting the system in.
What follows
That's backwards. Automation cements the current way of doing things and executes it faster and more thoroughly — automate a chaotic process and you produce chaos faster. And “sorting out the process” isn't a technical deliverable: who approves, how many stages, who signs off exceptions, whose definition wins when two departments disagree — those are management decisions, and no outside party can make them for you.
Instead
During the diagnostic we'll map the process and mark every point of disagreement, but the decisions are yours. Where a disagreement is unresolved, we recommend not automating that step yet — cementing something undecided costs more than doing nothing.
“Let it run fully automatically”
What gets said
If someone still has to watch it, what was the point of automating?
What follows
A system with no human checkpoints has no way of telling anyone when it's wrong. By the time a customer notices, it's the three-hundredth email or the three-hundredth image. And the actions that genuinely cause damage are few, and are precisely the ones you shouldn't remove a person from: spending money, committing to someone outside, writing to production data.
Instead
Keep checkpoints on those three categories and automate everything else — a deliberate checkpoint is design, not unfinished work. How a checkpoint reaches the right person, and what a useful alert has to contain, is part of what gets specified during delivery.
“We'll just buy a tool”
What gets said
There are dozens of them, priced monthly. Why build something?
What follows
Tools are general and your process is specific. What usually happens is that 80% of the features go unused, and the 20% that's slightly off is exactly where you needed it — it doesn't reach your ERP, your warehouse, your finance system or your internal approvals, so once the AI produces a result somebody still moves it across by hand. The gap is in that connecting and customising layer, which is where the real work is, and it's the part that can't be bought.
Instead
For testing the water, buying something off the shelf is genuinely the right move and we'll say so. But once this process becomes part of the business, data ownership and how deep it connects become the main questions — which is when self-hosting starts to matter.
On a timeline
Three moments where these projects usually die
The objective was written as “two fewer people”
From that moment every step requiring staff cooperation slows down: experience doesn't get surfaced, exceptions don't get explained, nobody confirms knowledge entries. Nothing goes wrong technically and the project still doesn't move.
A process disagreement nobody resolved
Two departments define the same step differently and neither will change. Development either stalls waiting, or picks one — and picking one is worse, because after launch neither side accepts it.
Nobody is working the review queue
New questions don't get added, the human answers don't flow back, and the machine is still working from two-month-old knowledge. Nothing is broken — it just becomes less accurate, and gradually people stop using it.
Before you start
Four preconditions — if one is missing, wait
The rules are settled
They won't be overturned next month. Don't cement something still being trialled — automation turns a temporary workaround into policy.
The information is in a system
Not in one person's head and not in a chat history. Data that can't be reached can't drive an automated process.
Someone can decide
Not just someone who has requirements, but someone with authority to change the process. Disagreements have to land on one person, or they stay open forever.
The volume is real
It happens every week. For something occurring three or four times a month, explaining the rules costs more than the time saved.
Which half of a role is safe to hand over is a different question, and it's answered on the role map.
Questions
The three follow-ups we get most
01We bought a system before and nobody used it. Why would this be different?+
The first question is which step broke last time, and in most cases it's one of three: it couldn't reach your existing systems, so results were still moved by hand; it was someone else's general logic and sat slightly off your process, and that gap had to be filled manually every day; or nobody owned it after launch and it drifted out of accuracy. The first two are what custom, self-hosted work addresses — connected to your systems, built to your process. The third isn't a technical problem, which is why it's written into delivery: who works the review queue and how much time it takes each week is agreed during the diagnostic, and if that can't be agreed, we'll tell you that this is a risk.
02Will you tell us anything is possible just to win the work?+
Every diagnostic output includes the part we recommend against — and that isn't a posture, it's our own economics: taking on automation that shouldn't exist means a longer delivery, an argument at acceptance, and a system nobody uses. That's a net loss for us. So what you receive at the end of a diagnostic is a list in three tiers: worth doing now, possible later, and we recommend you don't. The conclusions are yours to keep, including if you implement them without us.
03Someone on the team is openly against it. Do we push on?+
First work out what they're against. If it's fear of replacement, check whether the objector happens to be the person who understands the process best — usually they are, in which case they belong in the project rather than routed around it, and the launch order should change: ship the part that saves them time before the part that watches them. If the objection is “this step can't be automated, we'll lose customers”, they're probably right and worth hearing out in full. That kind of objection is the most valuable input in a diagnostic, which is why we specifically ask to talk to front-line people.
Next