Welcome to Module 3: Project Scope

Management
Project scope management includes the processes required to ensure that the project addresses
all the work required, and only the work required, to complete the project successfully. The main
processes include planning scope management, collecting requirements, defining scope, creating
the WBS, validating scope, and controlling scope.

The first step in project scope management is planning scope management, a crucial part of many
projects. The main outputs of this process are scope management plan and requirements
management plan.

The second step in project scope management is collecting requirements, also very crucial in many
projects. It is important to review the project charter and meet with key stakeholders listed in the
stakeholder register when collecting requirements. The main outputs of this process are
requirements documentation, a requirements management plan, and a requirements traceability
matrix.

A project scope statement is created in the scope definition process. This document often includes
a product scope description, product user acceptance criteria, detailed information on all project
deliverables, and information on project boundaries, constraints, and assumptions. There are often
several versions of the project scope statement to keep scope information detailed and up-to-date.

A work breakdown structure (WBS) is a deliverable-oriented grouping of the work involved

in a project that defines the total scope of the project. The WBS forms the basis for planning and
managing project schedules, costs, resources, and changes. A good WBS is often difficult to create
because of the complexity of the project. There are several approaches for developing a WBS,
including using guidelines, the analogy approach, the top-down approach, the bottom-up approach,
and mind mapping.

Validating scope involves formal acceptance of the project scope by the stakeholders. Controlling
scope involves controlling changes to the project scope.

Poor project scope management is one of the key reasons projects fail. It is important for good
project scope management to have strong user involvement, a clear statement of requirements,
and a process for managing scope changes.

Readings
Compulsory reading

1. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition. Pennsylvania:
Newtown Square, 2017, pages 129-172.
Can be downloaded through www.pdfdrive.com or purchase through www.amazon.com.

1
Read the Case study below

CASE STUDY

Chloé Ngueya was leading a meeting to create the work breakdown structure (WBS) for the IT
Upgrade Project. This project was necessary because of several high-priority, Internet-based
applications the company was developing. The IT Upgrade Project involved creating and
implementing a plan to get all employees information technology assets to meet new corporate
standards within nine months. These standards specified the minimum equipment required for
each desktop or laptop computer, including the type of processor, amount of memory, hard disk
size, type of network connection, and software. Chloé knew that to perform the upgrades, they
would first have to create a detailed inventory of all of the current hardware, networks, and
software in the entire company of 500 employees. Chloé had worked with other stakeholders to
develop a project charter and initial scope statement. The project charter included rough cost and
schedule estimates for the project and signatures of key stakeholders; the initial scope statement
provided a start in defining the hardware, software, and network requirements as well as other
information related to the project scope. Chloé called a meeting with her project team and other
stakeholders to further define the scope of the project. He wanted to get everyone’s ideas on
what the project involved, who would do what, and how they could avoid scope creep. The
company’s new CEO, Georges Ebelle, was known for keeping a close eye on major projects like
this one. The company had started using a new project management information system that let
everyone know the status of projects at a detailed and high level. Chloé knew that a good WBS
was the foundation for scope, time, and cost performance, but he had never led a team in creating
one or allocating costs based on a WBS.

Required:
Where should Chloé begin?

5. INTRODUCTION
5.1 What is Project Scope Management?
From Chapter 1 we said that several factors are associated with project success. Many of these
factors, such as user involvement, clear business objectives, a minimized or clearly defined scope,
and firm basic requirements, are elements of project scope management.

2
One of the most important and most difficult aspects of project management is defining the scope
of a project. Scope refers to all the work involved in creating the products of the project and the
processes used to create them. Recall from Chapter 2 that the term deliverable describes a
product produced as part of a project. Deliverables can be product-related, such as a piece of
hardware or software, or process-related, such as a planning document or meeting minutes.
Project stakeholders must agree on what the products of the project are and, to some extent, how
they should produce them to define all of the deliverables.

According to PMBOK® Guide, 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” (2017, p.129). That means Project scope management includes the
processes involved in defining and controlling what work is or is not included in a project. It ensures
that the project team and stakeholders have the same understanding of what products the project
will produce and what processes the project team will use to produce them. There are six main
processes involved in project scope management:

