Project Scope Management Tutorial

Welcome to the fifth lesson of the PMP tutorial, which is part of the ‘PMP® Certification Training Course.’ In this lesson, we will focus on project scope management.

Let us begin with the objectives of this lesson.


After completing this lesson, you will be able to:

  • Define Project Scope Management

  • Differentiate between project scope and product scope

  • Identify the key terms used in project scope management

  • Explain work breakdown structure

  • Describe the Project Scope Management processes

Let us begin with the first topic of this lesson, project scope management.

What is Project Scope Management?

Project scope management includes the processes required to ensure that a project comprises all and only the work required to complete the project successfully. The project scope management is concerned about the scope; what is not there in the scope is also clearly identified.

In the next section, let us look at the key activities performed under project scope management.

Project Scope Management Activities

Let us look at few of the typical activities that happen as part of the project scope management.

The key activities of Project Scope Management are as follows:

Ensure Constant Monitoring

Constant monitoring is essential to make sure that all the project work is being completed.

Avoid Scope Creep

The gradual, uncontrolled increase in the scope of the project is referred to as scope creep. It is necessary to define the project scope boundaries and not let people randomly add to the project scope.

Prevent Gold Plating

Gold plating is doing more than what is required as part of the project scope. This has to be avoided in projects. As per the published statistics about projects done globally, less than 40 percent of projects can be considered successful.

Therefore, the focus should be on what is required rather than squandering around with what is not required. 40 percent might be considered less, but a project is classified as successful only if it meets all its objectives and is done within time and cost budgets.

In the next section, let us understand the difference between product scope and project scope.

Product Scope vs. Project Scope

Given below are some differences between product scope and project scope.

Product Scope

Project Scope

Product scope refers to the features and functions that characterize a product, service, or result.

Project scope refers to the work performed to deliver a product, service, or result with the specified features and functions. Project Scope is often inclusive of Product Scope.

The word “product” may also include the creation of a service.

Project scope management deals with managing both the product scope as well as the project scope.

Example: In the banking sector, services like savings accounts and mutual funds are called products.

Example: To deliver a product, requirement and design documents have to be produced. This is a part of project scope and not product scope.

In the next section, let us cover the Definition Work Breakdown Structure in detail.

Definition of Work Breakdown Structure (WBS)

A deliverable-oriented, functional decomposition of the project scope of work into hierarchically grouped work elements is called a Work Breakdown Structure, i.e., WBS.

Work Breakdown Structure (WBS) reflects the scope baseline of the entire project. Deliverables not incorporated in WBS will not be a part of the project.

  • WBS is prepared with the team’s buy-in.

  • During decomposition, each level should be complete; it should include all the work in the project before decomposing further.

  • Decomposition should be done until the lowest work unit cannot be logically subdivided further (and it can be estimated with reasonable accuracy).

  • WBS is a deliverable-oriented decomposition and should contain only deliverables and not activities.

  • WBS is part of Project Scope Baseline along with Project Scope Statement and WBS Dictionary

In the next section, let us look into Work Breakdown Structure.

Work Breakdown Structure

Along with the scope statement and the WBS dictionary, the work breakdown structure forms the scope baseline of the project, i.e., it should reflect the entire scope of the project. Any deliverables that are not reflected in WBS are not part of the project.

The creation of the WBS should involve the whole team. The creation of WBS creates a common understanding of the scope and therefore leads to team buy-in. During decomposing the deliverables, you must ensure that each level is complete, i.e., it includes all the work in the project before you start to decompose further.

Decomposition continues until the lowest level deliverable cannot be logically sub-divided further or they can be estimated with reasonable accuracy. WBS is a “deliverable-oriented” decomposition. It should only contain deliverables and not activities.

While developing the schedule, converting the deliverables into activities is one of the problems as WBS does not contain activity level details. Concept-based questions on Work Breakdown Structure can be expected in the exam. So it is essential to have a clear understanding of the concept of WBS.

In the next section, let us look into an example, which shows how WBS is derived.

