5.

3 DEFINE SCOPE
Define Scope is the process of developing a detailed description of the project and product. 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-8. Figure 5-9 depicts the data flow diagram
of the process.

Define Scope

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 • Alternatives analysis • Assumption log
.3 Project documents .3 Decision making • Requirements
• Assumption log • Multicriteria decision documentation
• Requirements analysis • Requirements traceability
documentation .4 Interpersonal and team skills matrix
• Risk register • Facilitation • Stakeholder register
.4 Enterprise environmental .5 Product analysis
factors
.5 Organizational process assets

Figure 5-8. Define Scope: Inputs, Tools & Techniques, and Outputs

Part 1 - Guide
150
 4.1
Develop Project
Charter

• Project charter

Project
Management
Plan
• Project scope statement

Project management plan

• Scope management plan

5.3 Project
Define Documents
Project Scope
• Project Project document updates
charter • Assumption log
Documents
• Requirements documentation
• Requirements traceability matrix
• Stakeholder register

Project documents
• Assumption log
• Requirements documentation
• Risk register

Enterprise/
Organization

• Enterprise environmental factors

• Organizational process assets

Figure 5-9. Define Scope: Data Flow Diagram

Since all the requirements identified in Collect Requirements may not be included in the project, the Define Scope
process selects the final project requirements from the requirements documentation developed during the Collect
Requirements process. It then develops a detailed description of the project and product, service, or result.
The preparation of a detailed project scope statement builds upon the major deliverables, assumptions, and
constraints that are documented during project initiation. During project planning, the project scope is defined and
�

described with greater specificity as more information about the project is known. Existing risks, assumptions, and
�

constraints are analyzed for completeness and added or updated as necessary. The Define Scope process can be highly
iterative. In iterative life cycle projects, a high-level vision will be developed for the overall project, but the detailed scope
is determined one iteration at a time, and the detailed planning for the next iteration is carried out as work progresses
on the current project scope and deliverables.

151
5.3.1 DEFINE SCOPE: INPUTS

5.3.1.1 PROJECT CHARTER

Described in Section 4.1.3.1. The project charter provides the high-level project description, product characteristics,
and approval requirements.

5.3.1.2 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. A project management plan component includes but is not limited to the scope
management plan as described in Section 5.1.3.1, which documents how the project scope will be defined, validated,
and controlled.

5.3.1.3 PROJECT DOCUMENTS

Examples of project documents that can be considered as inputs for this process include but are not limited to:
Assumption log. Described in Section 4.1.3.2. The assumption log identifies assumptions and constraints about
uu
the product, project, environment, stakeholders, and other factors that can influence the project and product scope.
Requirements documentation. Described in Section 5.2.3.1. Requirements documentation identifies
uu
requirements that will be incorporated into the scope.
Risk register. Described in Section 11.2.3.1. The risk register contains response strategies that may affect the
uu
project scope, such as reducing or changing project and product scope to avoid or mitigate a risk.

5.3.1.4 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Define Scope process include but are not limited to:
Organization’s culture,
uu

Infrastructure,
uu

Personnel administration, and

uu

Marketplace conditions.
uu

5.3.1.5 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Define Scope process include but are not limited to:
Policies, procedures, and templates for a project scope statement;
uu

Project files from previous projects; and

uu

Lessons learned from previous phases or projects.

uu

Part 1 - Guide
152
 5.3.2 DEFINE SCOPE: TOOLS AND TECHNIQUES

5.3.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with knowledge of or
experience with similar projects.

5.3.2.2 DATA ANALYSIS

An example of a data analysis technique that can be used in this process includes but is not limited to alternatives
analysis. Alternatives analysis can be used to evaluate ways to meet the requirements and the objectives identified in
the charter.

5.3.2.3 DECISION MAKING

Described in Section 5.1.2.2. A decision-making technique that can be used in this process includes but is not limited
to multicriteria decision analysis. Described in Section 8.1.2.4, multicriteria decision analysis is a technique that uses
a decision matrix to provide a systematic analytical approach for establishing criteria, such as requirements, schedule,
budget, and resources, in order to refine the project and product scope for the project.

5.3.2.4 INTERPERSONAL AND TEAM SKILLS

Described in Section 4.1.2.3. An example of an interpersonal and team skills technique is facilitation. Facilitation
is used in workshops and working sessions with key stakeholders who have a variety of expectations or fields of
expertise. The goal is to reach a cross-functional and common understanding of the project deliverables and project
and product boundaries.

5.3.2.5 PRODUCT ANALYSIS

Product analysis can be used to define products and services. It includes asking questions about a product or service
and forming answers to describe the use, characteristics, and other relevant aspects of what is going to be delivered.
�

Each application area has one or more generally accepted methods for translating high-level product or service
descriptions into meaningful deliverables. Requirements are captured at a high level and decomposed to the level of
�

detail needed to design the final product. Examples of product analysis techniques include but are not limited to:
Product breakdown,
uu

Requirements analysis,
uu

Systems analysis,
uu

Systems engineering,
uu

Value analysis, and

uu

Value engineering.
uu

153
5.3.3 DEFINE SCOPE: OUTPUTS

5.3.3.1 PROJECT SCOPE STATEMENT

The project scope statement is the description of the project scope, major deliverables, assumptions, and constraints.
The project scope statement documents the entire scope, including project and product scope. It describes the project’s
deliverables in detail. It also provides a common understanding of the project scope among project stakeholders. It may
contain explicit scope exclusions that can assist in managing stakeholder expectations. It enables the project team
to perform more detailed planning, guides the project team’s work during execution, and provides the baseline for
evaluating whether requests for changes or additional work are contained within or outside the project’s boundaries.
The degree and level of detail to which the project scope statement defines the work that will be performed and the
work that is excluded can help determine how well the project management team can control the overall project scope.
The detailed project scope statement, either directly or by reference to other documents, includes the following:
Product scope description. Progressively elaborates the characteristics of the product, service, or result
uu
described in the project charter and requirements documentation.
Deliverables. Any unique and verifiable product, result, or capability to perform a service that is required
uu
to be produced to complete a process, phase, or project. Deliverables also include ancillary results, such as
project management reports and documentation. These deliverables may be described at a summary level
or in great detail.
Acceptance criteria. A set of conditions that is required to be met before deliverables are accepted.
uu

Project exclusions. Identifies what is excluded from the project. Explicitly stating what is out of scope for the
uu
project helps manage stakeholders’ expectations and can reduce scope creep.
Although the project charter and the project scope statement are sometimes perceived as containing a certain
degree of redundancy, they are different in the level of detail contained in each. The project charter contains high-
level information, while the project scope statement contains a detailed description of the scope components. These
components are progressively elaborated throughout the project. Table 5-1 describes some of the key elements for
each document.

Part 1 - Guide
154
 Table 5-1. Elements of the Project Charter and Project Scope Statement

Project Charter Project Scope Statement

Project purpose Project scope description (progressively
elaborated)
Measurable project objectives and related
success criteria Project deliverables
High-level requirements Acceptance criteria
High-level project description, boundaries, Project exclusions
and key deliverables
Overall project risk
Summary milestone schedule
Preapproved financial resources
Key stakeholder list
Project approval requirements (i.e., what
constitutes success, who decides the
project is successful, who signs off on the
project)
Project exit criteria (i.e., what are the
conditions to be met in order to close or to
cancel the project or phase
Assigned project manager, responsibility,
and authority level
Name and authority of the sponsor or other
person(s) authorizing the project charter

5.3.3.2 PROJECT DOCUMENTS UPDATES

Project documents that may be updated as a result of carrying out this process include but are not limited to:
Assumption log. Described in Section 4.1.3.2. The assumption log is updated with additional assumptions or
uu
constraints that were identified during this process.
Requirements documentation. Described in Section 5.2.3.1. Requirements documentation may be updated
uu
with additional or changed requirements.
�

Requirements traceability matrix. Described in Section 5.2.3.2. The requirements traceability matrix may be
uu
�

updated to reflect updates in requirement documentation.

Stakeholder register. Described in Section 13.1.3.1. Where additional information on existing or new
uu
stakeholders is gathered as a result of this process, it is recorded in the stakeholder register.

155