Foundation first.
Almost nobody fails at the technology. They fail because the ground underneath was never laid, and it only shows up nine months in when the enthusiasm has gone and the licence is still billing.
The four foundations
What has to be true before any of it works
- Data you can trustWhere it lives, how bad it really is, which of it is fit to feed anything.
- Access you controlWho sees what, what leaves your estate, what you would have to disclose.
- A named ownerOne person accountable after go-live. The strongest single predictor of survival.
- A rule people followOne page on what staff may and may not put into a tool. Written to be read.
Do not bring me in for
- Building the modelHire an engineer. I will help you pick one and write the brief.
- Signing off a decision already madeIf you want validation, buy a deck from a large firm. It will cost more and agree with you.
- Replacing your teamI work with the people you already employ. They know the business better than I will.
- A twelve-week strategy documentNobody reads them and the market moves faster than the print run.
Five ways this goes wrong
These are the failure patterns that show up again and again, in twenty-person firms and in global enterprises alike. All of them are avoidable, and all of them cost more than doing it properly would have.
Starting with the tool
Deciding to do AI, then hunting for somewhere to put it. You pay to search for a problem that fits the answer you already bought.
Start from a pain that is already measurable, then ask whether AI beats the alternatives.
Layering AI on a broken process
A messy workflow underneath means AI inherits the mess at speed, and you pay a subscription for it.
Simplify first. Removing four approval steps often beats automating them.
Counting licences as adoption
Seats deployed is a procurement fact, not a business outcome. Usage on its own is not value either.
Agree one outcome number before anything is built, then check it honestly.
Treating data as a parallel track
Data preparation is typically 40 to 60 percent of the effort. Finding out afterwards is how budgets double.
Look at the data first, and pick something narrow enough that the data question stays answerable.
Spending on tools, not on people
Roughly eighty percent on technology, twenty on training and workflow. Then people quietly work around what you bought.
Closer to half and half early on. Talk to the people whose work changes before you change it.
Not finished at go-live
The common failure is not a bad launch. It is a decent launch that nobody looks at afterwards, until people quietly go back to the old way. Everything built here is handed over with a runbook and a recorded walkthrough, measured against one agreed number, and can be kept under maintenance so that somebody is still watching it a year later.
Built, then kept running
A runbook and a recording
What to do when it is wrong and how to spot it drifting, replayable for anyone who was not there at handover.
Kept up to date
Dependency and security updates, with a short written note on what changed.
Break-fix by email
A response within two working days and a fix within five, for systems under maintenance.
Check the one number
Agreed before build. If it has not moved, I say so and we change course.