Chapter 5: Project Scope Management

After reading this chapter, you will be able to

• List key reasons why good project scope management is important
• Describe the process of planning scope management
• Discuss methods for collecting and documenting requirements to meet stakeholder needs and
expectations
• Explain the scope definition process and describe the contents of a project scope statement
• Discuss the process for creating a work breakdown structure using the analogy, top-down,
bottom-up, and mind-mapping approaches
• Explain the importance of validating scope and how it relates to defining and controlling scope
• Given an information technology (IT) project situation, show how recommended approaches
for controlling scope can improve the potential for project success
• Describe how software can assist in project scope management
• Discuss considerations for agile/adaptive environments

Project scope management

- Many of the factors associated with project success, such as user involvement, clear business
objectives, and optimized scope, are elements of project scope management
- Scope refers to all the work involved in creating the products of the project and the processes
used to create them
- Answer the question – “What will the project produce in the end”.
-“The processes required to ensure that the project includes all the work required to complete the
project successfully”

- includes the processes involved in defining and controlling what work is or is not included in a
project.
It ensures that the project team and stakeholders have the same understanding of what products
the project will produce and what processes the project team will use to produce them.
Why Do We Manage Scope?

 Can’t manage schedule and budget if scope is out of control (Triple Constraint)

 Scope docs are used to manage expectation

1
 Schedule TIME

SCOPE Budget COST

Project Initiation documents

 Project Mandate: first document produced to trigger a project,

 It encapsulates the ideas and any basic information that can be obtained at this initial phase

 This document should not take more than one day to write.

 Project Charter: it is a document that

 Formally recognizes the existence of a project

 provides direction on the project´s objectives and management.

Six main processes are involved in project scope management:

1. Planning scope management involves determining how the project’s scope and requirements
will be managed.
2. Collecting requirements involves defining and documenting the features and functions of the
products as well as the processes used for creating them.
[Link] scope involves reviewing the scope management plan, project charter, requirements
documents, and organizational process assets to create a scope statement, adding more
information as requirements are developed and change requests are approved.
4. Creating the WBS involves subdividing the major project deliverables into smaller, more
manageable components.
5. Validating scope involves formalizing acceptance of the project deliverables. Key project
stakeholders, such as the customer and sponsor for the project, inspect and then formally accept
the deliverables during this process. If the deliverables are not acceptable, the customer or
sponsor usually requests changes.
6. Controlling scope involves controlling changes to project scope throughout the life of the
project—a challenge on many IT projects. Scope changes often influence the team’s ability to

2
meet project time and cost goals, so project managers must carefully weigh the costs and benefits
of scope changes.
Planning Scope Management
-The first step in project scope management is planning how the scope will be managed
throughout the life of the project.
-After reviewing the project management plan, project charter, enterprise environmental factors,
and organizational process assets, the project team uses expert judgment, data analysis, and
meetings to develop two important outputs: the scope management plan and the requirements
management plan. The scope management plan is a subsidiary part of the project management
plan
-a scope management plan includes the following information:
• How to prepare a detailed project scope statement: For example, are there templates or
guidelines to follow? How much detail is needed to describe each deliverable?
• How to create a WBS: It is often difficult to create a good WBS. This section of the scope
management plan would provide suggestions, samples, and resources for creating a WBS.
• How to maintain and approve the WBS: The initial WBS often changes, and project team
members disagree on what should be included. The scope management plan describes guidelines
for maintaining the WBS and getting approval for it.
• How to obtain formal acceptance of the completed project deliverables: It is extremely
important to understand the process for obtaining formal acceptance of completed deliverables,
especially for projects in which payments are based on formal acceptance
 How to control requests for changes to the project scope: This process is related to
performing integrated change control, as described in Chapter 4. Organizations often have
guidelines for submitting, evaluating, and approving changes to scope, and this section of the
scope management plan would specify how to handle change requests for the project
Requirements management plan
-Another important output of planning scope management is the requirements management plan
-a requirement is defined as follows:
1. A condition or capability needed by a user to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a system or system component to
satisfy a contract, standard, specification, or other formally imposed document.
3. A documented representation of a condition or capability as in 1 or 2.

