M10-1 - Introduction to Managing Change

10.0 - MANAGING CHANGE

10.1 - MODULE 10-1 - INTRODUCTION TO MANAGING CHANGE

10.1.1 - WHAT IS THE PURPOSE OF MANAGING CHANGE?

The purpose of the Managing Change is to introduce the tools, techniques and methodologies, deemed appropriate to identifying, documenting and otherwise managing change that have been identified as being “best tested and proven” practices and 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.

In terms of the change management processes, there is not any major or significant difference between how owners and contractors identify, document or otherwise manage change, and in fact, the processes require both parties to collaborate.

Change in project is a fact of life. There has yet to be a project which experienced no changes and it is highly doubtful there ever will be a project with no changes. Which means from the perspective of the project control practitioner, our job is to help MANAGE that change, which means we have to be able to IDENTIFY what a change is and understand how to demonstrate the impact it will have on our projects, not only in terms of time and costs, but also in terms of resources, risks and most importantly, whether or not the change will impact the business case, either for better or worse. The assumption being that if we are able to show the impact changes have on not only our projects, but the product the project was undertaken to create, develop or implement, it will help the decision making stakeholders make better or at least more informed decisions.

There are several definitions we need to know and understand before we get too involved exploring what change is and how we can help manage it:

• Scope Creep – relatively small changes in a plan or project that necessitate other changes which lead to still more changes ... and so on.
• Mission Creep - is the expansion of a project or program beyond its original strategic goals or objectives and/or adding features or functionality beyond what was originally intended.
• Constructive Change - is an alteration by the client without issuing a formal change order.
• Directed Change - is a client initiated formal change order after the award of contract.
• Configuration Management - administrative and technical actions taken to identify and document the functional characteristics such as software options and physical layout of a computer system and is the change control process used primarily in software and systems engineering. For project control professionals assigned to any IT or Systems Engineering projects (i.e. aircraft, ship building etc) where data driven or data controlled systems need to interface (i.e. SCADA) configuration management will consume a fair amount of your time and attention.
• Cumulative Impact - the impact which results from the incremental impact when added to other past, present, and reasonably foreseeable future actions. The significance of cumulative impact has in the context of the project control practitioner is that whenever there are a series of changes on a project, that you simply cannot add up the total impact of the change orders either in terms of cost or time- that there is a hidden inefficiency that results from the start and stop effects change has on projects. How to measure this impact will be explored in greater detail in Module 12- Managing Forensic Analysis.

In this module, we will also explore the tools & techniques associated with REBASELINING a schedule and creating a RECOVERY schedule for while the options can be invoked for many reasons, they are most commonly associated with changes, either in the project scope or the impact of negative risk events or the opportunity to exploit opportunities.

10.1.2 - WHAT ARE THE PROCESS MAPS FOR MANAGING CHANGE?

At the 1,000 meter level of detail this is what the process flow chart looks like to manage change. As this process applies equally to both the Owner and Contractor organizations and in fact is an iterative process that requires that they interface in order to process the change orders, at this level of detail, the process maps are identical.  Where they will change is at the more detailed process maps where we can see this iterative process in more detail.

Figure 1 - 1,000 Meter Level Process Flow Chart for Module 10- Managing Change, from BOTH the OWNER and CONTRACTOR ORGANIZATION PERSPECTIVE

Source: Guild of Project Controls

Like we saw in Module 6, Managing Resources, Module 10 is also very much a process internal to the project teams from both the owners and contractors perspective.

Most commonly, a change order comes about because either a risk event occurred or an opportunity presented itself, however before the change order can be written, presented to the appropriate decision makers along with supporting documentation for their acceptance or rejection, regardless of how the change order came about, it requires inputs from Module 3- Managing Scope for not all change requests are scope changes.  As noted previously most often a change order comes about because of either a Risk Event or an Opportunity has presented itself. (Module 6- Managing Risk/Opportunity)  As a change order most likely means changes to the contract documents we need to determine which contractual clauses apply and what modifications to those clauses needs to be referenced. Lastly, as change orders almost always impact either or both Module 7- Planning and Scheduling and Module 8- Managing Cost Estimating and Budgeting, these processes become inputs to the change management process if for no other reason to ascertain whether the change request does or does not impact either the schedule completion dates and/or the costs.

