Why automation projects fail

A step is automated because it exists, not because it is needed — often one that was introduced to work around a problem that has since been fixed.

Warning sign

Nobody can explain why the step is there, and the explanation you do get starts with the name of someone who left.

What to do instead

Before scoping anything, ask what breaks if the step is simply removed. Sometimes the honest answer is nothing, and the project ends there having saved more than it would have.

The build follows the process document, and the process document describes how the work was supposed to happen two years ago.

Warning sign

Discovery happened in a meeting room with managers rather than at the desk of whoever actually does the work.

What to do instead

Sit with the work as it happens. The informal steps — the second screen, the sticky note, the person everyone quietly asks — are exactly where the exceptions live, and they are never in the document.

The automation handles the clean case beautifully and has no defined behaviour for anything else, so the first unusual input dumps everything back on a person.

Warning sign

The design review covers what the system does and spends no time on what it does when it is unsure.

What to do instead

Design the failure path before the working path. Decide what happens on low confidence, on a system being down, and on input nobody anticipated — and make that behaviour visible rather than silent.

A language model is used for a decision that is fully specifiable, which makes the outcome non-identical between runs and impossible to explain afterwards.

Warning sign

Someone asks why a particular case was decided that way and the only available answer is a description of how the model works in general.

What to do instead

Use a model where the input is genuinely ambiguous — free text, a document, a thread. Everywhere else write a rule you can read, change and defend to an auditor. It is cheaper to run and identical every time.

Nobody decided in advance what should move, so when the budget conversation comes round there is no way to argue the automation earned its place.

Warning sign

Asked what success looks like, the answer is a description of the automation rather than a number that should change.

What to do instead

Name the measure at design time — hours per week, error rate, or elapsed time from request to done — and record the baseline before anything ships. If you cannot name it, the work is not ready to scope.

The build stalls for weeks on credentials, permissions or a vendor's approval process, and the delay is attributed to the automation being difficult.

Warning sign

The kickoff finishes without a named person responsible for granting access to each system, with a date.

What to do instead

Treat access as the first deliverable, not an administrative detail. Engagements stall on permissions far more often than on code, and it is the one risk that is entirely predictable at the start.

A proof of concept is scoped so narrowly that it proves nothing extensible, and rebuilding it properly costs more than starting again would have.

Warning sign

The pilot runs against sample data, in a sandbox, on a path the real process does not use.

What to do instead

Make the first build small but real: one genuine workflow, in production, carrying actual work. A narrow thing that runs beats a broad thing that demonstrates.

The automation stops and nobody notices for weeks, because working and not working look identical from the outside until a customer points it out.

Warning sign

Monitoring is a dashboard somebody would have to open. Nothing pushes to a person when work stops moving.

What to do instead

Alert a named person when something is stuck, queue work rather than dropping it while a system is unavailable, and make sure running twice cannot create the record twice. Loud, safe failure is what keeps a team trusting the system.

The automation works on the day it ships and degrades from there, because keeping it working is nobody's job and changing it needs a person who has moved on.

Warning sign

You cannot name the person who would change a business rule inside it next quarter.

What to do instead

Insist on documentation good enough for another developer to take over, credentials you control, and rules a business person can change without a developer. Then name the owner before handover rather than after it.