03.0 - MANAGING SCOPE
03.1 - MODULE 03-1 - INTRODUCTION TO MANAGING SCOPE
03.1.1 - WHAT IS THE PURPOSE OF MANAGING SCOPE
The purpose of the Managing Scope Module is to introduce the tools, techniques and methodologies associated with Scope Definition and Scope Management that have been identified as being “best tested and proven” practices which have been found to work on “most projects, most of the time”; provide a logical or rationale sequence showing when those tools or techniques would normally and customarily be used and in selected instances, show how to use those tools/techniques and/or where to find additional information on how to use or apply them.
Scope Management consists of two major components, Scope Definition and Scope Management.-
- “Scope Definition”- is an iterative process or series of processes, usually the responsibility of asset or operations managers in their roles in most owner organizations as project sponsors, to progressively elaborate as precisely and accurately as possible, what deliverables, both tangible and intangible, are necessary in order to achieve the strategic and/or tactical objectives for which the project is being undertaken. (i.e. the “Business Case”) When done completely and correctly, scope definition identifies at any given point in time, “all the work and only the work” necessary to achieve or realize the objectives for which the project was undertaken to achieve or realize. Exactly 100%- no more, no less.
Project Scope is normally defined by what is known as the Work Breakdown Structure (WBS) which is a deliverable oriented, hierarchically organized listing of tangible and/or intangible products, services or outcomes. The WBS is progressively elaborated over time and eventually forms the planning packages and work packages at a level above that defined by the activities in the CPM schedules. The WBS forms the basis for the development of the Organizational Breakdown Structure (OBS), and the Cost Breakdown Structure (CBS) and the Risk Breakdown Structure (RBS). It also provides the basis for the Cost Estimate and Cost Budgets.
- "Scope Management” – is an interactive and iterative set of processes through which the Owner’s project manager/project control team is primarily responsible to monitor and control changes to the scope baseline over the life span of the project especially during the Execution and Closing Phase, seeking to minimize changes to as great an extent possible or making certain that the value added of any changes exceeds the cost of making those changes, including delays and disruption to the baseline.
From the perspective of a CONTRACTOR organization, scope is defined in or by the contract documents and the primary responsibilities of Contractor’s project management/project controls falls under the processes defined in Module 5- Managing Contracts, Managing Change (Module 10) and Managing Forensic Claims (Module 12).
To clarify what is meant by “Owner” or “Contractor” organizations, here are the definitions for each:
- An “Owner Organization” is any person or entity, be it public or private sector for which a project is an INVESTMENT or COST center. For an owner organization, the revenue, cost savings or other benefits of doing the project do not come from the project itself but from whatever product, service, change or other benefit the project was undertaken to create, achieve or realize.
- A “Contractor Organization” is any person or entity which undertakes a project where they undertake the project with the expectation to make a profit or otherwise realize benefit from the project itself and NOT from whatever business objective the project was undertaken to create or produce.
In many organizations, especially large ones, it is not only possible but probable that the organization is doing projects where on some projects they are playing the role of a contractor, while on other projects, they are playing the role of an owner.
03.1.2 - WHAT ARE THE PROCESS MAPS FOR MANAGING SCOPE
OWNER’S PERSPECTIVE-
From the OWNER’S perspective, this module is about taking inputs from sources EXTERNAL to the project and converting these inputs to a Work Breakdown Structure which, if done completely and correctly, should define exactly 100% of the products, services or other deliverable necessary to achieve the strategic and/or tactical goals or objectives established by the Business Case.
Figure 1 - Process Flow Chart for Module 3- Managing Scope, from the OWNER ORGANIZATION PERSPECTIVE
Source: Guild of Project Controls
As Figure 1 illustrates for an OWNER’S ORGANIZATION, the INPUTS to Module 3 are coming from sources EXTERNAL to the project and consist of:
- Outputs from each of the Phase Gate Decision Support Packages
- The results of the Stakeholder Analysis Meetings
- The Business Case
- The relevant and appropriate Standardized WBS Coding Structures
And the primary output from Module 03-4 - Creating the Work Breakdown Structure being the Work Breakdown Structure, becomes a primary input into virtually all the subsequent processes that the Owner’s project control team would be likely to apply.
Important to note that the OWNER’S project management/project control team would be responsible to further decompose their own WBS into those items which the owner’s organization is responsible for and if there are more than one contractors on the project, the Owner’s team would also be responsible to break down the work into one or more CONTRACTUAL WORK BREAKDOWN STRUCTURE, depending on how many contractors will be working on the project.
If there is a single prime contractor, then the owner would provide only a single CWBS and it would be up to the prime contractor to break it down for his/her subcontractor’s CWBS. If there are multiple prime contractors, then the Owner would be responsible to identify which WBS elements go into each CWBS, making certain that there are no overlaps or gaps- that every single WBS element identified by the Owner is assigned either to his/her own people or to one of the chosen contractors.
As shown by the red lines, for an OWNER, it is possible that changes to the scope (+ or -) can come from any of the subsequent processes.
CONTRACTOR’S PERSPECTIVE-
Figure 2 below illustrates the important differences in scope definition between the Owner’s perspective and that of the Contractor.
Figure 2 - Process Flow Chart for Module 3- Managing Scope, from the CONTRACTOR ORGANIZATION PERSPECTIVE
Source: Guild of Project Controls
From the perspective of a CONTRACTOR’S organization, the scope definition process is somewhat different. For a CONTRACTOR, his/her scope of work is defined via the Contract Documents, which were drawn up based on the CONTRACTUAL WORK BREAKDOWN STRUCTURE as defined by the Owner’s project management/project control team, working with their legal or contracts department. In the event there is a single prime contractor, the total scope of work would be divided into those WBS elements that the owner is responsible for and the CWBS elements that the Prime Contractor is responsible for. In this case, it would be up to the Prime Contractor to further decompose the CWBS into CWBS appropriate for each of the Prime’s Sub-Contractors.
For contractors, particularly working under the traditional “Firm Fixed Price” contracting, changes often represent an opportunity for the contractor to increase his/her profit margin. Changes often result in additional claims for the “cumulative impact”, meaning that the damages or losses incurred by the contractor due to “delay and disruption” are more than just the sum of the value of the change orders, but an additional sum to cover the hidden inefficiencies.
Figure 3 - The Scope Management Process Map 100 Meter Level of Detail
Source: Guild of Project Controls
At the 100 Meter level of detail, the Managing Scope process is INITIATED by the creation of a Policy and Procedures Manual, which, if done correctly is one that those who are supposed to be following it actually know and understand and do follow it.
The second step in the process, Validating Stakeholder Expectations is part of the Planning Process and is designed to serve as a quality check to ensure that there is no scope missing. This should happen before the OWNER organization creates the full Work Breakdown Structure (WBS) as this is the last chance to add or modify scope before the creating the scope baseline, after which any changes in scope need to follow the Change Management process explained in Module 10-1 - Introduction to Managing Project Change.
The third step, Creating the WBS should represent exactly 100% of the deliverables required from the entire project and ideally at the same time, the OWNER’S project control organization creates the CONTRACTUAL WORK BREAKDOWN STRUCTURE (CWBS) for each contractor they plan on using for the project. Once this process has been completed, the scope of work should be FROZEN or BASELINED and once done, any/all changes, whether coming internally from the owners organization or externally, need to follow the change management processes as shown in Module 10-1 - Introduction to Managing Project Change.
The fourth step in this process is also part of the Planning Process and it requires that we further decompose the WBS into Control Accounts which are further broken down into either Planning Packages (if they have not been authorized and/or assigned to anyone to commence) or Work Packages (Planning Packages which have been authorized to commence work AND that have been assigned to someone responsible to execute them or see that they are executed by others.)
The final step in this process is a CONTROLLING PROCESS and this is where elements of the WBS are physically accepted in whole or in part by the OWNER organization. This is an important step in the process as acceptance of the deliverables requires that three criteria have been met:
- The work is physically completed
- The work completed is in “substantial conformance” to the technical requirements
- The work completed has satisfied all the contractual requirements. (The “shall clause”)
- The accepted deliverables becomes a direct input into Module 9- Managing Progress
While this level of detail provides a more granular look of the processes and how they interact than the 1,000 Meter view, there is yet another deeper level of detail which the Guild calls the “ground” or “working level”. It is the next level deeper which contains the explanation for each of the modules shown above, telling more about what inputs are required, including providing some examples; what tools, techniques are typically used, including providing examples or templates, and in selected instances, specific step by step instructions or links to additional resources, showing how to use each of these tools or techniques consistent with the Guild’s commitment to identify and advocate “best tested and proven” practices.
03.1.3 - BACKGROUND INFORMATION FOR MANAGING SCOPE
For purposes of clarity:
“Scope Management” - the overall process is explained / defined to be an interactive and iterative process through which an “Owner Organization” takes a projects strategic objectives and determines what deliverables are going to be necessary in order to achieve them (i.e. their Business Case). Then at this stage the “Contractor Organization” takes over to further define and deliver the project...
- During Planning - when we capture and define the project work that needs completing
- During Implementing - when we are concerned with documenting, tracking, scope creep, tracking, and disapproving / approving project changes.
- During Closing - when we audit the deliverables and assess the outcomes against the original / baseline plan
Summary - it's the management of the process that's required to ensure that a project includes all the work / work items necessary to complete the project successfully. It main concerned primarily with controlling what is / is not in the scope and concists of three main stages or processes:
An “Owner Organization” is any person or entity, be it public or private sector for which a project is an INVESTMENT or COST centre. For an owner organization, the benefits of doing the project do not come from the project itself but from whatever product, service, change or other benefit the project was undertaken to achieve or realize.
A “Contractor Organization” is any person or entity which undertakes a project where they make money or otherwise realize benefit from the project itself and NOT from whatever business objective the project was undertaken to create or produce.
When viewing projects using the combined “Project & Asset Life Span” (5 & 6) phase gate approach the because in the first two phases, Identify (11) and Select (12) there may not be and may never be a “project”, the “project life span” is categorised as consisting of Select (13), Define (14), and Execute (15) phases while the “Asset Life Span" (5), consists of the first two phases, Identify (11) and Select (12) PLUS the Project Life Span of phases Select (13), Define (14), and Execute (15), PLUS in addition, the Operate (16) and Dispose (17) phases.
Thus the time horizon of the Asset Life Span will always be greater than that of any single project life span.
Figure 4 - Asset, Program and Project Control Life Span
Source: Giammalvo, Paul D (2015) Course Materials. Contributed Under Creative Commons License BY v 4.0
If you recall from Module 1 - Introduction and Managing Project Controls, in order to meet the needs of both OWNER and CONTRACTOR project control professionals, the Guild of Project Controls has adopted the “Integrated Asset and Project Management” model developed back in the mid to late 1950’s by either Esso or Diamond Shamrock Oil and still in use by all the major International Oil companies and many regional and national oil companies as well. This model or approach is consistent with AACE’s Total Cost Management Framework and this graphic is an adaptation of one developed by Chevron.
In this model, project life span management (6) is the DELIVERY METHOD used by OWNER companies to acquire, create, update, maintain, expand and eventually dispose of ORGANIZATIONAL ASSETS. (5).
Figure 5 - Clarification between Owner’s Project Life Span and Contractor’s Project Life Span
Source: Giammalvo, Paul D (2015) Course Materials. Contributed Under Creative Commons License BY v 4.0
If you recall from Module 1 - Managing project Controls, the model shown in the previous two graphics is based on the project life span from an OWNER’S perspective. To make the relationship between the Owner’s perception of the project life span and the various Contractor’s perception of the project life span as clear and understandable as possible, we can see above that the owner’s project life span starts from the time a single option has been decided upon and initial funding has been provided internally either through the CAPEX or OPEX budgeting process. (Select Phase) and continues to beyond the end of the project Execution phase.
If the project is to be executed under some form of cost reimbursable contracting strategy (i.e. Design-Build, Engineer, Procure, Construct and Commission (EPCC), Integrated Project Delivery (IPD) or Cost Plus Fixed Fee etc.) the contractor would likely be brought on board by the owner during the latter part of the Select Phase or start of the Design phase to provide Engineering and Procurement services during the Define phase, at which point the contractor would involve his/her own Project Manager and Project Control Team along with that of the Owner’s Project Manager and Project Controls Team lasting through the Define phase (Engineer and Procure) to the end of the Execution phase. (Construct and Commission).
If however the project were going to be contracted using a Firm Fixed Price type contract (i.e. traditional Design>Bid>Build, “hard money” or Unit Price Contract) the contractor would more than likely not be bidding on the contract until the end of the Define phase and not start work until the beginning of the Execution phase through to the completion of the Execution phase. One or both of these two latter approaches is the model most contractor project control practitioners are likely to be familiar with.
In using this model, done correctly, the owner organization, with the support and input from Project Control practitioners, Business Analysts, Cost Engineers, Systems Engineers and other technical support professionals matches portfolios of projects to portfolios of available assets in order to acquire, create, update, expand or eventually dispose of organizational assets.
The reason this model has so much relevance and importance to “Managing Scope” is because IF owner’s Project Controls practitioners are according with good practice then over the project development life span the scope of the project should be PROGRESSIVELY ELABORATED from a MINIMUM of:
- Level 1 WBS, a Level 1 Schedule and Cost Estimate in Phase 1, to a
- Level 2 WBS, a Level 2 Schedule and Cost Estimate in Phase 2, to a
- Level 4 WBS, a Level 4 Schedule and Cost Estimate when getting to Phase 4
For those wanting or needing to learn more about the importance of scope definition, “front end loading” and the responsibilities of owners to do a robust job of scope definition, here are additional references:
- Butts, Glenn (2009) Joint Confidence Level Estimates - A History of Denial
- Butts, Glenn (2010) Mega Project Estimates - A History of Denial
- Flyvbjerg, Bent; Skamris, Mette; Holm, Buhl, Søren (2002) Underestimating Costs in Public Works Projects Error or Lie?
- Merrow, Edward (2012) Oil and Gas Industry Megaprojects: Our Recent Track Record
During these early Phases, project control practitioers play the role of subject matter experts. Referencing back to Identifying and Engaging Stakeholders Process Map it was explained that during this early pre-project phase, the team produced two primary documents:
- A list of stakeholders along with their needs, wants and expectations not only for the project itself (i.e. on time, within budget, no lost time accidents or fatalities etc.) but more importantly from a business perspective, what strategic objects the project was undertaken to achieve or deliver.
- A Logical Framework Document which provides a high level “one page summary” of the project.
Using these two documents as the starting point for the “Scope Definition Process”, the project team needs to further DECOMPOSE the high level objectives into specific deliverables which can be used to develop more refined cost and resource estimates, create the CPM schedule and establish control accounts which can then be either insourced or outsourced (i.e. tendered, awarded, contracted) depending on the type of project and the capabilities of the owner organization.
By the time we get to Phase 3 , we now have a “project” at least from the perspective of the OWNER and now that the business case has been established and management has made the decision to proceed:
- It is this phase where we start to get serious responsibilities as project control practitioners, in particular, planners and schedulers and cost estimators. The role and responsibility of the project control practitioner is to challenge and validate the assumptions and calculations used in the development of these documents.
- It is now up to the project control practitioners to first analyse, test and validate the assumptions made in the decision support packages (DSP) and/or in the log frame document and if necessary, provide constructive feedback to the stakeholders if their assumptions are found to be unrealistic, impractical or flat out wrong.
- Once the project is agreed to be viable, the next step is to develop the work breakdown structure.
- Then by assigning people responsible we create the responsibility assignment matrix or control accounts which is the marriage between the wbs elements and the organizational breakdown structure.
The scope management process is completed when the deliverables have been physically created, constructed, implemented or produced, in substantial compliance with the technical specifications, have fulfilled or met all the contractual requirements (the “shall clauses”) and are accepted by the owner, subject only to checklist or punch list items.
The final step in this process is where the project control practitioner compares what was actually created or delivered by the project execution against what was originally specified or required and either rejects or accepts each deliverable at the appropriate level.
03.2 - Module 03-2 - Developing the Scope Management Policies & Procedures Manual
03.3 - Module 03-3 - Validating Stakeholder Expectations
03.4 - Module 03-4 - Creating the Work Breakdown Structure
03.5 - Module 03-5 - Creating the Control Accounts
03.6 - Module 03-6 - Accepting Completed Deliverables
GPCCAR M03-1 Managing Scope Process Map, Revision 1.04