Planning and Scope

Project planning is the construction of a dynamic agreement across diverse functional

groups involved in a project. This agreement specifies the goals and deliverables of the
project -- what is being developed -- and the major activities that will be performed to
achieve those goals. It includes the assumptions that were made and identifies major risks
as they become known. The planning process allows for changes to this agreement during
the project's execution. As the planning process is documented, the documentation
becomes a dynamic guide for the execution of the project.
The benefits of good planning seem obvious. So why do so many organizations and
project managers fail to plan their projects? New project managers may lack paradigm
knowledge about planning, but why do even some experienced project managers ignore
or actively avoid good planning? What are the elements of a good project plan? No
matter how much or how little I plan a project, the plan ends up gathering dust on the
shelf during execution - why? What are some of the methods used to create such a plan?
How detailed does the plan need to be? How can I identify the risk areas early? What is
the difference between project scope and product scope? What is "scope creep" and how
can I avoid it? How do I manage the trade-offs among project stakeholders? What
processes and tools can help me turn a product vision into a coherent, executable plan?
Scheduling and Estimating
Estimating work and managing schedules is a project management core
competency. How can I create schedules that don't slip? What estimating
techniques and tools are available? How do I create work-breakdown
structures? How do I get commitments from team members that stick? I
spend a day a week in my scheduling program - is this too much? Too little?
What can I do early in a project to keep schedules on track later in the
project? What is "critical chain" scheduling? Does it have any real-world
benefits? Where can I find out more about it?

Scheduling/Estimating
Controlling Software Projects: Management, Measurement and Estimation, Tom Demarco,
Barry W. Boehm, Yourdon, 1986 ISBN 0131717111
This guide for software scheduling and estimating shows managers how to organize software
projects so that they are objectively measurable, and prescribes techniques for making early and
accurate projections of time and cost to deliver.
Critical Chain, Eliyahu M. Goldratt, North River Press, 1997 ISBN 0884271536
Goldratt's original work, in novel form, on the Critical Chain method of project scheduling. The
Critical Chain method models the limitations and constraints on resources more effectively than

traditional planning methods, yielding more realistic schedules and more effective schedule
management. A controversial book with both fanatical supporters and disappointed detractors, it
should be read by anyone interested in one of the toughest problems of project management.
Critical Chain Project Management , Lawrence Leach, Artech House, 2000 ISBN 1580530745
The author combines current project management knowledge and practice with his own extensive
project management experience to extend the vision in Eli Goldratt's writings into a complete
guide on implementing critical chain project management and measuring its impact on project
success.

Estimating Software Costs, T. Capers Jones, McGraw Hill, 1998 ISBN 0079130941
Written by one of the pioneers in software estimating, this guidebook discusses the fundamentals
of effective software estimating, what tools are available, and how to handle real-world issues
such as creeping requirements and excessive schedule pressure.

Guideline for Project Selection and Controlling Project Starts

Should all the projects underway in your organization really be taking your peoples time
and attention?
To answer that question, ask a few more specific questions about the projects underway:

Do all of the projects in your organization fit with your strategic plan?

Will your project portfolio enable you to meet your strategic goals?

Is there a structured process for selecting which projects will be pursued, to ensure
the most important projects are getting resource time and budget?

Are you sure the benefits of each project outweigh the true costs (including effort
hours)?

Does the senior management team, as a group, decide which projects will be
initiated, to ensure that the above questions are answered before a project is
approved?

If your answer to these questions is yes, then youre in the distinct minority and you may stop
reading now. If the answer to any of these questions is no, then youre reading the right guideline.
What Is Project Selection and Who Does It?
The questions just posed relate to project selection, the first phase of a Project Portfolio
Management process, sometimes called a project steering process (PSP). A project steering
process needs to be in place in order to manage the portfolio of projectsthe group of projects
that together will achieve the strategic goals of the organization in a particular time period.
The portfolio should be managed by the cross-functional team of senior managers responsible for
the organization meeting its business goals. Portfolio or Steering processes typically designate an
explicit group of these executives, referred to as a Portfolio Management Committee or Project
Steering Council, to guide the portfolio of projects from inception to completion. (A project or
program office can be helpful in providing the data and reports needed by the management team
to make sound portfolio decisions, but the accountability for steering the portfolio lies with
management.)

