Assignment: PMBOK Ch# 5 Project Scope Management

Submitted to: Sir Shahid Naseer

Submitted by: M Saad Sarfraz

Date: 7-4-2017

1
Table of Contents
Purpose of CH#5:.................................................................................................................................5
1. Plan Scope Management.........................................................................................................................5
1.1 Inputs.............................................................................................................................................5
1.1.1 Project Charter...........................................................................................................................5
1.1.2 Organizational Process Assets....................................................................................................5
1.2 Outputs..........................................................................................................................................5
1.2.1 Scope Management Plan............................................................................................................5
1.2.2 Requirements Management Plan...............................................................................................6
2. Collect Requirements Process.................................................................................................................6
2.1 Inputs.............................................................................................................................................6
2.1.1 Scope Management Plan............................................................................................................6
2.1.2 Requirements Management Plan...............................................................................................6
2.1.3 Project Charter...........................................................................................................................6
2.1.4 Stakeholder Management Plan..................................................................................................7
2.2 Tools and Techniques....................................................................................................................7
2.2.1 Questionnaire.............................................................................................................................7
2.2.2 Observation................................................................................................................................7
2.2.3 Benchmarking.............................................................................................................................7
2.2.4 Prototyping.................................................................................................................................7
2.2.5 Facilitated Workshop..................................................................................................................7
2.2.6 Focused Groups..........................................................................................................................8
2.2.7 Group Decision Making Techniques............................................................................................8
2.2.8 Context Diagram.........................................................................................................................8
2.3 Outputs..........................................................................................................................................8
2.3.1 Requirements Traceability Matrix..............................................................................................8
2.3.2 Requirements Documentation....................................................................................................8

2
3. Define Scope............................................................................................................................................8
3.1 Inputs.............................................................................................................................................9
3.1.1 Project Charter...........................................................................................................................9
3.1.2 Requirements Documentation....................................................................................................9
3.2 Tools and Techniques....................................................................................................................9
3.2.1 Product Analysis.........................................................................................................................9
3.2.2 Alternative Generation...............................................................................................................9
3.3 Outputs..........................................................................................................................................9
3.3.1 Project Scope Statement............................................................................................................9
4. Create WBS............................................................................................................................................10
4.1 Inputs...........................................................................................................................................10
4.1.1 Requirements Documentation..................................................................................................10
4.1.2 Project Scope Statement..........................................................................................................10
4.2 Tools and Techniques..................................................................................................................10
4.2.1 Expert Judgment.......................................................................................................................10
4.2.2 Decomposition..........................................................................................................................10
4.3 Outputs........................................................................................................................................11
4.3.1 Scope Baseline..........................................................................................................................11
5. Validate Scope.......................................................................................................................................11
5.1 Inputs...........................................................................................................................................11
5.1.1 Project Management Plan........................................................................................................11
5.1.2 Requirements Documentation..................................................................................................11
5.1.3 Work Performance Data...........................................................................................................12
5.1.4 Requirements Traceability Matrix.............................................................................................12
5.2 Tools and Techniques..................................................................................................................12
5.2.1 Inspection.................................................................................................................................12
5.2.2 Group Decision Making Techniques..........................................................................................12
5.3 Outputs........................................................................................................................................12
5.3.1 Accepted Deliverables..............................................................................................................12
5.3.2 Change Requests......................................................................................................................12
6. Control Scope........................................................................................................................................12
6.1 Inputs...........................................................................................................................................13

3
6.1.1 Requirements Documentation..................................................................................................13
6.1.2Work Performance Data............................................................................................................13
6.1.3 Project Management Plan........................................................................................................13
6.2 Tools and Techniques..................................................................................................................13
6.2.1 Variance....................................................................................................................................13
6.3 Output.........................................................................................................................................13
6.3.1 Work Performance Information................................................................................................13

4
Purpose of CH#5:
Ch # 5 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.

Scope baseline is the approved version of project scope statement, WBS and WBS dictionary.
Completion of project scope is measured against project management plan while completion of product
scope is measured against product requirements.

1. Plan Scope Management

Plan scope management is the first process and will tell “HOW” remaining processes ‘collect
requirements’, ‘Define scope’ and ‘Create WBS’ will be done. In plan scope management, we will be

5
defining how WBS will be created and even ‘How’ the two processes of Monitoring and closing will be
done.

Scope is related to the requirements of clients. ’Requirement Management Plan’ which is output of Plan
Scope management is different from process ‘Collect Requirements’.

Plan Scope Management helps to reduce the risk of project scope creep. Project scope creep refers to
uncontrolled changes or added objectives in a project scope. This phenomenon occurs when scope of
project is not properly defined.

1.1 Inputs

1.1.1 Project Charter

Project charter contains the high level details of scope, time and cost. Project charter contains SOW
which provides the high level project description and product characteristics.

1.1.2 Organizational Process Assets

Previous project files can be used as input in the plan scope management process.

1.2 Outputs

1.2.1 Scope Management Plan

Scope management plan will tell how to run the other processes of Plan Scope Management.

1.2.2 Requirements Management Plan

Requirements management plan is the component of Project management plan that describes how
requirements will be analyzed, documented and managed. This Plan is used to document necessary
information required to effectively manage project requirements from definition through traceability to
delivery.

2. Collect Requirements Process

Collect requirements is the process of determining, documenting and managing stakeholder needs and
requirements to meet project needs. This process provides the basis for defining and managing the
project scope including the product scope.

6
Project Charter contains only high level details of requirements while Process Collect requirements
contains each and every detail of requirements. Meeting is done with stakeholders requirements. End
user should be in meeting as end user is very critical stakeholder.

2.1 Inputs

2.1.1 Scope Management Plan

Scope Management Plan will contain information like the time and venue of meeting with stakeholders
and the agenda of meeting.

2.1.2 Requirements Management Plan

This Plan will contain information as in what sort of requirements have to be asked from clients.

2.1.3 Project Charter

To counter wish list of client, we need project charter as input to counter undue wishes. You can tell the
client that extra work he asked is outside the project boundaries set by the project charter.

2.1.4 Stakeholder Management Plan

This plan is one of the inputs as it is used to understand the stakeholder’s communication requirements.

2.2 Tools and Techniques

Tools and techniques are used in process ‘Collect Requirements ‘for three purposes, to collect, clarify
and finalize the requirements.

2.2.1 Questionnaire
There are two types of questionnaires open ended and close ended. In open ended there is space to
write answer while in close ended only options are given to be selected.

7
When stakeholders are large in number then interviewing them one by one is difficult so instead of
interview, we will share questionnaire among a sample of stakeholders at random. These questionnaire
then reflect the requirements.

2.2.2 Observation
Observation is also known as “Job Shadowing” and in this case requirements are taken just by observing.
For example, developing an automated solution for making 1 lac bread at ‘Baheria Dastarkhawan’.

2.2.3 Benchmarking
Benchmarking means to idealize for example if a client tells to construct a university like LUMS, then he
has idealized or benchmarked LUMS.

2.2.4 Prototyping
Prototyping is used to get correct and complete requirements. We verify the correctness of
requirements by making a model that is prototyping.

There are two types of prototype: Throw away Prototype and Evolutionary Prototype. In throw away
prototype, model is disposed of once client agrees with that model is the right thing he want.

In Evolutionary prototype, prototype will change and evolve until finally agreed. This model is not
disposed.

2.2.5 Facilitated Workshop

Sometimes even after showing model to client, requirements are not synchronized after prototyping. To
solve this issue, we have a technique called ‘Facilitated Workshop’. In this workshop, both performing
organization and client will sit together and make prototype together.

In facilitated workshop, only problematic issues will be discussed and then you will get right prototype.

JAD is one example of facilitated workshop.

User story is covered in facilitated workshop. In user story, client makes a story to clarify requirements.
To get clear understanding, we get user story.

2.2.6 Focused Groups

In focused groups, interviews are specific and done with specific group of people like taking
requirements from cashier one day and taking requirements from order taker the other day.

2.2.7 Group Decision Making Techniques

Sometimes PM has to bring people on common point during collecting requirements when people are
divided in their opinion. To solve this issue, we use group decision making techniques.

In ‘Unanimity’ we create unanimity be making people understand the situation and to bring everyone on
the same page.

In ‘Majority’ we solve the issue by vote count and decision is done by the majority.

8
In ‘Plurality’ when people are divided into three or more blocks of opinions of requirements, the group
with ‘Majority’ will be selected for final say.

In ‘Dictatorship’ one person rules everyone else.

2.2.8 Context Diagram

This is an example of scope model. This visually depicts the ‘product scope’ by showing a business
system and how system and other people interact with it.

2.3 Outputs

2.3.1 Requirements Traceability Matrix

This matrix is a grid that links product requirements from their origin to the deliverables that satisfy
them. It provides structure for managing changes to product scope.

2.3.2 Requirements Documentation

This document describes how individual requirements meet the business need for the project.

3. Define Scope
Key benefit of this process is that it describes which of the requirements collected will be included in
and excluded from the project. Define Scope is the process of developing a detailed description of the
project and product.

There are two types of requirements, functional and non functional. Functional requirements are the
characteristics of the product while non functional requirements are like asking for reliability, security
and durability features.

Once we have gathered all the requirements then we need to define scope. For that we need to make a
document called Project scope statement.

3.1 Inputs

3.1.1 Project Charter

SOW is ‘what’ part of project in brief and is contained in project charter hence project charter is input to
‘Define Scope’ Process.

9
3.1.2 Requirements Documentation
This document contains the detailed requirements.

3.2 Tools and Techniques

3.2.1 Product Analysis

Product analysis is effective tool when projects have product as deliverables as opposed to service or
result.

3.2.2 Alternative Generation

This technique is used to develop as many potential options to identify different approaches to execute
and perform the work of project.

3.3 Outputs

3.3.1 Project Scope Statement

Project scope statement contains description of project, description of product, major deliverables,
assumptions, constraints and acceptance criteria.

