Project Scope Management Chapter 5

Overview
Take Notes:
Scope management is the process of defining what work is required and making sure all
of that work and only that work is done. In a generic sense, requirements and scope
seem to be synonymous .but in PMI terminology, these two terms are sequential. PMI
has a rather odd process in this knowledge area. First, “Requirements” will come from
collected in bits and pieces. Then all those collected requirements are summed up into
“A Scope Statement”. From there, the formed scope statement will be broken down
into bits and pieces called “Work Break-down Structure”. Just for easy recall I noted this
down. . However, there is a difference between the two sets of bits and pieces.
Requirements are totally unrelated non cohesive bits and pieces. WBS bits are cohesive
which result into activities.
Scope management also includes the verification part of the project and has a Control
process too.
Scope Management Processes:
th
PMBOK 4 edition has 5 defined processes to manage project scope. These processes
interact with one another and with the processes in the other knowledge Areas. These
processes are:
5.1 Collect Requirements— the process collects stakeholders needs and document all
project needs
5.2 Define Scope— the process develops a detailed scope for the project work. It builds
on the collected requirements
5.3 Create WBS— the process of subdividing project work and deliverables into more
manageable components called “Work Packages” and organizing these work packages
in a hierarchical chart.
5.4 Verify Scope—the process formally accepts completed and quality controlled
deliverables.
5.5 Control scope—the process of monitoring the status of the project and product
scope and managing changes to the scope baseline.

Product Scope Product scope is another way of referring to the “requirements that
relate to the product of the project." It answers the question “What end result is
wanted?" Product scope may be supplied as a result of a previous project to determine
the requirements, or it may be created as a part of the project. Using an example of a
project t of building a new baseball stadium, the product scope might be "build a new
baseball stadium that meets the technical specifications" To determine if the product
scope has been completed on a project, the resulting product (the new baseball
stadium) is evaluated against the product requirements, which are recorded in the
requirements documentation and the project scope statement for the project.

Project Scope This is the work the project will do to deliver the product scope or
product of the project. In the example of the project to build a new baseball stadium, the
project scope is the work to be done to deliver the stadium. This work includes the
planning, coordination, and management activities (such as meetings and reporting) that
ensure that the product scope is achieved. These become part of the scope management
plan, which in turn is a part of the project management plan. To determine if the project
scope has been completed on a project, it is measured against the project management
plan.
The following table describes the Scope Management Inputs, tools & techniques and
outputs.

CertSchool.com
 Chapter 12 Project Procurement Management
Chapter 5 Project Scope Management
Take Notes: Inputs
Project Charter
Stakeholder Register
5.1 Collect
Requirements
Project charter
Requirements Documentation
5.2 Define Scope
Organizational process assets
Project Scope Statement
Requirements Documentation
5.3 Create WBS Organizational process assets
Project Management Plan
Requirements Documentation
5.4 Verify Scope Requirements Traceability
Matrix
Validated Deliverables
Project Management Plan
Work Performance
Information
5.5 Control Scope Requirements Documentation
Requirements Traceability
Matrix
Organizational process assets
Scope Management – Knowledge Area Process Elements (ITTO)
Tools & Techniques Outputs
Interviews Requirements Documentation
Focus Groups Requirements Management
Plan
Facilitated workshops Requirements Traceability
Matrix
Group Creative Techniques
Group Decision Making
Techniques
Questionnaires and Surveys
Observations and Prototypes
Expert Judgments Project Scope Statement
Product Analysis Project Document Updates
Alternative Identification
Facilitated Workshops
Decomposition WBS
WBS Dictionary
Scope Baseline
Project Document Updates
Inspection Accepted Deliverables
Change Requests
Project Document updates
Variance Analysis Work Performance
Measurements
OPA Updates
Change Requests
Project Document updates
Project Management Plan
Updates
CertSchool.com
Project Scope Management Chapter 5

5.1 Collect Requirements Take Notes:

Requirements are what stakeholders need from a project or product. Work should not
be included in a project simply because someone wants it. Instead, the requirements
should relate to solving problems or achieving objectives. Requirements may include
requests about how the work is managed ("You cannot shut down our systems on a
Friday") or capabilities stakeholders would like to see in the product of the project ("The
new software should allow multiple users to access it at the same time"). They also may
be related to quality ("There can be no more than one day of unexpected down time"),
business processes ("You must track and report the project's expenses in this way"), or
even project management ("We require risk management procedure X to be used on
T
the project"). he Collect Requirements process will consider all requirements, not just
those related to the product of the project.
The high-level project and product requirements should have already been defined in
the project charter. The Collect Requirements process involves gathering more specific
input on those requirements from all stakeholders. This process is critical to project
success, as a missed requirement could mean significant changes and conflict
throughout the remainder of the project and could even cause project failure.
There are many techniques available to collect the requirements. The project manager
needs to choose the techniques that are most appropriate for the project and the
stakeholders. The following are some of the techniques:
Interviewing: also called as "expert interviewing”. The team manager or project
manager interviews project stakeholders to identify their requirements for a specific
element of the product or project work, or for the overall project. These interviews can
take place between individuals or in group settings. Interviews can also be conducted
via e-mail, phone calls, letters, or other methods.
Focus Groups This technique helps get a specific set of stakeholders' or subject matter
experts' opinions and requirements for the product or an aspect of the project. The
members of the focus group can discuss their ideas, but the discussion is facilitated by a
moderator.
Facilitated Workshops Facilitated workshops bring together stakeholders with different
perspectives (e.g., product designers and end-users) to talk about the product and,
ultimately, arrive at a consensus regarding the requirements.
Brainstorming This technique strives for "group think.' One person mentions an idea to
solve a problem or, in this case, to determine scope. That idea generates another idea
from another participant, which leads to yet another idea, and so on. This technique
does not assure that all the participants' ideas are captured. Instead, it produces ideas
that were generated from the participants.
Nominal Group Technique' This technique is usually, but not always, done during the
same meeting as brainstorming. The meeting participants rank the most useful ideas
generated during the brainstorming session.
Delphi Technique With this technique, a request for information is sent to experts who
participate anonymously and whose responses are compiled. The results are sent back
to all participants for further review until consensus is reached.

CertSchool.com
 Chapter 12 Project Procurement Management

Chapter 5 Project Scope Management

Mind Maps: A mind map is a diagram of ideas or notes to help generate, classify,
Take Notes: or record information. It looks like several trees radiating out of a central core
word. Colors, pictures, and notations can be used to make the diagram easier to
understand. More readable.

Affinity Diagrams: In this technique, the ideas generated from any other requirements
gathering technique are sorted into groups according to their similarities. Each group of
requirements is then given a title. This sorting makes it easier to see additional scope (or
risks) that have not been identified.
Questionnaires and Surveys Questionnaires or surveys are typically used for large groups.
These tools present questions that help identify requirements from the respondents.
Observation This technique involves job shadowing or watching a potential user of the
product at work and, in some cases, participating in the work to help identify
requirements.
Prototypes A prototype is a model of the proposed product. In this technique, the
prototype is presented to stakeholders for feedback. The prototype may be updated
multiple times to incorporate the feedback until the requirements have been solidified for
the product.

Group Decision-Making Soliciting input on requirements from all stakeholders may

result in too many or conflicting requirements. These need to be reviewed, analyzed,
accepted or rejected, and prioritized before recording them in project documents. There
are different ways to make decisions in a group setting. These are the categories:
- Unanimity
- Majority
- Plurality
- Dictatorship
Requirements Documentation After the requirements have been collected and
finalized, they are documented. This output helps make sure that the requirements are
clear and unambiguous.
Requirements Management Plan In addition to describing the methods to use to identify
requirements, this plan should describe how to analyze, prioritize, manage, and track
changes.
Requirements Traceability Matrix The requirements traceability matrix helps track the
requirements over the life of the project to ensure they are accomplished. The process of
determining requirements for large projects can easily involve one requirement leading to
more refined requirements and clarifications. Therefore, it can be difficult to remember
where a requirement came from. The project manager uses the requirements traceability
matrix to keep track of all the information and to analyze requirements when there are
proposed changes to the project or to the product scope. This matrix usually takes the
form of a table with information like requirement identification numbers, the source of
each requirement, who is assigned to manage the requirement, and the status of the
requirement, including its completion.

CertSchool.com
Project Scope Management Chapter 5

5.2 Define Scope: Take Notes:

The Define Scope process is primarily concerned with what is included and what is
excluded in the project and its deliverables. This process uses the requirements
documentation created in the Collect Requirements process, the project charter, and any
information about project risks, assumptions, and constraints to define the project and
product scope.

The planning process is iterative. When the requirements have been determined, the
project manager determines the schedule and budget. If the resulting schedule and
budget do not meet the sponsor's or management's expectations for the project, the
project manager needs to balance the requirements (scope) against the budget,
schedule, and other constraints in the project.

Project Scope Statement: The primary result, or output, of the Define Scope process is
the project scope statement. This document describes what will be involved in this project
or “approved project and product scope for this project." The project manager should
also consider alternative approaches to perform the work and incorporate the needs of
the stakeholders into the project. The project scope statement, along with the WBS and
WBS dictionary, comprise the scope baseline, which is part of the project management
plan.

The project scope statement may include:

Product scope
Deliverables
Product acceptance criteria
What is not part of the project
Additional risks
Constraints and assumptions

Constraints are factors that limit the team's options, such as limits on resources,
budget, schedule, and scope. Assumptions are things that are believed to be true but
that they may not be true. Constraints and assumptions, which are recorded in the
project scope statement, are inputs to many project management processes.

CertSchool.com
 Chapter 12 Project Procurement Management

Chapter 5 Project Scope Management

5.3 Create WBS

Take Notes:
Experienced project managers understand that it is simply not possible to visualize and
manage an entire project without some sort of a tool. Instead of trying to manage the whole
project at once, all the time, the project must be broken down into manageable sized
pieces,. The Create Work Breakdown Structure process facilitates this goal by categorizing
(subdividing) the major project deliverables into smaller and more manageable groups..

The WBS documents all the work required to successfully complete the project. The WBS
must identify all of the work required, and only the work required, to successfully complete
the project. For real time projects, one should remember following technique to manage
scope creep:
Work packages are not in the WBS are out of scope.

A WBS:
 Is a graphical picture of the hierarchy of the project
 Identifies all the deliverables to be completed
 Is the foundation upon which the project is built
 should exist for every project
 forces you to think through all aspects of the project
 can be reused for other projects
 does NOT show dependencies

To create WBS, the following rules are normally followed:

 The WBS is created with the help of the team.
 The first level is completed before the project is broken down further.
 Each level of the WBS is a smaller piece of the level above.
 The entire project is included in each of the highest levels of the WBS.
 Eventually some levels will be broken down further than others.
 The WBS includes only deliverables that are really needed.

Following WBS Styles are used:

 Deliverables Based
 Functional Groups
 Geographical
 Time Phased
 Mixed

CertSchool.com
Project Scope Management Chapter 5

Chart Format WBS Take Notes:

Outline format WBS

CertSchool.com
Chapter 5 Project Scope Management
Deliverables Based WBS
Take Notes:

WBS Dictionary
The WBS dictionary is an output of the Create WBS process. It can be used as a part of a
work authorization system to inform the team members when their work package is going
to start, schedule milestones, and other information. It can then be used to control what
work is done, when this is to be done to prevent scope creep, and to increase
understanding of the efforts for each work package. The WBS dictionary helps the project
by putting boundaries on what is included in the work package.

Scope Baseline For scope, the baseline is the agreed-upon project scope statement, the
WBS, and the WBS dictionary. A project's (and project manager's) measurements of
success include whether the project has met the requirements and whether the scope
baseline has been met. The scope baseline becomes part of the project management plan
that is approved by the sponsor.

CertSchool.com
Project Scope Management Chapter 5

5.4 Verify Scope: Take Notes:

The Verify Scope process actually involves frequent, planned-in meetings with the
customer or sponsor to gain formal acceptance of deliverables during monitoring and
control. It must be understood that a project deliverable is not complete until it has been
formally accepted, by the individual or group authorized to accept it.

Scope verification differs from quality control. Quality control focuses on the correctness
of work. Scope verification focuses on the formal acceptance of the work.
Formal acceptance must be documented. Scope verification can occur at any level of the
project which can be done for work, for a specific deliverable, for a milestone, for a phase,
or for the overall project. Verify Scope is often a predecessor to the closure of a project
phase or when closing the overall project.

Work must be completed and checked each time before PM meets with the customer.
The completed and checked deliverables are called "validated deliverables”. Validated
deliverables are outputs of the “Quality Control:” process.
The tool used to verify deliverables is Inspection which determines if the deliverable meets
the requirements or not.
Inspection activities include
 Measuring
 Examining
 Verifying
Inspection is also called: reviews, product reviews, audits, and walkthroughs

The following diagram depicts how the project deliverables are planned, checked, and
accepted.

Legend for above diagram:

Process
Output

CertSchool.com
 Chapter 12 Project Procurement Management

Chapter 5 Project Scope Management

Take Notes:
5.5 control Scope

The Control Scope process involves measuring project and product scope performance and
managing scope baseline changes.

To control scope, work should have completed and a clear definition of what the scope on
the project is (the project scope baseline from the project management plan). PM also
needs to be aware of the original requirements recorded in the requirements
documentation and the requirements traceability matrix (inputs to this process). PM then has
to measure scope performance against the scope baseline to see the magnitude of any
variances (variance analysis) and decide if corrective action or preventive action is required.
Once that information is known, the next step is to determine if any updates to the scope
baseline, other parts of the project management plan, or the project documents are
needed, and what changes should be requested. At the same time, the project manager looks
for the impact of scope changes on all aspects of the project (through the Perform Integrated
Change Control process).

The project manager's job is not to just process other people's changes; it is to control the
project to the project management plan and to meet all baselines. Therefore, the project
manager should not be easily swayed or influenced and let others add scope or change scope
without following the approved change management process and without the suggested
changes being within the planned scope of the project. The project manager must control the
project scope.

CertSchool.com