This diagram depicts the steering process as an overlay on project planning and execution in the
organization, with an explicit project selection process at the front end to control project starts.
The purpose of project selection is to decide which project ideas meet the first hurdle for
inclusion in the portfolio. The Steering Committees job is to apply strategic filters to their project
decision-making, to ensure that any project idea is truly worthy of proceeding.

Project Steering Process (PSP) Oversight of Project Selection, Project

Starts,
and Ongoing Portfolio Status and Prioritization

Develop Test Deliver & Support

Project
Selection
Benefits and
cost
investigation

Backlog
Queue
of
approve
d
Projects

Project Execution
Plan & Design

Project
Ideas

What Questions Should Be Asked and Answered During Project Selection?

During the selection phase, executives weed out project ideas:
a) that dont fit with strategic goals,
b) that are not doable,
c) for which the costs outweigh the benefits, and/or
d) that are not going to meet an important customer need.
Project selection is about taking the first pass at rejecting those project ideas that just dont make
good business sense and then selecting those projects that are worth studying further.
Project selection should address four basic questions.

What are the overall benefits of the project and how important are those to the
business?

Is the project feasible?

What are the major risks involved?

What are the gross costs of the project?

NOTE: This is not the time to look at detailed specifics. Youre merely trying to get a handle on
the overview of the projectthe big picture and major parameters.
Steps in the Project Selection Process
The Project Selection process starts with a new project idea and finishes when a projects fate
has been decided:

The Project Selection steps that take a new project

from initial idea to an officially approved and started project:

Step 1: Project Request or Proposal to Portfolio Steering Committee

Step 1 Project Request or Proposal

The selection phase starts with a request by the project initiator. The initiator should spell out how
the proposed project fits with the strategic plan and what the expected benefits, risks and costs
will be (in broad terms).
See our related templates in the Concept phase for creating a New Project/Product Proposal.
Step 2 Initial investigation of project benefits
If the project concept is deemed a good idea and appears to fill a need in the project portfolio,
then the Project Steering Council (PSC) can commission one or more early studies to explore the
benefits side of the equation.
Examples of studies include:

Business analysis What is the business case for this project? What are the
business requirements?

Market analysis What is the market for the product/service being proposed?

Product/service definition What does the end user need/want from a new or
improved product or service?

Process problem definition What is the process problem being experienced that
this project would address?

Such initial studies are typically undertaken by a small group of people commissioned to do so. A
full-blown project team has not yet been commissioned, because this idea has not yet been
approved as a funded project. Essentially the executives have simply approved a limited
investigation. Some companies treat this as a Phase 0 concept and feasibility period.
Step 3 Feasibility and rough project sizing to understand cost implications
Along with clearly defining the benefits, the steering committee needs to understand the feasibility
and cost side of the equation. Studies can be commissioned, again usually to be done by a small
group of people, to explore:

Problem analysis What are the root causes of the problem being experienced and
what are possible approaches to solving the problem?

Concept feasibility analysis Is the proposed concept viable? Do the investigators

see feasible ways (technically and economically) to implement the concept?

Project sizing What would a full project likely cost in terms of time, resources from
various cross-functional groups, and other expenses?

