Project Scope Control

From apppm
Jump to: navigation, search

Contents

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

Reading Guide

The main contributions to this article, as outlined in the abstract, are credited to semi-structured interviews with seasoned Project Managers, Engineering Managers and practitioners. Therefore, some of the terminology used in this article refer to industry defined standards that are not completely aligned with standards defined by PMI (Project Management Institute), an organization that defines worldwide standards for project, program and portfolio management. The terminology used in this article have been defined, either in the body text or in the glossary, to address possible confusions. Nonetheless, terminology defined by PMI and the PMBOK® Guide (Project Management Body of Knowledge), are used for clarification.

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. Work breakdown structure (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 warn project members of potential issues regarding scope performance
  3. Change Request: These requests are made by the proposer, which could be for example be the Project Owner or external engineering partner. This can be done in paper form or through an IT system, depending on the size of the project


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 methodology explained in detail further in the article
  2. Performance measurement: The purpose of performance measurements is to measure the magnitude of any variations that do occur. Furthermore, additional planning may be required. This could include alterations to the WBS and scope definition


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

  1. Scope changes: This includes any changes to the project scope as defined by the WBS
  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 baseline must be recorded[10]
  4. Lessons learned: These are all the findings and all other lessons “learned” from the Scope Change Control process. These learnings are made as the project team carries corrective actions. All learnings must be documented so that this information is available for future projects


Introduction to Scope Change Control System

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

To better understand Scope Change Control System, it is important to understand the different types of scope changes. As outlined previously, the differentiation between types of changes is difficult. There is no "black or white" distinction between them.[11] This is often discussed in industry, especially in construction projects, where many stakeholders are involved. These five definitions are depicted in table 1, based on industry.[12]


Projects are required to have full transparency of changes and their implications on project costs, schedule and quality. Some changes, typically ones that occur as a result of external factors (e.g. change in request), emerge unexpectedly. Other changes arise due to inadequate engineering design made by external suppliers (e.g. re-design), where the client or Project Manager needs to evaluate the legitimacy of the scope change request. It is therefore essential for Project Managers to be well versed with managing scope and scope changes. Scope change, depending on the size, may directly or indirectly affect many stakeholders. This is something the Project Manager is expected to manage well and keep stakeholders satisfied, especially the powerful ones. The next section will focus on applying the Scope Change Control System method to address the above issues Project Managers face.

Application of Scope Change Control System

Methodology

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.

Financing Scope Changes

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. Semi-structured interview with Project Manager within the pharmaceutical industry held on 22 September 2017. Refer to appendix for meeting summary
  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. Semi-structured interview with Project Manager within the pharmaceutical industry held on 22 September 2017. Refer to appendix for meeting summary
  11. Semi-structured interview with Project Manager within the pharmaceutical industry held on 22 September 2017. Refer to appendix for meeting summary
  12. Semi-structured interview with Project Manager within the pharmaceutical industry held on 22 September 2017. Refer to appendix for meeting summary

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox