Scoping an automation project that won't balloon

Most automation projects that go over budget don't go over budget because the code was hard. They go over because the scope was never actually fixed, it was a vague description of a process that turned out to have six exceptions nobody mentioned in the kickoff call. Scoping properly is less exciting than building, and it's the single highest-leverage hour in the whole engagement.

Map the process before you map the code

Before touching an API or a script, we ask the client to walk through the process as it actually happens, not as the org chart says it happens. There's always a gap. The documented process has three steps; the real one has three steps and then someone in finance manually overrides it every time a customer is on a payment plan. That override is the part that breaks the automation if you don't scope for it up front.

• Ask for the exceptions first. 'What happens when this goes wrong' reveals more than 'what happens when this goes right.'
• Get three real examples, not a description. A real invoice, a real lead, a real ticket, with the messy formatting intact.
• Name what's explicitly out of scope in writing, before the quote, not after the first change request.
• Separate 'automate this' from 'fix this process' as line items. They're different projects with different risk.

Fixed scope, fixed price, named exceptions

We quote a defined version of the process: these input formats, this volume, these three exception paths, handled explicitly. Anything outside that is a change order, not scope creep we silently absorb. This isn't about being rigid, it's about both sides knowing exactly what 'done' looks like before the invoice goes out. Vague scope is the root cause of almost every automation project that goes bad.

If you can't describe an edge case in the scoping call, it will describe itself to you in production.

The discovery week pays for itself

A short, paid discovery phase before the build, where you actually map the process and pull real sample data, feels like overhead to clients in a hurry. It isn't. It's the cheapest insurance in the entire project, because every hour spent finding an exception before the build is worth ten spent fixing it after the automation is already live and quietly getting it wrong.