The answers to these questions will allow the executives to determine whether the project is
doable and whether the benefits will outweigh the costs.
Step 4 Review of cost-benefit by PSC, approval to officially proceed, or start
Once the detailed benefits and costs of the project are known based on both the benefits
investigation and the initial project feasibility and sizing, the project is resubmitted to the PSC for
the next level of funding consideration. The PSC decides how to prioritize the project, and
whether to fund it immediately or not, depending on the resources available. It is at this point that
the project is allowed to officially start and move to the next level of resource commitment. The
early work has provided the initial sanity check that this project idea is worth pursuing further.
As noted previously, companies often use this initial selection or concept phase for a quick-hit
investigation with a small group of people, before putting an entire core cross-functional team to
work. The rationale is to sanity check the project idea quickly before tying up a full range of
valuable resources.
Once the small investigative team brings their results back to the PSC, the committee typically
lets the project move into a full kickoff or Initiation phase. A full core cross-functional team is then
assigned to go forward with the project idea, define detailed requirements, do more detailed work
on potential solutions, and create detailed project plans as decisions are made on the detailed
project and solution approach.
The PSC then should have another funding decision point as the official project team finishes this
more detailed work. While the early sanity check work during the initial project selection period
ensured this project was worth further investigation, sometimes other problems with the feasibility
and cost-benefit equation do not surface until the more detailed definition and work is underway.
The PSC should weigh in on the project idea again as costs and risks are further understood, and
ultimately approve funding for full project execution past the planning stage.
Why the Selection Process Makes Sense Resource and Cost Impacts Without It
In organizations without a defined selection time for evaluating proposed project ideasfor the
sanity-check concept and feasibility worka cross-functional team is formed and goes straight to
detailed investigation and planning on each project idea. There is no executive go/no-go decision
until a full project plan has been created.
The problem with this approach is that every team pursues time and budget-consuming work on
every project idea without the soundness of the project concept ever being evaluated by the PSC.
The organization invests resources in every project idea, even those that the PSC might
determine is has no interest inafter all that work has been done!
Another pitfall with this approach is that with so many ideas getting full-blown attention without a
prior sanity check, resources are stretched too thin across ideas that might not even be allowed
to move into full execution. Not only is this unfair to the team, it also undermines the resource
allocation process. Its better to evaluate each concept first and then decide if it warrants
investing resources to study it further and develop a detailed project plan.
A sound project selection process is the first step to developing a portfolio of projects that will
enable you to meet your strategic goals. If youre not convinced that project selection is important,
ask yourself this question, Why expend a lot of resources working on a portfolio of junk?

INTRODUCTION:

The technique brief content starts on the following page.

What This Is
Context diagrams graphically depict a system's boundaries, the information that flows in and out of the
system, and the other systems and people that will use it and benefit from it. Representing the system as
a single black box process interacting with its environment, context diagrams provide a picture of project
scope.
Context diagrams can be very simple sketches or detailed graphical interface specifications, depending
on what you need for a given communication or interaction.

Why Its Useful

Any system exists in order to respond and provide services to the world around it. The context model
describes how the system relates to its business environment. It depicts the boundary, scope, and
benefits of the system in a simple, intuitive format that non-technical stakeholders can easily understand.
Context diagrams provide several additional benefits:

Careful determination of system boundaries helps limit costs, decrease development time,
and improve system analysis and design.

Clear communication of the system and its benefits to other systems and people will help you
enlist appropriate stakeholders.

Approaching the system from the top-most level will ensure that your analysis makes sense
at a high level before you invest time developing the details.

In some circumstances, a simple picture is a better way to rapidly gain clarity than a written
specification. Context models are the simplest of all modeling diagrams and are easy to
sketch.

How to Use It
Use an appropriate level of detail for the circumstances. In a quick conversation with a stakeholder, show
only those details relevant to your discussion. When creating a comprehensive specification to begin your
system analysis, be sure to include all the details you can think of and use a rigorous naming convention.

Draw a circle and label it with the system name.

Around the circle, draw one rectangle for each external entity (source or destination of
information or control). These can be either external systems or people.

Draw the data and control events that flow between the system and the external entities. Use
solid arrows for data and dashed arrows for control events. Label each arrow in terms
relevant to the business. Stay at a high level. Arrows should only go in one direction.

Show the diagram to potential users and other stakeholders. Check it against your other
models. Refine the diagram as you adjust project scope and system requirements.

Use additional notation sparingly. Stick figures representing external user roles or rectangles
that group related diagram objects may be useful, but adding too much stuff to the diagram or
using clipart shapes instead of rectangles confuses people.

The technique brief content starts on the following page.

INTRODUCTION TO CONTEXT DIAGRAMS

