There are two times during a project when the scope is
defined. The high-level scope is defined in the up-front project definition
process. These scope statements help establish the boundaries of the project.
The more detailed scope is defined when you gather business requirements. If
you think of scope as a box, the high-level scope would be used to define the
size and shape of the box. The requirements would then fill up the insides of
One of the first places to look for your high-level scope
definition is the project objectives. All projects build things and the
objectives are achieved through the creation of one or more deliverables.
Listing the deliverables tells the reader what your project will deliver and by
implication, what it will not deliver. This is the place to start when
describing your scope boundaries. If you do not include anything else in your
high-level scope section, at least list your deliverables. Since the sponsor
will approve your project definition document, these should be the external
deliverables that the sponsor understands. Don’t include the internal
deliverables that are only needed by your project team.
The deliverables tell you “what” your project is
producing. Once you have your deliverables listed, start asking other “what”
questions to determine other aspects of scope. This includes what types of data
are needed, what company locations are involved, what major capabilities need
to be included in the project, what types of business processes are affected,
As a point of clarity and contrast, you can also identify
out-of-scope conditions by describing what deliverables will not be created,
what organizations will not be impacted, what features and functions are not
included, etc. Of course, there are an infinite number of out-of-scope
statements. For the purposes of scope definition, you want to include only
those statements that help define the project boundary and touch upon related
areas that the reader may have questions about. For instance, if you were
installing financial software, you might state that a new Accounts Payable
package is in scope, but the related Purchasing System is out of scope. This
would make sense since the Purchasing and Accounts Payable processes are
related and there may be questions as to whether the Purchasing System was in
scope. You would not have to list every other system as out of scope–just the
ones that the reader might have questions about.
It’s also a good practice to document those organizations
that are in scope and those related organizations that are out of scope. The
readers of the project definition document can then determine more easily if
their organization is impacted or expected to assist. This exercise can also
help the sponsor decide if a steering committee should be created with
representatives of these organizations.