Why Automation Projects Fail, From Someone Who Has Rescued a Few

Failure looks like a slow fade, not a bang

Nobody sends an email announcing that the automation project has failed. What happens is that go-live slips twice, the pilot runs alongside the manual process indefinitely, the internal champion moves on, and eighteen months later someone asks what happened to that system and nobody quite knows.

We have been brought in to rescue enough of these to notice that the same six patterns come up. Each has a tell that appears weeks before the budget does.

1. The scope described a wish, not a process

“Automate our order handling” is not a scope. It is a hope. A scope names the intake channel, the systems touched, the decision rules, the exception paths and what done means.

Warning sign: nobody can answer “what exactly happens to an order that arrives at 4:55pm on a Friday for an out-of-stock product?” If that answer does not exist, the specification is not finished, however long the document is.

2. Exceptions were discovered in production

The happy path is 10% of the work and 90% of the demo. The project is really about the customer with two delivery addresses, the product code that changed, the supplier who invoices in a different unit, the order that arrives as a photograph.

Warning sign: the specification has no section on exceptions, or it has one sentence saying they will be “handled manually” without saying by whom, how they arrive, or what happens if nobody looks that day.

3. Nobody inside the business owned it

An automation project needs an internal owner with authority to make decisions and about half a day a week to spend. Not a sponsor who reads reports — an owner who answers questions.

Warning sign: questions from the build team take more than three days to answer. That single metric predicts outcomes better than anything in a project plan, because unanswered questions become assumptions, and assumptions become rework.

4. The process changed while it was being built

You cannot automate a moving target. If the team is still arguing about how something should work, encoding it in software just makes the argument more expensive.

Warning sign: during the build, someone says “actually we've changed how we do that now”. Once is normal. Three times means the process was not stable enough to automate and the project should be paused, not pushed.

5. It was built for the demo, not the Tuesday

Systems that look wonderful in a walkthrough sometimes have no answer for volume, for the thing breaking at 2am, or for a person needing to override a decision for a good reason. Real operations need monitoring, alerting, retry logic, an audit trail and a manual override.

• What happens when the third-party API is down for an hour?
• Who is told, and how, when something fails?
• Can a supervisor force a decision through, and is it logged?
• Is there a way to reprocess yesterday's failures without re-entering them?

If those four have no answers, what exists is a prototype, whatever it is being called.

6. Success was never defined, so it could not be claimed

Without a baseline, the benefit is a matter of opinion, and opinion in month six is generally less generous than it was in month one. Measure before you build: minutes per unit, errors per hundred, elapsed time end to end.

Warning sign: the business case is expressed entirely in percentages with no underlying counts. “60% faster” than what, measured how, by whom?

What the successful ones did differently

1. Scoped one process end to end rather than five processes partially.
2. Wrote the exception list before the build, and priced it as part of the work.
3. Named one internal owner with real availability.
4. Ran in parallel with the manual process for two to four weeks before cutting over.
5. Took a baseline measurement before anything changed.
6. Kept phase one under about ten weeks, so being wrong was survivable.

None of that is clever. It is just the difference between projects that go live and projects that quietly stop being mentioned.

Frequently asked questions