Context diagrams resulted from work by Yourdon,
Constantinei, DeMarcoii and others in the late 1970s as part
of structured analysis and structured design methodology.
They were top-level data flow diagrams. Extended by Gane &
Sarsoniii and applied to real time systems by Ward & Mellor iv,
they gained notation for depicting control flows, discrete-time
signals, and continuous-time signals. While venerable, they
retain their usefulness because of their simplicity.
Context diagrams show the proposed system in its
environment of external entities, exchanging data and control
information with those entities.
The system is shown as a simple, labeled circle (Yourdon
notation) or a rounded rectangle (Gane & Sarson notation).
No internal details are shown, not even major subsystems.
The focus is on the systems context, not the system itself.
External entities (sometimes called terminators) are sources
and sinks (destinations) of data and control information. They
are shown as simple rectangles. These can represent other
systems (Product Data Management System), external classes of users (Test Engineer),
organizations (Marketing), or hardware (Product Prototype). External entities typically are not
operators of the system nor are they implementation details like displays or keyboards. They
should represent entities that are important to the business, not implementation or architecture
components.
Data flows represent information, objects, or physical items passing in and out of the system and
are drawn with solid arrows. Control flows represent signals or events that cause a change in
system behavior and are drawn with dashed arrows.
Ward & Mellor further extend the notation to
use double-headed arrows for continuous-time
data (which, like the level of chemical in a tank,
is available all the time) and single-headed
arrows for discrete-time data (which, like an
order for more chemical, occurs only when
needed) but most drawing programs dont
easily support this notation. If its relevant to
your system, make the effort, but make sure your audience understands and values the
distinction.
RECOMMENDATIONS
Data and control flow names are important. Use names that are relevant and familiar to your
business stakeholders. In more formal diagrams used as part of your system analysis, the data
and control flow names are the first entries your data dictionary and should be traceable to
objects in your data model or signals in your hardware. But these internal names for data should
not be used on the context diagram.
Use single-direction arrows only. Its easy to use the same arrow if similar data is flowing both
to and from the same entity. You just put an arrowhead at both ends. But this is misleading. A
useful, non-trivial system always transforms data in a meaningful way and never hands the same
data back to the external entity. If you find yourself with a bi-directional arrow, think more carefully
about the data being exchanged and come up with better, more evocative names for the two
flows. For example, development engineers both create change requests and respond to change
requests. Rather than have one bidirectional arrow, it is better to have two arrows. Each

represents a unique system behavior and use case. What would you call the two flows to
differentiate them?
What you leave off is as important as what you include. If something is outside the scope of
your system, leave it off the diagram. For example, if your invoicing system generates billing
information for the purchasing department instead of sending invoices directly to vendors, leave
the vendors and invoices off the diagram. Show the interaction with the purchasing department
accurately. When your stakeholders ask where the invoices actually are sent, then your
discussion about system scope can begin.
Do not show data stores on context diagrams.

On data flow diagrams, data stores appear as two parallel lines and represent data at rest (in the
sense that flows are data in motion). Usually they only appear on lower-level data flow diagrams
representing internal processes. However, some authors advocate using them on context
diagrams. We disagree. If the database is part of the system, it is hidden inside the system
boundary. If it is external to the system, it is just another external entity. Because most data
relevant at a system level is stored in databases with their own API, administrators, and
organizational stakeholders, they deserve the status of an external system anyway.
Represent people as people.

Classes of users are common sources and sinks of data and control information. All systems
have customers. In all current notations these are represented as rectangles like any other
external entity. But consider using UML actor symbols instead. This has two advantages. 1) It
makes it instantly obvious where people are using and benefiting from the system; this has
strategic political benefits to the savvy project manager during stakeholder negotiations. 2) It
allows you to correlate and cross-check your context diagram to your top level use case diagram.
Sketch informal, partial context diagrams on the spot, at every opportunity. This notation is
so simple; you can use it on whiteboards, spare copier paper, or even on napkins as you discuss
the system with stakeholders. Drawing as you speak engages your listener. Being able to quickly
sketch the system during a conversation greatly facilitates understanding and demonstrates your
command of the subject matter.