Work Breakdown Structure - Example

Work breakdown structure of a core banking software development project is given in the section. The scope of the project has been divided into WBS elements, like requirements documentation, design and architecture, code, test, and go live.

Further, these elements are decomposed into work package level to make it easier to manage the deliverables regarding scope, cost, time. It also helps to estimate or assign the specific work packages to team members or groups.

Given below is the WBS of a core banking software development project.

Figure- WBS of a core banking software development project

The design and architecture have been decomposed to model and prototype. Similarly, the code is decomposed into work package 3.1 and 3.2, test into work package 4.1 and 4.2, and go live into product installer and warranty sheet.

WP 3.1 can be represented as module 1 and WP 3.2 as module 2. Similarly, WP 4.1 may be tested strategy document and WP 4.2 a test plan document. The number here indicates work breakdown code.

In the next section, let us discuss a few key terms used in the project scope management.

Key Terms

A few key terms used in the project scope management are:

  • Work Breakdown Structure

  • WBS Dictionary

  • Project Scope Statement

  • Control Account

Let us begin with Work Breakdown Structure.

Work Breakdown Structure:

WBS stands for work breakdown structure. It means breaking the project deliverables into smaller and more manageable components called work packages. The last level of work in such subdivision is called “work packages,” and the whole structure is called “WBS.”

For example, a typical software development project would have various activities, like finalizing requirements, designing the new system, coding, testing, and going live with the new system. Each of these translates into high-level deliverables, which can be further subdivided into smaller activities which are more predictable.

WBS Dictionary:

WBS dictionary, like any dictionary, contains the explanation of the terms used in WBS. A typical WBS dictionary has details like:

  • The control account, the name of the work package

  • Description of the work package

  • The resource assigned if there are any assumptions or dependencies to complete the work package

  • The due date to finish the work package

  • Technical dependencies, and so on.

WBS dictionary is useful for the person or group working on the work package as it further elaborates the decomposed work package. A control account is a level within WBS at which management wishes to exercise control, for example, perform earned value analysis, track performance, etc.

Project Scope Statement:

The project scope statement is the description of the project scope, major deliverables, assumptions, and constraints. It describes the project’s deliverables in detail.

Control Account:

A management control point where scope, budget, actual cost, and schedule are integrated and compared to the earned value for performance measurement.

In the next section, let us discuss how project scope management is accomplished.

Project Scope Management Processes

The figure below explains Project Scope Management Processes.


There are six project management processes, which are part of the project scope management knowledge area. These processes are plan scope management; collect requirements; define scope; create WBS; validate scope; and control scope.

The first four processes, i.e., plan scope management, collect requirements, define scope, and create WBS are part of the planning process group; and the remaining two processes, validate scope and control scope, are executed as part of the monitoring and controlling process group.

In the next few sections, we will look at each of these processes in detail. Let’s begin with plan scope management.

Plan Scope Management

Plan scope management process creates a scope management plan that documents how the project scope will be defined, validated, and controlled. It is usually the starting point of the planning processes on a project.

Understanding the scope and how it will be managed is fundamental to planning the other aspects of the project.

Given below is the Plan Scope Management: Inputs, Tools & Techniques, and Outputs.


Let us review the list of inputs to this process. The project management plan provides other subsidiary plans and will help guide the scope planning activities on the project.

The project charter provides an overall context and the high-level product and project description, which may help to determine the approach for scope management.

Enterprise environmental factors provide the organizational context to the project, including the culture of the organization, the infrastructure, key personnel, and so on. Organizational process assets provide inputs such as policies and procedures, historical information, and knowledge base.

Now, let us look at the tools and techniques employed in this process.

Expert judgment refers to input received from knowledgeable and experienced resources. Meetings may be organized to determine the scope management plan.

Everyone responsible for the project scope management, such as the project manager, sponsor, customer, and other stakeholders must attend these meetings.

Now, let us look at the outputs of this process.

