PRJM 1000 – Collaboration and Project Management

WEEK 3

ABDUL SHAIKH
Ph.D., PMP®
[email protected]

These slides have been created from Effective Project Management, PMBOK® and pmi.org
Project Scope Management
 Project Scope Management Knowledge Area
Project Scope Management Knowledge Area includes the processes required to ensure that the
project includes all the work required and only the work required to complete the project
successfully. It is primarily concerned with defining and controlling what is included and what is
not included in the project.
 Project Scope
The Project Scope is the work the project team will do to deliver the project’s product. Project scope refers to
everything that must be done to deliver the product.
The project scope encompasses the product scope. The scope must be clearly defined and formally approved
before work starts.
For example, On a project to build a new train terminal, the project scope will be “ a new train terminal that meets
this technical specification, plus all the work needed to deliver the train terminal.”
In other words, the project scope includes the planning, coordination, and management activities (such as
meetings and reports) that ensure product scope is achieved.
These efforts become part of the scope baseline and scope management plan, which are parts of a project
management plan.
 Product Scope
Product scope is another way to say “requirements that relate to the product, service, or result of the project.”
It can also be defined as the product deliverables with associated features and functions.
Product scope – not project scope – is defined as the project deliverables.
Let’s look at the train terminal example; the product scope is “a new train terminal that meets these technical
specifications.”
To determine if the project successfully achieved the product scope, the resulting product (the new train terminal) is
compared to the product requirements, which were recorded in the requirements documentation and the project
scope statement.
Note: Product scope refers more narrowly to the features and functions (requirements) of what is being produced. At
the same time, the project scope refers to all the work needed to deliver those features and functions
(requirements).
The product scope is measured against the product requirements.
 Project Scope Statement and Statement of Work
Scope Baseline:
The scope baseline is the approved version of a scope statement, Work Breakdown Structure, and its
associated WBS dictionary.
Once approved, it becomes a controlled document, and the scope baseline can be changed only through
formal change control procedures and is used as a basis for comparison.
It is a component of the project management plan.
Stakeholders have input, but the Project team creates the actual Scope Baseline.
 Scope Creep and Gold Platting
Scope Creep: The PMBOK Guide describes scope creep as “adding features and functionality (project scope)
without addressing the effects on time, costs, and resources, or without customer approval.” Scope creep refers to
uncontrolled changes in scope due to either interference of the customer/stakeholders or a misunderstanding of the
scope by the project team or the project manager.
Gold Platting: Gold plating refers to intentionally adding extra features or functions to the product which were not
included in the product’s scope.
Following are a few causes of gold plating:
A team member may add extra functions to prove his abilities to the project manager, or the Project manager may add
extra functions to earn credit from the client or the top management. Sometimes, it is performed to divert the client’s
attention from the defects in the product.
Although gold plating sounds good to everyone, there is no gold in gold plating, which is bad for the project team and
the project manager in the long run. Gold plating increases the input cost (though, in many cases, it does not appear to
be high), increases the risk, and increases the customer’s expectation.
If you do another project for the same customer, the customer will again expect you to deliver a product with extra
features. If you do not, the customer will be dissatisfied.
 Opportunity Cost
Opportunity Cost:
Opportunity cost is the loss of potential future return from the best alternative project when a choice is required for
several projects.
Opportunity cost in project management is the cost of forgoing one project or activity in favor of another. It is the cost of
not pursuing one option and instead taking another. In other words, it is the cost of the best alternative not chosen.
Opportunity cost can be used to compare the cost of the project to the cost of not doing it or the cost of doing something
else with the same resources.
Since there are limited resources such as humans, time, money, etc., we cannot work on an infinite number of projects
simultaneously. Opportunity cost is a concept to help you judge which project(s) to take and which project(s) NOT to
take based on the relative potential returns of the project(s).
For example, Project A has a potential ROI of $25,000 - Project B has a potential ROI of $20,000 - Project C has a
potential ROI of $10,000
The opportunity cost for selecting Project A for completion over Project B and C will be $20,000 (the “potential loss” of
not completing the second-best project).
Project Scope Management Processes

Define Scope
Collect
5.3
Requirements
Plan Scope
Management 5.2
Create WBS
5.1
5.4

Validate Scope Control Scope

5.5 5.6
 Plan Scope Management
