Scope it to something you can finish

Every process has a core case and a long tail. The core is 70–90% of instances and is often straightforward. The tail is endless and is where projects go to die.

This lesson is about drawing the line, in writing, before you are emotionally invested in the tail.

Handle the core, route the rest

You are not building a system that handles every case. You are building one that handles the common cases and reliably recognises the ones it cannot, then hands those to a person.

That second half is the product. An automation covering 75% of volume with a clean exception path is deployable next month. One covering 98% that fails silently on the other 2% is not deployable at all, because nobody can trust any of its output.

Coverage is negotiable. Knowing when you are out of your depth is not.

Write the non-goals list

Explicitly, in the same document as the goals: the cases this will not handle in version one, and where they go instead.

The list is for you as much as for anyone. In week three you will find an interesting edge case and want to solve it, and a non-goals list you wrote while thinking clearly is the thing that stops you.

Share of volume your core case covers

The percentage of last month's real instances that fall inside your defined scope. Count them against real data rather than estimating — the tail is almost always fatter than people think.

Your core case covers 62%

You expected 85%. The remaining 38% is spread across many small variations with no dominant pattern.

Publish scope and non-goals

Goals, non-goals, where the excluded cases go, and the coverage figure with the data it came from. Get the process owner to acknowledge it — this document is what prevents the scope argument in week four.

Drawing the line

A scope document is a set of refusals. Check you can defend each one.