After discussing with clients, we write down then major deliverables in project scope statement and this
is the difference between project scope statement and project charter.

A project scope statement is the summary of the work to be done. Project Scope statement contains
‘Project exclusion’ portion to explicitly state what is out of the scope for the project.

Completion of Project scope is measured against project management plan while completion of product
scope is measured against the product requirements.

4. Create WBS
We need WBS to have a map, to understand what work has to be done in the project. We use WBS to
get buy-in of the project team. It is said that best technique to get output from project people by
involving them in making WBS.

PM not being product oriented needs WBS to divide work. In WBS we divide project into their types.

WBS is picture used by PM for discussion of project with any stakeholders of that project.WBS diagram
is used for communication, for discussion with any stakeholder to verify that we are not missing any
piece of work.

10
Planned work is contained in the lowest level of WBS component which is called work package. A work
package can be used to group the activities where work is scheduled, estimated, monitored and
controlled. Work package is the lowest level of WBS for which cost and duration can be estimated.

4.1 Inputs

4.1.1 Requirements Documentation

This document is going to tell the experts to decompose the included work in the project into WBS.

4.1.2 Project Scope Statement

This statement will tell which work is included and excluded from the project.

4.2 Tools and Techniques

4.2.1 Expert Judgment

PM cannot break WBS himself because he is not product specific person rather he has project oriented
skills hence he need Product oriented experts to break WBS.

4.2.2 Decomposition
PM will decompose bigger works into smaller works. Decomposition required subdividing the work for
each deliverable or subcomponent into its most fundamental element where WBS component
represents verifiable product, service or result.

Decomposition may not be possible for deliverable that will be accomplished far into the future. Project
management team waits until deliverables or subcomponent is agreed on, so that the details of WBS
can be developed. This technique is called Rolling Wave Planning.

The total of the work at the lowest levels should roll up to the higher levels so that nothing is left out
and no extra work is performed. This technique is called 100 percent rule.

Control account is management control point where scope, budgets, actual cost and schedule are
integrated and compared to the earned value for the performance measurement.

Planning package is a WBS component below the control account with known work content but without
detailed schedule activities.

11
4.3 Outputs

4.3.1 Scope Baseline

Scope baseline is the approved version of WBS, WBS dictionary and project scope statement signed by
client.

PM will ask experts how one product specific work will be accomplished and then PM will write down
the details into WBS dictionary for future reference.

5. Validate Scope
Validate scope is the process of formalizing acceptance of the completed project deliverables. Outputs
obtained from planning processes in scope management knowledge area and work performance data
obtained from execution processes are basis for performing the validation and for final acceptance.

When deliverables are ready e.g. Itron flow prover machine, this is not shown to customer sngpl rather
quality team will first check and inspect itron flow prover machine .This is verification being done by the
quality team. Once verified by quality team, final product is given to client, who checks and validates the
project.

5.1 Inputs

5.1.1 Project Management Plan

This plan contains scope management plan and scope baseline. Scope management plan contains
information as in how validate scope process will be carried out.

5.1.2 Requirements Documentation

This document contains the entire project and product related requirements as well as acceptance
criteria.

5.1.3 Work Performance Data

This data include the degree of compliance with requirements and number of non conformities.

5.1.4 Requirements Traceability Matrix

Scope baseline is not input to validate scope process rather traceability matrix is .This matrix will help
when client will not agree to deliverables.

12
5.2 Tools and Techniques

5.2.1 Inspection
Inspection often called review is done by the client to validate the deliverable.

5.2.2 Group Decision Making Techniques

These techniques are used when validation is done by the project team and other stakeholders.

5.3 Outputs

5.3.1 Accepted Deliverables

Deliverables are considered accepted once validated by the client.

5.3.2 Change Requests

We face change requests when deliverables are not accepted by client.

6. Control Scope
Control scope ensures that no one during execution of project increases or decrease the project work
and same project work is being done which was assigned.

Gold platting is undue extra and not required work added by project team members.Do not take
additional work as compliment.PM should not like gold platting.

Scope creep is done by the client during execution phase. We have to stop client from adding changes to
scope which are out of boundaries.

6.1 Inputs

6.1.1 Requirements Documentation

This document will tell what the planned thing was assigned to project team.

6.1.2Work Performance Data

This data will tell the actual work done by the project team at the moment.

13
6.1.3 Project Management Plan
Project management plan contains scope baseline, scope management plan, change management plan
and configuration management plan.

Scope baseline is compared to actual results to determine if corrective or preventive action is required.

Change management plan tells how to manage changes on project.

Configuration management plan tells which items can be configured, which items require formal change
control and the processes for controlling changes to such items.

6.2 Tools and Techniques

6.2.1 Variance
Variance is the difference of actual vs. planned.

Important aspects of project scope control include determine the causes and degree of variance relative
to the scope baseline and then deciding whether preventive or corrective action is required.

6.3 Output

6.3.1 Work Performance Information

This contains contextualized and correlated information on how the project scope is performing
compared to the scope baseline.

14
15