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
control- ling 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 indi- viduals
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 well-
defined 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 spec- ified 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 sub- sidiary
components—hardware, software, training, and implementation.
Completion of the project
scope is measured against the project
plan, but com- pletion 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.
PROJECT SCOPE MANAGEMENT
5.1 Initiation
1 Inputs
.1 Product
description
.2 Strategic plan
.3 Project selection
criteria
.4 Historical
information
.2 Tools and
Techniques
.1 Project selection
methods
.2 Expert judgment
.3 Outputs
.1 Project charter
.2 Project manager
identified/assigned
.3 Constraints
.4 Assumptions
5.2 Scope Planning
.1 Inputs
.1 Product description
.2 Project charter
.3 Constraints
.4 Assumptions
.2 Tools and
Techniques
.1 Product analysis
.2 Benefit/cost
analysis
.3 Alternatives
identification
.4 Expert judgment
.3 Outputs
.1 Scope statement
.2 Supporting detail
.3 Scope management
plan
5.3 Scope Definition
.1 Inputs
.1 Scope statement
.2 Constraints
.3 Assumptions
.4 Other planning
outputs
.5 Historical
information
.2 Tools and
Techniques
.1 Work breakdown
structure templates
.2 Decomposition
.3 Outputs
.1 Work breakdown
structure
.2 Scope statement
updates
5.4 Scope Verification
.1 Inputs
.1 Work results
.2 Product
documentation
.3 Work breakdown
structure
.4 Scope statement
.5 Project plan
.2 Tools and
Techniques
.1 Inspection
.3 Outputs
.1 Formal acceptance
5.5 Scope Change
Control
.1 Inputs
.1 Work breakdown
structure
.2 Performance
reports
.3 Change requests
.4 Scope management
plan
.2 Tools and
Techniques
.1 Scope change
control system
.2 Performance
measurement
.3 Additional
planning
.3 Outputs
.1 Scope changes
.2 Corrective action
.3 Lessons learned
.4 Adjusted baseline
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. Proj- ects 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 fuel-
efficient 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 estab-
lish 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 require-
ments. The central theme of all these terms
is that management generally must
make a decision about how to respond.
Inputs
.1 Product
description
.2 Strategic plan
.3 Project
selection criteria
.4 Historical
information
Tools & Techniques
.1 Project selection
methods
.2 Expert judgment
Outputs
.1 Project charter
.2 Project manager
identified/assigned
.3 Constraints
.4 Assumptions
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 sup-port 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 con- sidered 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 selec- tion 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, non- linear, 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 sophisti-
cated 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 spe- cialized
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 gen- erally 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.
benefit contribution, or economic models.
■ Constrained optimization methods—mathematical models
using linear, non- linear, 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 sophisti-
cated 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 spe- cialized
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 gen- erally 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.
Inputs
.1 Product
description
.2 Project charter
.3 Constraints
.4 Assumptions
Tools & Techniques
.1 Product analysis
.2 Benefit/cost
analysis
.3 Alternatives
identification
.4 Expert judgment
Outputs
.1 Scope statement
.2 Supporting detail
.3 Scope management
plan
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 gen- erate
different approaches to the project. There is a variety
of general manage- ment
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 ref- erence 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 sat- isfactory delivery marks
completion of the project. For example, the major deliv- erables 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., “cus- tomer satisfaction”) entail high risk to successful accomplishment.
.2 Supporting
detail. Supporting detail for the
scope statement should be docu- mented and organized as needed to
facilitate its use by other project management processes. Supporting detail should always
include documentation of all identi- fied 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 iden- tified 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 identi-
fied in the scope statement as defined
in Section 5.2.3.1) into smaller, more man- ageable 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).
Inputs
.1 Scope statement
.2 Constraints
.3 Assumptions
.4 Other planning
outputs
.5 Historical
information
Tools & Techniques
.1 Work breakdown
structure templates
.2 Decomposition
Outputs
.1 Work breakdown
structure
.2 Scope statement
updates
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 impor-
tant 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.
Aircraft System
Project Management
Systems Engineering Management
Supporting PM Activities
Training
Equipment Training
Facilities Training
Services Training
Data
Technical Orders
Engineering Data
Management Data
Air Vehicle
Airframe
Engine
Communication System
Navigation System
Fire Control System
Support Equipment
Organizational Level SE
Intermediate Level SE
Depot Level SE
Facilities
Base Buildings
Maintenance Facility
Test and Evaluation
Operational Test
Developmental Test
Test
Many application areas
or performing organizations have standard or semi- standard WBSs
that can be used as templates. For
example, the U.S. Department of Defense
has recommended standards WBSs for Defense Material Items (MIL- HDBK-881). A portion of one of
these templates is shown as Figure 5-2.
.2
Decomposition. Decomposition
involves subdividing the major project
deliver- ables 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 manage- ment. 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 decompo-
sition 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 illus-
trated 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.
Software Product
Release 5.0
Project Management
Planning
Meetings
Administration
Product Requirements
Software
User Documentation
Training Program Materials
Detail Design
Software
User Documentation
Training Program Materials
Construct
Software
User Documentation
Training Program Materials
Integration and Test
Software
User Documentation
Training Program Materials
This WBS is illustrative only. It is not intended to
represent the full project scope of any specific project, nor to imply that
this is the only way to organize a WBS on this type of project.
Figure 5–3. Sample Work Breakdown Structure Organized
by Phase
(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 ser- vices 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, espe- cially in organizations that
follow earned value management practices. These work packages may
in turn be further decomposed in a subproject work break- down 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
plan- ning 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 manufac- tured 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 noti- fied 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
sat- isfactorily. If the project is terminated early, the scope verification
process should establish and document
the level and extent of completion. Scope verification dif- fers from
quality control (described in Section 8.3)
in that it is primarily con-
cerned 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 com- pleted—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 applica- tion 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
walk- throughs; in some application areas, these different terms have narrow and spe- cific 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 dis- tributed. 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 con- trol processes
(schedule control, cost control, quality
control, and others, as dis-
cussed 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. Deter- mining 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.
Tidak ada komentar:
Posting Komentar