PMBoK – Scope Management

Back to PMBoK table

5.1 Plan scope management

Inputs	Tools and techniques	Outputs
Project management plan	Expert judgment	Scope management plan
Project charter	Meetings	Requirements management plan
Enterprise environmental factors
Organizational process assets

Inputs

Project management plan

Project Charter

Enterprise Environmental Factors

Organizational Process Assets

Please refer to the common ITTOs

Tools and Techniques

Expert judgment

Meetings

Please refer to the common ITTO section

Output

Scope management plan

A document that explains how to prepare the scope statement, document the WBS and approval mechanisms to manage changes to the scope.

Requirements management plan

A document that details out how to collect, analyze, document and manage changes to the detailed requirements.

Back to PMBoK table

5.2 Collect requirements

Inputs	Tools and techniques	Outputs
Scope management plan	Interviews	Requirements document
Requirements management plan	Focus groups	Requirements traceability matrix
Stakeholder management plan	Facilitated workshops
Project charter	Group creativity techniques
Stakeholder register	Group decision-making techniques
	Questionnaires and Surveys
	Observations
	Prototypes
	Benchmarking
	Context diagrams
	Document analysis

Input

Scope management plan

Requirements management plan 

Stakeholder management plan

Needed to understand whom to engage with for collecting requirements

Project charter

Stakeholder register

Please refer to the common ITTO section.

Tools and Techniques

Back to PMBoK table

Interviews

A formal or informal approach to elicit information from stakeholders by talking to them directly.

Focus groups

Focus groups bring together stakeholders and subject matter experts to learn about a specific aspect of the system. The key is that the focus will be on a specific aspect of the project and different types of experts qualified to provide information about that aspect will be brought together.

Facilitated workshops

These are focused sessions that bring together key stakeholders to define product requirements. At times the requirements are defined by developing the solutions also inside the workshop. For instance,

• JAD (Joint Application Development) sessions are used to elicit requirements from the business users and the developers build graphical user interfaces in the workshop itself to ascertain if the requirements are understood correctly. The GUIs thus developed are used as reference for further work in the project.
• QFD (Quality Function Deployment) is another type of facilitated workshop technique that helps to determine characteristics of new products by bringing together cross-functional experts. No solution is developed in QFD workshops but requirements are clearly articulated with prioritization.
• VOC (Voice Of Customer) is a technique used to express the needs of the customer from customer’s own perspective and is used in QFD workshops

Back to PMBoK table

Group Creativity Techniques

Sometimes, creativity techniques are needed to generate ideas to define product requirements, prioritize and finalize them. Some of them are:

• Brainstorming: A technique used to generate and collect multiple ideas related to project and product requirements. Although brainstorming by itself does not include voting or prioritization, it is often used with other group creativity techniques that do. It is important to note that in many organizations, the practice of idea generation and idea reduction phases put together is referred to as brainstorming. However, in strict terms, it is only the idea generation that is called brainstorming and if idea reduction is also combined with generation, then it will be called nominal group technique which is what is described in the next part of this section.
• Nominal group technique: A technique that enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization.
• Idea/mind mapping: A technique in which ideas created through individual brainstorming sessions are consolidated into a single diagram to reflect on the relationship between the ideas and get the big picture.
• Affinity diagram: A technique that allows large numbers of ideas to be classified into groups for review and analysis.
• Multicriteria decision analysis: A technique that utilizes a decision matrix to provide a systematic analytical approach for establishing criteria and rank many ideas.

Group Decision-Making Techniques

A group decision-making technique is an assessment process having multiple alternatives with an expected outcome in the form of future actions. These techniques can be used to generate, classify, and prioritize product

requirements.

There are various methods of reaching a group decision, such as:

• Unanimity: A decision that is reached whereby everyone agrees on a single course of action. One way to reach unanimity is the Delphi technique, in which a selected group of experts answers questionnaires and provides feedback regarding the responses from each round of requirements gathering. The responses are only available to the facilitator to maintain anonymity.
• Majority: A decision that is reached with support obtained from more than 50 % of the members of the group. Having a group size with an uneven number of participants can ensure that a decision will be reached, rather than resulting in a tie.
• Plurality: A decision that is reached whereby the largest block in a group decides, even if a majority is not achieved. This method is generally used when the number of options nominated is more than two.
• Dictatorship: In this method, one individual makes the decision for the group.

Back to PMBoK table

Questionnaires and Surveys

When the number of stakeholders to be interviewed becomes too many, interviewing all of them may not be feasible. In such a case a questionnaire with some open ended questions and some close ended questions in the survey format are put up on say, an intranet site where stakeholders respond and the responses are consolidated to formulate requirements.

Observations

Also called Field Observations, this technique provides a direct way of viewing individuals in their work environment and how they perform their jobs or tasks and carry out processes. This technique is also known as “job shadowing” and apprenticeship.

Prototypes

Prototyping is a method of obtaining early feedback on requirements by providing a working model of the expected product before actually building it. Prototypes can take on many forms depending on the industry. In a software application, the prototype may involve graphical user interfaces whereas in a construction industry it can be a miniature model of the final building.