Each of the project management knowledge areas has a management plan.
For the scope management knowledge area, as we have discussed we have two scoops i.e., Project scope and product scope.
When we have two scopes, it means we have two management plans – a Scope Management Plan and a Requirements
Management Plan.
Together these plans provide direction on how the project scope and product scope will be defined, managed, and controlled.
The Scope Management Plan is mainly about tasks or actions required to complete a project or product.
Requirements Management Plan, on the other hand, are features or specifications you intend to build due to the project.
Requirements are ideas you want to implement.
 Plan Scope Management
Scope Management Plan: It is a formal document with the following in mind:
How will the acceptance criteria be derived;
Who will need to be involved in preparing a complete and foolproof Work Breakdown Structure;
How do we handle changes to WBS;
Who will review and approve the changes?
Overall, how do we handle changes in the project scope;
How do we prepare good project scope?
To create a scope management plan, we need; product analysis, stakeholder analysis, scope definition, historical records and lessons
learned from the previous project, and existing templates, forms, or standards for scope management.
Note: The Scope Management Plan does not describe the project scope. But it explains how to create, control, and manage scope
statements, WBS, and WBS dictionary.
 Plan Scope Management
Requirements Management Plan:
It is also a formal document. To create a project requirements management plan, you’ll need to define three key elements: the
project scope, the methodology or process, and the execution plan.
Requirements Management is essential to project success. First, you define the project scope, which drives the rest of the
requirements management plan. The scope provides critical information that informs all requirements necessary to complete the
project and helps avoid scope creep.
The project requirements management plan will note stakeholders, a definition of the requirements, who will manage the
requirements, how you will track each requirement, and what you will do to manage change.
 Plan Scope Management
Project Statement of Work (SOW): A statement Of Work defines, at a high level, the work to be done, pricing, and the
expected timelines. The purpose of a statement of work is to define the entire structure of a project, including its deliverables
and outcomes.
A statement of work is also referred to as an SOW, especially in government contracting. An SOW defines requirements -- a
description of the work requested, a timeline, performance criteria, a schedule of deliverables, travel requirements, location,
and special skills. This information enables the responding contractor or service provider to provide a proposal and cost
estimate.

Project Scope Statement (Scope of Work): The project Scope Statement focuses on the project's specific tasks and how they
connect to its overall goal. The scope of work explains the services the winning vendor will provide on a particular project and
the work performed under a contractual agreement.
The project scope statement documents and addresses the characteristics and boundaries of the project and its associated
products and services, as well as product acceptance criteria and scope control.

Project Scope Statement vs. Statement of Work: The statement of work is prepared by the customer while the project
management team develops the scope statement. The statement of work focuses on physical or technical matters, while the
project scope statement focuses on a functional view.
 Plan Scope Management

Inputs Tools & Techniques Output

The Project charter Expert Judgment Scope Management Plan
The project Management Plan Meetings Requirements Management Plan
EEFs
OPAs
 Collect Requirements
Requirements are what stakeholder needs from a project or product. Remember, work should not be included in a project
just because someone wants it.
Instead, requirements should relate to solving problems or achieving the objectives outlined in a project charter.
Requirements may include requests about how the work is planned and managed.
The collect requirements process looks for all requirements, not just those related to the product. This process is critical to
project success, as missed requirements could mean significant change and conflict throughout the remainder of a project –
and even project failure.
Collect Requirements provide the basis for defining and managing the project scope, including the product scope.
 Collect Requirements
Requirements documents:
The project requirements document (PRD) consolidates all final requirements clearly and concisely. This ensures that all
team members and stakeholders are on the same page. Project requirements are the conditions and functions you must
include for a project to be considered complete. Project closure can only happen when you meet customer and stakeholder
needs.
Project requirements may be business or technical requirements. Business requirements include the high-level business
needs the project must achieve, while technical requirements define how the project will fulfill the business needs.
Requirements documents are used to communicate the aims of a project in a clear, concise way to ensure all stakeholders are
on the same page.
Let’s talk about the main people involved in their creation.
The Customer is ultimately responsible for determining the requirements. The customers’ needs are the origin of the project.
The Business Analyst is responsible for discovering the problem/requirements and determining the solution.
The Project Manager is responsible for delivering the solution to a problem.
The Systems Analyst uses analysis and design to satisfy business requirements using information technology.
The Marketing Manager develops the marketing strategy for the project in line with its requirements.
The Product Manager is responsible for defining the why, when, and what of the product that the development team will
build.​
 Collect Requirements

