Project Scope Management – Overview

  1. Six project management processes in total
    1. 4 Processes in the planning phase
    2. 2 Processes in the control phase
  2. Two scope domains are ongoing in parallel
    1. Product scope – Which answers the question what needs to be done? In this domain we will verify the product or service against the specs/design, to make sure that we did things right.
    2. Project scope – Which answers the question how to get things done? In this domain we will verify if we have met the project objectives. The verification process is done vs. the Project Management Plan and project boundaries (see golden plating)
  3. Golden plating – A common term to describe project boundaries
    1. If the customer requested a plate, we will not provide a golden plate, we will provide exactly what the customer has asked for.
    2. When it comes to scope and contracts, it is important to keep in mind, that some organizations / contracts assume that if something is not specified in the scope, it is out of scope, while other clearly specify what is included AND what is excluded from scope.
    3. PMI view is not to deliver more than what the customer has asked for, and in this case, more is defiantly less. In this regard every modification to scope must be backed up with a change request.
    4. Scope management ensures that all and only the work required to complete the project successfully is included in the project scope.

5.1 – Plan Scope Management

  1. The scope management describes how the scope will be defined, developed, monitored, controlled, and verified. (Reference: PMI Glossary).
  2. Inputs – The available project data to date: Project management plan, enterprise environmental factors, organizational process assets, and the project charter.
  3. Tools – Expert judgment and meetings
  4. Outputs – Scope management plan and requirements management plan.

5.2 – Collect Requirements

  1. In this process we define and document stakeholder’s needs and requirements in the project. We document basic assumptions and constraints that must be address and met in order to meet to project goals.
  2. Inputs – The inputs are similar to the ones in process 5.1. plan scope management (Project management plan, enterprise environmental factors, organizational process assets, the project charter) with one addition – We now include the scope management plan from that process.
  3. Tools – Interviews, Focus Groups, Facilitated Workshops, Group Creativity Techniques, Group Decision Making Techniques, Questioners and Surveys, Observations, Prototypes, Benchmarking, Context Diagrams, Documents Analysis.

4. Outputs – There are two outputs to this process

  1. Requirements documentation – You can think of it as a checklist of the requirements in the projects
  2. Requirements Traceability Matrix – This output “links” the requirement with the business need / project goal. The goals of this document are
    1. To make sure that every requirement is addressing at least one business requirement or business goal.
    2. To make sure that there are no “floating” requirements, meaning requirements that are not linked to business needs or project goals (remember – “only the work required”).
      Simply put if a requirement has a blank cell in either business need or project objectives column it should either be out of scope, or reviewed and linked.

ID

Associated ID

Requirement

Description

Business needs, goals, objectives

Project objectives

WBS deliverable

Product design

Product development

Test Cases

001

1.0

 

 

 

 

 

 

 

001

1.1

 

 

 

 

 

 

 

002

2.0

 

 

 

 

 

 

 

5.3 – Define Scope

  1. This is the process of developing a detailed description of the project and product. (Source: PMI Glossary)
  2. Inputs – Scope Management Plan, Project Charter, Requirements documentation, Organizational process assets
  3. Tools – Expert judgment, Product analysis, Alternatives generation, Facilitated workshops
  4. Outputs – There are two outputs to this process
    1. Project scope statement. This is a crucial output.
      This document is essentially the agreement we have we our customer on the scope of the project. If something is not in the document, it will not be done.
      This document includes the deliverables, acceptance criteria, what is out of scope, and what are the assumptions and constraints used to define the scope (for example, the customer must assign 3 trained project team members to perform specific tasks or run tests).
    2. Update project documents, such as project charter and any other relevant document.

In regards to the project scope it is important to understand the difference between the project charter and the project scope statement

Project Charter

Project Scope Statement

Project purpose or justification

Project Scope description
(progressively elaborated)

Measurable project objectives
and related success criteria

Acceptance criteria

High-level requirements

Project deliverables

High-level project description

Project exclusions

High-level risks

Project constrains

Summary milestone schedule

Project assumptions

Summary budget

 

Stakeholder list

 

Project approval requirements
(what constitutes success, who
decides it, who signs off)

 

Assigned project manager,
responsibility and authority level

 

Name and authority of the
sponsor or other person(s)
authorizing the project charter

 

 Source: PMBoK 5th ed. Chapter 5.3 – Define Scope, Page 124

Subscribe to our Messenger Hub and be the first to get new tools from us as they go live
Subscribe

Pin It on Pinterest

Share This