3
- requirement can also be defined as “a condition or capability that is necessary to be present in a
product, service, or result to satisfy a business need.”
- requirements “include the quantified and documented needs and expectations of the sponsor,
customer, and other stakeholders. These requirements need to be elicited, analyzed, and recorded
in enough detail to be included in the scope baseline and be measured once project execution
begins
For example, the chapter’s opening case describes a project for upgrading IT assets to meet
corporate standards. These standards specify the minimum requirements for each laptop, such as
the type of processor, amount of memory, and hard disk size. The documented requirements for
this project, therefore, might state that all laptops include a specific type of processor, a
minimum amount of memory, and a minimum hard drive size. For software projects, it is helpful
to divide requirements development into the software engineering steps called elicitation,
analysis, specification, and validation. These steps include all the activities involved in gathering,
evaluating, and documenting requirements for a software or software-containing product. It is
also important to use an iterative approach to defining requirements because they are often
unclear early in a project. The requirements management plan documents how project
requirements will be analyzed, documented, and managed.
A requirements management plan can include the following information:
• How to plan, track, and report requirements activities
• How to perform configuration management activities
• How to prioritize requirements
• How to use product metrics
• How to trace and capture attributes of requirements

Collecting Requirements
Inputs

-project charter

-stakeholder register

-The second step in project scope management is often the most difficult: collecting
requirements. A major consequence of not defining requirements well is rework, which can
consume up to half of project costs, especially for software development projects.
- it costs much more (up to 30 times more) to correct a software defect in later development
phases than to fix it in the requirements phase

4
There are several ways to collect requirements.
- Interviewing stakeholders one on one is often very effective, although it can be expensive and
time consuming.
-Holding focus groups and facilitated workshops, and using group creativity and decision-
making techniques to collect requirements are normally faster and less expensive than one-on-
one interviews.
-Questionnaires and surveys can be efficient ways to collect requirements as long as key
stakeholders provide honest and thorough information.
-Observation can also be a good technique for collecting requirements, especially for projects
that involve improving work processes and procedures.
-For software development projects, prototyping and document analysis are common
techniques for collecting requirements, as are context diagrams, which help to clarify the
interfaces and boundaries of a project or process.
-On agile software development projects, the product owner creates the prioritized product
backlog for each sprint, as shown in Chapter 3. Benchmarking, or generating ideas by
comparing specific project practices or product characteristics to those of other projects or
products inside or outside the performing organization, can also be used to collect requirements
-The project’s size, complexity, importance, and other factors affect how much effort is spent on
collecting requirements. For example, a team working on a project to upgrade the entire
corporate accounting system for a multibillion-dollar company with more than 50 locations
should spend a fair amount of time collecting requirements. On the other hand, a project to
upgrade the hardware and software for a small accounting firm with only five employees would
need a much smaller effort. In any case, it is important for a project team to decide how it will
collect and manage requirements. It is crucial to gather inputs from key stakeholders and align
the scope with business strategy
Documenting Requirements
Outputs
-Requirement docs
-Requirement management plan
-Requirement traceability matrix

- listing of all requirements on a single piece of paper to a room full of notebooks

- creating a requirements traceability matrix. A requirements traceability matrix (RTM) is a table
that lists requirements, their various attributes, and the status of the requirements to ensure that
all are addressed

5
e.g
Requiremen Name Category Source Status
t No.
R32 Laptop Hardware Project Complete.
memory charter and Laptops
corporate ordered to
laptop meet
specifications memory
requirement.

Defining Project Scope

-provide a detailed definition of the work required for the project.
-Good scope definition is very important to project success because it helps improve the
accuracy of time, cost, and resource estimates, it defines a baseline for performance
measurement and project control, and it aids in communicating clear work responsibilities.
-The main tools and techniques used in defining scope include expert judgment, data analysis,
decision making, interpersonal and team skills, and product analysis.
-The main outputs of scope definition are the project scope statement and project documents
updates
- project scope statements should include at least a product scope description, product user
acceptance criteria, and detailed information on all project deliverables