The scope management plan describes how the project’s scope will be defined, like who will be involved in the process, whose inputs will be sought, what techniques may be used to get those inputs, etc., developed, i.e., in what form will the scope be elaborated and documented, monitored and controlled, and verified.

The plan may also describe how WBS will be created from the scope statement, how changes to the scope will be managed, how deliverables will receive formal acceptance, etc.

The requirements management plan is a subsidiary of the project management plan that describes how requirements will be analyzed, documented, and managed. A requirement is voiced by a customer or a stakeholder, whereas scope represents what the project team will do or deliver to meet that need.

The requirement management plan may also describe how the configuration management of the requirements will be carried out, how they will be prioritized, how the metrics will be used to rationalize these choices and how the traceability of the requirements will be maintained throughout the project.

You may get questions in the PMP exam, based on the inputs, tools and techniques, and outputs of plan scope management. So an understanding of these topics will help you to answer concept based questions correctly.

In the next section, let us look at the second process, Collect Requirements.

Collect Requirements

Collect requirements is the second of the six project scope management processes. It is the process of defining and documenting stakeholders needs to meet the project objectives.

Given below is the Collect Requirements: Inputs, Tools & Techniques, and Outputs.


Let us look at the inputs to this process.

  • Scope management and the requirements management plan provide clarity on how the team should go about collecting and documenting the requirements for the project.

  • The stakeholder management plan provides insights into the stakeholder's communication requirements and the level of stakeholder engagement needed.

  • The stakeholder register may provide useful guidance about which of the stakeholders could provide the requirements for the project. It is very important that all the stakeholder's expectations are captured adequately and represented in the requirements documentation.

  • The project charter provides high-level requirements and expectations and may be used to detail out the requirements.

Now, let us look at the tools and techniques that can be employed to collect the requirements.

It is important for the project team to use a combination of techniques that will give them maximum clarity about the requirements.

Some of the techniques may include direct interaction like:

  • Interviewing

  • Forming focus groups

  • Conducting workshops

  • Using group creativity techniques, like brainstorming, and group decision-making techniques. It may also include some offline activities like conducting surveys via questionnaires, etc.

  • Observation can be a very powerful way to capture requirements that may be difficult to state or articulate.

  • Prototyping is a powerful technique where the team comes up with a model or sample artifact that helps the users visualize and gain more clarity about what is being developed.

  • Benchmarking is useful for understanding and learning from the industry and organizational benchmarks about the bare minimum expectations.

Use of context diagrams and analyzing the documentation provided can also help in collecting requirements. Requirements documentation is one of the most important output.

The second output of this process is requirements traceability matrix. This table helps trace whether the work has happened on the requirements, whether all requirements are reflected in the final product of the project, etc.

In the next section, let us look into a business scenario to understand this concept better.

Business Scenario: Problem Statement

Gina is a project manager with Bluedot Software Development and Web Design Company. A large, global customer contracts the company to design software that would allow them to:

  • Capture service requests from thousands of potential client

  • Track existing client projects and facilitate communication between them and their clients.

Gina has never led a project of this size but has successfully completed a similar project on a smaller scale. Therefore, Gina feels confident about her abilities to lead the project and will utilize historical information from her previous project to plan for this initiative.

During the planning process, Gina and her team conduct interviews and surveys and facilitate workshops to collect the necessary requirements needed to complete the project scope of work. They use these requirements to design and build the software system.

Unfortunately, during the final user acceptance testing of the software, which is required for customer sign-off, Gina’s project team discovers the software design will not support the performance requirements when the system is under a load of several hundred users. What happens now?

Let us look at the solution.

Business Scenario: Solution

This is a major blow to Gina and her team. They had captured the customer requirements accurately but had not anticipated how to support the non-functional requirements for load and performance of the system.

With this being a software design issue, the team has to rewrite the core architecture of the software, which requires all components of the systems to be retested before customer sign-off.

Because of the team’s inability to adequately define the requirements without cutting corners, the rework impacts Gina’s project in several ways:

  • Increased cost

  • High risk of customer dissatisfaction

  • Missed schedule deadlines

  • Low morale of project team members

