Most automation projects fail for reasons that have nothing to do with technology

The tool is rarely the problem. The problem is automating a process nobody has looked at honestly in years.

August 12, 2026 5 min read Abraham Ibrahim Process automation

There is a familiar pattern in operations work. A process is slow and error-prone. Someone proposes automating it. A tool is selected, a project is scoped, and six months later the process is still slow and error-prone, except now it is also expensive and there is a system nobody trusts sitting in the middle of it.

The instinct is to blame the tool. It is almost never the tool.

Automation makes a process more of what it already is

Automation does not improve a process. It accelerates it and makes it consistent. If the underlying process is sound, that is enormously valuable. If the underlying process contains a step that exists because someone in 2019 wanted a second pair of eyes on a particular form, automation will faithfully reproduce that step forever, at speed, without anyone remembering why.

Most organizations have processes like this. Not because anyone is careless, but because processes accrete. A step is added after an incident. An approval is inserted when a new manager arrives. A spreadsheet is created to bridge two systems that do not talk to each other, and five years later that spreadsheet is load-bearing infrastructure that one person maintains.

The map is the deliverable

The most valuable thing we produce in an automation engagement is often not software. It is an accurate map of how work actually moves through the organization, which is reliably different from how leadership believes it moves.

That gap is not a failure of management. It is structural. Leadership sees the process as designed. Staff experience the process as practiced, including the workarounds that keep it functioning. Those workarounds are invisible from above, and they are exactly the things that break an automation project, because the automated version enforces the designed process and quietly removes the workarounds people depended on.

We map processes by sitting with the people doing the work and watching. Not a workshop, not a questionnaire. Watching. The question is never "what is the process?" — everyone has an answer to that. The question is "show me the last five times you did this," which produces a very different answer.

Three things worth deciding before you automate

Which steps should stop existing. Every process map we produce contains steps that survive only because nobody has had standing to question them. Removing a step is cheaper than automating it and produces a better outcome. This is the single largest source of value in most automation work, and it costs nothing but the willingness to ask.

Where the judgment lives. Some steps are mechanical: route this, calculate that, notify them. Others require a person to weigh something. Automating the mechanical steps and routing the judgment steps to a human with good context is a durable design. Trying to automate the judgment is how you end up with a system staff route around.

What happens when it goes wrong. Every automated process fails eventually — a system is down, an input is malformed, an edge case arrives that nobody anticipated. If the answer to "what happens then" is "it silently stops," you have built something that will erode trust the first time it matters. Failure paths deserve as much design attention as the happy path, and they rarely get it.

The case for doing less

The strongest automation work we have delivered has generally automated less than the client initially asked for. Not because of budget, but because the honest answer after mapping was that three of the seven steps should be deleted, two should stay manual because they carry real judgment, and two were worth automating properly.

That is a harder engagement to sell than "we will automate your process." It produces a better result, and, more importantly, one that is still working two years later — which is the only measure of an automation project that means anything.

If you are evaluating automation right now, the most useful thing you can do before selecting any tool is to spend a week watching the process happen. You will likely discover that some of what you were about to pay to automate should simply stop.

Abraham Ibrahim

Managing Partner & Chief Technology Officer

A technology executive and business leader with more than 20 years across healthcare, nonprofit, financial services, real estate, and the public sector.