Why we need Scope Management?

Project Scope: The process to ensure that the project team works on all the work required and ONLY the work required; in order to complete the project successfully.

The aim of the project scope is for the PM to implement:

• Constant Monitoring: To keep check that all activities in the requirements is worked upon.
• Avoid Scope Creep : Any sort of additional work that is not there in the requirement
• Avoid Gold Plating: At times, the project team tries to deliver more than expected in order to impress the stakeholders/managers etc. This is a negative practice and should be avoided.

Before we jump into what are requirements, scope and how to manage them, we need to first understand the difference between a Project Scope and a Product Scope.

Here is a snippet of various processes that are distributed across multiple phases of a project:

PLAN SCOPE MANAGEMENT

Phase: PLANNING            Knowledge Area: SCOPE MANAGEMENT

This is the go-to plan that helps you to strategize how to collect requirements, define work, monitor the work done etc. This helps you to define the approach what is in scope and what is out of scope. This is the parent for all the processes under the scope management.

The output of this process are mentioned below:

Scope Management Plan: The Scope Management Plan is a subsidiary of the Project Management Plan and helps to guide on how to plan, execute and monitor scope, like:

• How can project team achieve the scope
• What are the tools & techniques needed to achieve scope
• Create a Work Breakdown Structure (WBS) and WBS Dictionary – explained ahead
• Define approach to get acceptance

For your reference here is the template for Scope Management Plan

Requirements Management Plan: When you have all the requirements of the project, you ask yourself how to analyze, prioritize, monitor etc them. The answer is to refer Requirements Plan.

This is a document that follows the approach “Plan before you do”. It is also known as Business Analysis Plan. It is recommended that you take a look at Requirements Management Plan

COLLECT REQUIREMENTS

Phase: PLANNING            Knowledge Area: SCOPE MANAGEMENT

Simply put, the requirements are what the stakeholders want from the project/product.

The requirements are not always features, but could also be:

• Compliance: As per law; we need to obtain consent from users before storing cookies
• Quality:Website should be able to handle 1000 users at any given time without crashing
• Project Management: We need you to use Agile-Scrum approach for management

There are many inputs you need to collect the requirements & why we need these inputs:

• Project Charter: To understand the objective; why they are asking what they are asking.
• Assumption Log: To know what all assumptions are there before we proceed
• Stakeholder Register: To understand what requirements came from which stakeholder
• Agreement: For formal approval and also procurements needed
• Organization Process Assets: To check for requirement gathering process in your organization

Once you have all you need; next comes the part where you actually collect the requirements. There is no one-shoe-fits-all hence following are the tools & techniques needed – you can use any one or more techniques for collecting requirements, based on your needs:

Survey and Questionnaire: To provide every stakeholder with a list of specific questions so as to understand their set of requirements

Delphi Technique: This is the same as survey above however here the stakeholders are kept anonymous so as to give liberty to express better.

Voting: In order to prioritize and identify major requirements, voting can be done. There are multiple ways of voting, such as:

• Unanimous: Everyone agrees for the requirements
• Majority: If more than half the people in group agrees then requirements are considered
• Plurality: If there is no clear majority, then group with largest votes is considered.
• Autocratic: Where one person has the authority to approve requirement
• Brainstorming: Gathering all stakeholders in a room and discussing. At times, one person’s idea cascades and others can have more requirements and clarity based on that.
• Focus Group: Specific group of people who can provide requirements on one component or whole project
• Benchmarking: Considering existing product or competitor’s product as the benchmark
• Multi Criteria Decision Analysis: This technique includes the stakeholders to rank the requirements based on multiple parameters like cost-benefit, risk, time etc
• Affinity Diagram: The grouping of all the requirements (gathered by other techniques) based on their similarities.

Mind Maps Diagram: This a diagram mapped like a tree with its branches spreading out 

Nominal Group Technique :

Prototyping :

DEFINE SCOPE

Phase: PLANNING            Knowledge Area: SCOPE MANAGEMENT

This process deals with what is and what is NOT in scope of project plus the deliverables.

Product Analysis: This is performed to understand the deliverables of the project.

Project Scope Statement: A document that contains the product and project requirements. It comprises Product Scope, Project Scope, Deliverables, Acceptance Criteria, Assumptions, Constraints, what is NOT part of scope.

CREATE WBS

Phase: PLANNING            Knowledge Area: SCOPE MANAGEMENT

Work Breakdown Structure (WBS) is a chart created by dividing the chunk of work into smaller components. The major work is decomposed into smaller work packages known as tasks. The project name comes on the top and at every level, it is divided further.

• It should be created by Project Manager based on inputs from team & stakeholders
• Each level is breakdown of previous level
• Anything NOT in WBS is NOT part of the project.

• To understand the impact of change in case a CR is raised
• It can be used for controlling scope creep
• This helps to smoothen the communication with team and stakeholders

WBS Dictionary : The work packages on the WBS are simply names/titles of the work to be done. However in order to provide detailed information on the same, the Project Manager needs to create a WBS Dictionary.

In every work package in WBS, there is a chronological number assigned, the same number refers to the detailed WBS Dictionary doc for understanding that work package.

Scope Baseline: The scope baseline is the combination of 

• WBS
• WBS Dictionary
• Project Scope Statement

Anything that is not a part of Scope Baseline is not part of the project. In case there is any new scope edits, that shall be considered as change request.

The project shall only be considered a success if it meets all & only the requirements in the scope baseline.

VALIDATE SCOPE

Phase: M&C            Knowledge Area: SCOPE MANAGEMENT

Most people are confused by the name validate scope as the act of verifying if the scope is valid, however this is NOT what Validate scope means. The validate scope actually means the process of getting approval from the stakeholder/client for the work that is done. The PM meets the clients and get the deliverables reviewed who in return either approve them OR ask for changes (to be considered as Change request).

The PM needs to have the Requirement Document and Scope Management Plan in hand for this process.

This can be done at the end of each phase of the project. In case you are following Agile, then at the end of each sprint, this validation can be done with the clients. With this, the lessons learned document is also updated throughout.

CONTROL SCOPE

Phase: M&C            Knowledge Area: SCOPE MANAGEMENT

The control scope means measuring the work performance against the scope baseline. For this process you need to have the work completed first so that you measure it and determine if the work is done as per the scope baseline, if not then what variances are there. In case the variances are much; you may raise a change request.

This requires the project manager to proactively determine what all can cause changes to the project and ensure that the actual baseline is met.