Stuart Totterdell
Technical Director
Most automation projects do not fail because the technology was wrong. They fail because nobody did the work to understand what they were automating before they started building.
We have seen it enough times to know the pattern. A team identifies something they want to automate - usually a manual process that is painful and visible. They brief a developer or a vendor. The build starts. And three months later, the project is over budget, the team is frustrated, and the solution does not quite fit because the problem was never properly defined.
This is why we start every business automation engagement with scoping. Not a sales exercise. Not a discovery workshop that produces a PowerPoint. A structured, five-day process that ends with a project plan you can hold people to.
Day 1 - Understand the operation
We do not start with technology. We start with the business.
On day one, we sit with the people who actually run the process - not the managers who describe it in meetings, but the people who do it. We ask them to walk us through their day. Where does the work come from? What triggers it? What do they do with it? Where does it go next? What breaks?
This is not a workshop. It is observation. We watch, ask questions, and document what actually happens versus what the org chart says should happen. The gap between these two things is usually where the real problem lives.
By the end of day one, we have a clear picture of the current state - not the idealised version, the real one.
Day 2 - Map the process end to end
Day two is mapping. We take everything we observed and build a process map from trigger to outcome. Every step, every handoff, every system, every manual intervention.
We identify where data enters the process, where it gets transformed, where it gets stuck, and where it exits. We note which steps are performed by people because they require judgement and which are performed by people because nobody has built a system to do it yet.
This is the step most people skip. They jump from "we want to automate X" to building a solution without understanding the full chain. The result is automation that solves one step but creates a bottleneck somewhere else.
Day 3 - Identify what to automate and what to leave alone
Not everything should be automated. Day three is about drawing the line.
We separate the process into three categories. Steps that are high-volume, rule-based, and consistent - these are candidates for full automation. Steps that require human judgement but could be supported by better data or alerts - these are candidates for augmentation. Steps that are genuinely complex, variable, or require relationships - these stay manual, and that is fine.
We also identify dependencies. Can this step be automated independently, or does it require another system to change first? What data needs to be available? What permissions or approvals are required? These are data and systems integration constraints, and they shape the project plan more than the technology ever will.
Day 4 - Design the solution and estimate the build
Day four is technical design. We know the process, we know what to automate, and now we design how.
We select the integration points - which systems need to talk to each other, which APIs are available, which ones need building. We choose the right tools for each component. Some tasks need a simple scheduled script. Some need event-driven automation. Some need an AI model for classification or extraction.
We do not default to the most complex solution. We default to the simplest one that works. Over-engineering is the most common failure mode in development and build - building a platform when a script would do, using machine learning when a lookup table would suffice.
By the end of day four, we have an architecture sketch, a component list, and a realistic estimate of the build effort.
Day 5 - Deliver the project plan
Day five is documentation and handover. The output is not a strategy deck. It is a project plan with four things.
A scope document that defines exactly what will be automated, what will not, and why. A technical specification that describes the integration points, tools, and data requirements. A timeline with milestones, dependencies, and a realistic delivery date. And a cost estimate that includes build, testing, deployment, and the first three months of support.
We also include a simple ROI calculation. Hours currently spent on the manual process, multiplied by fully loaded cost per hour, multiplied by twelve months. Compare that to the project cost. If the payback is under twelve months - and it usually is - the decision makes itself.
Why five days matters
Five days is not arbitrary. It is long enough to do the work properly and short enough that nobody loses momentum. The people involved stay engaged. The context stays fresh. And at the end of the week, there is a tangible artefact that the business can use to make a real decision.
No six-month discovery phase. No death by workshop. No document that sits in a shared drive until everyone forgets it exists.
If you are considering automation, the first question is not "what tool should we use?" It is "do we understand what we are trying to fix?" Five days gives you that answer - and everything you need to act on it.
