Project Scope Control

Revision as of 16:43, 1 October 2017

Abstract

Project scope continuously develops throughout the lifetime of a project. Therefore, it is essential that projects have a clear scope management process, which defines how scope is to be defined, developed and managed. This is the process of monitoring the status of the project and product scope and managing changes to the scope baseline. The key benefit of this process is that it allows the scope baseline to be maintained throughout the project. This process captures changes in the project's budget and schedule. Project scope is defined as the "work required to output a project’s deliverable."^[1] A Scope Change is a change in the agreed scope and goals of a project to address a need not originally defined to be part of the project. This includes processes for requesting, reviewing, approving, carrying out and controlling changes to the project's deliverables. The main stakeholders involved in Scope Change Control include, the proposer of the change, Work Package Owner (WPO) and potentially a second approver, which could for example be the Project Director.^[2] This article focuses on the method of applying Scope Change Control, based on industry best practices through semi-structured interviews with Project Managers and Engineering Managers. For the sake of clarity, this method is applied to construction projects within the pharmaceutical industry.

Background

Glossary

Project Scope Management

Figure 1: Project Scope Management Overview, inspired from the PMBOK® Guide

According to the PMBOK® Guide, a body of project management standards and guidelines, the purpose of Project Scope Management is to ensure that the outcomes of a project are successfully achieved by only including all the necessary work to complete. Therefore, Project Scope is defined as the work that must be done in order to achieve desired project deliverables.^[3]

Figure 1 gives an overview of Project Scope Management. It includes five processes highlighted by the PMBOK® Guide:^[4]

1. Initiation: Engaging and committing the organization or project office to start the project
2. Scope Planning: Developing a scope statement that sets the course for future decision making
3. Scope Definition: Breaking down major deliverables into manageable sizes, also known as Work Breakdown Structures (WBS) to be executed by the Project Team.
4. Scope Verification: Verifying or accepting the scope statement
5. Scope Change Control: Controlling changes to the project scope

These above processes do interact and interface with each other to address a phenomenon called Scope Creep. Scope Creep is defined as the uncontrolled incremental changes in project scope.^[5] It can be difficult, especially early on in the design phase of a construction project, to determine whether or not the project scope has been added/subtracted, developed or has not been fully defined due to inadequate design by the engineering supplier as the project progresses. The purpose of this process is to ensure that scope changes are beneficial to the project, determine whether or not a scope change has occurred and finally managing the changes as they occur. Changes to project scope may have direct or indirect influence on the project cost, schedule, quality and others. Therefore, it is important to ensure any implications are accounted for. The process flow of Scope Change Control includes inputs, tools and outputs. This is depicted in Figure 2 and explained below.

Figure 2: Project Scope Change Control Process, inspired from the PMBOK® Guide

The inputs of Project Scope Change Control, as highlighted by the PMBOK® Guide, include:^[6]

1. WBS: The breakdown of project elements into groups that define the project scope. The purpose is to define confirm a common understanding of the project scope baseline.^[7]
2. Performance Reports/KPIs: Performance reporting is used to alert the project team of potential issues regarding scope
3. Change Request: These requests are made by the proposer, which could be for example be the Project Owner or external engineering partner.

The tools for Project Scope Change Control, as highlighted by the PMBOK® Guide, include:^[8]

1. Scope Control Change System: This is the description of the system or workflow required for authorizing change. This is explained in further detail in the next section
2. Performance measurements: The purpose of performance measurements is to measure the magnitude of any variations that do occur

The outputs of Project Scope Change Control, as highlighted by the PMBOK® Guide, include:^[9]

1. Changes to scope
2. Corrective action: To ensure the project deliverables are met
3. Actual cost and schedule recording: Any changes to the total project cost and schedule must be recorded^[10]
4. Lessons learned: These are all the findings and all other lessons “learned” from the Scope Change Control. All these learnings must be documented

Introduction to Scope Change Control System

In order to best understand Scope Change Control System, it is important to understand the different types of scope changes. These definitions are depicted in table 1, based on industry definitions.

Table 1: Types of Project Scope Change, based on industry definition

Application of Scope Change Control System

As outlined in the abstract, it is assumed that this method is applied to constructions projects within the pharmaceutical industry. This workflow has been established by Project Managers and Engineering Managers with many years of experience working within the industry. In this example, it is assumed that a pharmaceutical company plans on building a new green field plant. This workflow is broken down into eight steps involving three groups of stakeholders. The first group includes the Proposer. The Proposer is the individual, group of individuals or organization that propose changes to the scope. This could for example be the external engineering supplier responsible for designing the plant. The second stakeholder involved is the Work Package Owner, overlooking a portion of the project's work breakdown structure. The final individual, or group of individuals, involved is the Second Approver. This could, for example, be the Project Director. It should be noted that this is a generic workflow that should be adjusted to each project, depending on project size (Total Project Cost) and scope. This method has been divided and explained in the steps below.

Figure 3:Project Scope Change Control Workflow, based on best practice from the Pharmaceutical Industry

Steps 1 - 3

The method is initiated by the Proposer, with a change request to the project scope. This could be the engineering supplier, mentioned in the green field plant example given above, requesting modifications to the facility pumping system after having signed the contract with the client (pharmaceutical company). The Proposer may also be the project’s steering group (client) requesting changes to the project. The Scope Change Control (SCC) referred in figure 3, is a template filled out by the proposer. This template can be in paper form or an e-form as part of an integrated IT system, depending on the size of the project and frequency of Change Orders (CO). The SCC template is then sent to FA, which in this case could be the WPO responsible for pumping. The

Limitations

The main limitation of this method, is that it is not possible to accurately determine the project scope baseline at any given point of the project. This is especially true during the early design phase of the project where the scope has not yet been completely defined.

• Pending further input for the limitation of the method

References

1. ↑ https://www.pmi.org/learning/featured-topics/scope Project Management Institute. Retrieved 18 September 2017.
2. ↑ Meeting with Project Managers within the pharmaceutical industry.
3. ↑ Page 47, 1996 ed. PMBOK® Guide
4. ↑ Page 47, 1996 ed. PMBOK® Guide
5. ↑ https:http://www.project-management-skills.com/project-management-scope.html Project Management Skills. Retrieved 22 September 2017.
6. ↑ Page 57, 1996 ed. PMBOK® Guide
7. ↑ Page 54, 1996 ed. PMBOK® Guide
8. ↑ Page 58, 1996 ed. PMBOK® Guide
9. ↑ Page 58, 1996 ed. PMBOK® Guide
10. ↑ Meeting with experienced Project and Engineering Managers® Guide