The following are 9 requirements documents that a business may want to use while pushing a project through its stages of
completion;

1. Business Requirements Document (BRD)

2. Functional Requirements Document (FRD)
3. Market Requirements Document (MRD)
4. Product Requirements Document (PRD)
5. User Interface Requirements Document (UIRD)
6. Technical Requirements Document (TRD)
7. Quality Requirements Document
8. Software Requirements Document or Software Requirements Specification (SRS)
9. Customer Requirements Document
 Collect Requirements
Requirements Traceability Matrix: A requirements traceability matrix (RTM) is a document or tool used to trace the
requirements of a project from the initial stages of the project up to the final product. It ensures that all requirements are met
in the final product and that any changes are tracked and accounted for.
An RTM is typically created at the beginning of a project and continuously updated throughout the project. It tracks the
relationships between the various project requirements, such as user, system, design, and test requirements.
Example: System Requirements: The user must be able to log in to the system - The system must provide secure
authentication - The system must be able to store user data.
Design Requirements: The login page must include username and password fields - Authentication must use secure
encryption - Data must be stored in a secure database
Test Requirements: The login page must be tested for functionality - Authentication must be tested for security - The
database must be tested for security and data integrity.
The requirement Traceability Matrix is a document that contains the description, owner, source, priority, and status of
product requirements.
 Collect Requirements

Input Tools & Techniques Output

The Project Charter Data Gathering Requirements Documentation
Stakeholder Register Data Analysis Requirements Traceability Matrix
Stakeholder Engage. Plan Group Decision-Making
OPA Data Representation
Scope Management Plan Interviews
Requirements Management Plan Surveys/Questionnaires
 Define Scope

The scope is the foundation of the cost estimate and project schedule.
The project scope establishes the boundaries of Tasks that are and are not included for the client.
The defined scope process is primarily concerned with what is included and what is not included in the project and its
deliverables (product).
Define Scope is the process of developing a detailed description of the project and product.
This process uses information from the project charter, the scope management plan, the requirements management plan, the
assumption log, and the risk register to define the project and product scope.
Defining scope helps to ensure that the project is properly planned and executed and helps to ensure that it is completed on
time and within budget.
The key benefit of this process is that it describes the product, service, or result boundaries by defining which of the
requirements collected will be included in and excluded from the project scope.
The result and main objective of the Define Scope process is creating the project scope statement.
During the Planning Process Group, a project manager works on defining the project scope
 Project Requirements and Project
Scope
Project Requirements:
Project requirements are the specific needs or expectations that must be met for a project to be successful. They are based on
the project objectives and provide the basis for project planning.
For example, a project to design and build a new website might require a database to store customer data, a payment system
to process orders, and a content management system to update the site.

Project Scope:
Project scope defines the boundaries of the project. It is the activities required to meet the project objectives and deliverables.
For example, the scope of the website project could include designing the website, coding the database and payment system,
and testing the website before launch. The scope also includes any limitations or constraints that must be considered, such as
budget, timeline, and resources.

Another example: Requirement: Passing the PMP exam.

Scope: Studying PMBOK, reference books, giving mock tests, etc.
 Define Scope

Input Tools & Techniques Output

Scope Management Plan Expert Judgment Project Scope Statement
Project Charter Product Analysis Project Documents Update
OPA
Requirements Documents
Assumption's log
 Create Work Breakdown Structure (WBS)
The Work Breakdown Structure is a Key output of the Planning Process Group.
The Project Management Body of Knowledge (PMBOK Guide) defines the Work Breakdown Structure as a
“deliverable-oriented hierarchical decomposition of the work to be executed by the project team.”
The work breakdown structure visually defines the scope into manageable chunks that a project team can
understand, as each level of the work breakdown structure provides further definition and detail. The WBS
identifies and organizes all the project scope or work of the project.
Work Breakdown Structure (WBS) is an outline of the project tasks and subtasks used to organize and define the
total scope of a project. It breaks down the project into manageable pieces of work to facilitate planning,
scheduling, resource assignment, and cost estimating.
WBS is a graphical picture of the hierarchy of a project that is part of the scope baseline.
WBS identifies all deliverables to be completed. WBS can be used for other projects.
Lack of a good WBS may miss critical work. WBS does not show the dependencies.
A detailed project schedule can be created only after creating the WBS
Decompose until the WBS element cannot be logically decomposed further
Decompose until the WBS element can be estimated accurately
Decompose until the WBS element has a meaningful conclusion
Note: In WBS, the “work” refers not to the activities required to complete the deliverables but to the deliverables
that result from those activities.
 Create WBS