The project needs to assess the impact and likely requires a Change Request for schedule and budget impacts.

In the next section, let us discuss group creativity techniques.

Group Creativity Techniques

Group creativity techniques are used to channelize a group’s combined brainpower to solve a problem, identify requirements or risks, or make a decision.

Some of the popular group creativity techniques are:

  • Brainstorming

  • Nominal group technique

  • Idea or mind mapping

  • Affinity diagram

  • Multi-criteria decision analysis

Brainstorming is used to generate many ideas in a short span of time. It does not involve critique, analysis, or prioritization. The idea is to stimulate lateral thinking by promoting free, unfettered thinking among a group.

Nominal group technique is used to select from a set of ideas combines brainstorming with a voting process to identify the select ideas for further thought or prioritization. Idea or mind mapping combines ideas from individual brainstorming for identifying commonality and differences in thinking.

An affinity diagram is useful for categorizing ideas into groups for review and further analysis. Multi-criteria decision analysis utilizes a decision matrix to provide a systematic approach for decision-making based on multiple criteria.

In the next section, let us discuss the group decision-making techniques.

Group Decision-Making Techniques

Group decision-making techniques are used to arrive at decisions when many people are involved in the decision-making process. The commonly used methods are :

  • Unanimity

  • Majority

  • Plurality

  • Dictatorship

Group Decision-Making Techniques Everyone agreeing on a single course of action may take extensive discussions before reaching this stage. It may be preceded by a technique such as the Delphi technique where people answer questionnaires and reconcile differences with group thinking in a sequential process.

In a majority system, decisions are taken based on the choice of 50 percent or more of the group. In a system of plurality, there are typically multiple options available, and the decision is taken by a single group or block even if they are not in majority. In a dictatorship, one individual decides on behalf of the group.

In the next section, let us discuss requirements traceability matrix.

Requirements Traceability Matrix

Given the section is an example of the requirements traceability matrix.

Requirement Number



System Testing

Acceptance Testing (Multi-user access)

SDD Section 3.1

RBAC processing.cpp Schema Creation.sql

Tests 111-120

Tests 51-55









It lists all the requirements recorded in the requirements documentation in the first column. In the subsequent columns, it traces how the requirement is being met by specific sections or objects in the subsequent stages.

In case of a software development project, the requirement for enabling multi-user access may require changes in multiple places. These are specifically called out in the columns titled design, coding, testing, etc.

This ensures each requirement is specifically addressed through all the stages of the life cycle and also provides backward traceability by clarifying why a particular change is made at each stage (i.e., which requirement is driving these changes).

A typical question in the PMP exam can be one related to the creation of WBS. So understanding the requirements traceability matrix will help you to answer concept based questions.

In the next section, let us look at the third project scope management process, define scope.

Define Scope

The next process in the project scope management is “define scope.” Define scope is the process of developing a detailed description of the project and product. Collect requirements lists for all the different requirements or needs expressed by the stakeholders. Define scope deals with detailing these requirements and determining what will be within the scope of the project and what will not be. It belongs to the planning process group.

Given the section is Define Scope: Inputs, Tools & Techniques, and Outputs.


Let us look at the inputs to this process. The scope management plan provides the details about the process of capturing and documenting the scope of the project. Project charter, which describes the business need of the project, and the requirements documentation developed as part of the collect requirement process also form inputs to this process.

Organizational process assets are also a part of the define scope process. Organization template may be used to write the project scope or refer to the lessons learned from previous, similar projects. For projects, which have product instead of service as an output, product analysis is a commonly used technique. This defines what is required for a project’s product.

Alternatives generation is a technique used to see if the project requirements can be completed in a different way, similar to lateral thinking. Expert judgment is a technique using an expert, maybe an external consultant to look at various requirements and come up with the project scope statement.

