7
Active Risk Management

INTRODUCTION

Some projects appear to have a passive and ad hoc approach to the management of risk, without the benefits of either tracking the root causes of identified risks or making proactive decisions and actions to mitigate the risks. In a passive and ad hoc approach, risks may be identified but they are largely ignored in the planning and execution process until undesired events occur, at which time solutions are sought. This approach often includes an assumption that additional resources will be made available to solve the problems that arise, precludes the prevention of some undesirable events, and increases the costs of addressing others. An inexperienced project team, inadequate front-end risk management planning, and a tradition of budget increases may be the primary motivation for passive risk management and deterrents to implementing proactive risk management.

It is the owner’s responsibility to ensure that project risks are rigorously and aggressively managed and reviewed by senior managers in each of the project phases (CD-0 through approval to start operations [CD-4]). The previously discussed risk identification, analysis, and mitigation planning are important, but they are not sufficient. Active risk management includes the assignment of mitigation responsibilities to appropriate project participants and the oversight of follow-through regarding every risk factor. This chapter reviews some tools and methods that can form the basis for the development of risk management excellence by owners.



The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 61
The Owner’s Role in Project Rick Management 7 Active Risk Management INTRODUCTION Some projects appear to have a passive and ad hoc approach to the management of risk, without the benefits of either tracking the root causes of identified risks or making proactive decisions and actions to mitigate the risks. In a passive and ad hoc approach, risks may be identified but they are largely ignored in the planning and execution process until undesired events occur, at which time solutions are sought. This approach often includes an assumption that additional resources will be made available to solve the problems that arise, precludes the prevention of some undesirable events, and increases the costs of addressing others. An inexperienced project team, inadequate front-end risk management planning, and a tradition of budget increases may be the primary motivation for passive risk management and deterrents to implementing proactive risk management. It is the owner’s responsibility to ensure that project risks are rigorously and aggressively managed and reviewed by senior managers in each of the project phases (CD-0 through approval to start operations [CD-4]). The previously discussed risk identification, analysis, and mitigation planning are important, but they are not sufficient. Active risk management includes the assignment of mitigation responsibilities to appropriate project participants and the oversight of follow-through regarding every risk factor. This chapter reviews some tools and methods that can form the basis for the development of risk management excellence by owners.

OCR for page 61
The Owner’s Role in Project Rick Management RISK MANAGEMENT PLAN The risk management plan ties together all the components of risk management—i.e., risk identification, analysis, and mitigation—into a functional whole. The plan is an integral part of the project plan that informs all members of the project team and their supervisors of the risks to the project, how they will be managed, and who will manage them throughout the life of the project. It should be part of the initial project approval package, and an updated plan should be part of all subsequent project planning and performance reviews. Risk management plans are dynamic documents that are used to guide day-to-day decisions by the project team. The sample table of contents shown in Box 7-1 provides an outline of the issues that should be covered in a risk management plan. The level of detail in the plan may be adjusted for small, relatively simple projects, but the basics of risk identification, analysis, and mitigation need to be covered. The risk register (described later in this chapter) is often the core of risk management plans for smaller projects. WATERFALL DIAGRAMS A risk mitigation effort is a project activity and thus should have assigned resources, assigned personnel, and an estimated cost and duration. Similarly, a risk mitigation activity should be included in the project network and tracked, reported, and managed along with other project activities. The assigned objective of a risk mitigation activity is to reduce the impact or likelihood of a specific risk factor. If a risk is high, it is unacceptable to the project, its mitigation is critical to project success, and it must therefore be closely monitored by project management. A risk mitigation activity may thus be on the project’s critical path, making the activity especially important. Even if actual execution of a risk mitigation activity is assigned to a contractor, the owner’s project director should follow its progress, because failure to mitigate the risk may require other efforts to avoid project failure. Waterfall diagrams are used to incorporate risk mitigation activities in the standard project management procedures. They differ in this way from a risk register, which tracks and monitors risks separately from other project activities. Figure 7-1 shows a hypothetical waterfall diagram, extracted from the context of a project network diagram, with the project risks qualitatively tracked over time and divided into three color-coded zones of severity. The red zone corresponds to high or unacceptable risks; the yellow zone corresponds to moderate but unacceptable risks; and the green zone corresponds to low, acceptable risks. Using this simple scale, a