1. Plan Scope Management: The process of creating a scope management plan that
documents how the project and product scope will be defined, validated, and controlled.
2. Collecting Requirements: Involves defining and documenting the features and functions
of the products produced during the project as well as the processes used for creating them.
The project team creates stakeholder requirements, a requirements management plan, and
a requirements traceability matrix as outputs of the requirements collection process.
3. Defining scope: Involves reviewing the project charter, requirements documents, and
organizational process assets to create a scope statement, adding more information as
requirements are developed and change requests are approved. The main outputs of scope
definition are the project scope statement and updates to project documents.
4. Creating the WBS (Work Breakdown Structure): Involves subdividing the major project
deliverables into smaller, more manageable components. The main outputs include a work
breakdown structure, a WBS dictionary, a scope baseline, and updates to project
documents.
5. Validating scope: Involves formalizing acceptance of the project deliverables. Key project
stakeholders, such as the customer and sponsor for the project, inspect and then formally
accept the deliverables during this process. If the deliverables are not acceptable, the
customer or sponsor usually requests changes. The main outputs of this process, therefore,
are accepted deliverables and change requests.
6. Controlling scope: Involves controlling changes to project scope throughout the life of the
project a challenge on many projects. Scope changes often influence the team’s ability to
meet project time and cost goals, so project managers must carefully weigh the costs and
benefits of scope changes. The main outputs of this process are change requests, work
performance measurements, and updates to organizational process assets, the project
management plan, and project documents.

Figure 5-1 summarizes these processes and outputs and shows when they occur in a typical
project.

3
 Project Management Project Scope
Process Group Management Processes Outputs

Plan Scope Management Scope management plan, requirements management plan.

Requirements documentation, requirements management plan,

Collect Requirements requirements traceability matrix.
Project Start
Planning
Define Scope Project scope statement, project document updates.

Create Work Breakdown Structure Scope baseline, project document update.

(WBS)

Validate Scope:
Validate Scope Accepted deliverables, work performance information, change
requests, project document updates
Monitoring and
Controlling
Project Finish Control Scope:
Control Scope Work performance information, change requests, project
management plan updates, project document updates.

Figure 5.1. Project Scope Management Summary

The Project Scope Management processes are presented as discrete processes with defined
interfaces while, in practice, they overlap and interact in ways that cannot be completely detailed
in the PMBOK® Guide.

5.2 Key Concepts for Project Scope Management?

In project terms, the word “Scope” can refer to:

• Product scope: The features and functions that characterize a product, service, or result.
• Project scope: The work performed to deliver a product, service, or result with the specified
features and functions. The term “project scope” is sometimes viewed as including product
scope.

Completion of the project scope is measured against the project management plan, while
completion of the product scope is measured against the product requirements. The term
“requirement” is defined as “a condition or capability that is required to be present in a product,
service, or result to satisfy an agreement or other formally imposed specification” (PMBOK® Guide,
2017, p.131).

The Project Scope Statement is used to develop and confirm a common understanding of the
project scope among key project stakeholders. The scope statement should include the project
justification, a brief description of the project outputs and its intended benefits, a brief summary of
the project major constraints, assumptions and dependencies with other projects or external
initiatives and a statement of what constitutes project success. This document is used as a
communications tool with all project stakeholders to ensure all have a common perception of what
the projects is and what it is not, it is also used to communicate any approved changes made to
the project.

4
Validate Scope is the process of formalizing acceptance of the completed project deliverables. The
verified deliverables obtained from the Control Quality process are an input to the Validate Scope
process. One of the outputs of Validate Scope is accepted deliverables that are formally signed off
and approved by the authorized stakeholder. Therefore, the stakeholder needs to get involved early
on during planning (sometimes initiating as well) and to provide inputs about quality of deliverables
so that Control Quality can assess the performance and recommend necessary changes.

5.3 Trends and Emerging Practices in Project Scope

Management
Requirements have always been a concern in project management and have continued to gain
more attention in the profession. As the global environment becomes more complex, organizations
are starting to recognize how to use business analysis to their competitive advantage by defining,
managing, and controlling requirements activities. Activities of business analysis may start before
a project is initiated and a project manager is assigned. According to Requirements Management:
A Practice Guide, the requirements management process starts with a needs assessment, which
may begin in portfolio planning, in program planning, or within a discrete project.

Eliciting, documenting, and managing stakeholder requirements takes place within the Project
Scope Management processes. Trends and emerging practices for Project Scope Management
include but are not limited to a focus on collaborating with business analysis professionals to:

• Determine problems and identify business needs;

• Identify and recommend viable solutions for meeting those needs;
• Elicit, document, and manage stakeholder requirements in order to meet business and
project objectives; and
• Facilitate the successful implementation of the product, service, or end result of the program
or project.

The process ends with the requirements closure, which transitions the product, service, or result
to the recipient in order to measure, monitor, realize, and sustain benefits over time.

The project manager is responsible for ensuring that requirements-related work is accounted for in
the project management plan and that requirements-related activities are performed on time and
within budget and deliver value.

5.4 Tailoring Considerations

Because each project is unique, the project manager may need to tailor the way that Project Scope
Management processes are applied. Considerations for tailoring include but are not limited to:

• Knowledge and requirements management: Does the organization have formal or

informal knowledge and requirements management systems? What guidelines should the
project manager establish for requirements to be reused in the future?
• Validation and control: Does the organization have existing formal or informal validation
and control-related policies, procedures, and guidelines?
• Development approach: Does the organization use agile approaches in managing
projects? Is the development approach iterative or incremental? Is a predictive approach
used? Will a hybrid approach be productive?

5
 • Stability of requirements: Are there areas of the project with unstable requirements? Do
unstable requirements necessitate the use of lean, agile, or other adaptive techniques until
they are stable and well defined?
• Governance: Does the organization have formal or informal audit and governance policies,
procedures, and guidelines?

5.5 Plan Scope Management

The first step in project scope management is plan scope management. Plan Scope Management
is “the process of creating a scope management plan that documents how the project and product
scope will be defined, validated, and controlled” (PMBOK® Guide, 2017, p.133). The key benefit
of this process is that it provides guidance and direction on how scope will be managed throughout
the project. This process is performed once or at predefined points in the project. The inputs, tools
and techniques, and outputs of this process are depicted in Figure 5-2.

Inputs Tools & Techniques Outputs

1. Project charter 1. Expert judgment

1. Scope management plan
2. Project management plan 2. Data analysis 2. Requirements management plan
• Quality management plan • Alternatives analysis
• Project life cycle description 3. Meetings
• Development approach
3. Enterprise environmental factors
4. Organizational process assets

Figure 5.2. Plan Scope Management: Inputs, Tools and Techniques, and Outputs

The scope management plan is a component of the project or program management plan that
describes how the scope will be defined, developed, monitored, controlled, and validated. The
development of the scope management plan and the detailing of the project scope begin with the
analysis of information contained in the project charter, the latest approved subsidiary plans of the
project management plan, historical information contained in the organizational process assets,
and any other relevant enterprise environmental factors, as inputs. The principal outputs are the
scope management plan and the requirements management plan.

5.6 Collect Requirements

The second step in project scope management is often the most difficult: collecting requirements.
Collect Requirements is defined as “the process of determining, documenting, and managing
stakeholder needs and requirements to meet objectives” (PMBOK® Guide, 2017, p.137). The key
benefit of this process is that it provides the basis for defining the product scope and project scope.
A major consequence of not defining requirements well is rework, which can consume up to half of
project costs, especially for software development projects. Part of the difficulty is that people often
don’t have a consistent definition of what requirements are, how to collect them, and how to
document them.

The PMBOK® Guide (2017), defines a requirement as a condition or capability that must be met
or possessed by a system, product, service, result, or component to satisfy a contract, standard,
specification, or other formal document. It is important to document requirements in enough detail

6
so that they can be measured during project execution. After all, meeting scope goals is often
based on meeting documented requirements.

It is important to use an iterative approach to defining requirements since requirements are often
unclear early in a project.

The collect requirements process is performed once or at predefined points in the project. The
inputs, tools and techniques, and outputs of this process are depicted in Figure 5-3.

Inputs Tools & Techniques Outputs

1. Project charter 1. Expert judgment

1. Requirements documentation
2. Project management plan 2. Data gathering 2. Requirements traceability
• Scope management plan • brainstorming
• Requirements management plan • Interviews
• Stakeholder engagement plan • Focus group
3. Project documentations • Questionnaires and surveys
• Assumption log • Benchmarking
• Lessons learned register 3. Data analysis
• Stakeholder register • Document analysis
4. Business documents 4. Decision making
• Business case • Voting
5. Agreements • Autocratic decision making
6. Enterprise environmental factors • Multicriteria decision analysis
7. Organizational process assets 5. Data representation
• Affinity diagrams
• Mind mapping
6. Interpersonal and team skills
• Nominal group technique
• Observation/conversation
• facilitation
7. Context diagram
8. Prototypes

Figure 5.3. Collect Requirements: Inputs, Tools and Techniques, and Outputs

5.6.1 How Do You Collect Requirements?

There are several ways to collect requirements. Interviewing stakeholders one-on-one is often very
effective, although it can be very expensive and time-consuming. Holding focus groups, facilitated
workshops, and using group creativity and decision-making techniques to collect requirements are
normally faster and less expensive than one-on-one interviews. Questionnaires and surveys can
be very efficient ways to collect requirements as long as key stakeholders provide honest and
thorough information. Observation can also be a good technique for collecting requirements,
especially for projects that involve improving work processes and procedures. Prototyping is a
commonly used technique for collecting requirements for software development projects. There
are also several software tools available to assist in collecting and managing requirements,
described later.
The project’s size, complexity, importance, and other factors will affect how much effort is spent on
collecting requirements. For example, a team working on a project to upgrade the entire corporate
accounting system for a multibillion Francs company with more than 30 geographic locations
should spend a fair amount of time collecting requirements. A project to upgrade the hardware and
software for a small accounting firm with only five employees, on the other hand, would need a
much smaller effort. In any case, it is important for a project team to decide how they will collect
and manage requirements. It is crucial to gather inputs from key stakeholders and align the scope,
a key aspect of the entire project, with business strategy.
7
5.6.2 How Do You Document Requirements?

Just as there are several ways to collect requirements, there are several ways to document them.
Project teams should first review the project charter since it includes high-level requirements for
the project and may refer to other documents that include requirements. They should also review
the stakeholder register to ensure that all key stakeholders have a say in determining requirements.
The format for documenting stakeholder requirements can range from a listing of all requirements
on a single piece of paper to a room full of notebooks documenting requirements. People who have
worked on complex projects, such as building a new airplane, know that the paper documenting
requirements for a plane can weigh more than the plane itself! Requirements documents are often
generated by software and include text, images, diagrams, videos, and other media. Requirements
are also often broken down into different categories such as functional requirements, service
requirements, performance requirements, quality requirements, training requirements, and so on.

In addition to preparing stakeholder requirements documentation as an output of the collecting

requirements process, project teams often create a requirements management plan and a
requirements traceability matrix. The requirements management plan describes how project
requirements will be analyzed, documented, and managed. A requirements traceability matrix
(RTM) is a table that lists requirements, various attributes of each requirement, and the status of
the requirements to ensure that all requirements are addressed. There are many variations of what
can be included in an RTM. Remember that the main purpose of an RTM is to maintain the linkage
from the source of each requirement through its breakdown to implementation and verification.

5.7 Define Scope

The next step in project scope management is to define in detail the scope or work required for the
project. Define Scope is “the process of developing a detailed description of the project and
product” (PMBOK® Guide, 2017, p.149). The key benefit of this process is that it describes the
product, service, or result boundaries and acceptance criteria. The inputs, tools and techniques,
and outputs of this process are depicted in Figure 5-4.

Good scope definition is very important to project success because it helps improve the accuracy
of time, cost, and resource estimates, it defines a baseline for performance measurement and
project control, and it aides in communicating clear work responsibilities. The main tools and
techniques used in defining scope include expert judgment, product analysis, alternatives
identification, and facilitated workshops. The main outputs of scope definition are the project scope
statement and project document updates.

Key inputs for preparing the project scope statement include the project charter, project
management plan, enterprise environmental factors, and organizational process assets such as
policies and procedures related to scope statements as well as project files and lessons learned
from previous, similar projects. The charter describes the high-level scope, time, and cost goals for
the project objectives and success criteria, a general approach to accomplishing the project’s
goals, and the main roles and responsibilities of important project stakeholders.

Although contents vary, project scope statements should include, at a minimum, a product scope
description, product user acceptance criteria, and detailed information on all project deliverables.
It is also helpful to document other scope-related information, such as the project boundaries,
constraints, and assumptions. The project scope statement should also reference supporting
documents, such as product specifications that will affect what products are produced or
purchased, or corporate policies, which might affect how products or services are produced. As
time progresses, the scope of a project should become more clear and specific.
8
 Inputs Tools & Techniques Outputs

1. Project charter 1. Expert judgment 1. Project scope statement

