The Context Diagram That Settles the Scope Argument

The scope argument runs on what stays outside and who inherits it. One box, a ring of entities, one line per exchange, and two tables you can copy.

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

Two people, one meeting, forty minutes gone. One wants the warehouse inspection inside the project, the other wants it out. They are describing the same returns process, they are both right, and neither is arguing about what they think they are arguing about. The disagreement is over the part that will sit outside the new system, and who gets handed it on the Monday after go live. Nobody has said that out loud, which is why the meeting has another forty minutes in it.

A context diagram is one box for the thing you are changing, a ring of everything outside it that sends it something or receives something from it, and one labelled line per exchange. No internal steps, no screens, no boxes inside the box. That is the entire notation, which is why it takes five minutes and why it closes this argument.

One limit first. That argument is a composite of ones I have sat in on real projects, not a transcript. The returns case on this site has no meeting room in it: returns and complaints at a mid-size online retailer, built only from the published returns policy, the help centre and ten public complaint threads I picked myself. No engagement, no client, nobody inside the company asked anything. Where I claim a system exists across the boundary, I am inferring it from what those sources make visible, and the row says so.

In short

• The scope argument is rarely about the thing being built. It runs on the part being left out, and on who quietly inherits it.
• Draw one box, name every entity that exchanges something with it, write one line per exchange. Anything you cannot draw a line to is outside, and the reason goes on the page.
• The column that does the work is the last one: what happens when this flow is missing. That is where an exclusion stops being an opinion and becomes a cost with a name against it.
• Both tables are below, filled in and then blank, ready to copy.

Why does the same scope argument restart every week?

Two positions, near enough word for word, because they repeat with the job titles swapped.

If inspection stays outside, we approve refunds from photographs, and the first time somebody photographs an empty box we have paid for nothing.

Inspection is a warehouse process with its own hands, its own building and its own system. Pull it in and we are rewriting the warehouse, and this ships in a year rather than a quarter.

Both are true, which is the problem. Two true sentences can sit opposite each other for as long as the meeting lasts, because the word doing the damage is "returns", and it covers at least six things: the claim, the evidence, the eligibility check, the decision, the money leaving, and the item coming back. Each person holds a different subset and uses the same word for it.

A drawing removes the option. You cannot draw a boundary and keep two versions of it, and once the line is on the page the question changes shape. It stops being "should inspection be in the project" and becomes "if inspection sits outside, what crosses the line, in which direction, and what breaks when that crossing does not happen".

The diagram, written out so you can copy it

In the middle, one box, named as narrowly as the scope line in the document: damaged-delivery refunds for web store orders, from evidence upload to decision.

Around it, the entities, each with its source. [POLICY] is stated in the published returns policy, [HELP] in a help centre article, [THREADS] in the ten threads, and [INFERRED] marks reasoning from what those sources imply rather than state.

• Customer [POLICY] [HELP]
• Support contact route, the way the help centre says a case is raised [HELP]
• Warehouse goods-in inspection [HELP]
• Order and delivery record, the web store itself [POLICY]
• Payment and refund execution [INFERRED], because the policy says refunds return to the original payment method, so something executes them
• Carrier [INFERRED], because a damaged delivery usually has a claim path behind it
• Accounting ledger [INFERRED]
• Marketplace channel [POLICY], on the diagram because it is outside

One row per exchange. The last two columns are worth your afternoon.

Read down the fourth column. Half of those failures are not system failures. They are a person receiving something late, or nothing, and absorbing it. That is the argument the two people were really having, and it took a table to make it sayable.

Which side of the line, and who is left holding the rest?

The second table is the one that goes into the document.

The third column does what the first two cannot. "Out of scope: inspection" states a boundary. "Out of scope: inspection, and the goods-in lead now sees the verdict matter after the money has left" states a decision somebody may want to make differently.

One row type is missing on purpose. Anything genuinely undecided belongs in neither column; it needs its own line with an owner and a date, which is one of the eleven edits that make a BRD worth reading. Parking an open question in the out-of-scope column is the commonest way I see a scope section lie without anybody meaning to.

What does an exclusion cost, and who pays it?

The goods-in lead approves nothing. No public source I could find puts that role in an approval flow, and on an influence grid it sits in the quadrant you are told to monitor with minimal effort. It is on the diagram anyway, because the help centre says returned items are inspected on receipt and the inspection can change the outcome. A line crosses the boundary towards it whether anybody planned it or not.

Keeping inspection outside the box is almost certainly the right call. It is also the exclusion with a cost, and the cost lands on the one role here with no veto to defend itself with. Both are true at once, and the diagram lets you write them in one sentence instead of choosing. Same pattern as the stakeholder map that survives contact with the project: the row that matters in month two is the one that loses something, and no scope bullet surfaces it.

What you do about it is not heroic: name it in the document, log it as an open question with a fallback, and make sure whoever holds that role hears it from you and not from the first dispute.

The blank version

Copy these two. Hints in the brackets.

Five minutes, no software.

1. Write the box. One line, ending at a decision or a state rather than at a department.
2. List everything that touches it, walking the process end to end, exclusions included.
3. One row per exchange, per direction, because the two directions fail differently.
4. Fill the failure column before you argue with anyone. It is the only column that changes minds.
5. Anything with no line to the box is outside. Write the reason and the inheritor beside it, or take it back in.

One fair objection: the table invites you to draw systems you have never seen. Hence the source column, and four entities tagged as inferences.

Where to start

Take a scope section you already have, with an out-of-scope bullet list. For each bullet, write what crosses the boundary in each direction and who is holding that bullet when the project succeeds. Twenty minutes, no diagramming tool, no meeting.

You will usually find one exclusion nobody has told the inheritor about. That conversation is cheaper now than after go live.

The standard I hold my own artifacts to is on this site: the scorecard is twenty-five checks across six artifacts, versioned, free, no email address asked for. Run the diagram and the scope table through it before anyone else sees them.

A context diagram is finished when a stranger can point at any line and say what breaks if it goes quiet.

All field notes · The portfolio guide · More in The Document That Gets Read