OCR for page 61
The Owner’s Role in Project Rick Management BOX 7-1 Typical Table of Contents for a Risk Management Plan 1.0 Introduction and background   1.1 Statement of project philosophy, goals, and objectives relative to risk management   1.2 Risk management process and procedures 2.0 Risk management team   2.1 Team functions and responsibilities   2.2 Team members 3.0 Risk management process   3.1 Identification of risks   3.2 Assessment of risks   3.3 Analysis of risks     3.3.1 Qualitative     3.3.2 Quantitative     3.3.3 Methodology   3.4 Setting priorities on risks to be managed     3.4.1 Critical risks     3.4.2 Significant risks     3.4.3 Other (nonsignificant or de minimis) risks   3.5 Risk management     3.5.1 Risk avoidance     3.5.2 Risk transfer     3.5.3 Insurance     3.5.4 Risk control     3.5.5 Options     3.5.6 Organizational structures     3.5.7 Risk assumption 4.0 Risk management action plan   4.1 Risk register   4.2 Actions   4.3 Responsibilities   4.4 Commitments   4.5 Deadlines 5.0 Risk monitoring and updating   5.1 Waterfall diagrams   5.2 Leading indicators and other warnings   5.3 Decision points 6.0 Conclusion

OCR for page 61
The Owner’s Role in Project Rick Management FIGURE 7-1 Waterfall diagram. project as a whole is characterized as high risk if any project risk is in the red zone; the project is reported as moderate risk if any risk is in the yellow zone and no risks are in the red zone; and the project may be reported as acceptable risk only if there are no risks in the red or yellow zones. Figure 7-1 shows the progression of a risk as mitigation actions are applied over time. A risk mitigation activity is initiated and tracked because a risk assessment has shown that there is a high risk. This risk could be related to technology, scope, performance, quality, schedule, or any other factor that could expose the project to risks. Because the risk is high, a mitigation activity should be defined and established to reduce it. This mitigation activity is resource loaded, budgeted, and scheduled like any other project activity. At the conclusion of the risk mitigation activity, a new risk assessment is performed. While the mitigation activity might reduce the risk from high to acceptable, in this example the risk has only fallen to moderate—an improvement, but not enough. The project director then initiates a second risk mitigation activity, to try again to get the risk down into the acceptable zone. If this does not succeed, additional risk mitigation steps might be required. Two risk mitigation steps are shown in Figure 7-1; however, in practice, the risk reduction might be done in one step or in several steps, depending on the risk and the success of the risk mitigation methods.

OCR for page 61
The Owner’s Role in Project Rick Management Thus, the initiation of some risk mitigation activities may be contingent on the outcomes of others. Of course, the longer it takes to reduce a risk to acceptable, the more the project will cost and the longer it will take, especially if these activities are on the critical path. If time is critical, one might undertake two or more risk mitigation activities simultaneously, which, if the risk reduction activities are independent of each other, might cost more but hasten success. Determining which risk mitigation activities to undertake should be based on a cost-effectiveness analysis of the costs, durations, and probabilities of success for each. Regardless of the actual risk reduction strategies used, the waterfall diagram is a useful way to track specific risks, to be sure that risk reduction activities are scheduled and executed, and to communicate the status of risk reduction efforts to the project team and owner. This method, which highlights the activities related to risk reduction, avoids the common situation in which the project director reports that everything is 99 percent on target and that therefore the whole project is low-risk, despite the fact that the remaining 1 percent related to risk could kill the project. If the owner’s representative is not engaged in the actual risk reduction process, the owner should require that contractors present their progress in a similar way, so that the owner is aware of the status of all significant risks and the progress being made to mitigate them. PROJECT RISK REGISTER A risk register is a risk tracking system. Like other project activity or commitment tracking systems, it tracks the progress of various critical activities that require management visibility and attention. Because risk management is particularly critical to project success, risks require particular management attention, and the risk register is used to follow the actions and risk management efforts for all of the project’s identified risks. Unlike waterfall diagrams, project risk registers treat risk management activities as separate and distinct entities rather than integral project activities. Such a register identifies what actions are to be taken and when they are to be implemented, thus documenting how a project is going to control its risks. It tracks risks in the way that a project commitment tracking system tracks letters and commitments. It is also somewhat like a quality assurance plan, which documents how a project is going to achieve its quality goals. The risk register emphasizes that risk assessment should not be a static, one-time operation, as it unfortunately sometimes is, but a continuous operation throughout the life of the project, starting with initial preproject planning. Risk management requires the development of risk mitigation and reduction plans and management of the project in accor-

