Why automations die before they reach production

The demo works. Everyone is pleased. Then it sits in limbo for four months and quietly stops being mentioned.

There is a specific way automation projects fail that has nothing to do with the technology. The build works. The demo goes well. People are genuinely pleased. And then it sits somewhere between finished and live for four months, until it quietly stops appearing on the agenda.

I have seen enough of these to recognise the pattern early. The causes repeat.

Nobody owns it after go-live

This is the most common one. The project has a builder and a sponsor. It does not have an owner — the person who gets the alert at 6am when it fails, who decides whether to rerun or escalate, and whose objectives include it still working next quarter.

Without that person, going live is a risk transfer that nobody has agreed to accept. Operations teams sense this immediately, and their hesitation is not resistance. It is correct.

I now settle ownership before development starts, not before deployment. If we cannot name the owner at the design stage, that is information about whether the thing should be built.

The happy path was the only path

Demos run on clean data. Production does not. The invoice with a missing reference, the file that arrives in a different format, the approver who left last month, the record with a trailing space that breaks a lookup — these are not edge cases. In a high-volume process they are a daily occurrence.

An automation without a defined exception path does not handle these. It either stops, or worse, it carries on and produces something wrong. The second failure is far more expensive, because it is discovered later and trusted in the meantime.

The exception path is not the edge case. At volume, it is a daily occurrence with a rota.

Testing proved it ran, not that it was right

There is a real difference between system integration testing and user acceptance testing, and it is easy to let the second collapse into the first. SIT tells you the components talk to each other. UAT is supposed to tell you the business outcome is correct and that the people who will live with it accept it.

When UAT is run by the project team against test data, it answers the first question twice and the second question not at all. Real UAT needs the actual users, on realistic data, with permission to say it is not good enough.

Governance was treated as paperwork

Design documents have a reputation as bureaucracy, and badly done they earn it. Done properly, a process definition and a solution design are the only artefacts that let someone who was not in the room understand what was decided and why.

I write them for a specific reader: the person who inherits this after I have moved on. That framing changes what goes in. Not just what the automation does, but what it deliberately does not do, and which assumptions would invalidate it.

The benefit was never agreed

A surprising number of automations reach the end of development without anyone having written down what success would look like. The case was made informally at the start, everyone nodded, and nobody translated it into something measurable.

This becomes fatal at the approval stage, because a sponsor being asked to accept operational risk needs a benefit to weigh it against. Without one, the rational answer is to defer, and deferring is exactly what happens.

It does not need to be a financial model. It needs to be specific: which step disappears, how much elapsed time comes out, what error rate we expect to change, who gets those hours back and what they do with them. I would rather state a modest benefit precisely than a large one vaguely, because the precise version can be checked afterwards and the vague one can only be argued about.

It was built for a process that then changed

Long projects have a particular risk in operational environments: the process moves while you are building against it. A regional variation gets introduced, a system is upgraded, a control is added after an audit. By the time the automation is ready, it is solving a slightly historical problem.

The defence is shorter cycles and configurable design. Something narrow and live in six weeks will survive contact with reality better than something comprehensive delivered in nine months, because it gets corrected while the corrections are still cheap.

The people affected found out last

An automation changes someone's daily work. If the first they hear of it is a go-live notice, you have a change management problem that no amount of engineering will solve.

I would rather move slower and bring the team along. Not out of politeness — because a solution the team did not shape is one they will work around, and a workaround is indistinguishable from failure once it is in the numbers.

The short version

• Name the post-go-live owner before you write any code.
• Design the exception path at the same time as the happy path.
• Let real users run UAT on real data, with the power to reject.
• Write the documentation for whoever inherits it.
• Involve the affected team early enough that they can influence it.

None of these are technical problems, which is why technical teams are consistently surprised by them.