Better yet, having your stakeholders draw the

diagram with you has several benefits:

It
helps you
understand
requirements better.

their

It increases their buy-in.

It is creates a shared work product

early in the product cycle. Copy the
resulting page or photograph the
whiteboard so that everybody has a
take-away from the conversation.
For example, if you are in a meeting with marketing
& manufacturing stakeholders, discussing how the
use of a Software Configuration Management
system will benefit both their departments, draw
them a simple picture as you describe how the
system will guarantee that their feature requests
and bug reports will get implemented by the
engineering team. Theres no need to make them
study the complete and somewhat complex formal
diagram in their laps and certainly no need to use
PowerPoint. Keep the current version of the
complete diagram handy if more detail is required.
(The full example diagram appears later this brief.)

CREATING THE CONTEXT DIAGRAM

This section is a step-by step tutorial showing how to create the context diagram, using an
example software configuration management system.
Step 1: Choose the correct level of formality and complexity
As discussed above, sometimes a simple sketch is appropriate. On the other hand, having a
carefully maintained and accurate formal context diagram helps your systems analysts stay on
track. You should have one authoritative, up-to-date, and complete context diagram of your
system at all times. Then, sketch or draw simpler versions as the situation requires.
Step 2: Choose the correct symbols
Lets face it: circles, arrows, and rectangles are not visually exciting. Further, there are lots of
clipart, stencils, and symbols around to choose from that could easily add to the visual variety of
your context diagram. However, resist the urge to experiment. The symbols you use on the page
carry tacit cultural and personal connotations that each of your audience members will interpret
slightly differently. You dont want people making up their own information and adding it to your
diagram at random. Stick to the simple, boring, but unambiguous basics.
As suggested above, you might consider using UML actor symbols for classes of people
interacting with the system. However, if you are also using use case diagrams, be sure that these
external entities are directly related to your use case actors in some way or another. Visual and
label similarity implies that they are the same. If they are not, represent the external people as
rectangles or re-factor your diagrams to make them coherent.
Finally, be careful with color. Different hues and shades have different cultural connotations to
different people that may be inappropriate. Maintaining the same color, or even the same shade
of gray, is always a problem due to vagaries of display and printing technologies. Keep it simple.

Step 3: Draw the system

This step is easy. Draw a big circle in the center of the page and name it
something that everybody will recognize. Name the system for what it does
and avoid acronyms or abbreviations.
Example: Our example system is a software configuration management
system for a product development group. Enough stakeholders have been
referring to the proposed system as a change control system that, even
though change control is traditionally part of configuration management, those
words need to be incorporated somehow. Finally, there are several SCM
systems in the company, so this group has to be explicit.
Step 4: Identify external sources and sinks of data and control
Start by just listing all the external entities you can think of. Dont limit yourself. Think about all the
potential systems and people your new system will influence or affect. The farther away from the
anticipated automated system you look, the more useful and innovative your product is likely to
be.v In many drawing programs, its easy to create rectangles and label them, one after another.
Arrange them around the system in some reasonable fashion. While you should avoid listing such
mundane interfaces as keyboards and displays, do list devices that have business relevance
when specifying physical systems such as factory automation.
In most cultures, diagrams show things flowing from left to right or top to bottom. If you have
important sources, place them on the left. Important destinations or consumers of data tend to go
on the right. But few external entities are only sources or only sinks. Data flows back and forth, so
dont worry if things arent simple. Place related entities near each other. Finally, some positions
tend to have implicit connotations: things along the bottom tend to be foundational or in a
supporting role; things along the top tend to be in control. But these are just guidelines.
Example: Many departments will use our SCM system:

Marketing will record feature

requests and monitor progress.

Project management will monitor

progress.

Design engineering will take

change requests and produce
release candidate file sets of both
code and documentation.

Test engineering will test releases

and submit bug reports.

An automated test harness will

build and test releases, annotating
them with the results of testing.

Product prototypes will load

releases and execute them.

Manufacturing will take tested

releases via their PLM system,
read release notes and other
metadata, and submit bug reports.

Technical Support will read release notes and documentation and submit bug
reports.

