This is the second post in an eight part series that covers the fundamental theory of project management. This post focuses on Project Scope Management and is based on our online learning course Hands on Project Management Theory and Practice.
We will define the types of scope that exist in projects. We will discuss the purpose of Project Scope Management and we will see how the Project Scope is managed throughout the project life cycle:
- During project initiation stakeholders’ needs and expectations are translated into the required project scope
- During the project planning phase the required project scope is divided among the participating parties
- During the project execution phase resources execute the plans and the scope is created
- As part of the project monitoring and control, scope changes are introduced
- At the end of the project and at the end of some project activities the scope is verified and approved
According to the Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), there are two types of scope:
- The product scope also known as the product configuration is a description of the product, service or system to be delivered by the project. This description includes all features and functions required. The description of the product scope starts with a requirement document and is developed into detailed specifications or specs.
- The project scope is a description of the work that needs to be completed by the project team. The description of project work may include standards according to which the work must be performed and other applicable documents.
The project scope is presented in a document known as SOW – Scope of Work or Statement of Work. Later the project scope or the SOW is divided into subprojects known as work packages by the Work Breakdown Structure (WBS). The estimates of time cost and resources necessary for detailed planning are performed at the work package level.
The purpose of Project Scope Management is to avoid two pitfalls that are common in project management:
- Not completing all the work required to satisfy the stakeholders' needs and expectations and
- Performing work that is not required and therefore wasting time, money and resources effort. This second pitfall is also known as scope creep.
The goal is to manage the scope to avoid these two pitfalls and to complete the project successfully.
One way of presenting the product scope is by using a list of requirements based on the mapping of stakeholder's needs and expectations. For each requirement a formula is used to calculate the actual value of the requirement.
A typical project has different possible execution methods or alternatives. These can be operational alternatives or technological ones.
The value of the independent variables in the above formula is determined by the alternative selected to perform the relevant project task or activity.
By assigning a relative priority or importance to each requirement we can calculate the benefit of the product or system produced by the project.
The project manager’s goal is to maximize the value or benefit of the whole project.
The project scope is the list of activities or tasks that should be performed to satisfy the needs and expectations of the stakeholders. The tasks are assigned to work packages according to the Work Breakdown Structure of the project. When all the tasks are completed successfully the project scope is completed as required.
Early on in the project life cycle the stakeholder's needs and expectations are translated into requirements and alternative solution options are presented as modes. Tools like the Quality Function Deployment or QFD, are used to analyze the stake-holder's needs and expectations. In the QFD the first column on the left is a list of requirements, or what the stakeholders want.
The next column is the relative importance of each requirement. The first line of QFD is the engineering parameters the designers should consider. The matrix in the center represents the correlation between what the stakeholders want and the engineering parameters.
The actual value of each requirement is determined by the engineering decisions presented by the modes of project activities. The project team has to trade off the quality of the project with the cost and duration. As an example, consider a radar development project. One of the tasks is to develop the radar transmitter. We have three possible technologies we can use for the transmitter. If we choose the most advanced technology the developed radar would be of better quality, i.e. have a longer range. On the other hand making this choice will increase the project cost and duration.
During the project lifecycle and especially in the project planning phase the project team have to constantly trade off these three dimensions: time quality and cost, to find the best plan for the project according to the needs and expectations of the stakeholders.
Project planning is based on limited information and forecasts of task duration, availability of resources and so on. During the execution phase more information becomes available and it is possible to change the plans based on the new information. Change management is an important part of project management and it should be considered upfront during project planning. The plan developed during the planning phase is a baseline, against which actual performances are compared to find deviations and to trigger corrective actions.
One possible corrective action is to change the modes of activities. It is important to check the impact of mode changes on the scores and on the total benefit. This ensures that the deliverables satisfy the needs and expectations of the stakeholders.
Three types of changes are possible at the activity level:
- Changing the execution mode of an activity
- Changing the start time of an activity
- Splitting an activity that has already started and resuming it later
Only one of the three possible changes affects the product scope – when modes are changed. When this is done, it is important to check the impact of the change on the performances, the score and the benefit.
A project is finished when all the activities are completed and the deliverables are ready. A formal verification is required to ensure that the project is finished successfully.
*PMBOK is a registered mark of the Project Management Institute, Inc.