It is tempting to treat an automation project as a development project: define the scope, write the code, deploy it. But the projects that fail — or deliver systems nobody uses — almost always fail in the weeks before development starts. The failure is not technical. It is a failure to understand the process being automated.
Automating a broken process automates the breakage
The most common mistake is treating the current process as a given. If a workflow has eight manual steps and three of them are inconsistent — different people do them differently, or decisions depend on information that is not written down — then automating all eight steps will reliably reproduce all of that inconsistency, faster.
Before automating, map the process as it actually runs, not as it is documented. Interview the people who do the work. The map will show you which steps are worth automating, which should be removed entirely and which should be redesigned first.
The boundary problem
Automation projects are often defined by what a tool can do rather than by a business outcome. The question should not be “can we automate this step?” but “where should this process start and end?”
A clear boundary includes what triggers the process, what inputs it needs, who is responsible at each point and what counts as a successful outcome. Without these, the build team makes assumptions that users then fight against. Spend the time to write the boundary down and get it agreed.
The scope that quietly grows
Undefined scope is the second common failure. The first version of the system is designed around the happy path; the exceptions — the missing document, the unusual case, the user who skips steps — arrive during development and each one expands the work.
The discipline is to decide early what is in the first version and what is explicitly deferred. An automation project that can replace the core manual workflow reliably is more valuable than one that tries to handle every edge case and ships late. Successive versions can add the rest.
Change is not an implementation detail
People adapt to new systems at different speeds, and automation often changes who is responsible for what. A system that works perfectly but disrupts the flow of responsibility without warning will be abandoned. Part of the plan, before development, should be how the change is communicated, who is trained and what happens during the transition.
Success has to be measurable
“Reduce manual work” is a direction, not a measure. The projects that survive scrutiny define success in numbers that can be checked: hours saved per week, error rate, turnaround time, backlog cleared. Define those numbers before development so that the team builds toward them — and so that after launch, everyone can agree on whether the project actually worked.
The pattern that works
The discovery phase of an automation project should be run like a short investigation, not a scoping meeting:
- Map the real process, including its exceptions.
- Remove or simplify steps before automating anything.
- Define the boundary, trigger and success measures in writing.
- Scope the first version to the core workflow and defer the rest.
- Plan for the people, not just the software.
Automation projects do not fail because of the technology. They fail because the process was never understood, the boundaries were never agreed, and success was never defined. Fix those in the first weeks and the development that follows has a much better chance of shipping something the organisation actually uses.