Levels of WBS: There are four main levels of WBS (levels of WBS vary from project to project);

Level 1: The first and the top one of the WBS Levels is the project title.
Level 2: The second one of the WBS Levels is Control Accounts. Control accounts are a project's major parts, systems,
phases, or deliverables. PMI numbering system is also allotted from here.
Level 3: The third one of the WBS Levels is Work Packages. Work packages come together to constitute Control Accounts.
It is a point where it can be reliably scheduled, cost-estimated, monitored & controlled.

Level 4: The last one of the WBS levels is activities. Activities are the tasks assigned to project team member (s) to complete
the work package.
Note: When we are done with breaking down the scope into tasks, at that time, a project manager should identify Staff working
on the project tasks, their roles and responsibilities, and the tasks’ due dates.
 WBS Sample
PMI Numbering: PMI numbering starts from Control Accounts, our level 2 of WBS, and then comes to down level (at Level 1, we have
a project title, it doesn't contain any number).

Project Title

1 2

Control Account Control Account

1.1 1.2 2.1 2.2

Work package Work package Work package Work package

1.1.1 1.1.2 1.2.1 1.2.2 2.1.1 2.1.2 2.2.1 2.2.2

Activity Activity Activity Activity Activity Activity Activity Activity
 WBS of a Wedding Function

Wedding Function

1 2 3 4
Preparation Ceremony Reception Clean-Up

1.1 1.2 2.1 2.2 2.3 3.1 3.2 4.1 4.2 4.3

Hire Decorate Arrange Perform Setup Arrange Clean Return Collect

Book Venue Vendor Food Rentals Decorations
Venue Seating Ceremony Music Venue

1.1.1 1.1.2

Availability
Near Both
On the
Families
Dates
 WBS Dictionary
A Work Breakdown Structure Dictionary is a document that describes each element (Task) within a project’s Work
Breakdown Structure (WBS). A WBS dictionary is where the details of the tasks, activities, and deliverables of the work
breakdown structure are located. The content includes resources, cost, and quantity of each task. It also lists the acceptance
criteria for each deliverable/product. It is an output of Create WBS process.

Project

Control Accounts

Work Package WBS Dictionary

Activity/Task
 Create WBS

Input Tools & Techniques Output

Scope Management Plan Decomposition Scope Baseline
EEF Expert Judgment WBS Dictionary
OPA Project Documents Update
Requirements Documentation WBS
Code of Account identifiers
Description of Works
 Validate Scope
Many people need clarification about what it means to validate scope. People think validating scope means confirming the
validity and appropriateness of the scope definition during project planning. This is incorrect.
However, “the validate scope process actually involves frequent, planned meetings with the customer or sponsor to gain formal
acceptance of interim deliverables during project Monitoring & Controlling.”
The key benefit of this process is that it brings objectivity to the deliverables acceptance process and increases the chance of final
product, service, or result acceptance by validating each deliverable.
In the Validate Scope process, the project sponsor or customer (stakeholders) provides formal acceptance of the completed
project scope and deliverables.
This process is closely related to Control Quality. The key difference is that an internal team works on Control Quality, while an
external source (the customer or sponsor) must Validate the Scope.
If the project is terminated early, the level and extent of completion should be documented. This is done as a part of Validate
Scope.
 Validate Scope
Input Tools & Techniques Output
Project management Plan Inspection Accepted Deliverables
Requirements Documentation Change Requests
Verified deliverables Project Documents Update
Work Performance Data
Validated Deliverables
 Control Scope
The purpose of the control Scope process is to monitor the project’s status. The Control Scope process involves measuring &
assessing work performance data against the scope baseline and managing scope baseline changes.
At any point in a project, the project manager must be sure that the scope is completed according to the project management
plan.
The control scope process must be integrated with another control process. Modification in scope is the first and foremost
issue of the control scope process.
After the scope is finalized, it needs to be monitored throughout the project to see whether project activities will lead to the
successful delivery of project deliverables. The control scope process mainly tracks this in a project.
The control Scope process measures the performance of the project scope and product scope and manages the changes to the
scope baseline.
 Control Scope
Input Tools & Techniques Output
Project Management Plan Data Analysis Work Performance measurement/Information
Project Documents Variance Analysis Change Requests
OPA

Note: Variance analysis is the technique used to find the cause and variance between the agreed baseline
and the actual performance.
PRACTICE QUESTIONS
 Practice Question

As part of tracking a project, a project manager is validating the completion of the project scope.
He or she would measure this against:

A. Requirements traceability matrix

B. The Project Management Plan
C. The Project Charter
D. The Requirements Management Plan
 Practice Question

As part of tracking a project, a project manager is validating the completion of the project scope.
He or she would measure this against:

A. Requirements traceability matrix

B. The Project Management Plan
C. The Project Charter
D. The Requirements Management Plan

Completion of project scope is measured against the scope baseline which is a part of the project management plan.
In contrast, the product scope is measured against the product requirements.
 Practice Question

While managing a project, you have included the product acceptance criteria in the Quality Management Plan.
While reviewing your plan, a senior manager asks you to reconsider this. You then realize that what you did is
incorrect. Where should you place the product acceptance criteria?

A. Project Charter
B. Change control process
C. Project Scope Statement
D. Scope Verification Plan
 Practice Question

While managing a project, you have included the product acceptance criteria in the Quality Management Plan.
While reviewing your plan, a senior manager asks you to reconsider this. You then realize that what you did is
incorrect. Where should you place the product acceptance criteria?

A. Project Charter
B. Change control process
C. Project Scope Statement
D. Scope Verification Plan

The project scope statement documents and addresses the characteristics and boundaries of the project
and its associated products and services, as well as product acceptance criteria and scope control.
 Practice Question

The Project Scope Management Knowledge Area is primarily concerned with:

A. Defining the scope of work that included in the project

B. Ensuring that the project includes all the work required, and only the required, to complete the project.
C. The scope of work required during the initiation phase
D. Defining the specifications and functionality of the work product
 Practice Question

The Project Scope Management Knowledge Area is primarily concerned with:

A. Defining the scope of work that included in the project

B. Ensuring that the project includes all the work required, and only the required, to complete the project.
C. The scope of work required during the initiation phase
D. Defining the specifications and functionality of the work product

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. It is primarily concerned with defining
and controlling what is included and what is not included in the project.
 Practice Question

A project manager approaches you to better understand the Work Breakdown Structure (WBS). You tell her that:

A. A WBS is a detailed project plan and includes the effort and resource dates on which the tasks for the project
are complete.

B. A WBS is a task-oriented decomposition of work that identifies tasks and the resources required to
accomplish the task.

C. The WBS is a deliverable-oriented hierarchical decomposition of the project team must accomplish to meet
project objectives.

D. The WBS is a Gantt chart that contains details about the p deliverables the project team must do.
 Practice Question

A project manager approaches you to better understand the Work Breakdown Structure (WBS). You tell her that:

A. A WBS is a detailed project plan and includes the effort and resource dates on which the tasks for the project
are complete.

B. A WBS is a task-oriented decomposition of work that identifies tasks and the resources required to
accomplish the task.

C. The WBS is a deliverable-oriented hierarchical decomposition of the project team must accomplish to meet
project objectives.

D. The WBS is a Gantt chart that contains details about the p deliverables the project team must do.

The WBS is a deliverable-oriented hierarchical decomposition of the work to be accomplished by the

project team to accomplish project objectives.
 Practice Question

Why must the Validate Scope process be completed in a project?

A. To obtain scope documents from recent similar projects for benchmarking

B. To determine whether the scope is at the correct complexity level
C. To obtain formal acceptance of deliverables by the customer or sponsor
D. To ensure the project team is all aware of the scope
 Practice Question

Why must the Validate Scope process be completed in a project?

A. To obtain scope documents from recent similar projects for benchmarking

B. To determine whether the scope is at the correct complexity level
C. To obtain formal acceptance of deliverables by the customer or sponsor
D. To ensure the project team is all aware of the scope

Validate Scope is the process of formalizing acceptance of the completed project deliverables by the customer
or sponsor of the project.
THANK YOU