Figure 2 - The Managing Change Progress Process Map 100 Meter Level of Detail

Source: Guild of Project Controls

As with previous process maps at the 100 Meter Level of Detail the first step that initiates the Managing Change processes is to create a Standard Operating Procedure which has been created and is maintained by the people who own or are responsible for that process.  The reason for this is not only to generate “buy in” and “ownership but to ensure that the process s known, understood and actually followed.

The second step to the process is a CONTROL process where we look at managing change from the perspective of the OWNER’S ORGANZATON.  Obviously enough, while contractors should be familiar with this process, they will likely skip it, unless they are dealing with their vendors or subcontractors, in which case, they may well be playing the same role contractually as exists between the owner and them as the prime contractor.

The third step to the process is a CONTROL process where we look at managing change from the perspective of the CONTRACTOR’S ORGANZATON.  Obviously enough, while owners should be familiar with this process, they will likely never use this process.

The final step s configuration management, which is a change management process that can be used by both owner and contractor. It normally is used whenever we are integrating systems where a change in one part of the system can cause problems in other parts of the system. By documenting and recording changes as they are made, if a change in one part of the system causes downstream problems in another part of the system, the change management log provide a historical record so we can go back and undo those changes.

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.

10.1.3 - BACKGROUND INFORMATION FOR MANAGING CHANGE

To put this module in context, as the Guild of Project Controls expects or anticipates that a considerable amount of time and effort of project controls departments and their practitioner’s will be spent on “Managing Change” the Guild has chosen to dedicate an entire Module to this topic.

Given there are three documented and validated facts about change:

1) That change WILL happen on projects

2) Failure to MANAGE that change effectively results in cost over-runs and/or schedule delays to the owner or end user of the product, service or output produced by the project and;

3) Changes in scope, costs or time, lead to claims and disputes on the part of owners

Helps to explain why the Guild of Project Controls has dedicated a full module to managing change, from both the Owners and Contractor’s perspectives

Some of the key or important definitions or concepts for this module that we need to know and understand prior to starting:

• Change Order- Unilateral written order by a project owner directing the contractor to change contract amount, requirements, or time. Such changes must be within the scope of the contract and in accordance with the contract's Changes clause to be legally implemented without the consent of the contractor. Also called modification order. See also constructive change. (Business Dictionary- http://www.businessdictionary.com/definition/change-order.html)
• Change Order Request (Owner) or Proposal (Contractor)- Proposed (or requested) change(s) in contract amount, requirements, or time (outside the scope of a contract and/or the provisions of its changes clause) which become change order when approved by the other party (owner or contractor). Also called change order request. (Business Dictionary- http://www.businessdictionary.com/definition/change-order-proposal.html  If the change order is initiated by the CONTRACTOR to the OWNER, it is more correctly referred to as a PROPOSAL while if it is initiated by the OWNER to the CONTRACTOR it is often referred to as a Change Order REQUEST or Change Order DIRECTIVE. It is important to differentiate between them for in the event of a claim or dispute, there is often disagreement about who initiated the change order.  Following this convention helps eliminate any ambiguity.
• Constructive Change- This is an alteration or modification ordered or directed by the owner or client) WITHOUT issuing a formal change order. This is the most common type of change order that results in a claim or dispute. This is why all change orders should be isolated and identified in the CPM schedule and “cost” or “resource” loaded using “Activity Based Costing” (ABC) methods at the appropriate level of detail, understanding that once the project is completed, it is often hard to document or demonstrate just how a change order impacted costs, time or both. Business Dictionary-  http://www.businessdictionary.com/definition/constructive-change.html
• “MacLeamy Curve”- Is the correct term given to a graphic found in nearly all project management standards and textbooks which demonstrates that by defining scope and freezing the scope during the early phases of the asset life span, when the opportunity to add value is high and the cost to make changes is low, resulting in fewer downstream impacts to either or both time and cost, is the preferred or recommended “best tested and proven” practice.

