Abstract
The main goal of the Project is to be to complete the required work and deliver a product to the customer. If the customer is often ready to “close his eyes” in terms of Time and Cost, but the Project’s Scope always has a prevalent importance.
To make the Project successful, Project Team, key Stakeholders and, of course, the Project Manager must have a clear understanding about the Scope of the project, and about its assignment. In general, that’s clear without PMBok, so it makes no sense to contemplate this statement in details.
Instead, another important poin that was mentioned by the PMI is that the Project Manager must control the content of the work being done in order not to go beyond what is defined in the Project Charter. Since the Project Charter is a fundamental document, it should clearly and unambiguously describe the main purpose of the Project, and the Project Scope Statement only elaborates the Charter [Charter] in a detailed view. It is a common mistake of project managers, when the customer «expands» the boundaries of the project as it progresses, «asks» to expand the service, sometimes even without increasing the Budget/management/classic/cost#budget.
But the expansion of the Project not necessary means increase of tasks amount on the project. For example, when building a house, it will be considered admissible to build an annex to the building, which is (de facto) a part of the house. But the construction of the gazebo goes beyond the scope of the project and should be considered as a separate project (or Phase [Phase]).
From a PMI’s point of view, the Project Charter and the Project Scope Statement should completely protect the project from such a sequence of events. On the other hand, the performer is often dependent on the client, so here everything depends on the communication talent of the Project Manager and the management of the contractor’s party.
To successfully manage the Scope of the Project, PMI has developed five processes:
- 5.1 Plan Scope Management
- 5.2 Collect Requirements
- 5.3 Define Scope
- 5.4 Create Work Breakdown Structure, WBS
- 5.5 Validate Scope
- 5.6 Control Scope
5.1 Plan Scope Management
As you know, any project management process must start with planning, the same applies to the Scope - it is necessary to plan both the management of the content itself and the management of requirements.
Scope Management Plan
Since the success of a project depends directly on the completion of all tasks of the project, the Project Team must have a clear undestanding of what is a part of the Project. In addition, the Execution of a project is often accompanied by changes that have different influence on the Scope of the Project.
This document is rather of a recommendatory nature, but if it is not created separately - it should be part of consolidating all areas of the Project Management Plan. Since this document reflects the policy regarding the Scope of the Project, it should answer questions such as: «Who and how does the content?» , «Who and based on what determines the need for changes?» , «How is project or phase success being estimated?» etc. In addition to the answers to these questions, the Scope Management Plan might include:
- Scope management methodology;
- Standards and rules for the compilation of the Scope Statement;
- Description or references to the procedures for managing Change Requests;
- Rules and formats for content reporting.
PMI does not limit managers by any rules of drawing up the Scope Management Plan, you can describe everything that will help you effectively manage the Scope.
Requirements Management Plan
Likewise any other management plan, this is a tool that regulates and describes the methodology of a particular target. The Requirements Management Plan might include the following:
- Principles for the definition of Requirements;
- Tools used to identify Requirements;
- Rules for monitoring of performance and validity of Requirements;
- Rules for checking compliance with [Requirements] according to the Project Scope.
5.2 Collect Requirements
This is the process that is extremally important for the project. In order to build a home for the family, it is necessary to know the requirements of each family member, engeneers and workers, public services, neighbors and all those who will be affected by the project. In this example, consider the following categories:
| Category | Why is it important to know about requirements? |
|---|---|
| Family memebers | Each person wants to live according to his customs. If the grandmother likes to knit while sitting in front of the TV at a distance of no more than 3 meters, this will be one of the major requirement for her room; if the mother can cook only when the room is filled with natural light, then the requirement may be that it be illuminated by natural light for as long as possible. |
| Engeneers and workers | The requirement by engeneers and workers may be as follows: full-time access to tools, guarantees for no hurdles during the performance of tasks, etc. |
| Public services | If the water pipe is not laid out with required distance, then the landlord may be forced to correct it at his own expense (i.e. adjust one of the [Deliverables]). If the building is illegally connected to electricity, then the owner will be subject to administrative or criminal liability. |
| Neighbors | If the new house interferes with the video signal coming to the antenna installed on the neighbor’s house, this is likely to be a source of problems in the future. |
Reasonable question, what to do if some Requirements contradict others? This is a fairly common situation for which PMI has found the following solution - you must set your own priorities for the Requirements and decide which of them are more important. To do this, it is necessary to rank the Stakeholders according to their grade of interest in the Project and rate of influence. For example, the customer needs to urgently finish building a house and you consider working at night, which will inevitably lead to conflicts with neighbors. As the project is promising to continue cooperation, it was decided that the customer’s request is the priority and work will be carried out at night. Neighbor’s complaints will be considered as negative Risk. But it should be remembered that the Requirements must be implementable and comply with the Project Charter.
When drawing up Project Requirements, the maximum possible number of requirements from all Stakeholders should be taken into account. Sometimes the number of claims could reach 500 or more, but nevertheless they should be identified before they become into power during the project Execution. Keep in mind, it is always cheaper to identify a Requirement during the Planning phase and take it into account, than to discover it when part of the work has been done. For example, when building a house, it is better to know immediately what state standards must be observed than to acknowledge it when the construction is put into operation.
The question arises - how to collect all Requirements? Many tools come to the aid, which will be unfolded below.
Lessons Learned
A large number of claims can be collected by viewing information from similar projects previously executed. For example, you can highlight the project reporting rules, the general project management rules, state requirement, etc.
Interviewing
Communication with the Stakeholders face-to-face. To simplify the process, it is desirable to prepare questions.
Focus Group
Collective identification of requirements in a group with several representatives of the Stakeholders parties and external experts. It is desirable that this event someone leads and most likely, it should be you. Perhaps the most common way.
Facilitated Workshops
The type of seminars in which Stakeholders participate in discussing Deliverables and thereby define requirements for them.
Brainstorming
One way of generating ideas. About this method much is said, but missede prevails. Each manager has their own vision of how to organize it. More details can be found here.
Nominal Group Technique
All is simple - received (for example, after brainstorming) requirements are ranked according to the conducted additional votation.
Delphi Technique
Quite interesting method, but it is rarely used. The master of a session send a number of questions to Stakeholders (within any mean of communication). The answers received to the questions are analyzed. The session master generates additional, more detailed questions, based on the results of conduced analysis. Such iterations could be repeated until a sufficiently precise definition of requirements will be gathered.
Mind Maps
Frequently used method which is based on tree arrangement of diagrams. Basic elements can be some large areas of the project (regarding to example of building that could be: roof, walls, rooms, etc.), branches will be specific characteristics that must have essence. Based on this, the portion of requirements coud be harvested.
Affinity Diagrams
Simple grouping requirements by some global characteristics (for example, in relation to the requirements of project areas - roof, walls, rooms). Is exposed in table fashio, thus Mind Maps are easier for visual perception.
Questionnaires and Surveys
It is desirable to interview those whose work or activities will be directly affected by the Project.
Observation
Monitoring the work or activities of someone who will be affected by the Project. Based on observations, a list of requirements is drawn up.
Context Diagrams
The data of the Context Diagrams mostly describe the interaction of the Deliverables with external entities in relation to the project. These diagrams can also include those that describe the business processes that should implement or modify the project, as well as external processes. An example of these diagrams is the IDEF0 Diagram, Event-driven Process Chain (EPC) or Notation and Business Process Model and Notation (BPMN).
Prototyping
The prototype is usually a result of another project.
Requirements Traceability Matrix
Great, we found that it is necessary to collect all the Requirements from all Stakeholders, then it is necessary to rank them and «discard» those competing with a lower priority. It is desirable to monitor and track implementation of collected Requirements. The Requirements Traceability Matrix comes to the rescue. The approach to its formulation is different and largely depends on the norms adopted in the organization (see Organizational Process Assets), below is just an example.
After collecting the Requirements, the Project Manager and the Project Team should understand which area of the Project a particular Requirement belongs to. Thus, larger requirements can be broken down into smaller ones by assigning sub-levels with additional identification of each Requirement, for example:
1. The house
1.1. Kitchen
1.1.1. Cooking area
1.1.1.1. Naturally lightened durin no less then 10 hours
1.1.1.2. Should be no less then 3 m^2
1.1.1.3.…
1.1.2. Fridger
1.1.2.1. Blue color
1.1.2.2. Response to Eco standards (Regulation (EU) 2017/1369)
1.1.2.3. No less the 3 separate chambers
1.1.2.4. …
1.1.3. Sink
1.1.3.1. No less then 30 centimeter depth
1.1.3.2. Made of stainless steel
1.1.3.3.…
1.1.4. …
1.2. Kids room
1.2.1. Beds
1.2.1.1. Made of oak
1.2.1.2. Orange color
1.2.1.3.…
1.2.2. No less then 10 m^2
1.2.3.
1.3.…
The next step will be to create the matrix itself (in the first stage of planning, some fields could be remained empty):
| ## | Description | Date added | Date modified | Source | Responsible | Done | WBS |
|---|---|---|---|---|---|---|---|
| 1 | House | ||||||
| 1.1 | Kitchen | ||||||
| 1.1.1 | Cooking area | ||||||
| 1.1.1.1 | Naturally lightened durin no less then 10 hours | 2026-01-03 | 2026-01-04 | CID::29 | Smith A. | + | 11.1.2 |
| 1.1.1.2 | Should be no less then 3 m^2 | 2026-01-05 | CID::29 | Colins W. | - | 11.1.14.3 | |
| 1.1.2 | Fridger | ||||||
| 1.1.2.1 | Blue color | 2026-01-08 | 2026-01-10 | CID::32 | Technics Inc. | + | 8.7.12 |
| 1.1.2.2 | Response to Eco standards (Regulation (EU) 2017/1369) | 2026-01-08 | CID::32 | Technics Inc. | + | 8.7.12 | |
| 1.1.2.3 | No less the 3 separate chambers | 2026-01-08 | CID::32 | Technics Inc. | + | 8.7.12 | |
| 1.8 | Kids room | ||||||
| 1.8.1 | Bed | ||||||
| 1.8.1.1 | Made of oak | 2026-02-12 | CID::32 | - | 11.1.0.1 | ||
| 1.8.1.2 | Orange color | 2026-02-12 | 2026-02-17 | CID::26 | YourBedroom Inc. | - | 11.1.0.1 |
| 1.8.2 | No less then 10 m^2 | 2026-01-05 | 2026-01-06 | CID::28 | + | 11.1.2 |
You can notice that every Requirement has an identification code - it will be used in the Responsibility Assignment Matrix when Project Manager will determine who is responsible for tracking a given Requirement. There is also a CID, which is used to indicate the face for communications (see Communications). The CID can be used to indicate the face for communications. During the Execution phase the Requirements Tracking Matrix should be updated - if the requirement is satisfied, this should be marked correspondingly; if the requirement is not relevant, it should be removed from the Responsibility Assignment Matrix (or marked as done).
5.3 Define Scope
That’s the process of determining what can and what should be part of a project and vise versa. To do this, we’ll need the full list of Requirements that is an output of the Collect Requirements process.
The result of this process is the Project Scope Statement, which is a document that describes what needs to be done in order for the project to be considered successful. Since the document is aimed for the private usage, the form might be free. When writing a description of the Project Scope, you should take into account the following:
- Project limitations;
- Boundaries of the result (product or service) of the Project;
- Deliverables characteristics;
- The result acceptance rules;
- Limitations and assumptions.
In order to bring a more comprehensive Project Scope Statement, the Product Analysis might be used (i.e. [Deliverables]) - thereby defining the boundaries of the Project as necessary and sufficient to achieve the project’s goal (deliver a product or service).
5.4 Create Work Breakdown Structure, WBS
This is probably one of the most important processes in Project Planning phase. As mentioned above, PMI believes that in sake of proper management, at least three knowledge areas require basic plans - Scope Baseline, Schedule Baseline, Cost Baseline.
The main purpose of creating WBS is not just to «create another diagram» without a worthy purpose, but to simplifying and clarifying goals of the Project. Here are just the main advantages that WBS will bring:
- Understanding what needs to be done
- Visualization of the necessity of a particular work;
- When hiring a new employee on the Project, he can have a clear answer to the question: «Why is all this being done?»;
- If the Project Team is going to be involved in creating WBS then it will help to avoid lots of unnecessary questions.
Not to mention that most of the subsequent processes in PMI methodology are based on WBS and without its assembling, it’s impossible to execute the Project in classic approach - WBS is one of the keys of PMI’s approach.
So what is it? It is a result-oriented diagram, broken down into smaller and easily manageable parts, a hierarchically structured construction that defines the work to be done by the Project Team. The first element, which is on the first (top) level, is called a project, the second level is Deliverables, third and subsequent - tangible results of any action that will lead to the creation of an appropriate result.
In WBS all elements should be presented as nouns and represent those results that «can be touched» (in other words, they should be tangible). Each branch of the WBS is completed with elements that are called the Work Package. Since not all the details of the project are always known beforehand, the Rolling Wave Planning principle comes into force. The core of principle is based on continuous adjusting WBS by newly received information about the Project Result - thereby, creating, removing or modifying Work Packages or Deliverables suggested as applicable and standard operations (do you remember that all changes should pass through the Integrated Change Control process?).
Another important element in WBS is the Control Account. These elements are regular WBS elements but specially marked. They are used as reference points to measure the performance of a project, generally, after the completion of a sample element of WBS, but in some cases, before it begins. PMI assumes that this analysis will be conducted using the Earned Value method.
Some examples of WBS could be found here.
WBS Dictionary
At the end of the WBS construction (or in parallel with this process), the Project Manager should create the WBS Dictionary, which will describe each element of the diagram. The form and completeness depends on each specific project or organization, but the description should convey to the reader what specifically must be done in a particular Work Package and what is the expected result of a specific Work Package. Perhaps one of the most important requirements for describing elements in the WBS Dictionary is that for each Work Package its acceptance conditions must be explained - how to examine if the result of element done or not? This condition definition will alleviate control of the project. Moreover, it is often required by the customer.
WBS is the fundamental tool for a major part of PMI’s methodology, thus it is recommended to give it special attention. You can read about this tool in more detail in the article; examples of building WBS for different business areas could be found in the Documents section.
5.5 Validate Scope
This process is aimed on confirming that the results of the project has been achieved in accordance with the Scope Baseline (and therefore according to Requirements). This process is often confused with the Quality Control/management/classic/quality#control process, although they have a number of similarities, but this is only at first glance. The purpose of the Quality Control is to ensure that the Project result meets the quality requirements, but not to the Scope of the Project. Both of these processes usually go hand in hand, but the Quality Control process should always be completed before the Validate Scope. Sometimes they can be run simultaneously. For a better understanding of the difference between these two processes, an example should be given.
Let’s say, that we need to lay a water pipe to the house and the mandatory requirement is to follow the CPR 2.05.06-85. In addition, the pipeline should not cross a road (but this is not a requirement for quality, unlike the previous requirement). In the given example, the Quality Control process requires to examine following the CPR 2.05.06-85 in a particular intervals; the final examination of the pipe regarding to CPR 2.05.06-85 and verifying of non-crossing rule (does the water line cross a road?) will be referred to the Validation Scope process.
5.6 Control Scope
The main purpose of this process is to control the Scope of the project (in particular, the Scope Baseline). This includes both checking for any attempts to change the Scope of the Project, and checking the progress of the implementation of the Scope Baseline.
In the first case, the Project Manager’s task is to determine whether the change corresponds to the Project boundaries, why it was not processed earlier, try to identify the source of the Change and initiate additional Preventive Actions (they will help to prevent such undesirable Changes in the future). In some extend, that could be called “scope change analysis”.
In the second case, it is necessary to check how well the content is being executed, which can cause the initiation of Change Requests. Definitely, you remember, that all changes should pass through the Integrated Change Control process!?
To permit this process, it is necessary to have a clear understanding of the [Scope] of the Project - that once again emphasise the necessity and importance of Project Scope Statement, WBS and WBS Dictionary. It is also important to track Requirements and their Changes using, for example, the Requirements Traceability Matrix.