Scoping work when the customer cannot scope it

Asking a customer to "send the requirements" is asking them to do your job. Scope is drafted by you and corrected by them.

The short answer

Never request scope; propose it. A draft scope with wrong lines gets corrected in an hour; a blank page stays blank for a month.

Four techniques

1. The straw scope. Write the in/out lists from two interviews and send with: "correct my wrong lines." Customers edit eagerly what they could never author.

2. Slice by pain date. "Which pain bites before March?" Time sorts priorities that importance cannot. The March slice is the scope; the rest is backlog with names.

3. Price the fog. "Discovery slice: 2 weeks, ends in a signed brief and a working demo of slice one. Fixed shape, then we scope the rest from evidence." You sell certainty about uncertainty.

4. The stop line. Every slice states what stops it: budget, date, or a failed assumption with a named check. Stop lines make starting safe.

Worked example: the "platform" that became three slices

A fictional customer (fictional) asks for "a returns platform." Straw scope returns corrected: slice one, lookup page; slice two, rule table; slice three, reporting. Each with its own brief, metric and stop line. The "platform" ships as three calm slices instead of one panicked project.

Checklist: scoping without scope

1. Draft scope sent within 48 hours of first contact.
2. Every slice has a stop line in writing.
3. Estimates attach to slices, never to fog.
4. The customer corrected your draft at least once.

Related reading

• Writing a one-page project brief that holds
• Turning vague requests into acceptance criteria
• Discovery to handover: the FDE delivery loop