Figure 3 – “Left Shift” of Scope Definition Illustrated

Source: Adapted from Davis, Daniel (2013) MacLeamy Curve

The figure above illustrates this “left shift” (known in the oil and gas sector as “front end loading” or FEL) which is what BIM and Integrated Project Delivery (IPD) is supposed to deliver. The fundamental concept is to try to define scope as early in the design process as possible, then FREEZING that scope so as to minimize costly and time consuming changes during the execution phase.

• “Front End Loading”- Is a term normally used in the oil, gas and mining sector to explain the same thing described by the MacCleamy Curve, which is to develop scope as early as possible, then FREEZE that scope and only make changes if the value of those changes exceeds the direct and indirect costs associated with them, including the costs of inefficiency or rework.

Figure 4 - Concept of “Front End Loading” (FEL) Illustrated (MacLeamy Curve)

Source: Giammalvo, Paul D (2015) Course Materials Contributed Under Creative Commons License BY v 4.0

• “Cumulative Impact”- This is a term which refers to a legally accepted but hard to measure or quantify impact that is caused by many or frequently issued change orders which, due to disruptions to the flow of work, results in a cost or time impact which is greater than the sum of the change orders.  Explained another way, there is an “inefficiency” factor that has to be considered, but is hard to measure unless we use the “measured mile” approach or some of the metrics coming from Earned Value, such as SPI.

The classic example of why owners experience so many changes on their projects can be illustrated in this powerful graphic from NASA.

Figure 5 - Showing Conceptual to Actual

Source: Butts, Glenn (2010) Mega Project Estimates- A History of Denial

While we may find this to be mildly amusing, it is ironic just how common this is in too many owner organizations, which is why the PHASE GATE APPROACH to project design is considered most useful.

As we can see from the figure above, by using the Phase Gate Approach, IF owners follow it the way it was intended, by making changes as early as possible in the development process when the cost to make changes (Orange Line) is low and the Risk/Opportunity (Pink Line) is high, then by the time we get to the Execution Phase, where the cost to make changes (Orange) is high and the risk/opportunity (Pink) to make those changes without delaying the project or raising costs is low. Unfortunately, the unfortunate reality is that where most changes happen on a project are during the execution phase which is the period of highest cost and schedule impact to a project.

This concept is important for project control practitioners to know and understand because this curve and the problems of not doing what is known in the oil and gas sector as “Front End Loading” or FEL is one of the major drivers behind the push to use Building Information Modeling. By using BIM, we are able to move the period of highest cost impact (in Red) to the left, where the risk and opportunity remains high and the cost to make changes is low.

Figure 6 - Future of Project Controls? - More “Left Shift” focus

Source: Guild of Project Controls

Always keep in mind that for OWNER organizations, project management is nothing more than the delivery method of choice to acquire, created, update, maintain, expand and eventually dispose of organizational assets. In this model, the focus of owners is not on the project itself, but whatever product, service or other business objective the project was undertaken to achieve or deliver.

With the increasing use of BIM, the project control professional of the future will have the opportunity to provide input to the Building Information Modeling professional by developing and maintaining accurate, reliable and precise cost estimates and productivity data which will enable the BIM professional to produce more accurate, reliable and precise cost estimates and CPM schedules earlier in the project development life span, when the opportunity to exploit opportunities is high while the cost to make those changes is low. This “left shift” represents an ideal opportunity for those of us who practice the art and science of project controls.

Figures 3, 4 and 6 above illustrate this “left shift” (known in the oil and gas sector as “front end loading” or FEL) which is what BIM and Integrated Project Delivery (IPD) is supposed to deliver. The fundamental concept is to try to define scope as early in the design process as possible, then FREEZING that scope so as to minimize costly and time consuming changes during the execution phase.

10.2 - Module 10-2 - Managing Change - Develop The Managing Change Policies & Procedures Manual

10.3 - Module 10-3 - Managing Change - The Owner’s Perspective

10.4 - Module 10-4 - Managing Change - The Contractor’s Perspective

10.5 - Module 10-5 - Configuration Management

GPCCAR M10-1, Revision 1.02