Project Charter: Upgrades may affect servers . . . (listed under Project Objectives)
Project Scope Statement, Version 1: Servers: If additional servers are required to support this
project, they must be compatible with existing servers. If it is more economical to enhance
existing servers, a detailed description of enhancements must be submitted to the CIO for
approval. See current server specifications provided in Attachment 6. The CEO must approve a
detailed plan describing the servers and their location at least two weeks before installation.
Project Scope Statement, Version 2: Servers: This project will require purchasing 10 new
servers to support Web, network, database, application, and printing functions. Virtualization
will be used to maximize efficiency. Detailed descriptions of the servers are provided in a
product brochure in Attachment 8, along with a plan describing where they will be located.

Creating the Work Breakdown Structure

- After collecting requirements and defining scope, the next step in project scope management is
to create a work breakdown structure

6
- A work breakdown structure (WBS) is a deliverable-oriented grouping of the work involved in
a project that defines its total scope
- The WBS is a foundation document in project management because it provides the basis for
planning and managing project schedules, costs, resources, and changes.
- The project management plan, project documents, enterprise environmental factors, and
organizational process assets are the primary inputs for creating a WBS.
-In addition to expert judgment, the main tool or technique is decomposition—that is,
subdividing project deliverables into smaller pieces.
-The outputs of the process of creating the WBS are the scope baseline and project documents
updates. The scope baseline includes the approved project scope statement and its associated
WBS and WBS dictionary
- A WBS is often depicted as a task-oriented tree of activities, similar to an organizational chart
Intranet

Home Marketi
Web Sales
page ng
design pages
design pages

site graphic progra Hyperlin Hyperlin Hyperlin

Text Images Text Images Text Images
map design ms ks ks ks

Tabular form of WBS

1.0. Software Product Release 5.0
1.1 Project Management
1.1.1 Planning
1.1.2 Meetings
1.1.3 Administration
1.2 Product Requirements
1.2.1 Software
1.2.2 User Documentation
1.2.3 Training Program Materials
1.3 Detail Design
1.3.1 Software
1.3.2 User Documentation
1.3.3 Training Program Materials
1.4 Construct
1.4.1 Software

7
 1.4.2 User Documentation
1.4.3 Training Program Materials
1.5 Integration and Test
1.5.1 Software
1.5.2 User Documentation
1.5.3 Training Program Materials
Work package
-A work package is a task at the lowest level of the WBS.
-it represents the level of work that the project manager monitors and controls.
-You can think of work packages in terms of accountability and reporting.
-If a project has a relatively short time frame and requires weekly progress reports, a work
package might represent work completed in one week or less.
-If a project has a very long time frame and requires quarterly progress reports, a work package
might represent work completed in one month or more.
-A work package might also be the procurement of a specific product or products, such as an
item or items purchased from an outside source.
-A work package should be defined at the proper level so the project manager can clearly
establish an estimate of the effort needed to complete it, estimate the cost of all required
resources, and evaluate the quality of the results when the work package is finished

Approaches to Developing Work Breakdown Structures

You can use several approaches to develop a WBS:
• Using guidelines
• The analogy approach
• The top-down approach
• The bottom-up approach
• The mind-mapping approach
Using guidelines
-if guidelines exist for developing a WBS, it is very important to follow them
The Analogy Approach

8
Another method for constructing a WBS is the analogy approach.
-In the analogy approach, you use a similar project’s WBS as a starting point
The Top-Down Approach
- start with the largest items of the project and break them into subordinate items.
-This process involves refining the work into greater and greater levels of detail.
-After finishing the process, all resources should be assigned at the work package level.
-The top-down approach is best suited to project managers who have vast technical insight and a
big-picture perspective
Bottom-up approach
-team members first identify as many specific tasks related to the project as possible.
-They then aggregate the specific tasks and organize them into summary activities, or higher
levels in the WBS. For example, a group of people might be responsible for creating a WBS to
develop an e-commerce application.
-Instead of looking for guidelines on how to create a WBS or viewing WBSs from similar
projects, they could begin by listing detailed tasks they think they would need to perform in
order to create the application.
-After listing these detailed tasks, they would group the tasks into categories. Then they would
group these categories into higher-level categories

