The first automation a company attempts is usually the most ambitious one they can think of. It is the one that would be transformative, it touches five systems, and it requires a decision from three departments. It also, reliably, does not ship.
Why the big first project fails
- It requires coordination across teams who have no shared incentive and no history of working together on this
- It takes long enough that the sponsor's priorities change before it lands
- Nobody involved has calibrated expectations yet, so the estimate is wrong and the disappointment is attributed to automation generally
- There is no track record, so the first setback triggers a review rather than a fix
What a good first project looks like
Small enough to finish in a week. Owned by one person who can make every decision. Touching at most three systems. Saving hours that a specific named person will notice getting back.
Concretely: routing inbound enquiries into the CRM with an acknowledgement. Capturing receipts and coding them. Assembling a report that somebody currently builds by hand every Monday. Chasing overdue invoices. None of these are impressive. All of them work.
The purpose of the first automation is not the saving. It is proving that the next one will land.
What the small win buys you
- Calibration. Everybody now knows what a week of automation work actually produces, which makes the next estimate credible.
- A reference. The person whose Monday morning got shorter becomes the internal advocate, and internal advocacy beats any business case.
- Infrastructure. The first project establishes the platform, the credentials, the error handling patterns, and the monitoring. The second one is faster because of it.
- Trust. When something breaks later, and it will, there is a track record to weigh it against.
The sequencing that works
Three or four small automations in the first quarter, each independently useful. Then the ambitious one, in the second quarter, with a team that has now shipped together and estimates that are grounded in real delivery.
If somebody insists the first project has to be the big one, ask what happens if it slips by a month. The answer tells you whether the organization can absorb the risk.
One caveat
Small does not mean sloppy. A small automation with no error handling, no monitoring, and no documentation teaches the organization that automation is unreliable, which is the opposite of what the first project is for. Small scope, full engineering.
Written from work we have actually delivered. If your situation looks like the one described here, the quote form takes about two minutes and there is no sales sequence attached to it.
Get a free quote