2. Project management plan 2. Data analysis 2. Project documents updates
• Scope management plan • Alternative analysis • Assumption log
3. Project documents 3. Decision making • Requirements documentation
• Assumption log • Multicriteria decision analysis • Requirements traceability matrix
• Requirements documentation 4. Interpersonal and team skills • Stakeholder register
• Risk register • Facilitation
4. Enterprise environmental factors 5. Product analysis
5. Organizational process assets

Figure 5.4. Define Scope: Inputs, Tools and Techniques, and Outputs

An up-to-date project scope statement is an important document for developing and confirming a
common understanding of the project scope. It describes in detail the work to be accomplished
on the project and is an important tool for ensuring customer satisfaction and preventing scope
creep (the tendency for project scope to keep getting bigger and bigger).

Recall from Chapter 1 the importance of addressing the triple constraint of project management
meeting scope, time, and cost goals for a project. Time and cost goals are normally straightforward.
However, it is much more difficult to describe, agree upon, and meet the scope goal of many
projects.

5.8 Create Work Breakdown Structure (WBS)

After collecting requirements and defining scope, the next step in project scope management is to
create a work breakdown structure (WBS). Create WBS is “the process of subdividing project
deliverables and project work into smaller, more manageable components” (PMBOK® Guide,
2017, p.156).

Because most projects involve many people and many different deliverables, it is important to
organize and divide the work into logical parts based on how the work will be performed. The WBS
is a foundation document in project management because it provides the basis for planning and
managing project schedules, costs, resources, and changes. Since the WBS defines the total
scope of the project, some project management experts believe that work should not be done on
a project if it is not included in the WBS. Therefore, it is crucial to develop a good WBS.

The key benefit of this process is that it provides a framework of what has to be delivered. This
process is performed once or at predefined points in the project. The inputs, tools and techniques,
and outputs of this process are depicted in Figure 5-5.

The project scope statement, stakeholder requirements documentation, enterprise environmental

factors, and organizational process assets are the primary inputs for creating a WBS. The main
tool or technique is decomposition, that is, subdividing project deliverables into smaller pieces.
The outputs of the process of creating the WBS are the WBS itself, the WBS dictionary, a scope
baseline, and project document updates.

9
 Inputs Tools & Techniques Outputs

1. Project management plan 1. Expert judgment 1. Scope baseline

• Scope management plan 2. Decomposition 2. Project documents updates
2. Project documents • Assumption log
• Project scope statement • Requirements documentation
• Requirements documentation
3. Enterprise environmental factors
4. Organizational process assets

Figure 5.5. Create WBS: Inputs, Tools and Techniques, and Outputs

5.8.1 Approaches to Developing Work Breakdown Structures

There are several approaches you can use to develop a work breakdown structure. These
approaches include:

• Using guidelines: If guidelines for developing a WBS exist in the organization, it is very
important to follow them to ensure prescribed form and content for WBSs for particular
projects are followed.
• The analogy approach: In this approach, you use a similar project s WBS as a starting
point. Some organizations keep a repository of WBSs and other project documentation on
file to assist people working on projects.
• The top-down approach: This approach starts with the largest items of the project and
break them into their subordinate items. This process involves refining the work into greater
and greater levels of detail. The top-down approach is best suited to project managers who
have vast technical insight and a big-picture perspective.
• The bottom-up approach: With this approach, team members first identify as many specific
tasks related to the project as possible. They then aggregate the specific tasks and organize
them into summary activities, or higher levels in the WBS. The bottom-up approach can be
very time-consuming, but it can also be a very effective way to create a WBS. Project
managers often use the bottom-up approach for projects that represent entirely new
systems or approaches to doing a job, or to help create buy-in and synergy with a project
team.
• The mind-mapping approach: Mind mapping is a technique that uses branches radiating
out from a core idea to structure thoughts and ideas. Instead of writing tasks down in a list
or immediately trying to create a structure for tasks, mind mapping allows people to write
and even draw pictures of ideas in a nonlinear format. This more visual, less-structured
approach to defining and then grouping tasks can unlock creativity among individuals and
increase participation and morale among teams. Mind mapping can be used for developing
WBSs using the top-down or bottom-up approach.

5.9 Validate Scope

It is difficult to create a good project scope statement and WBS for a project. It is even more difficult,
especially on big and IT projects, to validate the project scope and minimize scope changes. Some
project teams know from the start that the scope is very unclear and that they must work closely
with the project customer to design and produce various deliverables. In this case, the project team
10
must develop a process for scope validation that meets unique project needs. Careful procedures
must be developed to ensure the customer is getting what they want and the project team has
enough time and money to produce the desired products and services.

