Chapter 5
Project Scope
Management
Project Scope
Management includes the processes required to ensure that the
project includes all
the work required, and only the work required, to complete
the project
successfully (1). It is primarily concerned with defining and controlling
what is or is not
included in the project. Figure 5-1 provides an overview
of the major project
scope management processes:
5.1 Initiation—authorizing the project or phase.
5.2 Scope Planning—developing a written scope
statement as the basis for future
project
decisions.
5.3 Scope Definition—subdividing the major
project deliverables into smaller, more
manageable
components.
5.4 Scope Verification—formalizing acceptance of
the project scope.
5.5 Scope Change Control—controlling changes to
project scope.
These processes interact with
each other and with the processes in the other
knowledge areas as
well. Each process may involve effort from one or more individuals
or groups of
individuals, based on the needs of the project. Each process
generally occurs at
least once in every project phase.
Although the
processes are presented here as discrete components with welldefined
interfaces, in
practice they may overlap and interact in ways not detailed
here. Process
interactions are discussed in detail in Chapter 3.
In the project
context, the term scope may refer to:
·
Product scope—the features and functions that characterize a
product or service.
·
Project scope—the work that must be done to deliver a product with
the specified
features and
functions.
The processes, tools, and techniques used to
manage project scope are the
focus of this
chapter. The processes, tools, and techniques used to manage
product
scope vary by application area and are usually defined as part of
the
project life cycle
(the project life cycle is discussed in Section 2.1).
A project generally
results in a single product, but that product may include
subsidiary
components, each with its own separate but interdependent product
scopes. For example,
a new telephone system would generally include four subsidiary
components—hardware,
software, training, and implementation.
Completion of the project scope is measured against the project
plan, but completion
of the product scope
is measured against the product requirements. Both
types of scope
management must be well integrated to ensure that the work of
the project will
result in delivery of the specified product.
5.1 INITIATION
Initiation is the
process of formally authorizing a new project or that an existing
project should
continue into its next phase (see Section 2.1 for a more detailed
discussion of project
phases). This formal initiation links the project to the
ongoing work of the
performing organization. In some organizations, a project is
not formally
initiated until after completion of a needs assessment, a feasibility
study, a preliminary
plan, or some other equivalent form of analysis that was itself
separately initiated.
Some types of projects, especially internal service projects and
new product
development projects, are initiated informally, and some limited
amount of work is
done to secure the approvals needed for formal initiation. Projects
are typically
authorized as a result of one or more of the following:
·
A market demand (e.g., a car company authorizes a project to build
more fuelefficient
cars in response to gasoline
shortages).
·
A business need (e.g., a training company authorizes a project to
create a new
course to increase its revenues).
·
A customer request (e.g., an electric utility authorizes a project
to build a new
substation to serve a new
industrial park).
·
A technological advance (e.g., an electronics firm authorizes a
new project to
develop a video game player after
advances in computer memory).
·
A legal requirement (e.g., a paint manufacturer authorizes a
project to establish
guidelines for the handling of
toxic materials).
·
A social need (e.g., a nongovernmental organization in a
developing country
authorizes a project to provide
potable water systems, latrines, and sanitation
education to low-income communities
suffering from high rates of cholera).
These stimuli may also be called
problems, opportunities, or business requirements.
The central theme of
all these terms is that management generally must
make a decision about
how to respond.
5.1.1 Inputs to Initiation
.1 Product description. The
product description documents the characteristics of the
product or service that the project was
undertaken to create. The product
description will generally have less detail
in early phases and more detail in later
ones as the product characteristics are
progressively elaborated.
The
product description should also document the relationship between the
product or service being created and the
business need or other stimulus that
gave rise to the project (see the list in
Section 5.1). While the form and substance
of the product description will vary, it
should always be detailed enough to support
later project planning.
Many
projects involve one organization (the seller) doing work under contract
to another (the buyer). In such
circumstances, the initial product description is
usually provided by the buyer.
.2 Strategic plan. All
projects should be supportive of the performing organization’s
strategic goals—the strategic plan of the
performing organization should be considered
as a factor in project selection decisions.
.3 Project selection criteria. Project
selection criteria are typically defined in terms
of the merits of the product of the project
and can cover the full range of possible
management concerns (financial return, market
share, public perceptions, etc.).
.4 Historical information. Historical
information about both the results of previous
project selection decisions and previous
project performance should be considered
to the extent that it is available. When
initiation involves approval for the next
phase of a project, information about the
results of previous phases is often critical.
5.1.2 Tools and Techniques for Initiation
.1 Project selection methods. Project
selection methods involve measuring value or
attractiveness to the project owner.
Project selection methods include considering
the decision criterion (multiple criteria,
if used, should be combined into a single
value function) and a means to calculate
value under uncertainty. These are
known as the decision model and calculation
method. Project selection also applies
to choosing the alternative ways of doing
the project. Optimization tools can be
used to search for the optimal combination
of decision variables. Project selection
methods generally fall into one of two
broad categories (2):
·
Benefit measurement methods—comparative approaches, scoring
models,
benefit contribution, or economic
models.
·
Constrained optimization methods—mathematical models using linear,
nonlinear,
dynamic,
integer, and multi-objective programming algorithms.
These
methods are often referred to as decision models. Decision models
include generalized techniques (Decision
Trees, Forced Choice, and others), as
well as specialized ones (Analytic
Hierarchy Process, Logical Framework
Analysis, and others). Applying complex
project selection criteria in a sophisticated
model is often treated as a separate
project phase.
.2 Expert judgment. Expert
judgment will often be required to assess the inputs to
this process. Such expertise may be
provided by any group or individual with specialized
knowledge or training, and is available
from many sources, including:
·
Other units within the performing organization.
·
Consultants.
·
Stakeholders, including customers.
·
Professional and technical associations.
·
Industry groups.
5.1.3 Outputs from Initiation
.1 Project charter. A project charter is a
document that formally authorizes a
project. It should include, either directly
or by reference to other documents:
·
The business need that the project was undertaken to address.
·
The product description (described in Section 5.1.1.1).
The project charter should be issued by a
manager external to the project, and
at a level appropriate to the needs of the
project. It provides the project manager
with the authority to apply organizational
resources to project activities.
When
a project is performed under contract, the signed contract will generally
serve as the project charter for the
seller.
.2 Project manager identified/assigned. In
general, the project manager should be
identified and assigned as early in the
project as is feasible. The project manager
should always be assigned prior to the
start of project plan execution (described
in Section 4.2) and preferably before much
project planning has been done (the
project planning processes are described in
Section 3.3.2).
.3 Constraints. Constraints
are factors that will limit the project management team’s
options. For example, a predefined budget
is a constraint that is highly likely to
limit the team’s options regarding scope,
staffing, and schedule.
When
a project is performed under contract, contractual provisions will generally
be constraints. Another example is a
requirement that the product of the
project be socially, economically, and
environmentally sustainable, which will also
have an effect on the project’s scope,
staffing, and schedule.
.4 Assumptions. See
Section 4.1.1.5.
5.2 SCOPE PLANNING
Scope planning is the
process of progressively elaborating and documenting the
project work (project
scope) that produces the product of the project. Project
scope planning starts
with the initial inputs of product description, the project
charter, and the
initial definition of constraints and assumptions. Note that the
product description
incorporates product requirements that reflect agreed-upon
customer needs and
the product design that meets the product requirements. The
outputs of scope
planning are the scope statement and scope management plan,
with the supporting
detail. The scope statement forms the basis for an agreement
between the project
and the project customer by identifying both the project
objectives and the project
deliverables. Project teams develop multiple scope
statements that are
appropriate for the level of project work decomposition.
5.2.1 Inputs to Scope Planning
.1 Product description. The
product description is discussed in Section 5.1.1.1.
.2 Project charter. The
project charter is described in Section 5.1.3.1.
.3 Constraints. Constraints
are described in Section 5.1.3.3.
.4 Assumptions. Assumptions
are described in Section 4.1.1.5.
5.2.2 Tools and Techniques for Scope Planning
.1 Product analysis. Product
analysis involves developing a better understanding of
the product of the project. It includes
techniques such as product breakdown
analysis systems engineering, value
engineering, value analysis, function analysis,
and quality function deployment.
.2 Benefit/cost analysis. Benefit/cost
analysis involves estimating tangible and
intangible costs (outlays) and benefits
(returns) of various project and product
alternatives, and then using financial
measures, such as return on investment or
payback period, to assess the relative
desirability of the identified alternatives.
.3 Alternatives identification. This
is a general term for any technique used to generate
different approaches to the project. There
is a variety of general management
techniques often used here, the most common
of which are brainstorming
and lateral thinking.
.4 Expert judgment. Expert
judgment is described in Section 5.1.2.2.
5.2.3 Outputs from Scope Planning
.1 Scope statement. The
scope statement provides a documented basis for making
future project decisions and for confirming
or developing common understanding
of project scope among the stakeholders. As
the project progresses, the scope
statement may need to be revised or refined
to reflect approved changes to the
scope of the project. The scope statement
should include, either directly or by reference
to other documents:
·
Project justification—the business need that the project was
undertaken to
address. The project justification
provides the basis for evaluating future
tradeoffs.
·
Project’s product—a brief summary of the product description (the
product
description is discussed in Section
5.1.1.1).
·
Project deliverables—a list of the summary-level subproducts whose
full and satisfactory delivery marks completion of the project. For example,
the major deliverables for a software development project might include the
working computer code, a user manual, and an interactive tutorial. When known,
exclusions should be identified, but anything not explicitly included is
implicitly excluded.
·
Project objectives—the quantifiable criteria that must be met for
the project
to be considered successful.
Project objectives must include at least cost,
schedule, and quality measures.
Project objectives should have an attribute
(e.g., cost), a metric (e.g.,
United States [U.S.] dollars), and an absolute or
relative value (e.g., less than 1.5
million). Unquantified objectives (e.g., “customer
satisfaction”) entail high risk to
successful accomplishment.
.2 Supporting detail. Supporting
detail for the scope statement should be documented
and organized as needed to facilitate its
use by other project management
processes. Supporting detail should always
include documentation of all identified
assumptions and constraints. The amount of
additional detail may vary by
application area.
.3 Scope management plan. This
document describes how project scope will be
managed and how scope changes will be
integrated into the project. It should
also include an assessment of the expected
stability of the project scope (i.e., how
likely is it to change, how frequently, and
by how much). The scope management
plan should also include a clear
description of how scope changes will be identified
and classified. (This is particularly
difficult—and therefore absolutely
essential—when the product characteristics
are still being elaborated.)
A
scope management plan may be formal or informal, highly detailed or
broadly framed, based on the needs of the
project. It is a subsidiary component
of the project plan (described in Section
4.1.3.1).
5.3 SCOPE DEFINITION
Scope definition
involves subdividing the major project deliverables (as identified
in the scope
statement as defined in Section 5.2.3.1) into smaller, more manageable
components to:
·
Improve the accuracy of cost, duration, and resource estimates.
·
Define a baseline for performance measurement and control.
·
Facilitate clear responsibility assignments.
Proper scope
definition is critical to project success. “When there is poor scope
definition, final
project costs can be expected to be higher because of the
inevitable changes
which disrupt project rhythm, cause rework, increase project
time, and lower the
productivity and morale of the workforce” (3).
5.3.1 Inputs to Scope Definition
.1 Scope statement. The
scope statement is described in Section 5.2.3.1.
.2 Constraints. Constraints
are described in Section 5.1.3.3. When a project is done
under contract, the constraints defined by
contractual provisions are often important
considerations during scope definition.
.3 Assumptions. Assumptions
are described in Section 4.1.1.5.
.4 Other planning outputs. The
outputs of the processes in other knowledge areas
should be reviewed for possible impact on
project scope definition.
.5 Historical information. Historical
information about previous projects should be
considered during scope definition.
Information about errors and omissions on
previous projects should be especially
useful.
5.3.2 Tools and Techniques for Scope Definition
.1 Work breakdown structure templates. A
WBS (described in Section 5.3.3.1) from
a
previous project can often be used as a template for a new project. Although
each project is unique, WBSs can often be
“reused” since most projects will
resemble another project to some extent.
For example, most projects within a
given organization will have the same or
similar project life cycles, and will thus
have the same or similar deliverables
required from each phase.
Many
application areas or performing organizations have standard or semistandard
WBSs that can be used as templates. For
example, the U.S. Department
of Defense has recommended standards WBSs
for Defense Material Items (MILHDBK-
881). A portion of one of these templates
is shown as Figure 5-2.
.2 Decomposition. Decomposition
involves subdividing the major project deliverables
or subdeliverables into smaller, more
manageable components until the
deliverables are defined in sufficient
detail to support development of project
activities (planning, executing,
controlling, and closing). Decomposition involves
the following major steps:
(1) Identify the major deliverables of the
project, including project management.
The major deliverables should always be
defined in terms of how the
project will actually be organized. For example:
·
The phases of the project life cycle may be used as the first
level of decomposition
with the project deliverables
repeated at the second level, as illustrated
in Figure 5-3.
·
The organizing principle within each branch of the WBS may vary,
as illustrated
in Figure 5-4.
(2) Decide if
adequate cost and duration estimates can be developed at this
level of detail for
each deliverable. The meaning of adequate may change over the
course of the
project—decomposition of a deliverable that will be produced far
in the future may not
be possible. For each deliverable, proceed to Step 4 if there
is adequate detail,
to Step 3 if there is not—this means that different deliverables
may have differing
levels of decomposition.
(3) Identify constituent components of the
deliverable. Constituent components
should be described
in terms of tangible, verifiable results to facilitate performance
measurement. As with
the major components, the constituent components should
be defined in terms
of how the work of the project will actually be organized and
the work of the
project accomplished. Tangible, verifiable results can include services
as well as products
(e.g., status reporting could be described as weekly status
reports;
for a manufactured item, constituent components might include several
individual components
plus final assembly). Repeat Step 2 on each constituent
component.
(4) Verify the
correctness of the decomposition:
·
Are the lower-level items both necessary and sufficient for
completion of the
decomposed
item? If not, the constituent components must be modified
(added
to, deleted from, or redefined).
·
Is each item clearly and completely defined? If not, the
descriptions must be
revised or expanded.
·
Can each item be appropriately scheduled? Budgeted? Assigned to a
specific
organizational unit (e.g., department, team,
or person) who will accept
responsibility for satisfactory completion of
the item? If not, revisions are
needed to provide adequate management control.
5.3.3 Outputs from Scope Definition
.1 Work breakdown structure. A
WBS is a deliverable-oriented grouping of project
components that
organizes and defines the total scope of the project; work not
in the WBS is outside
the scope of the project. As with the scope statement, the
WBS is often used to
develop or confirm a common understanding of project
scope. Each
descending level represents an increasingly detailed description of
the project
deliverables. Section 5.3.2.2 describes the most common approach for
developing a WBS. A
WBS is normally presented in chart form, as illustrated in
Figures
5-2, 5-3, and 5-4; however, the WBS should not be
confused with the
method of
presentation—drawing an unstructured activity list in chart form does
not make it a WBS.
Each item in the WBS
is generally assigned a unique identifier; these identifiers
can provide a
structure for a hierarchical summation of costs and resources. The
items at the lowest
level of the WBS may be referred to as work packages, especially
in organizations that
follow earned value management practices. These
work packages may in
turn be further decomposed in a subproject work breakdown
structure. Generally,
this type of approach is used when the project manager
is assigning a scope
of work to another organization, and this other organization
must plan and manage
the scope of work at a more detailed level than the project
manager in the main
project. These work packages may be further decomposed in
the project plan and
schedule, as described in Sections 5.3.2.2 and 6.1.2.1.
Work component
descriptions are often collected in a WBS dictionary. A WBS
dictionary will
typically include work package descriptions, as well as other planning
information such as
schedule dates, cost budgets, and staff assignments.
The WBS should not be
confused with other kinds of “breakdown” structures
used to present
project information. Other structures commonly used in some
application areas
include:
·
Contractual WBS (CWBS), which is used to define the level of
reporting that
the seller will provide the buyer. The CWBS
generally includes less detail than
the WBS used by the seller to manage the
seller’s work.
·
Organizational breakdown structure (OBS), which is used to show
which
work components have been assigned to which
organizational units.
·
Resource breakdown structure (RBS), which is a variation of the
OBS and is
typically used when work components are
assigned to individuals.
·
Bill of materials (BOM), which presents a hierarchical view of the
physical
assemblies, subassemblies, and components
needed to fabricate a manufactured
product.
·
Project breakdown structure (PBS), which is fundamentally the same
as a
properly done WBS. The term PBS is
widely used in application areas where
the term WBS is incorrectly used to
refer to a BOM.
.2 Scope statement updates. Include
any modification of the contents of the scope
statement (described
in Section 5.2.3.1). Appropriate stakeholders must be notified
as needed.
5.4 SCOPE VERIFICATION
Scope verification is
the process of obtaining formal acceptance of the project
scope by the
stakeholders (sponsor, client, customer, etc.). It requires reviewing
deliverables and work
results to ensure that all were completed correctly and satisfactorily.
If the project is
terminated early, the scope verification process should
establish and
document the level and extent of completion. Scope verification differs
from quality control
(described in Section 8.3) in that it is primarily concerned
with acceptance of
the work results while quality control is primarily
concerned with the correctness
of the work results. These processes are generally
performed in parallel
to ensure both correctness and acceptance.
5.4.1 Inputs to Scope Verification
.1 Work results. Work results—which deliverables have been fully or partially
completed—
are an output of project plan execution
(discussed in Section 4.2).
.2 Product documentation. Documents
produced to describe the project’s products
must be available for review. The terms
used to describe this documentation
(plans, specifications, technical
documentation, drawings, etc.) vary by application
area.
.3 Work breakdown structure. The
WBS aids in definition of the scope, and should
be used to verify the work of the project
(see Section 5.3.3.1).
.4 Scope statement. The
scope statement defines the scope in some detail and
should be verified (see Section 5.2.3.1).
.5 Project plan. The
project plan is described in Section 4.1.3.1.
5.4.2 Tools and Techniques for Scope Verification
.1 Inspection. Inspection
includes activities such as measuring, examining, and
testing undertaken to determine whether
results conform to requirements.
Inspections are variously called reviews,
product reviews, audits, and walkthroughs;
in some application
areas, these different terms have narrow and specific
meanings.
5.4.3 Outputs from Scope Verification
.1 Formal acceptance. Documentation
that the client or sponsor has accepted the
product of the project phase or major
deliverable(s) must be prepared and distributed.
Such acceptance may be conditional,
especially at the end of a phase.
5.5 SCOPE CHANGE CONTROL
Scope change control
is concerned with a) influencing the factors that create
scope changes to
ensure that changes are agreed upon, b) determining that a
scope change has
occurred, and c) managing the actual changes when and if they
occur. Scope change
control must be thoroughly integrated with the other control
processes (schedule
control, cost control, quality control, and others, as discussed
in Section 4.3).
5.5.1 Inputs to Scope Change Control
.1 Work breakdown structure. The
WBS is described in Section 5.3.3.1. It defines the
project’s scope baseline.
.2 Performance reports. Performance
reports, discussed in Section 10.3.3.1, provide
information on scope performance, such as
which interim deliverables have been
completed and which have not. Performance
reports may also alert the project
team to issues that may cause problems in
the future.
.3 Change requests. Change
requests may occur in many forms—oral or written,
direct or indirect, externally or
internally initiated, and legally mandated or
optional. Changes may require expanding the
scope or may allow shrinking it.
Most change requests are the result of:
·
An external event (e.g., a change in a government regulation).
·
An error or omission in defining the scope of the product (e.g.,
failure to
include a required feature in the design of a
telecommunications system).
·
An error or omission in defining the scope of the project (e.g.,
using a BOM
instead
of a WBS).
·
A value-adding change (e.g., an environmental remediation project
is able to
reduce
costs by taking advantage of technology that was not available when
the
scope was originally defined).
·
Implementing a contingency plan or workaround plan to respond to a
risk, as
described
in Section 11.6.3.3.
.4 Scope management plan. The
scope management plan is described in Section
5.2.3.3.
5.5.2 Tools and Techniques for Scope Change Control
.1 Scope change control. A scope
change control defines the procedures by which
the project scope may be changed. It
includes the paperwork, tracking systems,
and approval levels necessary for
authorizing changes. The scope change control
should be integrated with the integrated
change control described in Section 4.3
and, in particular, with any system or
systems in place to control product scope.
When the project is done under contract,
the scope change control must also
comply with all relevant contractual provisions.
.2 Performance measurement. Performance
measurement techniques, described in
Section 10.3.2, help to assess the
magnitude of any variations that do occur. Determining
what is causing the variance relative to
the baseline and deciding if the
variance requires corrective action are
important parts of scope change control.
.3 Additional planning. Few
projects run exactly according to plan. Prospective
scope changes may require modifications to
the WBS or analysis of alternative
approaches (see Sections 5.3.3.1 and
5.2.2.3, respectively).
5.5.3 Outputs from Scope Change Control
.1 Scope changes. A
scope change is any modification to the agreed-upon project
scope as defined by the approved WBS. Scope
changes often require adjustments
to cost, time, quality, or other project
objectives.
Project scope changes are fed back through
the planning process, technical
and planning documents are updated as
needed, and stakeholders are notified as
appropriate.
.2 Corrective action. Corrective
action is anything done to bring expected future
project performance in line with the
project plan.
.3 Lessons learned. The
causes of variances, the reasoning behind the corrective
action chosen, and other types of lessons learned
from scope change control
should be documented, so that this
information becomes part of the historical
database for both this project and other
projects of the performing organization.
.4 Adjusted baseline. Depending
upon the nature of the change, the corresponding
baseline document may be revised and
reissued to reflect the approved change
and form the new baseline for future
changes.
