How to Draw a Context Diagram: Step by Step with an Example

To draw one, you only need five steps: name the system, list the outside parties, draw and label the flows, check the boundary, and review it with the people on the diagram. Below I walk you through each step with a simple example, then show the mistakes I see most. It also helps you spot stakeholders and agree project scope before anyone starts building.

This page is a practical how-to: drawing a context diagram step by step. If you want to compare it with the other charts and diagrams the PMP exam uses, such as histograms, Pareto charts and mind maps, read my page on data representation tools.

What is a context diagram?

A context diagram shows how your project or system connects with the world outside it. It is a high-level view. It does not show how the system works inside, only who it talks to and what passes between them.

Components of a Context Diagram

Every context diagram has three parts: the system in the centre, the external entities around it, and the arrows between them.

Project Entity

The centre is one circle or box that stands for your whole project or system. You do not split it into parts. Business analysts often call it the “system under development”.

External Entities

External entities are the people, organisations or other systems that send something to your system or receive something from it. Draw them as rectangles around the centre. Common ones are customers, suppliers, regulators, other departments and existing IT systems.

Arrows

Arrows show what moves between the system and each entity: information, materials or money. The arrowhead shows the direction. Label each arrow with what moves, for example “order” or “invoice”. Keep it high level and leave the detail for later documents.

What are the benefits of a context diagram?

Why bother drawing a context diagram? Three reasons:

1. Identifying key stakeholders: Every box around the centre is a person, team or organisation you must talk to. It is a quick way to start your stakeholder list.
2. Communicating project scope: A sponsor or client who will never read a long scope statement will look at a one-page picture. They can see straight away what is in and what is out.
3. Better planning: Each arrow is an interface you need requirements for, and later a connection you need to test. The diagram gives you that list early.

How to create a context diagram in five steps

1. Name the system. Place your project, product or process in a single box or circle at the centre.
2. List every external entity. Think about customers, users, suppliers, regulators, other internal systems and departments.
3. Draw the flows. Add an arrow for each piece of information, material or money that moves between an entity and the system. Label each arrow.
4. Check the boundary. Anything inside the central box is in scope; everything outside is not. Confirm this with your sponsor.
5. Review with stakeholders. Walk through the diagram with the people represented on it. Missing flows usually surface quickly.

A simple example

Imagine a project to build an online booking system for a clinic. The system sits at the centre. Around it are patients (who send booking requests and receive confirmations), clinic staff (who manage availability), a payment provider (which receives payment requests and returns approvals) and an SMS service (which sends reminders). Each relationship is one labelled arrow, and the whole picture fits on one page.

Your first draft in 10 minutes. Write the clinic example as simple lines before you draw any boxes. One line per arrow:

• Patient → booking request → System
• System → confirmation and reminder → Patient
• Clinic staff → available slots → System
• System → payment request → Payment provider
• Payment provider → payment approval → System
• System → reminder message → SMS service

Now draw: system in the middle, four boxes around it, one labelled arrow per line. Then ask one question for each box: “Are we building this, or connecting to it?” Anything you are building belongs inside the centre box. Anything you only connect to stays outside. When I teach this, the mistake I see most is students putting the payment provider inside the system. You are not building the bank, you are only sending it requests.

Common mistakes to avoid

• Showing internal processes inside the system. A context diagram shows only the system as a single unit.
• Unlabelled arrows. Every flow should say what moves.
• Missing indirect stakeholders such as regulators or auditors.
• Treating the diagram as final. Update it when scope changes.

Context diagrams on the PMP exam

The PMP exam can present a context diagram and ask what it shows. Remember that it is a scope tool used when collecting requirements and defining scope. See our guide to PMP exam diagrams for how it compares with other visuals, and our project scope management guide for where it fits in the process.

Where does the context diagram fit in project management?

In the PMBOK Guide 6th edition, the context diagram is listed as a data representation technique in the Collect Requirements process, part of scope management. It helps the team and stakeholders agree the scope boundary early, before detailed requirements are written.

It also helps with other work. Business analysts use it to find interfaces that need requirements. Testers use it to plan integration testing. Project managers use it to find stakeholders, because every external entity is a person, team or organisation the project must engage.

On agile projects, a context diagram helps the team understand the product’s environment before building the backlog, especially when many outside systems are involved.

Context diagram vs other scope tools

A context diagram shows the system and its external interactions at the highest level. A work breakdown structure breaks the project’s deliverables down into smaller pieces. A use case diagram shows how users interact with specific functions, and a data flow diagram shows processes and data inside the system in more detail.

Start with the context diagram to agree the boundary, then use the more detailed tools to describe what happens inside it. On the PMP exam, if a question asks which tool shows the interactions between a system and its external users and systems, the answer is the context diagram.

Tips for drawing a clear context diagram

Keep it to one page. Put the system in the centre and show only the 5 to 12 most important external entities. Label every arrow with a noun that describes the data or material, such as “invoice” or “delivery note”, not an action. Review it in a short workshop and update it when scope changes. A whiteboard photo or a free tool such as draw.io is enough.

A worked example: a hospital appointment system

Here is a bigger example: a new hospital appointment booking system. The central box is the booking system. Around it sit six external entities: patients, GPs who refer patients, clinic staff, the electronic patient record system, the SMS and email reminder service, and the hospital finance system.

Arrows show what flows between them: referrals from GPs, appointment requests from patients, available slots from clinic staff, patient details from the patient record system, reminders to patients and activity data to finance.

Drawing this in a short workshop with the main stakeholders quickly shows what is in scope and what is not. For example, the team might agree that the reminder service is an existing system to connect to, not something to build. That one decision avoids weeks of confusion later.

The same diagram then helps identify stakeholders for each external entity, the interfaces to specify and the integration tests to plan. In our example, 6 entities and 12 data flows give the team a clear checklist for requirements.

A short history of the context diagram

Context diagrams come from structured systems analysis in the 1970s and 1980s, where they were the top level of data flow diagrams. They became a standard business analysis tool and appear in the PMBOK Guide 6th edition under Collect Requirements. They are still used because they are quick to draw and easy for anyone to read.

Many teams now draw them on shared online whiteboards, so several stakeholders can comment at once.

Conclusion

A context diagram is one of the simplest tools a project manager can use. One box, the parties around it and labelled arrows. Draw it early, walk through it with the people on it, and you will find scope gaps and missing stakeholders long before they become change requests.

Context diagrams: common questions

Is a context diagram the same as a level 0 data flow diagram?

They are closely related. A context diagram is often called a level 0 DFD. It shows the whole system as one process with its external entities.

Who creates a context diagram?

Usually a business analyst or project manager, working with stakeholders.

Is the context diagram on the PMP exam?

Yes, as a scope and requirements tool. Expect questions asking which tool shows a system’s interactions with external entities.