Automation
Why automation projects fail before development starts
Failed automation is rarely a technical failure. It is usually a failure to agree on the process that should exist.
Teams often ask for automation when they are tired of a process. That is a valid signal. It is not a specification.
If two departments describe the same workflow differently, software will not reconcile them. It will freeze the disagreement into an interface. Development then becomes a negotiation that should have happened in analysis.
The work before development is unglamorous: map the current path, name the exceptions, count the time, and decide what should stop. Many “automations” are actually requests to keep a broken process, only faster.
Scope fails in the same moment. A request that starts as “notify us when a file arrives” expands into an unofficial ERP, because nobody drew a boundary. Controlled scope is not a limitation. It is how the first version becomes usable.
We treat automation as a business change. The software is the last part. If the operating rule is unclear, we do not build. That is slower at the start and much cheaper than rebuilding the wrong thing.