Context Diagram

Scope technique · See it on the map

Runnable here

One picture of a system as a box, showing everything outside it that it touches.

When to use it

Draw one when 'what's in scope' has become an argument nobody can resolve in words -- a stakeholder keeps assuming an integration or a user group is included that another stakeholder assumed was out. It is also useful early, before requirements gathering starts, to give everyone in the room the same starting picture of the system's edges.

When to avoid it

Don't reach for it on a project with no external interfaces or actors worth drawing -- a single-team internal process change gets nothing from a box-and-arrows diagram that a sentence didn't already say. And don't let it substitute for detailed requirements: a context diagram fixes the boundary, not the behavior inside it.

Steps

1. Draw one box in the center labeled with the product or system under scope -- not a business unit, the thing being built.
2. Around it, draw a box for every external actor (user role, external system, other internal system this one talks to) that sends or receives something from it.
3. Draw one labeled arrow per interaction, naming what crosses the boundary (an order, a status update, a login credential) -- not just 'data'.
4. Walk the diagram with the stakeholders who disagreed about scope and ask each one, out loud, to point at what's missing or what shouldn't be there.
5. Revise until nobody in the room objects, then treat every box and arrow as something Define Scope has to explicitly include or exclude.

What it produces

• A one-page context diagram naming the system, its external actors, and every labeled interaction between them.
• An explicit, stakeholder-agreed scope boundary to carry into the scope statement.

Common pitfalls

• Drawing the internal architecture instead of the boundary -- the diagram balloons into a design document nobody can review in a meeting.
• Leaving an interaction unlabeled ('data flows here') so the diagram settles nothing when the same argument comes back up.
• Building it alone and circulating it for sign-off instead of walking it live with the people who disagreed -- the value is in the room reaction, not the artifact.

Worked example

A logistics company is scoping a new dispatch system. Two stakeholders disagree over email about whether the driver mobile app is 'in' this project or a separate one. The PM draws a context diagram: dispatch system in the center, boxes for dispatcher, driver app, the existing billing system, and the customer notification service, with a labeled arrow from dispatch to driver app for 'assigned route'. Walking it in a 20-minute working session, both stakeholders agree the driver app is a consumer of this system's output but its own project -- settled in the room, not in another email thread.

Source

• PMBOK-6 §5.2.2.7

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.