Project Scope Control

Abstract

Project scope continuously develops throughout the liftetime 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." 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. This article focuses on the method of applying Scope Change Control, based on industry best practices through 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

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.

Figure 1 gives an overview of Project Scope Management. It includes five processes:

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. 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 include:

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.
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 include:

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 include:

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
4. Lessons learned: These are all the findings and all other lessons “learned” from the Scope Change Control. All these learnings must be documented

Application

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. 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.

• Pending further input on definition of stakeholders*
• Pending further input on the explanation of the workflow - question: Should the workflow be described in a table format (.e.g step 1 for row 1 and so on) or should it be described in text?*

Figure 3:Project Scope Change Control Workflow, based on best Pharmaceutical Industry Practice

limitation

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

---