Benchmarking

Benchmarking involves comparing actual or planned practices, such as processes and operations, to those of comparable organizations or industry standardsto identify best practices, generate ideas for improvement, and provide a basis for measuring performance.

Context Diagrams

The context diagram is an example of a scope model. Context diagrams visually depict the product scope by showing a business system (process, equipment, computer system, etc.), and how people and other systems (actors) interact with it. It is essentially a model that shows the relationship of the system with its interfaces.

Document Analysis                

Document analysis is used to elicit requirements by analyzing existing documentation and identifying information relevant to the requirements. There are a wide range of documents such as business process or interface documentation, use cases etc. that may be analyzed to help elicit relevant requirements.

Output

Requirements documentation

Requirements documentation describes how individual requirements meet the business need for the project.

Requirements Traceability Matrix

The requirements traceability matrix is a grid that links product requirements from their origin to the deliverables that satisfy them. The implementation of a requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. Finally, it provides a structure for managing changes to the product scope.

Back to PMBoK table

5.3 Define scope

Inputs	Tools and techniques	Outputs
Scope management plan	Expert judgment	Project scope statement
Project charter	Product analysis	Project documents updates
Requirements documentation	Alternatives generation
Organizational process assets	Facilitated workshops

Input

Scope Management Plan

Project Charter

Requirements Documentation

OPA

Please refer to previous section and the common ITTO section.

Tools and Techniques

Expert Judgment

Please refer to the common ITTO section.

Product Analysis

Analysing the product usage, characteristics, etc. to arrive at requirements.

Alternatives Generation

Generating multiple alternatives to requirements and solution and finalizing a one or a subset of options.

Facilitated workshops

Please refer to Tools and Techniques of 5.2

Output

Project Scope Statement

The project scope statement is a narrative description of the project scope, major deliverables, assumptions, and constraints.

Project Document Updates

Please refer the common ITTOs

Back to PMBoK table

5.4 Create WBS

Inputs	Tools and techniques	Outputs
Scope management plan	Expert judgment	Scope baseline
Project scope statement	Decomposition	Project documents updates
Requirements documentation
Organizational process assets
Enterprise environmental factors

Input

Scope Management Plan

Project Scope Statement

Requirements Documentation

Please refer to previous sections

EEF

OPA

Please refer to the common ITTO section

Tools and Techniques

Expert Judgment

Please refer to the common ITTO section

Decomposition

A technique of dividing an entity into its subcomponents and each subcomponent further into its sub component and so on, till leaf nodes are not to be decomposed further. The system scope is subdivided till all the work packages are reached as leaf nodes. A work package (a leaf node of the Scope WBS) is taken up for activity definition in time management knowledge area.

Outputs

Project scope baseline

Contains the project scope statement, the WBS and the WBS dictionary.

Base lining the scope means that the project scope has reached a meaningful status and hence will be assigned a version number and used as a reference henceforth for further planning and execution of the project. And any further change to the scope will be subject to integrated change control procedure.

Project Document Updates

Please refer to the common ITTO section

Back to PMBoK table

5.5 Validate Scope

Inputs	Tools and techniques	Outputs
Project management plan	Inspection	Accepted deliverables
Requirements traceability matrix	Group decision making techniques	Change requests
Requirements documentation		Work performance information
Verified deliverables		Project documents updates
Work performance data

Input

Project Management Plan

Requirements Documentation

Requirements Traceability Matrix

Please refer to previous sections and common ITTOs

Verified deliverables

These are the tested project deliverables that comprise the product, service or result. The deliverables may include the engineering deliverables, project management documentation, engineering documentation among others. When the project team develops the deliverables, they are subject to verification such as inspections, software testing and so on and when the deliverables are certified internally (through 8.3, control quality process), they become verified deliverables.

Work performance data

Raw observations from work performance submitted by team members. Explained in detail in 4.3, direct and manage work.

Tools and Techniques

Inspection

A form of verifying if the deliverables meet the scope which can include reviews, audits, software testing and so on.

Group decision making techniques

Please refer to previous sections and common ITTOs

Output

Accepted Deliverables

The final deliverables that comprise the product, service or result that the customer has reviewed and deemed accepted.

Change requests

Change requests are raised if the deliverables are not accepted and need to be changed.

Work performance information

Project Document Updates

Back to PMBoK table

5.6 Control scope

Inputs	Tools and techniques	Outputs
Project management plan	Variance analysis	Work performance information
Requirements traceability matrix		Change requests
Requirements documentation		Project management plan updates
Organizational process assets		Project documents updates
Work performance data		Organizational process assets updates

Input

Project Management Plan

Requirements Documentation

Requirements Traceability Matrix

Work performance data

OPA

Please refer to previous sections and common ITTOs

Tools and Techniques

Variance analysis

Analysis of variance between the baseline and actual performance.

Outputs

Work performance information

Change requests

Project management plan updates

Project Document Updates

OPA updates

Please refer to previous sections and common ITTOs

Back to PMBoK table

——————————- End of document ——————————