-this approach can be very time consuming, but it can also be a very effective way to create a
WBS.
-Project managers often use the bottom-up approach for projects that represent entirely new
systems or approaches to doing a job, or to help create buy-in and synergy with a project team.
Mind mapping
- mind mapping is a technique that uses branches radiating from a core idea to structure thoughts
and ideas.
- Instead of writing down tasks in a list or immediately trying to create a structure for tasks, mind
mapping allows people to write and even draw pictures of ideas in a nonlinear format.
-This more visual, less structured approach to defining and then grouping tasks can unlock
creativity among individuals and increase participation and morale among teams
- this approach can be used for developing WBSs using the top-down or bottom-up approach

9
WBS Dictionary
- A WBS dictionary is a document that provides detailed information about each WBS item.
- each WBS item must be documented in a WBS dictionary to ensure accurate understanding of the
scope of work included and not included in that item

e.g
WBS Dictionary Entry March 20
Project Title: Information Technology (IT) Upgrade Project
WBS Item Number: 2.2
WBS Item Name: Database Update
Description: The IT department maintains an online database of hardware and software
on the corporate intranet. We need to make sure that we know exactly what hardware
and software employees are currently using and if they have any unique needs before
we decide what to order for the upgrade. This task will involve reviewing information
from the current database, producing reports that list each department’s employees and location,
and updating the data after performing the physical inventory and receiving inputs from
department managers. Our project sponsor will send a notice to all department managers to
communicate the importance of this project and this particular task. In addition to general
hardware and software upgrades, the project sponsors will ask the department managers to
provide information for any unique requirements they might have that could affect the upgrades.
This task also includes updating the inventory data for network hardware and software. After
updating the inventory database, we will send an e-mail to each department manager to verify the
information and make changes online as needed. Department managers will be responsible for
ensuring that their people are available and cooperative during the physical inventory.
Completing this task is dependent on WBS Item Number 2.1, Physical Inventory, and must
precede WBS Item Number 3.0, Hardware and Software Acquisition

scope creep
- the tendency for project scope to keep getting bigger and bigger
- it is very important to verify the project scope with users throughout the life of the project and
develop a process for controlling scope changes.

Scope validation
-involves formal acceptance of the completed project deliverables.

10
-This acceptance is often achieved by a customer inspection and then sign-off on key
deliverables.
-To receive formal acceptance of the project scope, the project team must develop clear
documentation of the project’s products and procedures to evaluate whether they were completed
correctly and satisfactorily
- The main tools for performing scope validation are inspection and decision-making techniques
- The main outputs of scope validation are accepted deliverables, change requests, work
performance information, and project documents updates
Controlling Scope
- Scope control involves managing changes to the project scope while keeping project goals and
business strategy in mind.
-Users often are not sure how they want screens to look or what functionality they will need to
improve business performance.
-Developers are not exactly sure how to interpret user requirements, and they also have to deal
with constantly changing technologies.
-The goal of scope control is to influence the factors that cause scope changes, to ensure that
changes are processed according to procedures developed as part of integrated change control,
and to manage changes when they occur
- The project management plan, project documents, work performance data, and organizational
process assets are the main inputs to scope control. An important tool for performing scope
control is data analysis, including variance analysis
- Variance is the difference between planned and actual performance. For example, if a supplier
was supposed to deliver five special keyboards and you received only four, the variance would
be one keyboard. The outputs of scope control include work performance information, change
requests, project management plan updates, and project documents updates.
Using Software to Assist in Project Scope Management
- can use word-processing software to create scope-related documents
- use spreadsheet or presentation software to develop various charts, graphs, and matrixes related
to scope management.
-Mind-mapping software can be useful in developing a WBS.

11