Project Scope Management

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 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:

s Product scope—the features and functions that characterize a product or service.

s 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

5.2 Scope Planning 5.3 Scope Definition

5.1

Initiation

Inputs

.1 Product description

.2 Strategic plan

.3 Project selection criteria

.4 Historical information

.1 Product description

.2 Project charter

.3 Constraints

.4 Assumptions

.1 Scope statement

.2 Constraints

.3 Assumptions

.4 Other planning outputs

.5 Historical information

Tools and Techniques

.1 Project selection

.1 Product analysis

.2 Benefit/cost analysis

.3 Alternatives identification

.4 Expert judgment

.2 Tools and Techniques

methods

.1 Work breakdown

.2 Expert judgment

structure templates

.3 Outputs

.2 Decomposition

.1 Project charter

.2 Project manager

Output

.1 Scope statement

.2 Supporting detail

.3 Scope management plan

.1 Work breakdown

identified/assigned

structure

.3 Constraints

.4 Assumptions

.2 Scope statement

updates

 5.5 Scope Change Control

Scope Verification

5.4

Inputs

.1 Work results

.2 Product documentation

.3 Work breakdown

.1 Work breakdown

structure

.2 Performance reports

.3 Change requests

.4 Scope management plan

.4 Scope statement

.5 Project plan

.2 Tools and Techniques

.2 Tools and Techniques

.1 Scope change control

.1 Inspection system

Outputs

.2 Performance

.1 Formal acceptance

measurement

.3 Additional planning

.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:

s A market demand (e.g., a car company authorizes a project to build more fuel-

efficient cars in response to gasoline shortages).

s A business need (e.g., a training company authorizes a project to create a new

course to increase its revenues).

s A customer request (e.g., an electric utility authorizes a project to build a new

substation to serve a new industrial park).

s A technological advance (e.g., an electronics firm authorizes a new project to

develop a video game player after advances in computer memory).

s A legal requirement (e.g., a paint manufacturer authorizes a project to estab-

lish guidelines for the handling of toxic materials).

s 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 Tools & Techniques Outputs :

Product description

Strategic plan

Project selection criteria

Historical information 

Project selection methods

Expert judgment

Project charter

Project manager

identified/assigned

Constraints

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):

s Benefit measurement methods—comparative approaches, scoring models,

benefit contribution, or economic models.

s 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:

s Other units within the performing organization.

s Consultants.

s Stakeholders, including customers.

s Professional and technical associations.

s 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:

s The business need that the project was undertaken to address.

s 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 Tools & Techniques Outputs:

Product description

Project charter

Constraints

Assumptions

Product analysis

Benefit/cost analysis

Alternatives identification

Expert judgment

Scope statement

Supporting detail

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:

s Project justification—the business need that the project was undertaken to

address. The project justification provides the basis for evaluating future

tradeoffs.

s Project’s product—a brief summary of the product description (the product

description is discussed in Section 5.1.1.1).

s 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.

s 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:

s Improve the accuracy of cost, duration, and resource estimates.

s Define a baseline for performance measurement and control.

s 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 Tools & Techniques Outputs:

Scope statement

Constraints

Assumptions

Other planning outputs

Historical information

Work breakdown structure

templates

Decomposition

Work breakdown structure

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

Support

Air

Management Training Data

Evaluation 

Vehicle

Equipment Facilities Test and

Systems

Equi pmen t

Technical

Organizational

Engineering

Training

Orders

Level SEB ase Building  Mock- ups

Management

Facilities

Supporting

Engineering

Intermediate

Mainenance

Operational

PM  Activities

Training

Data

Level SE

Facility

Test

Services

Management

Depot

Developmental

Training

Level SE

Test

Data

Test

Navigation

Fire  Control

Airframe Engine Communic at ion

System

System

System

This WBS is illustrativeonly.  It is not intended to represent the full project scope of any specific project nortoimply  that this is the only way to organize a WBS on this type of  project.

Figure 5–2. Sample Work Breakdown Structure for Defense Material Items

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:

s 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.

s 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.

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:

s 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).

s Is each item clearly and completely defined? If not, the descriptions must be

revised or expanded.

s 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

Wastewater

Treatment Plan

Earlier

 Later

Phases

Phases

Design

Construction

Civil Drawings

 Headworks

Architectural Drawings

Aeration Basin

Structural Drawings

Effluent Pumping Station

Mechanical Drawings

Air-Handling Building

HVAC Drawings

Sludge Building

Plumbing Drawings

Instrumentation Drawings

Electrical Drawings

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–4. Sample Work Breakdown Structure for Wastewater Treatment Plant

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

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).

Inputs Tools & Techniques Outputs:

 Work breakdown structure

Performance reports

Change requests

Scope management plan

 Scope change control

Performance measurement

Additional planning

 Scope changes

Corrective action

Lessons learned

Adjusted baseline

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:

s An external event (e.g., a change in a government regulation).

s 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).

s An error or omission in defining the scope of the project (e.g., using a BOM

instead of a WBS).

s 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).

s 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.