Why automation projects fail, and how to start one that holds
Automation projects fail most often when they try to automate everything at once. Too many untested parts go live together, so something breaks where nobody can see it. Start with one system that works end to end on real work, with an owner, a log and an alert. Add the next only after that one holds.
You automated a few things and the simple ones are still running. The ones with any complexity in them started to fall apart, and now the team does those by hand again. Or you started a big project to fix everything, and months later it is half finished, with the old spreadsheet still open on someone's second monitor.
A quieter version of the same failure is an automation nobody remembers building. It stops, and someone loses hours finding out why. Scheduled jobs sit in the background that everyone has forgotten exist.
What usually gets tried
The usual fix is one large project. Automate everything in one go, or move the whole business into a new CRM over a few weeks. It feels sensible because the mess is large and a single clean start sounds better than many small repairs.
It rarely holds. The project is finished on paper while the team keeps the old spreadsheet because they cannot yet trust the new setup. Now there are two places to look, and the business has more work to keep in sync, not less.
Why it happens
A big rebuild puts a lot of untested parts into use on the same day. Each part depends on the others, so when one is slightly wrong, the fault shows up somewhere else, and nobody can tell where it began. Nothing has proved itself on real work yet, so there is nothing solid to stand on while you find the cause.
Systems that work well in the end almost always grew from a small one that worked first. The writer John Gall made this observation, and it is now known as Gall's law: a complex system that works grew from a simple system that worked, and one designed complex from the start rarely works and is hard to patch into working.
Signs you can notice in your own business
- A migration that was meant to take a few weeks and is still described as nearly done.
- The old spreadsheet is still in use, and people trust it over the new tool.
- The automations that survive are the simple ones. The ones with several steps or exceptions get switched off or worked around.
- Someone on the team says they would rather do it by hand than fix it again.
- An automation stopped and nobody can say who built it or what it was meant to do.
- Scheduled jobs are running that no one on the team can name.
What starting small looks like as a system
The rule is one system at a time. Pick the piece of work that follows the same steps every time and costs the most attention, and run it end to end on real work. The next system waits until that one has held for long enough that the team stops checking it by hand.
| Part | What it is | Why it keeps the system from going quiet |
|---|---|---|
| A named owner | One person who knows what the system does and looks after it when a tool changes. | A forgotten automation is one nobody owns. |
| A log of every run | A record of each time it ran, what it received and what it did. | When something looks wrong, you read the record instead of guessing for hours. |
| An alert that names the step | A message to the owner when a run fails, saying which step failed. | A break reaches a person the same day, not when a client mentions it. |
Because the first system is small, a fault has few places to hide. The second system goes on top of one that already works, which is how the complex whole grows from simple parts that held.
What stays with you
- Choosing which piece of work goes first. That depends on what is costing your team the most, and you know it best.
- Deciding when a system has held long enough for the next to start.
- Naming the owner for each system, and keeping that name current when people change roles.
The system behind this: one automation at a time, each with a named owner, a log of every run and an alert that names the step when something fails.
Questions
Why did the simple automations hold when the complicated ones failed?
A simple one has few parts, so there is little to go wrong and a fault is easy to find. A complicated one has many steps that depend on each other, and a small error in one shows up somewhere else. Build the complicated one from simple ones that already work.
Is a full CRM migration always a mistake?
No. It goes wrong when everything moves at once and nothing has proved itself on real work first. Moving one process at a time, with the old setup kept until the new one holds, keeps the risk small and the fault easy to find.
How do I stop forgotten automations from breaking without anyone noticing?
Give each one a named owner, a log of every run and an alert that names the failing step. An automation with those three is never forgotten for long, because it tells a person when it stops.
Related
- What a reliable automation looks likeFive properties any automation should have, checkable by an owner who doesn't build: logged runs, named alerts, one send per approval, safe reruns, an owner.
- Questions to ask anyone building your automationsQuestions to ask an automation builder before you hire them, with what a careful answer sounds like and the answers that should worry you.
- Automations that fail without telling anyoneAn automation can stop for weeks before anyone notices. The usual causes, what not knowing costs, and what an alert should say when a step fails.
- Build it, hire for it, or install a system: a one-page decisionDecide whether to build it yourself, hire a person or set up a system by the kind of work it is, with a one-page memo to fill in for your own business.
- Should your own team build your automations, or should you bring someone in?When your own staff should build your automations and when to bring someone in: whose hours it takes, who fixes it at night, and what happens when they leave.
- What does coordination cost your business each year?Turn your leads, proposals and active projects into the hours your people spend coordinating each month, and what that time costs you in a year.