Marketing will publish documentation, patches, and other downloads on the

customer-facing website.

System administrators will keep the system running and apply updates and patches
from the SCM system software vendor.

Step 5: Estimate top-level system functions or use cases

You create the context diagram while you are capturing and refining system requirements and as
you are creating system use cases. One activity does not precede the others. Notice that our
example descriptions of externals also include what people will do with the system and what data
they will supply or expect. Estimating this information about data and behavior is useful in
preparation for determining the data and control flows. (Note that you dont need to be using use
cases for context diagrams to be of value.)
Step 6: Draw the data and control flows
For each external entity, draw arrows for all the information that moves between the entity and the
system. Focus on the events and information that are important to the business, not necessarily
data that is available in convenient formats. For example, a business event named Customer
unhappy is better than Bug report submit form. By staying in problem space and focusing on
what is going on in the business context, you avoid prematurely setting the system boundary and
locking yourself into an inappropriate implementation.
Some events happen periodically, as a specific point in time. Indicate this in the name.
Control flows are relatively rare in non-real time business modeling. They are events that carry no
information other than that the event occurredlike an interrupt. Most events have additional
information. If your system is monitoring all the doors in the building, for example, a door opening
is an event. Your system needs to know which door opened, so this is should be modeled as a
data flow rather than a control flow.
The same data rarely flows in and then out of the system without undergoing some
transformation. That transformation is the reason your system exists. Reflect this transformation
in the names of the data flows. In our example SCM system, Bug reports and Feature
requests flow into the system from various sources, but Change requests flow out to
development engineers. In fact, all of these will be implemented with a single data object.
Finally, dont worry about all this in the early stages. At every point in the process, put down what
you know, and revise and re-factor as you go. By seeing whats on the page, you will better
understand what you need to find out.
Example: At an early stage in the process, our context diagram has all data and control flows we
can think of, but there are questions.

What are the SCM System Administrators doing? Theres some indication that they
are important to the system (or they wouldnt be on the diagram) but we dont know
what they need or what they produce. Are they really external to the system at all?

Why does the Technical Writer only have data flowing out? What information does
this role need to do their job? Are they expected to check in their work or submit bug
reports?

The Test Harness Automation Scripts apparently are triggered by a check-in event. Is
there other information required with this event, or does the Harness just go off and
run the same tests each time?

Are the Bug reports the Manufacturing Engineer generates really the same as the
Bug reports the Development engineer generates? Is the difference important to
the system?

The Project Manager requires Status and produces Prioritizationthis is far too
vague. We need more details about what information this role needs and how it will
use the system.

Are the Release notes produced by the Development Engineer the same as the
Release Notes produced by the Technical Writer? Are these identical to those
required by other externals?

Why is the Manufacturing Product Lifecycle Management System connection a

one-way street?

The system apparently needs to interface with Development Tools in addition to the
Development Engineer. Is this simply an inappropriate implementation interfacing
detail or is this a legitimate separate connection that deserves special mention on the
context diagram?

Step 7: Annotate and organize the diagram

It may be useful to organize and arrange the external entities on the diagram to improve
understanding. Typical groupings include:

Externals that report to the same area of the organization chart

Externals that will be implemented in the same phase

Externals that have the same priority

This is also the time to try using UML actor symbols.

Example: Heres the SCM context diagram that well be using as we discuss the system with
stakeholders. The organizational groupings imply some new information, or at least new
questions:

The Manufacturing group doesnt seem to be very connected to the system. Are
there more things we can do to provide benefits to them?

The IT group is responsible for the system itself and its proper operation. Are they
really an external entity? If not, how do we represent their requirements?

Where is the customer on this diagram? Is our vision of the system too internally
focused? What affect will a Product Development SCM system have on our ability to
delight the customer and how can we represent this?

Where is senior management on this diagram? What benefits does the system
provide them? What inputs can they provide? Where is the business value flowing on
this diagram?

Step 8: Validate and revise

The context diagram is only one of the models you use to describe the system. It must be
compatible and coherent with the other models.

Compare it with your use case diagrams. Are all of your use case actors represented
in some way by external entities?

Compare it with your use cases. Each data and control flow should participate in a
use case. Are there use cases that require information that is missing from your
diagram?

Compare it with your data model. Does every flow correspond to one or more data
objects?

In all these cases, there may not be a simple, one-to-one correspondence between items in one
model with items in another.
Most importantly, revisit the diagram and keep it up to date with every project iteration.
USING CONTEXT DIAGRAMS
A context diagram is useful to the project manager in several ways.

Communicating. Like all models, your context diagram is primarily a communication

tool. Print your context diagram on the biggest sheet of paper you can, take it out and

show it to all your stakeholders, scribble all over it, and revise it. Put it up on the wall
of your projects war room. Sketch parts of it every time you discuss the system.

Setting the system boundary. A systems boundary is rarely determined by

technical factors alone. Social, organizational, financial, or interpersonal factors can
influence what is in scope and what isnt. Trying different groupings on your diagram,
using the right names for external entities, and enumerating the data flowing in and
out of your system can aid in understanding these factors.

Identifying your dependencies. Any data source you dont control makes you
dependent on external, uncontrolled factors. Perhaps these should be brought inside
the system boundary as a risk-mitigation tactic. Perhaps you can delay the
requirement to use troublesome data sources, or eliminate them entirely.

Determining your development partners. External sources and sinks that cannot
be controlled, cannot be eliminated, and cannot be brought inside must still be
managed. External data sources are your supply chain. External consumers of data
are your customers. Visit the key stakeholders that represent each external entity and
make sure you understand their point of view.

Negotiating scope to control budget and schedule. Every arrow translates into effort
and time. Perhaps some can be eliminated. Perhaps an internal data transformation
or behavior can be moved out of scope if the data is already available from an
external source in the appropriate form.

Showing progress. Use shading, grouping, or animation to indicate which externals

and which data flows will be available at which project phase.

Breaking down the system into subsystems. Multiple instances of similar data
might indicate the need for a subsystem to handle that sort of data.

Controlling integration costs. Context diagrams enumerate the external systems

that must be integrated. Integration is troublesome and expensive. Minimize the
external entities your system has to interact with. On the other hand, the adjacent
systems are why your systems exists; dont throw the baby out with the bathwater.

Splitting up one product into several to form a product line. The diagram is a
generalization across the product line; not every system in the product may connect
with all systems or types of users shown in the diagram.vi

SUMMARY
Context diagrams use simple notation to depict critical information: how your system interacts
with its environment and the business benefits it provides. They are simple to sketch and clear to
non-technical viewers, making them useful during discussions with stakeholders. While one of the
older modeling techniques, context diagrams remain an excellent tool for communicating about
projects and controlling project scope, schedule, and budget.
ABOUT THE AUTHOR
Alan Zimmerman's 35-year career has included hardware and software engineering, system
analysis and business planning, project and functional management, technical writing, and
training development and delivery. And, along the way, he's thrown in a little rock-and-roll disk
jockey and improvisational comedy here and there. His research interests include the on-going
maturation of the software engineering profession and the intersection of business and software
development processes. As owner of Pragmatic Design Studio, he is using agile methods and
web technologies to solve problems in traditionally under-served markets.

i Yourdon, E. and Constantine, L.L. (1979). Structured Design: Fundamentals of a

Discipline of Computer Program and Systems Design. Prentice Hall.
ii DeMarco, T. (1978). Structured Analysis and System Specification. Yourdon Press
iii Gane, C. and Sarson, T. (1979). Structured Systems Analysis. Prentice Hall
iv Ward, P. and Mellor, S. ( 1986). Structured Development for Real-Time Systems, Volume
2: Essential Modeling Techniques, Englewood Cliffs, NJ: Prentice Hall,
v Robertson, S. and Robertson, J. (2006). Mastering the Requirements Process, Second Edition, Addison Wesley Professional

viA Framework for Software Product Line Practice, Version 5.0 (retrieved 2008-12-04)
http://www.sei.cmu.edu/productlines/frame_report/productLS.htm