To define the scope, you may also conduct specific workshops that are facilitated to generate ideas around the project scope. The output of this process is the project scope statement, which describes in detail the project’s deliverables and the work required to create those deliverables.

Therefore, the project scope statement has project’s product scope description, product acceptance criteria, project deliverables, and project constraints. This process also results in updating the requirements documentation and requirement traceability matrix developed earlier.

Let us look at the next process, Create WBS.

Create WBS

The final planning process within scope management is Create WBS. Create WBS is the process of subdividing project deliverables and project work into smaller, more manageable components. It belongs to the planning process group.

Below figure explains  Inputs, Tools & Techniques, and Outputs for creating WBS.

Figure -Create WBS: Inputs, Tools & Techniques, and Outputs

The WBS is created with project scope statement and the requirements document as input. The scope management plan provides the details about the process of capturing and documenting the scope of the project, and how the deliverables should be decomposed in the form of a WBS and how it should be maintained.

The templates and standards related to the industry and the specific enterprise may be useful in creating WBS. If there is an organization’s template for writing down WBS, that is also used. The other two inputs are organizational process assets and enterprise environmental factors. Decomposition is an important technique used in this process.

In decomposition, the project deliverables are subdivided into smaller, more manageable components until the work and deliverables are defined at the work package level. The work package level is the lowest level in the WBS and is the point at which the cost and activity duration of the work can be reliably estimated and managed.

The level of detail for work packages vary as per the size and complexity of the project. Another technique used is expert judgment. The output of this process is scope baseline. The project scope statement, WBS and WBS dictionary are collectively referred to as scope baseline.

Scope baseline is part of project management plan. This process also results in project document updates. Implementing WBS may result in getting more clarity about the requirements itself. The requirement document or the project scope statement developed earlier should be updated.

In the next section, let us look at the validate scope process.

Validate Scope

Validate scope is the process of formalizing acceptance of the completed project deliverables. Validating scope includes reviewing deliverables with the customer or sponsor to ensure they are completed satisfactorily and obtain formal acceptance. Validate scope is closely related to quality control as well.

However, scope validation is primarily concerned with acceptance of the deliverables; whereas, quality control is primarily concerned with the correctness of the deliverables and meeting the quality requirements specified for the deliverables.

Quality control is generally performed before scope validation, but these two processes can be performed in parallel as well.


Let us look at the inputs to this process.

The project management plan provides information about how the deliverables will be validated and accepted by the customer and other stakeholders. The requirements documentation acts as the basis on which the validation activity is to be carried out. The requirements traceability matrix documents how each of the requirements has been implemented and how it can be validated.

The fourth input is verified deliverables and implies that the verification activity is first carried out by the team under the control quality process, and only then, the deliverable enters the validation process. Work performance data gives more inputs on the deliverables that may be useful in validating and getting acceptance.

The technique used to validate scope is inspection and group decision making. Some of the typical activities that are done as part of inspection are measuring, examining, and validating to determine whether the work and deliverables meet requirements and product acceptance criteria.

Group decision-making techniques may be employed if a team is working on the process of validating the deliverables. It helps in arriving at a decision by either consensus or majority or any other method. The output of this process is the accepted deliverable.

Sometimes deliverable might be acceptable, and that results in another output, i.e., change request. Due to the validation process, the information about the deliverables, which have been accepted, and any observations during the validation process may be recorded.

Some documents, like a report on the status of the project’s product, is updated as result of this process and listed as one of the outputs.

In the next section, let us look at the control scope process.

Control Scope

Control scope is the process of monitoring the status of the project and product scope and changes to the scope baseline. Controlling the project scope ensures all requested changes and recommended corrective or preventive actions are processed through the “perform integrated change control process.”


The inputs project management plan, requirements documentation, and work performance data are the same as the inputs for control scope and validate scope. Work performance data has information about the progress of work on the different deliverables.

The other input is requirements traceability matrix, which lists the requirements included in the requirements document.

Organization process assets also influence control scope in a sense where an organization would have standard templates for monitoring and reporting scope related updates.

