| | RISK MANAGEMENT INTEGRATION - ZONE DEFENSE IS NOT FOR THE PROS: THE PROJECT SCHEDULE AS THE PLAYBOOK FOR YOUR PROJECT RISK MANAGEMENT PLATFORM
By: Reza Nikain, President of The Nielsen-Wurster Group, Inc. and Harold Dorbin, Executive Vice President of The Nielsen-Wurster Group, Inc.
Click here for a PDF version of this month's newsletter!
Today’s Risk Management Systems in the Engineering and Construction industry often structure Risk Identification and Risk Management processes so that they are managed separately from the actual project planning and project management processes, rather than being "in the game" and directly interfacing with the project planning and project management process outputs. Sophisticated risk system software and management systems have been developed to precisely quantify and track risks identified. However, the processes used to identify project risk or even evaluate whether the risk is likely to occur aren’t always developed to identify the key risks which are particular to a project’s scope. This lack of project specificity and inability of the Risk Management System to use actual project planning and execution data in their analysis, limits the capability of many Risk Management Systems and allows risks to "split the risk Zone Defense" set by Corporate and project executives. This "Zone Defense" used for risk management perpetuates management and project executives frustration when the project suffers material surprises due to a risk that went undetected or unaddressed until the project is labeled "out of control." For over thirty years, The Nielsen-Wurster Group, Inc. ("Nielsen-Wurster") and its subsidiary Pegasus Global Holdings Inc. ("Pegasus") have had the opportunity to review and consult on hundreds of Risk Management Systems used on projects. A number of useful tools are available to keep track of risks identified and a few even take steps to monitor the early warning signs of risks that have an increasing likelihood to occur. But the processes used to identify risks often fail to uncover risks which are particular to the project scope and objectives. This paper will provide the framework which Nielsen-Wurster and Pegasus have found successful to manage risk on multibillion dollar projects and bids as well as much smaller turn around or retro-fit projects. This framework uses the Project Schedule as the Playbook for managing the effort. Real project examples are detailed showing how using this Risk Management System format easily identifies risks specific to the project and readily mitigates risk impacts by providing greater opportunity to react to the risk. Scaling up or down the level of effort required is also much easier if the Risk Management System is designed to integrate with the other project processes which define the Project plan and execution management. This ability to integrate with project processes typically defines a successful Risk Management System from a pile of spreadsheets and color graphs that are constantly in the mode of responding to already manifested risk impacts. Risk Management Systems Today - Breakfast Burritos and False Prophets
With recognition of Risk Management as a principle Project Management process, a number of software systems and internally developed Risk Management Systems have evolved. While this paper does not fully evaluate the benefits and vulnerabilities of particular systems, there are a few general observations that can be made. Upon a recent visit to a fast food restaurant, an engineer ordered a breakfast burrito and was stopped from driving to the pay window by the restaurant employee apprising him that there are 32 different combinations for the composition of the breakfast burrito. Being in a hurry he commented "just put all of it in" and then started to drive off. The engineer was stopped again when the restaurant employee told him that the burrito could not handle that much. Perhaps a strange comparison, but many Risk Management Systems are designed to take an already completed project plan and a completed list of identified risks developed by the Project Team in order to perform their analysis. It is simply not possible in many instances to evaluate Cost / Pricing Risk, Schedule impacts and functional / quality risks all at the same time, nor is it plausible to use such a system to optimize the project plan by evaluating alternatives. These Risk Management Systems rely heavily upon an appropriate framework to identify risks and then input them into their analysis. Some Risk Management Systems, and even some sophisticated software tools, claim to provide a "complete package" and a solution to all future problems with Risk Management. Several Nielsen-Wurster and Pegasus clients have embraced these "all knowing - all telling" Risk Management Systems but found these tools to be ineffective during the project planning stage and too cumbersome to be of value during the execution stage. These "False Prophets" lead even the most well intending companies toward Risk Management Systems that are isolated from project planning and project management processes. Systems requiring a duplication of data gathering efforts in order to feed the Risk Management System, which render optimization of the Project Plan and project execution changes difficult to address effectively. Risk Identification Framework
Project Risk definitions used in most Risk Management Systems generally fall into two broad categories: - Event Driven: Risks are defined by and evaluated broadly as "events" such as unexpected weather or lack of skilled labor.
- Scope Driven: Risks are identified as the failure of a particular deliverable, such as the "turbine arrives late."
Event Driven Risk Identification Systems are an effective way to quantify the knock on, or ripple effect, which particular events have on multiple scope elements. A single event, such as bad weather, can be evaluated and its total impact quantified on the whole project. However, when used as the only risk identification approach, they cannot identify risks which are specific to the scope of work planned. For instance, the risk of "abnormal rainfall" can be used to identify effectively those aspects of the work which may be impacted and can even be used to quantitatively determine what the overall impact of an abnormal rainfall would be on the project. However, relying only on a broad list of physical events to derive the total risk assessment for the project would ignore particular contractual obligations of the parties (timely approval of preliminary engineering design by the Owner or notice to the Owner of both Cost and Schedule impact for an event the Contractor is seeking a Change Order for) or the execution environment (i.e. another Contractor occupying the work site). Scope Driven Risk Identification Systems can be a sound basis for risk identification, provided that they also identify the "root cause" for the risk. Using the above example, "turbine arrives late" does not identify "why" the turbine is late - and therefore actions cannot be taken to effectively mitigate or eliminate this risk. The processes commonly used for risk identification also fall into two categories: - Brainstorming: A collection of project staff generate a list of risks based on their experience performing similar projects.
- Checklists: A series of general risks which are often used with a brainstorming technique as a "primer" to generate more specific risks.
The strength of a brainstorming technique - reliance not on one person but on several to identify and evaluate risk - also creates a number of vulnerabilities. Risks developed from a brainstorming technique rely on the experience of the individuals participating in the brainstorming exercise. It is Nielsen-Wurster’s and Pegasus’ experience that many companies do not prescribe exactly who must participate in the brainstorming exercise or when participants must attend. This often causes unpredictable, non-uniform results. The brainstorming process also requires individuals to speak up and identify the risk to the group for evaluation. The risks identified are often only those of the more outspoken brainstorming participants. Finally, because brainstorming relies on the experience of the process participants, Contractors in particular have difficulty relying on brainstorming as their sole risk identification process. Contractors perform projects in a number of geographic regions and may not be familiar with the execution environment (local weather conditions, labor market, transportation routes, etc.); therefore, brainstorming alone tends to leave significant gaps in development of project specific risks. Checklists, whether developed as a commercial product or internally by a large company, are often used as a way to ensure the breadth and completeness of the risk identification process. Attempts at providing a "foolproof" complete checklist of risk priming questions leads Owners and Contractors to typically distribute the questions to different project participants and as a result risks are identified by individuals rather than a group effort. The vulnerability in this risk identification process caused by the risk identifier lacking specific project experience (performing similar scopes of work, performing work in similar region or execution environments, etc.) is even greater than in brainstorming. For both Owners and Contractors, Checklist Driven Risk Identification Systems, in an effort to be thorough, make execution of the checklist system impracticable due to the large number of primer questions asked of the participants. During a recent assessment of one client’s Risk Management System which utilized a drop down menu driven checklist comprised of over 5,000 questions, it became apparent that the Checklist Driven risk identification process was essentially abandoned due to too many questions being asked in order to complete the process. There was no way to focus the effort. In the early stages of planning and early stages of project execution, each of the checklist questions were asked and answered with a great deal of care; however, as the planning and execution steps matured, less time was given to addressing the risk management effort and the checklist responses were merely copied over and over again. Preparing the Risk Management Framework to Integrate with Project Controls
We already covered some of the vulnerabilities created by defining risk as either Event Driven or Scope Driven and developing the risk identification process from a Brainstorming or Checklist driven approach. The two fundamental concepts that are frequently ignored in the hundreds of Risk Management Systems Nielsen-Wurster and Pegasus have consulted on are that risk management must focus on identifying risks which are specific to the particular project under review and must integrate with the other project management processes during both project planning and project execution. Below is a brief overview of a system that can be used to provide integration and project specific risk identification. Fundamental Paradigm Drives the Need for a Broader Plan
The fundamental paradigm that must be acknowledged to develop an effective Risk Management System is simply that Owners and Contractors approach risk management from two very different project perspectives: The Owner makes its money from the constructed projects and the Contractor makes its money from designing / constructing the project. Including this statement in other papers and presentations often precipitates long discussions with some that perceive risk management only as a joint effort by both the Contractor and the Owner to nurture the success of the eventual project. While both Contractors and Owners intend for the project to be successful and each party intends for the other party to perform the project well, on-time and make money from the project, recognizing this Fundamental Paradigm elevates the importance of understanding the Execution Environment, the Scope Relationships and the Contract between the parties as the primary drivers for risk. 
Understanding the necessary scope of an effective project Risk Management System is as simple as understanding the triangle above. - Scope Relationships: Owners and Contractors have to clearly understand how the scope is separated amongst the project participants (who will provide what and to whom) as well as the parties that they rely upon (the Owner will deliver the preliminary layout plan for Contractor’s use, or the Vendor will receive the pre-engineering from the Contractor) and project parties who expect a deliverable from them. Scope Separation is performed by both Owners and Contractors as part of scope development during the planning stage, i.e., the development of Work Breakdown Structures by both Owners and Contractors, the development of a Project Delivery Method by the Owner, etc. This set of scope relationships continues to evolve during project planning, becoming more specific as decisions are made and as the defined scope becomes more detailed.
- Execution Environment: This includes regional and even site specific factors (labor availability, capability of local labor, weather, access to the facility, port availability), local rules and regulations (electrical codes, permitting obligations, etc.) and site specific conditions (other Contractors and work being performed at the project site, safety regulations particular to the Owner and location, etc.). This set of execution parameters is very project specific and the allocation of who is responsible for the risks associated with defining the parameter and meeting it is often not clear in Contracts.
- Contract: The Contract is the third key source of risk because it is used by the Owner as the method to allocate risk to the Contractor. Therefore, the Contract must be fully understood by each party participating in risk identification analysis and risk management. This would include not only the legal terms and conditions of the Contract, but also key entitlements to both parties (i.e. the Owner’s right to periodically test during the fabrication of key equipment and the Contractor’s right to request an extension of time or Change Order under certain specified conditions). Claims and often poor project performance result from vague terms and inconsistencies in this key document. A process to fully understand the Contract, identify the vague terms or other vulnerabilities and to allocate the risk for performing specific scope elements must be part of the Risk Management System in order for it to work effectively.
The more complete a Risk Management System addresses each of these three risk sources (Scope Relationships, Execution Environment and Contract) on a project specific basis, the more capable that Risk Management System will be at using project information developed from other project management processes during the normal course of project planning and project execution to manage risk. Set the Game Plan on a Project Specific Basis - Prepare a Risk Management Tool Belt
The Pegasus Risk ToolbeltTM works to take the three sources of risk (Scope Relationships, Execution Environment and Contract) identified above and provide specific tools to overcome chronic problems observed in the performance of the project management processes required during planning and project execution. This drives risk identification toward a more project specific basis. In general the development of a project specific Risk Toolbelt should incorporate the following principles which are all part of the Pegasus Risk Toolbelt(TM): - The Contract Document Set: Part of the development of the work breakdown structure, the Contract forms to be let and the development of scope of the project is for the Owner to ascertain the specifications and standards that apply to engineering, procurement, construction, start-up, commissioning and operation. These, of course, must meet the local and state requirements for each site where the project is to be constructed. Defining and organizing these particular requirements for incorporation into the numerous Contract forms to be let and for specific elements (local permitting, ASME stamp inspection, etc.) must be addressed in the work breakdown structure. The numerous standards and elements of the bid which the Contractor must respond to within increasingly short time frames must be carefully partitioned to the project planning participants and distributed to each of the project participants in a way that is uniform and can track changes in Owner requirements.
- Soft Scope Identified: Vague and ill-defined scope obligations of any party must be identified by both Owners and Contractors. These are often the drivers for claims and often cause project confusion during bid equalization and even project execution.
- Project Contract and Scope Relationship Diagram: For both Owners and Contractors identifying the parties to which you have a contractual relationship and to which you have a scope obligation for delivery of or receipt of a project deliverable with or without a Contract is important. The old adage that "risk should be allocated to the party who is in the best position to manage it" is not necessarily a commercial reality. Owners who have a material risk such as design and selection of a major piece of equipment (i.e. a turbine for the power plant) will not turn over the choice of the turbine supplier and ultimate design blindly to the Contractor but will require the Owner to have input into the Vendor selection and drawing review. Likewise, Contractors who require the approval of third parties (i.e., the Owner’s Technology Licensor) but do not have a Contract with that third party must include the obligation of the Owner to provide the Licensor’s approval timely in the Contractors Contract with the Owner or risk being delayed and failing to receive Cost entitlement or perhaps even a time extension.
- Contract Overview: A simple, uniform structure of the liabilities and entitlements of both parties. The Contract overview should be presented in a uniform manner so that the Risk Management participants will know what to look for and will know when something is missing.
- Hard Scope Definition: The procedure of tracking the deliverables to and from each of the project participants in the Risk Management System typically done by database.
Use of the Project Schedule as the Playbook for your Risk Management System
As stated earlier, the fundamental process used to define risk is either Event or Scope focused. Nielsen-Wurster and Pegasus have found that it is first important to understand what is essential to calling the project a "success." In the "Guide to the Project Management Body Of Knowledge" (PMBOK), this is described a necessary step to Project Initiation. It is equally important for Contractors as well because it forces a total understanding of the project including its risk. Simply put, a risk is defined as an event that causes one or more of these Project Success Goals to not be achieved. Project Success Goals (PSGs) for Owners often relate to performance of the project and its operation. The delivery timing as well as capital Cost of the project can also be important considerations. Typically all of these will be evaluated in an economic model or business plan to determine if the project will proceed. As stated before - Owners make their money from operating the project constructed. For Contractors typically bidding a project, the PSGs are defined by the vehicle from which the Contractor will make its money - the project - which is defined by Project Scope Relationships, Execution Environment and the Project Contract. The Contract must be carefully included as part of a project specific Risk Management System. Performance guarantees, entitlement for damages for late project completion and interim deliverables and approvals by the Owner are all requirements stated only in the Contract. Taking into account the two fundamental requirements of a Risk Management System, integration with other project management processes and development of risks from a project specific basis, the most logical collection of project specific tasks arranged in a manner to meet the specific requirements of the project which is updated periodically during the project planning and during project execution is - the Project Schedule. As explained below, the Project Schedule is used as a basis to perform the Risk Management process for project planning and project execution. Breakdown of Project Success Goals to Deliverables
One of the recognized handicaps of some Risk Management tools is that Cost and Schedule Risk cannot be analyzed at the same time. Risks related to meeting project function and quality requirements are often not addressed effectively in Risk Management Systems. Owners or Designers will typically manage these risks by allocating design margin and / or specific instructions as to fabrication and handling. Once generated, these requirements are not often followed up on (inspections, testing, etc.). Contractors generally fail to perform performance assessments of process or construction components on the whole (i.e., failure mode analysis, performance simulations, etc.). As a result, quality and performance risks are often grossly over-designed or mishandled. For example, it is not uncommon to have a project provide 120-130 percent of its design capacity. If we take the Project Success Goals (PSGs) and identify the Key Deliverables associated with achieving each of the PSGs and then using the Project Schedule to further breakdown each of the Key Deliverables into their Component Deliverables as defined by the Project Schedule (i.e. activities), what is identified are individual project deliverables that are related to a PSG. Although this is a very obvious and simple step, it provides significant benefit. In summary, each of the Project Success Goals can be broken into three categories: Schedule, Cost and Quality / Performance. - Cost: Deliverables which exceed a value cut-off in the execution budget are listed as Key Deliverables and the resulting Component Deliverables defined from there. This can be done at very early stages in the project planning.
- Quality / Performance: These Project Success Goals define deliverables that are sometimes overlooked. Many times the success of a significant component of a project is defined by the manufacture or operation of relatively small priced elements. These particular Key Deliverables require analysis by process and structural experts on the project. For example, a recent multibillion dollar infrastructure project reviewed by Pegasus yielded the risk of manufacturing cement weight bearing modules as being critical to the success of the project in performance, Cost and Schedule. The quality of cement and uniformity of its density was paramount to the success of thousands of these modules. While the modules were not a significant Cost component of the project, they were found to be very critical to the successful operation and Delivery Schedule for the project. If they were not found to be functional and precisely manufactured once in place, their extraction and replacement would upset the Schedule and if not found, would cause this infrastructure to fail in a material way.
- Schedule: The individual Component Deliverables that are on or near the then critical path are evaluated for risk. Of course as the near critical path changed during project planning and execution, new deliverables are evaluated for risk and others are removed from concern.
Not surprisingly, many of the deliverables that appear as Schedule Component Deliverable risks are also Cost Component Deliverables and are also Quality / Performance Component Deliverables. Consolidation is performed and is necessary. Structured Brainstorming - A Very Efficient Method of Performing Risk Assessments
During optimization of the Project plan, Owners typically have limited staff involved and therefore their Risk Management exercises must be performed efficiently. Contractors chronically must develop sophisticated lump sum bids in ever increasingly short periods of time and therefore Risk Management must be very time efficient. Use of the Project Schedule and the PSG-Key Deliverable-Component Deliverable method described above provides a framework that is very efficient for performing risk analyses. Although it may be beneficial to have all project participants in a room performing risk brainstorming and reviewing the individual risk checklist questions all at the same time, in the real world this is not possible. In Nielsen-Wurster’s and Pegasus’ experience, a Risk Management System relating Project Success Goals to Component Deliverables allows participants to be scheduled into the brainstorming session in a structured way, hence the name Pegasus Structured Brainstorming (TM). The Project Schedule is used to bring in only the participants required in each phase of the project. For example, a Contractor performing Risk Management would typically schedule the risk identification and risk evaluation process by having the Project Management and engineering groups involved first, followed by procurement and then construction participants. A small overlap is incorporated between engineering and procurement and procurement and construction to address the natural stages of the Project Schedule of transitioning from engineering to procurement and procurement to the field. Through the use of the Pegasus Risk Toolbelt(TM) the project specific information and foundation are provided to all participants. Therefore, the customary one to two week time period to prepare a significant risk profile of a large project (1500-2000 identified risks) requires the participation of most participants for only 2-3 days. While it may be beneficial to require all participants to be in the Structured Brainstorming session for the entire two week period, it has been Nielsen-Wurster’s and Pegasus’ experience that little, if anything, is missed as a result. Integration of Project Controls During Execution
Another key benefit to using the Project Schedule as the backbone to the Risk Management process is the immediate project context - Integration - the Risk Management System has with project information developed real time. An example of how this integration process works is provided in the following section. The Project Schedule provides the Risk Management platform access to the other project data, i.e., Cost, Budget, Schedule and progress which are all deliverable based, so if the Risk Management System measures risk tied to specific project deliverables, it can and will use actual project information. This Integration provides two key benefits. First, updating the Risk Management System can be reduced by up to 90 percent. Only those deliverables which relate to an identified Key Deliverable are reviewed for risk analysis during periodic updates. Changes to the budget created by Change Orders or reduction in work and adjustments to the critical path and near critical path during execution are easily noted and the Component Deliverables slated for analysis in the next risk update are easily modified. Those deliverables outside of the Component Deliverable lists are not reviewed. It has been Pegasus’ experience that this focusing of project risks for updating allows a Risk Management System to provide realistic up-to-date information on the most important risks on the project without distracting the project team with completing analysis of each and every risk on the project. This Integration with customary project control tools and forecasting methods provides a more up to the minute Risk Management System, as well as allowing an instant interface between the Risk Management System and project management. For instance, if the Risk Management action plan indicates that an inspection failed, the impact to the project could be easily identified and notified to the Owner, only because the Risk Management System was designed to define risk by impacts to the Project Success Goals and individual project Component Deliverables. Lessons from Past Projects - Examples of How the Project Schedule Is Used as the Playbook for a Risk Management System
Most Contracts today require Schedules and, more specifically, critical path method (CPM) scheduling. Fundamental in this competitive Contracting environment is how to best develop and utilize these CPM Schedules for management of resources and the inherent risks in the project. Let us discuss two hypothetical projects from two different industries. The scope of the first Project relates to the revamping of a Power Plant. The project entailed upgrading of a single cycle power plant to a combined cycle plant, including installation of new Gas Turbines, Heat Recovery Steam Generators (HRSGs) and upgrading of the associated Electrical and Mechanical systems including installation of Distributed Control System. The project was in a confined area; much of the equipment had to be installed at different elevations given the vertical nature of the building housing the equipment. Inventory management was complex given the limitation on lay-down and unloading areas. The initial Schedule had several hundred activities that included the sequence and priorities for the major equipment installation leading to mechanical and electrical activities. A summary of the initial Schedule is illustrated in Figure A. As the figure illustrates, the critical path of the construction activities was through mobilization to site and installation of the Gas Turbines. The near Critical Paths of the project were through the installation of HRSGs and the associated piping and electrical to achieve the power production in the Combined Cycle mode. Given that the HRSGs were prepackaged equipment, with the vender pre-selected by the client, the Contractor identified the need for proper coordination of the HRSG related activities. The Contract defined Owner and Contractor responsibilities and that the EPC Contractor had accepted the risk of design interface, coordination of procurement, erection and startup testing, particularly as it related to HRSGs. By virtue of this risk allocation in the Contract, the Contractor’s coordination activities with respect to HRSG’s in summary would therefore include: - Understanding of the scope of HRSG Vendor deliverables
- Coordination of the Vendor supplied information during the design phase
- Design of the foundation and Mechanical / Electrical tie-in points
- On-site receiving of the equipment
- Erection of assemblies, piping and Electrical
- Startup and Performance testing
As its common, there is a long-lead between the initial Vendor design information and the actual delivery of the equipment to site for erection. Often, as it was on this project, the Schedule did identify the on-site erection and assembly activities, and had an initial interface point during the design phase. The Contractor identified the information that it needed from the Vendor to allow engineering to proceed on items such as: - Foundation Design, including floor loading and / or maintenance access requirements
- Building Steel design, particularly vertical clearance and platform design requirements
- Electrical and Mechanical Access and tie-in requirements
During the process, the Contractor also required information on the progress of the HRSGs in the shop and the anticipated delivery to site for erection. During the installation process, delays in HRSG casing installation resulted in an overall delay in completion of the HRSGs and ultimately delaying the overall project as shown in Figure B. The root cause of the delay was that the Vendor provided the HRSG casings in significantly more pieces requiring more field related effort and ultimately time for erection of assemblies and increased costs. The impacts resulting from this unanticipated problem were particularly expensive to resolve given the already congested equipment arrangement and site conditions. If this project had developed a Risk Management System based on project deliverables as defined in the Project Schedule and Contract, there would have been multiple opportunities to address and mitigate the root cause of the condition that led to delays and increased costs in the field. At the very least, the delivery and installation of the HRSG would have been identified in the initial Schedule as a Key Deliverable for completing the HRSG and its timely completion, which was a PSG, since they were on the near critical path. Each of the deliverables called out in the project Contract would have been monitored in the Hard Scope stage of the Risk Tool Belt and assessed for events which would cause the Component Deliverable that might fail to meet plan. In concept, the system based on deliverable would have escalated the awareness through: - Understanding of the scope of HRSG Vendor deliverables: The Schedule was premised on a more assembled casing concept which led to estimating fewer field labor hours. Identifying the necessary deliverables to Vendor, assessing the premise of Vendor’s design and then incorporating the desired fabrication basis of packaging and delivery of assemblies during the vender design / drawing review process would have allowed for more timely recognition of the field requirements and / or implementation of the mitigation efforts.
- Coordination of the Vendor supplied information during the design phase: similar to that above - even if the Vendor had been awarded the project - coordination of the design information would have been another opportunity to confirm consistency between what the field and design team expected and what the Vendor was providing. Inspection of the fabrication shop would also have yielded early warning and would be an easy to perform task and an essentially no Cost Risk Management action.
The second sample project is a Light Rail project that included new installation and renovation of approximately 30 miles of Track. A summary of the Baseline Schedule is included in Figure C. The detailed Schedule contained several thousand activities. The issues surrounding the Underground Utilities in one of the towns, Area A in the Figure C Schedule, became a significant area of concern and resulted in impacts throughout the project. These utilities fall into two principle categories, Dry Utilities, such as Electric, Phone and Cable lines, and Wet utilities such as Water and Sewer lines. The Project Critical Path was through Track alignment design, fabrication, installation and system testing, with the near critical path being through the renovation and reconstruction of the existing tracks in the city streets. An important underlying scope allocation was the assignment of the Utility coordination to the Design-Build (D / B) Contractor. The Owner had entered into agreements with the Utility companies with the Contract between the Owner and the D / B Contractor assigning the coordination responsibilities to the D / B Contractor in the context of the agreements that had been in place with the Utility Companies prior to the Contract’s award. Within the utility scope, the Wet utilities were to be relocated by the D / B Contractor and the Dry Utilities to be relocated by the respective Utility Company with the Owner reimbursing the Dry Utility Company for the relocation effort. Thus, the D / B Contractor properly identified a potential risk associated with the third party utility relocation and even had allowed for Schedule contingencies in the event of non-performance. The Contract had a defined calendar day duration with large Liquidated Damages in the event of non-excusable delays. The Contract also provided for Schedule relief to the extent there were delays to the critical path that were either Force Majeure or would otherwise be considered as excusable per the terms of the Contract. Within that context, the Schedule is utilized to identify when all related activities, including the coordination activities with the respective Utility Contractors and D / B’s Subcontractors would have to be initiated. Once the work began, delays in relocation of Dry Utilities resulted in these non-critical activities to lose much of their available float, resulting in delays in start of Wet Utility operation by D / B Contractor as shown in Figure D. While the overall project was not delayed as the result of Dry Utility relocation, they did significantly impact various activities, particularly resulting for the need for multiple crew mobilizations in various areas. Early interface and integration of the actual Dry Utility related events and assessing the potential consequences would have allowed for much of the impacts realized to have been eliminated or significantly mitigated. Utilizing the Schedule as an element of the Risk Tool Belt would have provided for assessment of the events requiring coordination to meet the ultimate field requirement. Using the Contract deliverables and Schedule as the bases for risk assessment would have provided for: - The Contract provided for the need for D / B to coordinate the Utility relocation activities. Per the Utility relocation agreement which was provided to the D / B Contractor, the Owner was to pay directly to third parties for relocation as necessary without any limitation, thus allowing the Contractor to define specifically what was to be needed from the Utility Companies. In this case, D / B did not identify the specific requirements from the Utility Company and the Field Schedule requirements were not timely communicated to the Utility Company. Had proper risk assessment been done, it would have been recognized that the mitigation effort may be necessary for Third party impacts and key specific deliverables could have been assigned to the Utility Companies in the backdrop of the Owner and Utility Companies agreement.
- Even if the Utility design interface / coordination activities were not reflected in the Schedule or were not coordinated early, use of the Schedule as a basis of Risk Management would have allowed for efficiently determining how much flexibility was available in coordinating the third party activities, allowing for identification of a contingency planning, including inclusion of trigger points for implementation. Once the Project Schedule status caused for a trigger flag, the contingency plan to mitigate the anticipated delays including the implementation of the recovery strategy would have been initiated more timely than otherwise implemented on this project.
In this example, had D / B better understood the context of the Owner’s pre-established Utility agreements and had the compliance and its requirements been recognized as one of the key PSG, meaning that timely performance by Third party Contractors would result in more productive operation, the coordination activities at an earlier phase would have been prioritized. The Project Schedule was available for use as a tool for assessing how the individual Deliverables could result in the inability to meet or maintain the Schedule requirements and the loss of float would have resulted in additional Field Costs. Timely initiation of recovery strategy is often the most effective approach in mitigating damages - a Risk Management System that utilizes the already available - and maintained project control tools would facilitate resolution in an efficient manner. Conclusion - Zone Defense is Not for the Pros
The "Zone Defense" set up by commercial developed Risk Management Systems and internally developed systems lack the project context necessary for integration with actual project information developed in project planning / management processes. This integration identifies risks that are specific to the project being planned or executed. The more successful Risk Management Systems provide project context by systematically identifying the Project Success Goals (PSGs), prioritizing them and then defining project risks as events which prevent the completion of the PSGs. Identifying the individual Component Deliverables in the Project Schedule which will result in the completion of the PSGs allows the management of risks to the PSGs to be done in a way that relies on project data developed through the project management practices used during project planning as well as execution. This reduces the duplication of effort required to update the risk system and can reduce that effort by 90 percent.
Attachments
Figure A
Figure B
Figure C
Figure D
References
- Project Risk Management, Processes, Techniques and Insights, 2nd edition, Chris Chapman & Stephen Ward, pp. 144-150, John Wiley & Sons, Ltd. 1997.
- A Guide to the Project Management Body of Knowledge, Project Management Institute, Chapter 3.2.1, pp. 43-45. 2004 Edition. Click here for a PDF version of this months newsletter!
| |
