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.