How long does an automation project take?

Week by week

Those stages overlap less than people expect. The audit has to finish before the blueprint can be honest, and the parallel run cannot start before the build is functionally complete. Compressing the schedule mostly means compressing the parallel run, which is the worst place to save time.

What actually causes delays

In our experience the engineering estimate is rarely the problem. These are.

Waiting for access

By some distance the most common cause. A project stalls for eleven days because nobody can find who administers the accounting system, or because the CRM licence with API access needs a purchase order, or because IT policy requires a security review nobody started. This is entirely avoidable and entirely predictable — sorting access during the audit rather than at the start of the build removes it.

Exceptions discovered late

Someone mentions in week three that orders from one particular customer are handled completely differently, and always have been. That is not a small change; it is a new branch with its own testing. A thorough audit surfaces most of these, but the genuinely tacit ones — the things people do without knowing they do them — sometimes only appear when the automation gets them wrong during parallel running. This is an argument for the parallel run, not against it.

No single decision-maker

Scope questions arrive constantly during a build: should this edge case route to a human or default to the standard path? If answering that requires a meeting between three people who are all busy, the project moves at the speed of their calendars. One named person who can decide is worth more to the timeline than an extra engineer.

Dirty data

Duplicate records, inconsistent formats, three spellings of the same supplier. Discovering this mid-build means either stopping to clean it or building defensive logic to cope with it, and both cost time. A competent audit checks data quality before quoting.

What makes it go faster

• Sort credentials during the audit. A dedicated service account with the right permissions, created and tested before the build starts, routinely saves a week.
• Name one decision-maker. Someone who can answer scope questions within a day without convening anyone.
• Be honest about exceptions early. Nobody is judging the fact that your process has fifteen special cases. Every process does. Hiding them does not make them go away, it just moves the cost to week three.
• Start narrower than feels satisfying. One process, done properly and live in a month, beats four processes half-built in a quarter. The second build is always faster because we already know your systems.
• Do not batch the sign-off. Reviewing the blueprint the day it arrives rather than the following Friday moves the whole schedule forward.

Why parallel running is not padding

The most common request is to skip the parallel run and go straight live. It is understandable — the build works in testing, and another two weeks feels like caution for its own sake.

It is not. Testing proves the automation handles the cases you thought of. Parallel running proves it handles the cases that actually occur, on real data, at real volume, including the ones nobody mentioned. The two are not the same, and the gap between them is where automation projects fail publicly.

Running both in parallel means every discrepancy gets found while the manual process is still there to catch it. Nothing reaches a customer wrong. When the outputs match for a sustained period, you cut over with evidence rather than hope — and you keep the manual fallback documented, because vendors have outages.

Two weeks of parallel running is cheap. One invoice sent to the wrong customer because you skipped it is not.