Scope control is performed using variance analysis. The variation is measured from the original scope baseline, which decides whether any corrective or preventive action is required.

The key output of the control scope is work performance information, which is planned versus actual technical scope performance. If any part of the scope performance does not meet the acceptance criteria, it may result in change requests, which is the other major output of this process.

All of these may result in updates to the project plan as well as other project and organizational process documents. Business scenario based questions on scope control can be expected in the PMP exam. So understanding the concept of scope control is essential.

In the next section, let us look into important outputs from Project Scope Management.

Important Outputs

Outputs from Project Scope Management can be:

  • Work Performance Information

  • Accepted Deliverables

  • Change Requests

Let us begin with Work Performance Information.

Work Performance Information:

The performance data collected from controlling processes analyzed in comparison with project management plan components, project documents, and other work performance information. Work performance data becomes work performance information after the tools and techniques of a process have been applied.

Accepted Deliverables:

These are deliverables that have been verified and are ready for validation against the project scope at which point they are accepted.

Change Requests:

When validating project scope, new requirements might be discovered, for example, adding an email notification when a password is changed. These requirements should be documented as change requests.

In the next section, let us understand what Data–Information–Knowledge–Wisdom is.


The PMI emphasizes managing project known as an important technique throughout all processes.

Existing knowledge and new knowledge are represented as Project Performance Data, which acts as an input to a process and, in turn, produces an output of Project Performance Information.

Graph- Data–Information–Knowledge–Wisdom

Data-Information-Knowledge-Wisdom (DIKW) is the heart of knowledge management. Effective sharing of knowledge requires the development and maintenance of data.

Some facts related to DIKW are:

  • Data is a set of discrete facts

  • Information requires applying meaning or relevance to the set of facts

In the next section, let us look into a business scenario to understand this concept better.

Business Scenario: Problem Statement

Brian, the project manager of a strong-matrix organization, has been leading projects for his company for ten years. The company has decided to streamline their operations and create policies and procedures to cultivate a culture that is more centered on driving customer excellence.

This shift in mindset is slowly being adopted by company leaders and staff members. Brian’s current project is 25% complete, ahead of schedule, and currently under budget. Every two weeks, Brian schedules meeting with key stakeholders to review the project reports and metrics.

During the last stakeholder meeting, Brian was asked by one of the key stakeholders to add a new feature to the scope of work in the form of a formal change request.

This stakeholder has just returned from an industry conference where he gained insight into some advanced technology that would increase the company’s competitive position and result in a large increase in market share. How should Brian handle this change request?

Let us now look at the solution for this business scenario.

Business Scenario: Solution

As this was a formal request by a key stakeholder, Brian should follow the agreed upon Change Request process. This would include analyzing the costs and benefits of the proposed request and providing alternatives to minimize the impact on cost and schedule.

Once this analysis is complete, Brian can present his findings to the Sponsor and Stakeholders for their decision.


Here is a quick recap of what was covered in this lesson:

  • Project Scope Management includes the processes required to ensure that a project includes all and only the work essential to complete the project successfully.

  • Product scope refers to the features and functions that characterize a product, service, or result, while project scope refers to the work that must be performed to deliver a product, service, or result with the specified features and functions.

  • Work Breakdown Structure breaks the project scope into smaller and more manageable pieces called work packages which are easy to manage.

  • WBS dictionary contains the explanation of the terms used in WBS.

  • The six Project Scope Management processes are Plan Scope Management, Collect Requirements, Define Scope, Create WBS, Validate Scope, and Control Scope.


This concludes the lesson on Project Scope Management. In the next lesson, we will discuss Project Schedule Management

Find our PMP Certification Training Online Classroom training classes in top cities:

Name Date Place
PMP Certification Training 29 May -26 Jun 2021, Weekend batch Your City View Details
PMP Certification Training 5 Jun -3 Jul 2021, Weekend batch New York City View Details
PMP Certification Training 6 Jun -21 Jun 2021, Weekdays batch Boston View Details
  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*