Why do AI projects fail in small businesses?
Ask why AI projects fail and the answer is rarely the technology. They fail because nobody defined what done meant, nobody wrote the process down, nobody captured the before picture, nobody owned the thing after go-live, and the ambition was set at a level that could not be proven inside a quarter. Five causes, all of them managerial, all of them preventable for free.
The uncomfortable part is that these are the same reasons software projects have failed for thirty years. AI has not invented a new failure mode. It has just made it cheaper to start something and therefore easier to start something badly.
What does an undefined scope look like in practice?
It looks like a project everyone can describe enthusiastically and nobody can describe identically.
The test is brutal and useful: ask four people in the business what the machine will do, separately, in one sentence. If you get four different sentences, you do not have a scope, you have a mood. Build in that state and every review meeting becomes a negotiation about what was meant, which is expensive and sours the room.
The fix is a written definition of done before anything is built. What the machine will do, what it will never do, what it costs, and which numbers must move for it to be called a success. We put that on paper first because a decade of fixed-price building taught us that defining done before starting is the whole ball game. AI projects fail loudest exactly where that habit is missing.
Why does nothing being written down cause failure?
Because a machine can only follow a process that has been described, and most small businesses run on processes that live in someone's head.
This is the single most common stall. The build gets to eighty percent, then hits the twenty percent of cases where the answer is "well, it depends, Steve just knows". Steve does just know. Steve has known for eleven years. But nobody has ever written down the eleven rules Steve is applying, and until somebody does, the machine cannot apply them either.
Treat that as the first deliverable rather than a blocker. Getting the real process out of Steve's head and onto paper has standalone value: it survives Steve's holidays, and it makes the next hire faster to train, regardless of what you automate.
What happens when nobody captures a baseline?
The project ends in an argument about feelings, because the evidence needed to settle it was never collected.
Once the machine is running, the old numbers are gone. You cannot go back and count how many enquiries were missed last quarter or how long quotes really took. So the review becomes a discussion about whether things seem better, and that discussion is won by whoever is most invested rather than whoever is right.
Take the baseline in week one, before anything changes. Two or three numbers is enough. This costs nothing and it is the difference between a defensible investment and a permanent unexamined subscription. It is also the mistake we see cost the most, because it destroys the ability to make a good decision rather than just a good machine.
Why does an unowned machine decay?
Because the world it was built for keeps moving and nothing tells it.
Your prices change. A service gets added. A supplier renames a product line. A policy shifts. Six months later the machine is confidently telling customers something that was true in March. Nobody notices for a while, because it fails quietly rather than loudly, and quiet failure is the worst kind.
Two things prevent it. Someone ordinary owns it: not a technical owner, a person whose job includes saying "that reply was wrong, fix it". And there is a real monitoring and tuning arrangement rather than a subscription to nothing. A monthly fee should buy that against a stated standard. If nobody can tell you what the retainer produces, it is not maintenance.
Is ambition the real problem?
Overreach is the fastest cause of failure, and it usually arrives dressed as strategy.
The pattern is recognisable. Rather than fixing the one process that costs real money, the project becomes a platform, a transformation, a roadmap with four workstreams. Nothing is live for two quarters. Enthusiasm decays faster than the build progresses. Eventually a budget review arrives and there is nothing running to defend.
Small, then proven, then bigger is the only growth model we trust. One working machine, live in weeks, measured against numbers agreed in advance. If it earns its keep, it earns the next one. That sequence is set out in full on the method page, and what we build is deliberately organised as single problems rather than programmes.
How do you tell early that a project is going wrong?
Watch for three signals in the first fortnight: the scope sentence keeps changing, nobody can produce the baseline numbers, and the go-live date has no definition attached.
Any one of those is fixable in an afternoon at week two and very expensive at week ten. Ask for the one-sentence scope in writing. Ask for the baseline figures. Ask what "live" means specifically, and insist the answer involves real work with real consequences rather than a parallel rehearsal that nobody depends on.
A supplier who finds those questions unwelcome has told you something useful for free.
Where to look next
The Australian Government's AI Ethics Principles are a good governance checklist for a first project, and business.gov.au covers current support for digital adoption.
If you have a project that has stalled, or one you would rather not stall, tell us where it got stuck. Most of the time the fix is a page of writing rather than more software.