Validate Scope is “the process of formalizing acceptance of the completed project deliverables”
(PMBOK® Guide, 2017, p.162). The key benefit of this process is that it brings objectivity to
the acceptance process and increases the probability of final product, service, or result acceptance
by validating each deliverable. This process is performed periodically with users throughout the life
of the project as needed and develop a process for controlling scope changes. The inputs, tools
and techniques, and outputs of this process are depicted in Figure 5-6.

Inputs Tools & Techniques Outputs

1. Project management plan 1. Inspection 1. Accepted deliverables
• Scope management plan 2. Decision making 2. Work performance information
• Requirements management plan • Voting 3. Change requests
• Scope baseline 4. Project documents updates
2. Project documents • Lessons learned register
• Lessons learned register • Requirements documentation
• Quality reports • Requirements traceability matrix
• Requirements documentation
• Requirements traceability
matrix
3. Verified deliverables
4. Work performance data

Figure 5.6. Validate Scope: Inputs, Tools and Techniques, and Outputs

Scope validation involves formal acceptance of the completed project scope by the stakeholders.
This acceptance is often achieved by a customer inspection and then sign-off on key deliverables.
To receive formal acceptance of the project scope, the project team must develop clear
documentation of the project’s products and procedures to evaluate if they were completed
correctly and satisfactorily.

The project management plan, project documentations, the requirements traceability matrix, and
validated deliverables are the main inputs for scope validation. The main tool for performing scope
validation is inspection. The customer, sponsor, or user inspects the work after it is delivered. The
main outputs of scope validation are accepted deliverables, change requests, and project
document updates.

5.10 Control Scope

Change is inevitable on projects, especially changes to the scope of large and IT projects.

According to PMBOK® Guide, Control Scope is “the process of monitoring the status of the project
and product scope and managing changes to the scope baseline” (2017, p.167). It involves
controlling changes to the project scope. Users often are not exactly sure how they want the
product to look or what functionality they will really need to improve business performance.

The goal of scope control is to influence the factors that cause scope changes, assure changes
are processed according to procedures developed as part of integrated change control, and
manage changes when they occur. You cannot do a good job of controlling scope if you do not first
11
do a good job of collecting requirements, defining scope, and validating scope. How can you
prevent scope creep when you have not agreed on the work to be performed and your sponsor
hasn’t validated that the proposed work was acceptable? You also need to develop a process for
soliciting and monitoring changes to project scope.

The key benefit of this process is that the scope baseline is maintained throughout the project. This
process is performed throughout the project. The inputs, tools and techniques, and outputs of this
process are depicted in Figure 5-7.

Inputs Tools & Techniques Outputs

1. Project management plan 1. Data analysis 1. Work performance information

• Scope management plan • Variance analysis 2. Change request
• Requirements management plan • Trend analysis 3. Project management plan updates
• Change management plan • Scope management plan
• Configuration management plan • Scope baseline
• Scope baseline • Schedule baseline
• Performance measurement • Cost baseline
baseline • Performance measurement
2. Project documents baseline
• Lessons learned register 4. Project documents updates
• Requirements documentation • Lessons learned register
• Requirements traceability • Requirements documentation
matrix • Requirements traceability matrix
3. Work performance data
4. Organizational process assets

Figure 5.7. Control Scope: Inputs, Tools and Techniques, and Outputs

Stakeholders should be encouraged to suggest changes that will benefit the overall project and
discouraged from suggesting unnecessary changes.

The project management plan, work performance data, requirements documentation, requirements
traceability matrix, and organizational process assets are the main inputs to scope control. An
important tool for performing scope control is variance analysis. Variance is the difference between
planned and actual performance. For example, if a supplier was supposed to deliver five special
keyboards and you received only four, the variance would be one keyboard. The outputs of scope
control include work performance measurements, organizational process assets updates, change
requests, project management plan updates, and project document updates.

Project scope management is very important, especially on large and IT projects. After selecting
projects, organizations must collect the requirements and define the scope of the work, break down
the work into manageable pieces, validate the scope with project stakeholders, and manage
changes to project scope. Using the basic project management concepts, tools, and techniques
discussed in this chapter can help you successfully manage project scope.

12