OCR for page 61
The Owner’s Role in Project Rick Management dance with these plans. The risk register documents these plans and, more importantly, provides a mechanism for project directors to track the plans against project execution to ensure that the project is in conformance with these plans. The risk register can be a manual system but is most commonly implemented in a computer database system or run in a computer spreadsheet. It may contain the following data elements for every risk that is identified in the risk identification and assessment processes and considered to be of significant interest: Name and description of the risk Tracking number for computerization Name of the party responsible for managing the risk (the risk owner) Rank or priority of the risk compared to others Severity of the impact if the risk materializes Impact on project quality, scope, performance, or ultimate success Impact on project cost Impact on project duration Likelihood that the risk will materialize, given current management controls Leading indicators for the risk and when they must be evaluated Risk reduction and mitigation plans now in effect Risk reduction and mitigation plans contingent on leading indicators Tracks of the leading indicators or priority of the risk over past time Forecasts of the leading indicators over future time Tickler file on actions to be taken in the future Of course, any information that a manager wishes to track can be included in the risk register. The most important reason for having a computerized system is to maintain a tickler file that reminds managers of what they are supposed to do and when it must be done. These action reminders are either preset, according to project milestones, or based on forecasts of the leading project control indicators. The leading indicators are tracked over time and projected into the future. This projection may be based either on extrapolation, such as by regression analysis or trend analysis, or on statistical control charts, which specify that no action need be taken as long as the indicator tracks inside the prearranged control limits, but that action is required if the indicator falls outside the control limits. The actions themselves may be predetermined, in the form of contingency plans set in motion when triggered by the indicators, or the indicators may simply alert management to develop a response to the relevant risk. The primary purpose of the risk register should be to support

OCR for page 61
The Owner’s Role in Project Rick Management management decisions and actions and to avoid delay. Delay is a serious problem in risk management, whether it is due to procrastination, over-optimism, or simple ignorance that some action needs to be taken. Table 7-1 is an example of a project risk register. As in all database systems, a potential problem lies in keeping the data in the system current. Therefore, when possible, the risk register should be interfaced to other project management control systems. For example, if one leading indicator is the project schedule performance index, then these values should be input to the risk register every reporting period. Other indicators may be external to the project and some may be qualitative or judgmental. In any case, most of the relevant data will have to be entered manually, and project management must ensure that this is regularly and conscientiously done if the risk register is to have value. A project risk register is initially constructed during front-end project planning through the identification and analysis of risks that could affect project performance (e.g., scope, schedule, technology, permits, site conditions, environmental impact). The likelihood of occurrence and the nature and magnitude of risks are used for prioritizing risk mitigation actions. The risk register is a tool for allocating managerial responsibility for specific risks and for reporting and monitoring the status of these risks. For example, if fewer funds are appropriated than requested, the risk register provides a basis to redesign the project to remain consistent with the allocated funding level. The effective use of this tool includes regular and frequent progress reporting on each risk until the risk or the project passes the point where the risk is no longer an issue and is closed out. Project risk registers have been used successfully on many projects, including DOE projects, but they can easily become a merely bureaucratic paper exercise. DOE project directors need to ensure that they are actually managing risks and not simply contributing to a bloated data system that has detailed data on many risks that no one is bothering to manage. Again, the point is not to document risks for the project postmortem, but to take managerial actions in a timely way to mitigate the risks.

OCR for page 61
The Owner’s Role in Project Rick Management TABLE 7-1 Risk Register with Sample Entry Risk Element ID (1) Risk Event Description (2) Likelihood (1 to 5) (3) Relative Impact (A to E) (4) Specific Impact to the Project (Cost/Schedule/Scope/Quality) (5) II.B.2. Political stability—new socialist parliament, governor, and mayor 4 D Potential new requirements—policies/laws/etc. to increase percentage of local contractors         Taxes expected to rise         More local government interest in all aspects of the project (permits, labor, etc.) NOTE: Columns 1 and 2 are identifying features that come directly from the IPRA’s assessment sheet. The risk event description in Column 2 should include specific risk event details. Columns 3 and 4 are the results from the IPRA evaluation. Column 5 refers to the specific potential impact to the project (cost/schedule/scope/quality). Once the event or issue is identified as critical owing to its likelihood of occurrence and/or its relative potential impact on the project, a mitigation strategy and/or action must be identified and followed up (Column 6) to mitigate the specific impact in Column 5. Several actions or strategies may be identified, studied, and documented for each item in columns 2 and/or 5.

OCR for page 61
The Owner’s Role in Project Rick Management Mitigation Strategy/ Action (6) Relative Cost (7) Probability of Successful Mitigation (8) Person Responsible for Action (9) Action Due Date (10) Status/ Comments (11) CONTROL—Contact U.S. embassy representative L H John Jones 10/17/XX   TRANSFER—OPIC political risk insurance M H Paul Smith 12/5/XX   ACCEPT—Assess tax implications and potential increase L M Rick Reyes 11/1/XX   CONTROL—Assess local capabilities and requirements in detail M M John Jones 10/18/XX   Column 7 refers to the cost of the action relative to the total installed cost of the project (high (H)/medium (M)/low (L)) or an estimated amount of money if available. Column 8 is an estimated probability of success if said mitigation action is implemented. Columns 9 and 10 refer to the person responsible for the action and the date of the next update or resolution. Column 11 is for comments and status of the action. SOURCE: CII (2003).