Project Scope Control

Latest revision as of 19:51, 17 November 2018

Developed by Hani Selim

[edit] 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)^{[glossary 1]} 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.

[edit] Background

[edit] 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 at a leading organization. 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. It is noteworthy to mention that the identity of the interviewed individuals, as well as the organization's internal business processes have been censored due to confidentiality issues.

[edit] 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

[edit] 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. Moreover, the identification and submission of change can come from internal or external project members (seen from the company's perspective). The change is always compared to the project's current approved scope, budget and schedule. The next section will focus on applying the Scope Change Control System method (which will be referred as SCCS from this point forward) to address the above issues Project Managers face.

[edit] Application of Scope Change Control System

[edit] 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 together with the interviewed Project 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.^{[glossary 2]} This workflow is broken down into nine steps involving three groups of stakeholders as shown in figure 3. In addition to the groups identified, the roles and responsibilities involved in the SCCS process are illustrated in table 2. The first group includes the Proposer or Requester. 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 (WPO), overlooking a portion of the project's work breakdown structure. The final individual, or group of individuals, involved is the Change Approver or Second Approver. This could, for example, be the Project Director.^{[glossary 3]} It should be noted that this is a generic workflow that should be adjusted to each project, depending on project size (Total Project Cost)^{[glossary 4]} and scope. This method has been divided and explained in the workflow flow below.

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

Table 2: Role Responsibilities in Scope Change Control System

[edit] 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) described in figure 3, is a template filled out by the proposer. This template can be in paper form or as part of an integrated IT system, depending on the size of the project and frequency of Change Orders (CO).^{[glossary 5]} It is important that the SCC template is agreed on by all parties. It is important that the SCC template is completed with enough detail with sufficient background and rationale to enable decisions to be taken. It is part of the Change Manager's responsibility to ensure sufficient information is provided. The completed SCC template is then sent to First Approver, which in this case could be the WPO responsible for the plant's pumping system. An evaluation of the impact on the project time and budget is adequately addressed. The output of this step is a decision on approving or rejecting the change request. In the case of rejection or doubt, the WPO or the First Approver must provide feedback or clarification to the Proposer. In the case of approval, the change request is forwarded to the external engineering supplier to investigate the change impact on project scope, time and budget. The findings made by the engineering company are incorporated into the SCC form.

[edit] Steps 4 - 6

The updated SCC is then accelerated to the Second Approver. In some cases, multiple individuals collectively make a final decision on the change request. In this case, it is assumed the Project Director and Quality Assurance (QA) Manager evaluate the request. If the request is rejected, feedback to Proposer is provided. Otherwise, the SCC is developed into an official Change Order (CO). The CO needs to incorporate the update costs, scope and time impact. After the Project Director has reviewed and approved the CO, it is attached to the original project contract as a binding change to the reviewed project scope, budget and schedule.

[edit] Steps 7 - 9

All internal and external stakeholders of the project are legally bound to implement the approved change, as well as updating the project cost and time schedule. This requires updates to documents relating to project specifications such as work package reports made by the WPO, including the User Requirement Specification (URS).^{[glossary 6]} It is important for the Project Manager to continuously monitor and record actual project cost and schedule development to ensure project devliverables are met.

[edit] Financing Scope Changes

Figure 4: Categories of project scope funding

To best understand scope change financing, it is important to define Contingency and Management Reserve. Contingency is defined as an amount added to a project cost estimate to allow for uncertain events or occurrences that are expected to happen during the project, based on experience. Whereas, Management Reserve is defined as "an amount added to allow for discretionary management purposes to covering unforeseen events outside the defined scope of the project necessary to achieve project objectives. Management reserve is included in the project grant to cover unforeseen risk."^[13] It is important to note that there is no fixed percentage of the total project budget allocated to neither Contingency nor Management Reserve. This depends on the project and associated risks identified during risk analyses.

There are four main categories for funding project scope changes. These are summarized in figure 4. These are categorized based on their frequency, funding account and owner. Generally, it is common to use the Contingency funding account to finance scope changes. One of the most common types of funding is WBS Transfer, which is the transfer of resources between work packages without adjusting the total project budget. Management Reserves are rarely used for extreme situations. An example of this could be unforeseen events such as industry regulations in pharma that require changes to the validation process of finished product packaging lines. This is an example of a Change in request (see above). Some organizations evaluate and asses the Project Managers ability to avoid using such findings for scope changes to deliver the project's agreed scope, quality and timeline. However, this is not always the case despite relentless efforts by the Project Manager to implement good Scope Management practice. These challenges are highlighted in the next section.

[edit] Limitations

There are a few main limitations of Scope Change Control System method highlighted by industry practitioners. The method described above may seem straightforward to follow. However, in reality, Project Scope Control is a very complicated topic that involved many stakeholders. Some of the most dominant issues faced by Project Managers are highlighted below:

1. Project scope definition can be extremely difficult: It is not always possible to accurately determine project scope baseline at any given point of the project lifetime. This is especially true during the early design phase of the project where the project objectives have not yet been completely defined. These situations result in Re-Design changes as a result of faulty engineering drawings, as described in the example above
2. Extensive documentation: It can challenging for the Project Manager to identify and validate change requests. As outlined in the first point, the degrees of freedom of project scope is large during its early phases. It is therefore essential to record and archive design documents to hold external suppliers accountable if the project team is faced with scope changes. However, this maintenance of records is resource costly and could potentially slow down project progress. Depending on the project size, thousands of design documents are needed to be recorded
3. SCCS does not consider management of change from people's perspective: This method does not address the issues of dealing with the people side of change, or changing people's behavior. This workflow only addresses the technical aspect of change. This is an important aspect of scope change that must be taken into the project team's consideration, as many stakeholders are involved.

[edit] Glossary

1. ↑ Work Package Owner (WPO): Person responsible for a Work Package, a group of related tasks in a project. The WPO's usually report to the Project Manager throughout the lifetime of a project.
2. ↑ Green Field Project: Construction of plants or buildings "from scratch" where work is not restricted to constraints imposed by existing buildings or infrastructure. This is different from brown field projects.
3. ↑ Project Director: Individual that is responsible for strategically overseeing, monitoring and realizing a projects' deliverable from an executive level. This person carries the most responsible authority over a project.
4. ↑ Total Project Cost (TPC): This cost includes all expected direct and indirect costs from project start to validation, referring to construction projects as an example.
5. ↑ Change Order (CO): A request to the contractor to increase/decrease the value of a contract. This is usually as a result of increasing/decreasing project scope.
6. ↑ User Requirement Specification (URS): In the pharmaceutical industry, a URS is an end user document that lists clear, concise and testable technical specifications that are to be met by the supplier whenever installing new equipment or modifying existing ones.

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

[edit] Bibliography

Hayes, John (2014): The Theory and Practice of Change Management. 4th edition. This book provides extensive insight into the dealing with the people side of change in engineering systems. This is not addressed in the Scope Change Control System method.

William R. Duncan (1996), pages 47 - 58: A Guide to The Project Management Body of Knowledge: This guide provides deeper insight into the topic of Project Scope Management to give further input into the process of Scope Management.

PMI (Project Management Institute), an organization that defines worldwide standards for project, program and portfolio management: This link to PMI's perspective on Scope Management. It is relevant for readers interested in reading about articles published by practitioners on the topic of Scope Change Control.

[edit] Appendix

Meeting Minutes: Semi-structured interview with Project and Engineering Managers at a leading organization, held on 22-September-2017