[Back to list of Exposure Drafts]

The Practice Standard for Project Risk Management

1

 

Chapter 1 Introduction 2  Project Management Institute (PMI) practice standards are guides to the use of a 3  tool, technique, or process identified in A Guide to the Project Management Body 4  of Knowledge ( PMBOK ® Guide – Fourth Edition) or other 5  PMI standards. Practice standards are targeted at audiences who participate in the management 6  of projects. This includes project managers, project personnel, contract personnel, supervisors, 7  and other project stakeholders. 8  A PMI practice standard describes processes, activities, inputs, and outputs for a 9  specific discipline subject area. It provides information on what the significant process, 10  tool, or technique is, what it does, why it is significant, when it should be performed 11  or executed, and, if necessary for further clarification, who should perform the process. 12  A practice standard does not prescribe how the process is to be implemented, leaving 13  that subject for other forums such as handbooks, manuals, and courses. 14  This chapter includes the following sections: 15  1.1 Purpose of the Practice Standard for Project Risk Management 16  1.2 Project Risk Management Definition 17  1.3 Role of Project Risk Management in Project Management 18  1.4 Good Risk Management Practice 19  1.5 Critical Success Factors for Project Risk Management

20

 

1.1 Purpose of the Practice Standard for Project Risk Management21  The purpose of the Practice Standard for Project Risk Management is to (a) provide 22  a standard for the project management profession and other stakeholders that defines 23  the aspects of Project Risk Management that are recognized as good practice on most projects 24  most of the time and (b) provide a standard that is widely recognized and consistently 25  applied. This practice standard has a descriptive purpose rather than one used for training 26  or educational purposes. 27  The Practice Standard for Project Risk Management covers risk management as it 28  is applied to single projects only. Like the PMBOK® Guide – Fourth 29  Edition, this practice standard does not cover risk in programs or portfolios of projects. 30  Chapter 11 of the PMBOK® Guide – Fourth Edition, is the basis for 31  the Practice Standard for Project Risk Management. This practice standard 32  is consistent with that chapter, emphasizing the concepts and principles relating to Project 33  Risk Management. It is aligned with other PMI practice standards. 34  Figure 1-1 compares the purposes of this practice standard to those of 35  the PMBOK® Guide – Fourth Edition and textbooks, handbooks, 36  and courses.

 

37

38  

Figure 1-1. Hierarchy of PMI Project Risk Management Resources 39  This practice standard is organized in three main sections: 40  1.   Introductory material including the framework, purpose, principles, 41  context of, and introduction to Project Risk Management processes as defined in 42  the PMBOK® Guide – Fourth Edition. 43  2.   Principles underlying the six Risk Management processes in 44  the PMBOK® Guide – Fourth Edition as follows: 45     •  Plan Risk Management 46     •  Identify Risks 47     •  Perform Qualitative Risk Analysis 48     •  Perform Quantitative Risk Analysis 49     •  Plan Risk Responses 50     •  Monitor and Control Risks 51   52  Each of these six processes is described in a chapter that addresses the following 53  four topics: (a) purpose and objectives of the process; (b) critical success factors for 54  the process; (c) tools and techniques for the process; and (d) documenting the results 55  of the process. 56  3.   A glossary of terms used in this practice standard. 57   58  In order to describe those aspects of Project Risk Management that are recognized as 59  good practice on most projects most of the time, and provide a standard that is 60  widely recognized and consistently applied, this practice standard emphasizes those principles 61  that are fundamental to effective, comprehensive, and successful Project Risk Management. 62  These principles can and must be stated at a general level for several reasons: 63  1.   Principles are expected to be agreed upon now and to be valid in 64  the future. While tools and techniques are constantly evolving, the principles have 65  more stability and persistence. 66  2.   Different projects, organizations, and situations will require 67  different approaches to Project Risk Management. In particular, risk management is 68  an appropriate process to apply to both large and small projects, but the way it 69  is practiced is tailored to be appropriate for the project at hand. There are many specific 70  ways of conducting risk management that will be found to be in compliance with the principles 71  of Project Risk Management as presented in this practice standard. 72  3.   The principles should be applicable to projects carried out in a

73  global context, reflecting the many business and organizational arrangements 74  between participants, such as joint ventures between commercial and national companies, 75  and the cross-cultural environment often found on these project teams. 76  The principles described herein can be used as a check for an organization’s 77  process. Practitioners can establish a process specific to their particular situation, project, 78  or organization and then compare it with these principles, thus validating it against 79  good Project Risk Management practice.

80

 

1.2 Project Risk Management Definition 81  The definition for Project Risk Management, as defined in the PMBOK® Guide 82   – Fourth Edition, is the basis for this practice standard: “Project Risk Management includes 83  the processes concerned with conducting risk management planning, identification, 84  analysis, responses, and monitoring and control on a project.” The PMBOK® 85  Guide – Fourth Edition also states: “The objectives of Project Risk Management are 86  to increase the probability and impact of positive events, and decrease the probability 87  and impact of events adverse to the project.” In the PMBOK® Guide 88  – Fourth Edition, “project risk is an uncertain event or condition that, if it occurs, has 89  a positive or negative effect on at least one project objective.” Examples of project 90  risk include time, cost, scope, or quality. 91  Project Risk Management aims to identify risks in advance of their occurrence, when they 92  are only possible but not certain. This orientation requires consideration of events that 93  may or may not happen and are therefore described in terms of probability of occurrence.

94

 

1.3 Role of Project Risk Management in Project Management 95  Project Risk Management is integral to successful project management. Because risk management 96  should be embedded in the planning and operational documents of the project, it 97  is established as part of the project; therefore Project Risk Management should not 98  be considered as an optional activity. 99  Many of the project management processes address planning the project, from concept to 100  final design and from procurement through daily management of execution and close-out. 101  These processes are mostly based on disciplines that assume an unrealistic degree 102  of certainty about the project. 103  Project Risk Management views a project from a different perspective than many other 104  project management processes, for example, time management and scheduling. Project 105  scheduling assumes that the durations of activities, and hence the completion date 106  and critical path, can be known in advance with certainty. In contrast, quantitative schedule 107  risk analysis addresses, in advance, whether the durations of scheduled activities 108  may deviate from the plan and derives the implications of those possible deviations 109  for project schedule results. 110  Risk management is not a substitute for the more traditional project management processes. 111  On the contrary, Project Risk Management requires that these project management processes 112  (e.g. scheduling, budgeting, and change management) be performed at the level of the 113  best practices available. Risk management adds the perspective of project risk to the outputs 114  of those other processes and adds to their value by taking risk into account. For instance, 115  risk management provides the basis upon which to estimate the amount of cost and 116  schedule contingency reserves to a required level of confidence for meeting objectives 117  that are needed to cover risk response actions. 118  There is a paradox about project risk that affects most project managers. In the early stages 119  of a project, risk is at its maximum but information about risk may be at its minimum. 120  This situation does not mean that a project should not go forward because little is known

121  at that time. Rather, there may be different ways of approaching the project that 122  have different risk implications. The more this situation is recognized, the more realistic 123  the project plans and expectations of results will be. 124  Risk management methods are useful at all stages of a project’s evolution. Risk management 125  is most useful when project planning has progressed, since information is developing about 126  the approach, resources, time, and cost. At this stage, the balance between project flexibility 127  and knowledge about project risk may be optimal for Project Risk Management. 128  It is true that as the project plan becomes more set, with fundamental decisions, agreements 129  and contracts in place, the options for making substantial changes to capture opportunities 130  or mitigate threats are limited. During project execution, risk management processes monitor 131  the changes the project undergoes for new risks that may emerge and fashions appropriate 132  responses to them. Risk management plays a role in providing realistic expectations for 133  the completion dates and cost of the project even if there are few options for changing 134  the future. 135  Finally, during project closure, risk-related lessons are reviewed during the post-project 136  review, in order to contribute to organizational learning.

137

 

1.4 Good Risk Management Practice 138  Project Risk Management is a valuable component of project management and it is of equal 139  value with other project management processes. As with all of these processes, Project 140  Risk Management must be conducted in a manner consistent with organizational practices 141  and policies. In addition, like other project management processes, Project Risk Management 142  must be conducted in a way that is appropriate to the project. Project Risk Management 143  must recognize the business challenges as well as the multi-cultural environment implied 144  by an increasingly global environment including many joint venture-owner projects 145  and customers, suppliers, and workforces spread around the globe. 146  Project Risk Management must be conducted within the context of the organizational framework 147  of practices and policies. For instance, any change in the project plan that is implied 148  by the risk management process may require decisions at the appropriate level of management 149  to reassign personnel, establish or modify budgets, make commitments to others outside 150  the project, interact with regulators, and comply with the rules of accounting and 151  law. Project Risk Management must be conducted in compliance with these internal and 152  external requirements. 153  Project Risk Management should always be conducted on an ethical basis. Honesty, responsibility, 154  realism, and fair dealing with others are among the characteristics of successful Project 155  Risk Management. Effective Project Risk Management benefits from agreement among 156  all stakeholders that Project Risk Management in general, and risk identification, analysis 157  and response in particular, should be carried out in a realistic and objective way and 158  should not be subject to political or other unreasonable influences. 159  Project Risk Management should be conducted on all projects. Like other project 160  management processes, Project Risk Management must be conducted in a way that is appropriate 161  for the project. The degree, level of detail, sophistication of tools, and amount of time 162  and resources applied to Project Risk Management should be in proportion to 163  the characteristics of the project under management and the value that they can add to 164  the outcome. Thus, a large project that has significance to the future of the organization, 165  say in its ability to please or displease an important customer, would theoretically require 166  more resources, time, and attention to Project Risk Management than would a smaller, 167  short-term, internal project that can be conducted in the background with no particular deadline. 168  Each of the Project Risk Management processes should be scaled to be appropriate to 169  the project under management during the Plan Risk Management process and reviewed periodically 170  to determine if the decisions made in that process remain appropriate.

171

 

1.5 Critical Success Factors for Project Risk Management

172

 

173  

Figure 1-2. Critical Success Factors 174   175  Specific criteria for success of each Project Risk Management process are listed in 176  the chapters dealing with those processes. The general criteria for success include: 177     •  Project Risk Management must be recognized as a valuable discipline, which provides 178  a positive return on investment by organizational management, project stakeholders, 179  project management, and team members. 180     •  All parties must be committed, up to the highest level of management, to 181  the principles of Project Risk Management. 182     •  Project participants and stakeholders must all accept responsibility for 183  undertaking risk-related activities as required. Risk management is everybody’s responsibility. 184     •  There must be open communication among project participants concerning project 185  risk. Any actions or attitudes that hinder communication about project risk reduce 186  the effectiveness of Project Risk Management. 187     •  Risk management does not exist in a vacuum, isolated from other project 188  management processes. Successful risk management requires the correct execution of the 189  other project management processes. 190     •  Risk management activities should be consistent with the value of the project to 191  the organization and with its level of project risk, its scale, and other organizational 192  constraints. In particular, the cost of Project Risk Management should be appropriate to 193  its potential value to the project and the organization. 194  These critical success factors for Project Risk Management are illustrated in Figure 1-2.

195

 

1.6 Conclusion 196  The principles of Project Risk Management described in this practice standard should 197  be appropriately applied based on the specifics of a project. Experience indicates

198  that project benefits can be expected from the appropriate application of these principles 199  to projects.

200

 

Chapter 2 Principles and Concepts 201

 

2.1 Introduction 202  This chapter introduces the key ideas required to understand and apply risk management 203  to projects following the approach described in Chapter 11 of the PMBOK® 204  Guide – Fourth Edition. These principles and concepts are generally consistent with 205  other approaches to Project Risk Management commonly used in the industry, although 206  the terminology may differ in some details. 207  The execution of the Project Risk Management process is dealt with in subsequent chapters 208  of this practice standard and so is not discussed here.

209

 

2.2 Definitions 210  The word “risk” is used in many ways in everyday language and in various specialist disciplines. 211  Its use in the PMBOK® Guide – Fourth Edition is consistent 212  with other risk management standards and process descriptions. The definition of project 213  risk given in the PMBOK® Guide – Fourth Edition is as follows: 214  Project risk is an uncertain event or condition that, if it occurs, has a positive or 215  a negative effect a project’s objectives. 216  This definition includes two key dimensions of risk: uncertainty and effect on 217  project objectives. When assessing the importance of a project risk, these two dimensions 218  must both be considered. The uncertainty dimension may be described using the 219  term “probability” and the effect may be called “impact” (though other descriptors 220  are possible, such as “likelihood” and “consequence”). 221  The definition of risk also includes both distinct events which are uncertain but which 222  can be clearly described, and more general conditions which are less well defined but 223  which also give rise to uncertainty. 224  The definition of project risk also encompasses uncertainties which could have a negative 225  effect on a project objective, as well as those which could have a positive effect. These 226  two types of risk are called threats and opportunities. It is important to address 227  both threats and opportunities within a unified Project Risk Management process, in order 228  to gain synergies and efficiencies. 229  Risks are uncertain future events or conditions which may or may not occur, but which 230  would matter if they did happen. It is important to distinguish risks from related non-risks, 231  such as cause and effect, although identifying these may provide additional insights into 232  the risk. Causes are events or circumstances which currently exist and which might give 233  rise to risks. Effects are conditional future events or conditions which would directly 234  affect one or more project objective if the associated risk occurred. The cause-risk-effect 235  chain can be used in a structured risk statement or risk description to ensure that these 236  three elements are properly separated (see Section 5.3). 237  When a risk occurs, it ceases to become uncertain and so is no longer a risk. Threats 238  which occur may be called issues or problems; opportunities which occur are benefits. 239  Both issues/problems and benefits require active management, but this is outside the scope 240  of the Project Risk Management process.

241 

2.3 Individual Risks and Overall Project Risk 242  It is useful to consider project risk at two levels: individual risks, and overall project risk. 243  Individual risks are the focus of day-to-day Project Risk Management in order to enhance 244  the prospects of a successful project outcome. It is important to examine individual 245  risk events or conditions that might affect project objectives. Individual risks refer 246  to specific events or conditions that have the ability to affect project objectives positively 247  or negatively. Note that an individual risk may affect one or more project objectives, elements, 248  or tasks. Understanding individual risks can assist in determining how to apply effort 249  and resources to enhance the chances of project success. 250  Overall project risk represents the effect of uncertainty on the project as a whole. 251  Overall project risk is more than the sum of individual risks on a project, since it applies 252  to the whole project rather than to individual elements or tasks. It represents the exposure 253  of stakeholders to the implications of variations in project outcome. It is an important 254  component of strategic decision-making, program and portfolio management, and project 255  governance where investments are sanctioned or cancelled and priorities are set. At 256  these higher levels, it is necessary to set realistic targets for the cost and duration of 257  a project, establish the contingency reserve levels required to protect the project’s owners, 258  set appropriate project priorities, and judge whether the risk of overall success 259  is increasing or decreasing as implementation advances.

260

 

2.4 Stakeholder Risk Attitudes 261  The extent to which an individual risk or the level of overall project risk matters depends 262  on the risk attitudes of the stakeholders in a project. These risk attitudes will 263  be influenced by a wide range of factors, including the scale of the project within the 264  range of stakeholders’ overall activities, the strength of public commitments made about 265  the performance of the project, and the stakeholders’ sensitivity to non-financial issues 266  such as environmental impacts, industrial relations, and other factors. Stakeholder 267  risk attitudes usually result in a desire for increased certainty in project outcomes, 268  and may express a preference for one project objective over another. 269  Understanding stakeholders’ attitudes toward risk is an important component of the 270  risk management planning that precedes risk identification and analysis. These attitudes 271  must be identified and managed proactively and deliberately throughout the Project 272  Risk Management process. They may differ from one project to another for the same stakeholders 273  and will usually differ from one group of stakeholders to another. Indeed a single stakeholder 274  may adopt different risk attitudes at various stages in the same project. 275  It is also important to understand the particular implications on stakeholder risk attitudes 276  of working on projects where the team is international, cross-industry 277  or multi-organizational.

278

 

2.5 Iterative Process 279  It is the nature of projects that circumstances change as they are being planned 280  and executed. The amount of information available about risks will usually increase as 281  time goes on. Some risks will occur while others do not; new risks will arise or 282  be discovered, and the characteristics of those already identified may change. As a result, 283  the Project Risk Management process must be repeated and progressively elaborated throughout 284  the entire project life cycle. 285  To ensure that Project Risk Management remains effective, from time to time, 286  the identification and analysis of risks must be revisited, progress on risk response 287  actions must be monitored, and the action plans might have to be adjusted. If

288  external circumstances change significantly, it may also be necessary to revisit the 289  risk management planning stage of the process. 290  The production of an initial Project Risk Management plan and risk assessment is the start 291  of the process, not the end. The frequency and depth of reviews and updates will depend 292  on the nature of the project, the volatility of the environment in which it is 293  being implemented and the timing of other project management reviews and updates.

294

 

2.6 Communication 295  Project Risk Management cannot take place in isolation. Success relies heavily 296  on communication throughout the process. 297  Risk identification and analysis depend on comprehensive input from stakeholders in 298  a project to ensure that nothing significant is overlooked and that risks are realistically 299  assessed. The credibility of the process and the commitment of those who must act to 300  manage risks can only be assured if the way the process operates and the conclusions 301  it produces are understood and seen as credible by all concerned. This demands effective 302  and honest communication from the risk management process to the rest of the project team 303  and other project stakeholders. Communication of the results of the Project Risk Management 304  process must be targeted to meet the specific needs of each stakeholder.

305

 

2.7 Responsibility for Project Risk Management 306  It may be considered simplistic to say “risk management is everyone’s responsibility” 307  as previously stated. However it is important that management of project risk is not left 308  to a few risk specialists. Since project risks can affect project objectives, anyone with 309  an interest in achieving those objectives should play a role in Project Risk Management. 310  This particular role depends on the project team members’ and other stakeholders’ place 311  within the project and their relation to project objectives. Roles and responsibilities 312  for Project Risk Management should be clearly defined and communicated, and individuals 313  should be held both responsible and accountable. This includes allocating responsibility 314  for specific activities within the risk process, as well as for resulting actions required 315  to implement agreed-upon responses. Responsibility should also be allocated for ensuring 316  that risk-related lessons are captured for future use.

317

 

2.8 Project Manager’s Role for Project Risk Management 318  The project manager has particular responsibilities in relation to the Project Risk 319  Management process. The project manager has overall responsibility for delivering 320  a successful project which fully meets the defined objectives. The project manager 321  is accountable for the day-to-day management of the project and as part of this must make 322  sure that risk management takes place and that risks are identified and managed effectively. 323  The role of the project manager will include: 324     •  Determining the acceptable levels of risk for the project in consultation with 325  key stakeholders. 326     •  Approving the risk management plan. 327     •  Promoting the risk management process for the project. 328     •  Participating in the risk management process and identifying and owning risks. 329     •  Approving risk responses and associated actions prior to implementation. 330     •  Applying project contingency funds to deal with identified risks that occur during 331  the project. 332     •  Overseeing risk management by subcontractors and suppliers.

333     •  Regularly reporting risk status to key stakeholders, with recommendations 334  for appropriate strategic decisions and actions to maintain acceptable risk exposure. 335     •  Highlighting to senior management any identified risks which are outside the scope 336  or control of the project, or which require input or action from outside the project, 337  or where release of “management reserve” funds might be appropriate. 338     •  Monitoring the efficiency and effectiveness of the Project Risk Management process.

339

 

Chapter 3 Introduction to Project Risk Management Processes

340

 

3.1 Project Risk Management and Project Management 341  All projects are uncertain, since they are unique and temporary undertakings based 342  on assumptions and constraints, delivering change to multiple stakeholders with 343  different requirements. Project management can be seen as an attempt to control this 344  uncertain environment, through use of structured and disciplined techniques such 345  as estimating, planning, cost control, task allocation, earned value analysis, monitoring 346  and review meetings, etc. Each of these elements of project management has a role 347  in defining or controlling the uncertainty which is inherent in all projects. 348  Project Risk Management provides an approach by which uncertainty can be understood, assessed, 349  and managed within projects. As such it forms an integral part of project management, 350  and effective Project Risk Management is a critical success factor for project success. 351  For project management to be fully effective, however, it is important that Project 352  Risk Management should not be viewed as an optional process, or performed as an additional 353  overhead task. Since many elements of project management address inherent uncertainty, 354  the interface between structured Project Risk Management and the other processes of 355  project management needs to be clear. Many parts of the project management process should 356  be informed by the outputs of Project Risk Management. For example: 357     •  Estimating resource requirements, cost, or duration 358     •  Assessing the impact of proposed scope changes 359     •  Planning or re-planning the forward strategy of the project 360     •  Allocating resources to tasks 361     •  Reporting progress to key stakeholders. 362   363  None of these tasks can be performed properly without a clear view of the risk involved, 364  as determined during the Project Risk Management process. In other words, project management 365  process effectiveness is increased by using the information and results from Project 366  Risk Management. 367  In addition, effective Project Risk Management requires input from other project 368  management processes. Outputs such as the work breakdown structure (WBS), estimates, 369  the project schedule, and assumptions list, etc. are all important prerequisites 370  for effective Project Risk Management.

371

 

3.2 Project Risk Management Processes 372  Project Risk Management provides a structured approach to understanding and managing risk 373  on a project, with a number of defined steps. This chapter outlines the steps required 374  for effective Project Risk Management. Each step is described in more detail in subsequent chapters. 375  As previously defined, project risk is an uncertain event or condition that, if it occurs,

376  has a positive or negative effect on a project’s objectives. From this definition, it 377  is clear that risks only exist in relation to defined objectives. It is therefore essential 378  at the start of the Project Risk Management process to clearly define the objectives which 379  are at risk. It is also clear that different projects are exposed to different levels 380  of risk, so each step in the Project Risk Management process must be scalable to meet 381  the varying degrees of risk challenge. Scalable elements of the process include: 382     •  Available resources 383     •  Methodology and processes used 384     •  Tools and techniques used 385     •  Supporting infrastructure 386     •  Review and update frequency 387     •  Reporting requirement. 388   389  As an initial step in the Project Risk Management process, it is important to have a 390  clear understanding of the risk thresholds which define the key stakeholders’ view 391  on acceptable levels of risk, as well as a framework against which identified risks can 392  be assessed. 393  As a result, the first step in the Project Risk Management process is an initiation stage. 394  This is required in order to ensure a common understanding and agreement of the team 395  and other stakeholders as to the approach and parameters that will be applied in managing 396  risk in this project, as well as the scope and objectives of the Project Risk Management 397  process itself. Risk management activities, resources, and attention should be appropriate 398  to the project since different projects warrant different levels of risk management application. 399  The main actions to provide the required scalability are as follows: 400     •  Define those objectives against which risks will be identified 401     •  Define how the elements of the Project Risk Management process will be scaled 402  for this project 403     •  Define risk thresholds and the assessment framework. 404   405  The outputs from this initial step must be documented, communicated, and approved by 406  key stakeholders to ensure a common understanding of the scope and objectives for the 407  Project Risk Management process. 408  Once the Project Risk Management scope and objectives are agreed upon, it is possible 409  to start identifying risks, being careful to distinguish genuine risks from non-risks (such 410  as causes, effects, problems, issues etc.). A variety of risk identification techniques 411  is available, each with strengths and weaknesses. One or more techniques should be selected 412  as appropriate for meeting the needs of the specific project. The aim is to expose 413  and document all knowable risks, recognizing that some risks will be inherently unknowable 414  and others will emerge later in the project. The emergent nature of risk requires the 415  Project Risk Management process to be iterative, repeating the risk identification step 416  in order to find risks which were not evident earlier in the project. Input should be 417  sought from a wide range of project stakeholders when identifying risks, since each will 418  have a different perspective on the risks facing the project. Historical records and 419  project documents should also be reviewed to identify risks for this project. Identified 420  risks are not filtered, screened, or assessed at this stage; all identified risks 421  are recorded. Ideally, a risk owner is designated for each identified risk. It 422  the responsibility of the risk owner to manage the corresponding risk through all of 423  the subsequent risk management processes. 424  Following risk identification, it is necessary to assess risk, in order to prioritize 425  individual risks for further attention, evaluate the level of overall project risk, 426  and determine appropriate responses. Risk evaluation can be performed using qualitative 427  techniques which address individual risks, using quantitative techniques which consider

428  the overall effect of risk on the project outcome, or using both in combination. These 429  two approaches require different types of data, but where both qualitative and quantitative 430  techniques are used, an integrated approach must be adopted. 431  Qualitative techniques are used to gain a better understanding of individual risks, considering 432  a range of characteristics such as probability of occurrence, degree of impact on 433  project objectives, manageability, timing of possible impacts, relationships with other 434  risks, common causes or effects etc. Understanding and prioritizing risks is an 435  essential prerequisite to managing them, so qualitative techniques are used on most projects. 436  The outputs from qualitative assessments must be documented and communicated to key 437  project stakeholders and form a basis for determining appropriate responses. 438  Quantitative techniques provide insights into the combined effect of identified risks on 439  the project outcome by taking into account probabilistic or project-wide effects, such 440  as correlation between risks, interdependency, and feedback loops, thereby indicating 441  the degree of overall risk faced by the project. The results of quantitative analysis should 442  be used to focus the development of appropriate responses, particularly the calculation 443  of required contingency reserve levels, and must also be documented and communicated 444  to inform subsequent actions. Quantitative techniques may not be required for all projects 445  to ensure effective management of risk. 446  Once individual risks have been prioritized and the degree of overall project risk exposure 447  is understood, appropriate risk responses must be developed using an iterative process 448  which continues until an optimal set of responses has been developed. A range of possible 449  response strategies exists for both threats and opportunities. The risk owner should select 450  a suitable strategy for each individual risk, based on its characteristics and assessed 451  priority, ensuring that the strategy is achievable, affordable, and appropriate. The use 452  of a single strategy that addresses several related risks should be considered whenever 453  possible. The risk owner is responsible for defining actions to achieve the chosen strategy. 454  These may be delegated to action owners as appropriate. The risk owner should monitor actions 455  to determine their effectiveness, and also to identify any secondary risks which may 456  arise because of the implementation of risk responses. In addition to individual 457  risk responses, actions may be taken to respond to overall project risk. All response strategies 458  and actions must be documented and communicated to key project stakeholders and incorporated 459  into the project plan. 460  It is essential that agreed-upon actions are implemented; otherwise the risk exposure of 461  the project remains unchanged. It is also vital that the Project Risk Management process 462  be repeated at regular intervals throughout the life of the project. This will enable 463  the project team to reevaluate the status of previously identified risks, to identify emergent 464  and secondary risks, and to determine the effectiveness of the Project Risk Management process. 465  The steps outlined previously form the Project Risk Management process. These are detailed 466  in subsequent chapters, as follows: 467     •  Plan Risk Management (Chapter 4)— Defines the scope and objectives of 468  the Project Risk Management process, and ensures that the risk process is fully integrated 469  into wider project management. 470     •  Identify Risks (Chapter 5)— Identifies all currently knowable risks. 471     •  Perform Qualitative Risk Analysis (Chapter 6)— Evaluates key characteristics 472  of individual risks enabling them to be prioritized for further action. 473     •  Perform Quantitative Risk Analysis (Chapter 7)— Evaluates the combined effect 474  of risks on the overall project outcome. 475     •  Plan Risk Responses (Chapter 8)— Determines appropriate response strategies 476  and actions for each individual risk and for overall project risk and integrates them into 477  a consolidated project plan. 478     •  Monitor and Control Risks (Chapter 9)— Implements agreed-upon actions, 479  reviews changes in project risk exposure, identifies additional risk management actions

480  as required, and assesses the effectiveness of the Project Risk Management process. 481   482  Figure 3-1 shows the flow of control and information between the various steps within 483  the Project Risk Management process. 484  

485

 

486  

Figure 3-1. Project Risk Management Process Flow Diagram 487  

488

 

Chapter 4 Plan Risk Management 489

 

4.1 Purpose and Objectives of the Plan Risk Management Process 490  The objectives of the Plan Risk Management Process are to develop the overall risk 491  management strategy for the project, to decide how the risk management processes will 492  be executed, and to integrate Project Risk Management with all other project management activities. 493  Effective risk management requires creation of a risk management plan. This plan describes 494  how the risk management processes should be carried out and how they fit in with the

495  other project management processes. At a broader level, it describes the relationships 496  among Project Risk Management, general project management, and the management processes 497  in the rest of the organization. To provide the greatest benefit, initial project 498  risk management planning must be carried out early in the overall planning of the project, 499  and the corresponding risk management activities integrated into the overall project 500  management plan. The risk management plan may subsequently need to be adapted as the needs 501  of the project and its stakeholders become clearer or change. 502  Although the risk management processes form an integral part of the overall project plan, 503  a budget in terms of resources, cost, and time for the specific risk management activities 504  should be established in order to better track, control, and, as necessary, defend 505  the corresponding expenditures throughout the project. The cost of treating the 506  risks themselves should be included appropriately in the project budget, while the 507  risk management plan should describe how this part of the project budget is evaluated, 508  allocated, and managed. It will define the monitoring methods to ensure that 509  the corresponding expenditures are tracked appropriately, and define the conditions under 510  which the approved budget for risk management can be modified. 511  In the same way that project management is a process of progressive elaboration, Project 512  Risk Management activities need to be repeated throughout the project. The risk management 513  plan should define both the normal frequency for repeating the processes as well as specific 514  or exceptional conditions under which the corresponding actions should be initiated. 515  There are two categories of success criteria for risk management: those for success of 516  the project in general, and those for success of the Project Risk Management process itself. 517     •  Project-Related Criteria. In order to ensure consistency and agreement 518  among stakeholders, the risk management plan should present these objectives with reference 519  to the project definition documents. To help prioritize risks and their corresponding 520  responses, each objective may be assigned a priority, based on discussion with 521  the stakeholders. 522     •  Process-Related Criteria. The measures for success in Project Risk Management 523  depend on a number of factors, such as the inherent level of uncertainty of the project. 524  For example, in a research project, the number of unforeseen changes and the allowable degree 525  of variance from the baseline could be much greater than for a project in which the project 526  and its environment are much more predictable. 527   528  The level of risk that is considered acceptable in a project depends on the risk attitudes 529  of the relevant stakeholders. The risk attitudes of both the organization and the 530  key stakeholders may be influenced by a number of factors, all of which need to 531  be identified. These include their inherent tolerance for uncertainty, and the relative 532  importance to them of achieving or missing specific project objectives. This analysis 533  should then be taken into account in defining how the risk management processes are applied 534  in the specific project. 535  Rules for escalating risk-related information to management and other stakeholders 536  should reflect the risk attitudes and expectations of the corresponding stakeholders. 537  The project manager should maintain effective communication with the stakeholders as 538  the project evolves, in order to become aware of any changes in the stakeholders’ attitudes 539  towards risk and to adapt the risk management approach accordingly. 540  It is important that the participants share a common understanding of all terms used 541  to describe the risks, and that the critical values and thresholds that will serve 542  as parameters for the tools should be defined in a manner consistent with the scope of 543  the project and the attitudes of the stakeholders. If qualitative analysis needs to use 544  terms such as “high impact” or “medium probability,” these should be defined objectively 545  in the risk management plan. Similarly, the risk management plan must specify any 546  key numerical values required in quantitative analysis or for decision-making in risk

547  response planning or risk monitoring and control. 548  Risk management planning should establish the type and level of risk detail to be addressed 549  and provide a template of the risk register that will be used for recording risk-related 550  information. The plan should also indicate the intensity of effort and the frequency 551  with which the various risk management processes should be applied; this depends on 552  the characteristics of the project as well as on the specified risk management objectives. 553  In order for risk management processes to be carried out correctly and effectively, 554  the project team and other stakeholders need to know where and when they will be expected 555  to participate, their criteria for determining success, their level of authority, and 556  what action to take relative to actions or decisions beyond this level. The risk management 557  plan specifies the project’s risk management roles and responsibilities and defines 558  the corresponding expectations for both senior management and project personnel. 559  Risk-related communication occurs at two levels: (a) within the project team, and (b) between 560  the project team and the other project stakeholders. The principles for each of 561  these categories of communication are defined in the risk management plan. For the team, 562  the plan describes the frequency and scope of the various risk management meetings 563  and reports required to carry out the corresponding risk management processes as well as 564  the structure and content of such meetings and reports. For the other stakeholders, the 565  plan sets their expectations as to the structure, content, and frequency of routine documents 566  to be received as well as the way in which information will be shared for escalation 567  or exceptional events. Details of the information required from these stakeholders towards 568  the project team should also be clearly defined.

569

 

4.2 Critical Success Factors for the Plan Risk Management Process570  The principal criteria for a valid risk management plan are acceptance by the stakeholders, 571  alignment with the internal and external constraints on the project, balance between effort 572  and benefit, and completeness with respect to the needs of the Project Risk Management 573  process. Critical success factors for the Risk Management Planning process are detailed below.

574

 

4.2.1 Identify and Address Barriers to Successful Project Risk Management 575  The time and effort required to carry out Risk Management Planning will not be supported 576  unless the key stakeholders, and especially management in the organization responsible 577  for the project, recognize and accept the benefits of managing risk, and the added value 578  of addressing this as a skill in its own right rather than as a passive or reactive component 579  of general project management. 580  A clear definition of the project objectives and a high-level view of the project environment 581  and solution approach are required to provide a valid basis for risk management. The 582  project manager should therefore ensure that valid definition and planning information 583  is available for the Risk Management Planning activity. 584  An organization inexperienced in Risk Management Planning may need to develop its 585  own approach and may expend an inappropriate amount of time and effort on this. Alternatively 586  it may use a proprietary or preexisting approach which requires tailoring. The availability 587  of some or all of the following organizational process assets contribute to the chances 588  of success of the Risk Management Planning activities: standard templates, predefined 589  risk categories, an established project management methodology incorporating risk 590  management, procedures which specify what risk information is required for decision making, 591  when it is required, and a definition of concepts and terms, roles, responsibilities 592  and authority levels. Access to relevant lessons learned at this stage will allow 593  this experience to be taken into account from the start. 594  The risk management plan will not deliver its value unless Project Risk Management

595  is carried out as an integral part of the project. The corresponding activities should 596  be built into the project work breakdown structure and included in the corresponding 597  schedule, budget, and work-assignment documents.

598 

4.2.2 Involve Project Stakeholders in Project Risk Management 599  The project manager needs to involve the project stakeholders in the Risk Management 600  Planning activities to build on their skills and experience as well as to ensure 601  their understanding of, and commitment to the full risk management process. 602  The provision for risk management resources specified within the risk management plan should 603  be approved by management at a level adequate for carrying out the required risk 604  management processes in accordance with agreed-upon objectives. Management should 605  be involved in the analysis of the level of resourcing required for managing project risk 606  and accept the risks that may arise from specific limitations placed on the provision 607  of resources.

608

 

4.2.3 Comply with the Organization’s Objectives, Policies, and Practices 609  The feasibility of Risk Management Planning is dependent upon the features of 610  the organization in which it is carried out. The rules and guidelines defined in the 611  risk management plan should be compatible with the culture of the organization, 612  its capabilities from the point of view of people and facilities, and its values, goals, 613  and objectives. 614  Project management in general, and risk management in particular, contribute to 615  the organization’s effective governance. The risk management plan should identify and 616  take into account the relevant organizational procedures and any other enterprise environmental 617  factors that apply such as strategic risk management or corporate governance processes.

618

 

4.3 Tools and Techniques for the Plan Risk Management Process

619 

4.3.1 Planning Sessions 620  Planning sessions are required in order to build an understanding between the stakeholders’ 621  individual attitudes towards the project’s risks and the agreement on the techniques to 622  be used for managing uncertainty. 623  Elaboration of the risk management plan serves to develop an effective means for the team 624  to work together since a similar consultative team approach will be used in subsequent stages 625  of the risk management process. The participants should include: the project manager, 626  selected project team members and other stakeholders, members of the broader organization 627  having responsibility for risk, and other subject matter experts or facilitators as needed. 628  At this point, the initial risk responsibilities, methodology, templates, terms, definitions, 629  time, and cost budgets for the other risk management processes should be assigned 630  and accepted. The specification for the tools that will be used in subsequent processes 631  should include all parameters and other inputs required to ensure their applicability to 632  the specific project. These should be documented in the risk management plan, which, 633  when formally approved, is the principal deliverable of the Plan Risk Management Process process.

634

 

4.3.2 Templates 635  In order to benefit from experience and existing best practice, risk management planning 636  should take into account relevant existing templates, such as risk status reports or the

637  risk register. A decision should be made as to which templates are relevant to the project, 638  and these should then be adapted and included in the risk management plan.

639

 

4.4 Documenting the Results of the Plan Risk Management Process640  The results of risk management planning are documented in the risk management plan. The 641  plan serves to provide all project stakeholders with a common view of how the risk-related 642  activities of the project will be handled, what has been agreed upon, and a description 643  of the stakeholders’ involvement and responsibilities in these activities. An overview 644  of the key areas of focus is given in Figure 4-1.

645

 

646  Figure 4-1. Key Areas of Focus for the Plan Risk Management Process 647   648  Depending upon the size and complexity of the project, some or all of the following elements 649  will be present in a risk management plan. 650     •  Introduction 651     •  Project description 652     •  Risk management methodology 653     •  Risk management organization 654     •  Roles, responsibilities, and authority 655     •  Stakeholder risk tolerance 656     •  Use of tools 657     •  Communications planning.

658

 

Chapter 5 Identify Risks 659

 

5.1 Purpose and Objectives of the Identify Risks Process 660  A risk cannot be managed unless it is first identified. Consequently, after risk management 661  planning has been completed, the first process in the iterative project risk management 662  process aims to identify risks to project objectives. 663  It is, however, impossible to identify all risks at the outset of a project. The level 664  of risk exposure changes with time throughout the project as a result of the decisions 665  and actions taken earlier in the project, and due to externally imposed change. 666  The purpose of risk identification is to identify all knowable risks. The fact that some 667  risks are unknowable or emergent requires the Identify Risk Process to be iterative, repeating 668  risk identification to find new risks which have become knowable since the last iteration 669  of the process. 670  When a risk is first identified, potential responses may also be identified at the same 671  time. These should be recorded during the Identify Risk process and considered for 672  immediate action. Where such responses are not implemented immediately, these should 673  be considered during the Plan Risk Responses process.

674

 

5.2 Critical Success Factors for the Identify Risks Process 675  The practices described in 5.2.1 through 5.2.10 will maximize the value and effectiveness 676  of the Identify Risk process and enhance the likelihood of identifying all knowable risks.

677 

5.2.1 Early Identification 678  Risk identification should be performed as early as possible in the project lifecycle, 679  recognizing the paradox that uncertainty is high early on so there is often less 680  good information on which to base the risk identification. Early risk identification enables 681  key project decisions to take full account of risks inherent in the project, and may result 682  in changes to the project strategy. It also maximizes the time available for development 683  and implementation of risk responses, which maximizes efficiency since responses taken 684  early are often less costly than later ones.

685 

5.2.2 Iterative Identification 686  Since not all risks can be identified at any given point in the project, it is essential 687  that risk identification is repeated throughout the project life cycle. This should be 688  done periodically, at a frequency determined during the Plan Risk Management process. 689  Risk identification might also be repeated at key milestones in the project, or whenever 690  there is significant change.

691

 

5.2.3 Emergent Identification 692  In addition to regular risk identification exercises, the Risk Management process should 693  permit risks to be identified at any time, not limited to formal risk identification events 694  or regular reviews.

695 

5.2.4 Comprehensive Risk Identification 696  A broad range of sources of risk should be considered to ensure that all uncertainties 697  that might affect objectives that have been identified.

698 

5.2.5 Explicit Identification of Opportunities 699  Attention should be given to ensuring that opportunities are properly considered during 700  risk identification.

701

 

5.2.6 Multiple Perspectives 702  The Identify Risks process should take input from a broad range of project stakeholders 703  to ensure that all perspectives are represented and considered. Limiting risk identification 704  to the immediate project team is unlikely to expose all knowable risks.

705 

5.2.7 Risks Linked to Project Objectives 706  Each identified project risk should relate to at least one project objective, since 707  the PMBOK® Guide (Fourth Edition) defines risk as an uncertain event 708  or condition that, if it occurs, has a positive or a negative effect on a project’s 709  objectives. Consideration of each project objective during the Identify Risks process

710  will assist in identifying risks, noting that some risks may affect more than one objective.

711 

5.2.8 Complete Risk Statement 712  Identified risks should be clearly and unambiguously described, so that they can 713  be understood by those responsible for risk assessment and risk response planning. Single 714  words or phrases such as “resources” or “logistics” are inadequate and do not properly 715  communicate the nature of the risk. More detailed risk descriptions are required 716  which explicitly state the uncertainty and its causes and effects.

717 

5.2.9 Ownership and Level of Detail 718  Risks can be identified at a number of levels of detail. A generalized or high-level description 719  of risk can make it difficult to develop responses and assign ownership, while describing 720  risks in a lot of detail can create a great deal of work. Each risk should be described at 721  a level of detail where it can be assigned to a single risk owner with clear responsibility 722  and accountability for its management. Trigger conditions should also be identified where 723  this is possible and appropriate.

724 

5.2.10 Objectivity 725  All human activities are susceptible to bias, especially when dealing with uncertainty. 726  This should be explicitly recognized and addressed during the Identify Risks process. Sources 727  of bias should be exposed wherever possible, and their effect on the risk process should 728  be managed proactively. The aim is to minimize subjectivity, and allow open and 729  honest identification of all knowable risks to the project.

730

 

5.3 Tools and Techniques for the Identify Risks Process 731  A range of tools and techniques is available for risk identification. These fall into 732  the following three categories, as illustrated in Figure 5-1:

733 

5.3.1 Historical Review 734  Historical reviews are based on what happened in the past, either on this project, 735  other similar projects in the same organization, or comparable projects in other 736  organizations. Historical review approaches rely on careful selection of comparator situations 737  which are genuinely similar to the current project, and intelligent filtering of data 738  to ensure that only relevant previous risks are considered. In each case, the risks identified 739  in the selected historical situation should be considered, asking whether they might arise 740  in this project.

741 

5.3.2 Current Assessments 742  Current assessments rely on detailed consideration of the current project, analyzing 743  its characteristics against given frameworks and models in order to expose areas 744  of uncertainty. Unlike historical review approaches, current assessment techniques do 745  not rely on outside reference points, but are based purely on examination of the project.

746

 

5.3.3 Creativity Techniques 747  A wide range of creativity techniques can be used for risk identification, which encourages

748  project stakeholders to use their imagination to find risks which might affect the project. 749  These techniques can be used either singly or in groups, and employ varying degrees 750  of structure. These techniques depend on the ability of participants to think creatively, 751  and their success is enhanced by use of a skilled facilitator.

752

 

753  Figure 5-1. Three Perspectives of Risk Identification 754   755  Each category of risk identification technique has strengths and weaknesses, and no 756  single technique can be expected to reveal all knowable risks. Consequently, the Identify 757  Risks process for a particular project should use a combination of techniques, perhaps 758  selecting one from each category. For example, a project may choose to use a 759  risk identification checklist (historical review), together with assumptions analysis 760  (current assessment) and brainstorming (creativity). 761  Use of a risk breakdown structure, a prompt list, or a set of generic risk categories 762  may assist in ensuring that all sources of risk have been addressed. 763  Whichever risk identification techniques are used, it is important that identified risks 764  are unambiguously described in order to ensure that the project risk process is focused 765  on the actual risk and not distracted or diluted by non-risks. Use of structured 766  risk descriptions can ensure clarity. Risk meta-language offers a useful way 767  of distinguishing the risk from its cause(s) and effect(s), describing each risk 768  using three-part statements in the form: “As a result of , 769  might occur, which would lead to ” The relationship between cause, 770  risk, and effect is shown in Figure 5-2.

771

 

772  Figure 5-2. Cause, Risk and Effect

 

773 5.4 Documenting the Results of the Identify Risks Process 774  The results from the Identify Risks process should be recorded in order to capture 775  all relevant information currently available for each identified risk. The main output 776  from risk identification is the risk register. This includes a properly structured 777  risk description and the nominated risk owner for each risk, and may also include information 778  on the causes and effects of the risk, trigger conditions, and preliminary responses.

779

 

Chapter 6 Perform Qualitative Risk Analysis

780

 

6.1 Purpose and Objectives of the Perform Qualitative Risk Analysis Process

781  The Perform Qualitative Risk Analysis process assesses and evaluates characteristics 782  of individually identified project risks and the prioritizes risks based on 783  agreed-upon characteristics. 784  Assessing individual risks using qualitative risk analysis evaluates the probability that 785  each risk will occur and the effect of each individual risk on the project objectives. 786  As such it does not address the overall risk to project objectives that results from 787  the combined effect of all risks and their potential interactions with each other. This 788  can however be achieved through use of quantitative risk analysis techniques (see Chapter 7). 789  One step in the analysis is to categorize risks according to their sources or causes. 790  If several risks arise from a common source, sometimes called a root cause, risk responses 791  may be more effective when they focus on addressing this root cause. 792  Identifying common effects from groups of risks allows identification of the areas 793  of greatest risk exposure (e.g. to the project completion date, the budget, or a 794  particular deliverable’s scope), facilitating risk response focus in these areas. 795  The methods of qualitative risk analysis are applied to the undifferentiated list of 796  risks emerging from the Identify Risks process to provide project management with 797  the identity and characteristics of the risks that are most important in determining 798  the success of the project’s objectives. Risks that are assessed as high priority to 799  either threaten or to enhance the achievement of project objectives will be an important 800  focus in the Plan Risk Responses process, and may be further analyzed, such as in 801  the analysis of the overall project risk that is discussed in Perform Quantitative 802  Risk Analysis process.

803

 

6.2 Critical Success Factors for the Perform Qualitative Risk Analysis Process

804  Several factors that lead to successful qualitative risk analysis are described in 805  6.2.1 through 6.2.4, and summarized in Figure 6-1.

 

806

807  Figure 6-1. Building Risk Analysis Credibility 808  

809 

6.2.1 Collect High-Quality Information about Risks 810  Collection of high-quality information about risks is required. Often this information 811  is not available in any historic database and should be gathered by interviews, workshops, 812  and other means using expert judgment. Data gathered from individuals may be subject 813  to reporting or intentional bias. When this occurs, the bias should be identified 814  and remedied where possible, or a different, unbiased, source of information should be 815  found and used.

816

 

6.2.2 Use an Agreed-Upon Approach 817  The process is based on an agreed-upon approach to this assessment that is applied across 818  all of the identified risks in any project. By the nature of project risk, all risks may 819  be assessed according to probability of occurrence and impact on individual objectives 820  should the risk occur. Other factors may be considered in determining the importance of 821  a risk as follows: 822     •  Urgency (proximity). Risks requiring near term responses may be considered 823  more urgent to address. Indicators of urgency can include the lead time necessary to execute 824  a risk response and the clarity of symptoms and warning signs that may trigger the response. 825     •  Manageability. Some risks are not manageable and it would be a waste 826  of resources to attempt to address them. The project sponsor may examine these and decide 827  to: 828        •  Go forward, perhaps establishing a contingency reserve. 829        •  Stop or re-scope the project because these risks pose an unmanageable threat 830  or an unmissable opportunity with high probability and consequences. 831        •  Inform the customer of the risks and ask for a decision from that point of view. 832     •  Impact external to the project. A risk may increase in importance if 833  it affects the enterprise outside of the project. 834  

835

 

6.2.3 Use Agreed-Upon Definitions of Risk Terms 836  The risk assessment should be based on agreed-upon definitions of important terms, and

837  those definitions should be used consistently when assessing each risk. The use 838  of definitions, for example, of levels of probability and of impact on objectives, assists 839  the providers of the information in giving realistic assessments for each risk, 840  and facilitates the communication of the results to management and other stakeholders.

841 

6.2.4 Perform Iterative Qualitative Risk Analysis 842  The success of qualitative risk analysis is enhanced if the process is used periodically 843  throughout the project. It is impossible to know in advance all the risks that may occur 844  in a project, therefore risk identification and qualitative analysis of individual risks 845  should be repeated periodically. The frequency of this effort will be planned in the Plan 846  Risk Management Process, but may also depend on events within the project itself.

847

 

6.3 Tools and Techniques for the Perform Qualitative Risk Analysis Process

848  Tools and techniques used for assessing individual risks identify the risks that 849  are important to the project’s success. This is illustrated in Figure 6-2.

850

 

851  Figure 6-2. The Perform Qualitative Risk Analysis Process 852  

853 

6.3.1 Conduct Risk Assessment by Using Factors that Define Risks’ Importance 854  Qualitative risk analysis tools provide ways to distinguish those risks that are important 855  for response or further analysis from those that are not important. The criteria that make 856  a risk of interest to management are agreed upon in advance and implemented in the tools 857  used. Output from qualitative risk analysis tools includes a listing of risks in priority 858  order or in priority groups (e.g., high, moderate, and low). 859  The tools for qualitative risk analysis allow the organization or project stakeholders 860  to specify those levels or combinations of risk characteristics that make a particular risk

861  of interest for management. Most tools assess a risk’s importance from a combination 862  of probability of occurrence and degree of impact on objectives.

863

 

6.3.2 Collect and Evaluate Data 864  Assessment of individual risks is based on information collected about them. Hence, 865  data collection and evaluation tools, including interviews, workshops, and references 866  to databases of prior projects, require management support and attention. It is important 867  to protect against bias in data gathering, which is important when relying on expert judgment 868  for the information.

869

 

6.3.3 Prioritize Risks by Probability and Impact on Specific Objectives 870  Some tools permit distinguishing a risk’s priority by the affected objective. This capability, 871  which facilitates providing a list of risks that are important for any specific objective 872  of interest to management, is useful since it is common for risks to have uneven impacts 873  on various project objectives.

874

 

6.3.4 Prioritize Risks by Probability and Impact on Overall Project 875  There are reasons for constructing a measure of a specific risk’s importance to the 876  entire project as contrasted with its importance to specific objectives. A common reason 877  is for ease of communication with management and other stakeholders. When a single 878  risk prioritization index is needed, the organization should be explicit about how that 879  index is created, which is usually by reflecting the organization’s preference among 880  the objectives. The technique for creating the overall risk priority measure should 881  be documented in the Plan Risk Management process.

882

 

6.3.5 Categorizing Risk Causes 883  Categorizing risks appropriately may lead to improved analysis of the probability 884  and magnitude of project risk and to effective responses. Understanding the relationships 885  between risks may provide a better understanding of the possibility and magnitude of project 886  risk than if risks are only considered as separate and independent events. Identifying 887  common root causes of a group of risks, for instance, may reveal both the magnitude of 888  the risk event for the group as a whole along with effective strategies that might 889  address several risks simultaneously. Alternatively, some risks may be linked with others 890  in a causal chain, and understanding the chain of risks may lead to a better understanding 891  of the implication of risk for the project. Identifying risks that can occur at the same 892  time or using the same resources for recovery might provide a realistic picture of problems 893  of risk mitigation using scarce resources. 894  Combining the results of the Perform Qualitative Risk Analysis process with the risk 895  breakdown structure (see Identify Risks, Chapter 5) can show clusters of priority risks 896  arising from specific sources. A combination of the risk analysis information with the 897  work breakdown structure (WBS) can show which areas of the project exhibit the most 898  risk. Assessing the high-priority risks’ impact on one objective, say the schedule, 899  may indicate which activities to address to reduce that objective’s uncertainty. All 900  of these approaches can contribute to the realism and usefulness of the qualitative 901  risk analysis.

902 

6.4 Documenting the Results of the Perform Qualitative Risk

Analysis Process 903  Qualitative risk analysis structures the list of undifferentiated risks (see Identify 904  Risks, Chapter 5) into categories of priority, usually based on the risk’s probability 905  of occurring and the impact on objectives, if it were to occur, for different project objectives 906  or the whole project. Each identified risk is assigned a priority, perhaps by objective 907  or for the entire project. This information is usually stored in the risk register that 908  is easy to use and update with new information. The risk register list of prioritized risks 909  is posted to the project participants who are responsible for further analysis or action 910  to improve the project plan. Risks that are judged to have high priority are segregated 911  for further analysis and response planning and are generally monitored frequently. Risks 912  of low priority to the project may be placed on a watch list and are reviewed less often 913  for changes in their status.

914

 

Chapter 7 Perform Quantitative Risk Analysis

915

 

7.1 Purpose and Objectives of the Perform Quantitative Risk Analysis Process

916  The Perform Quantitative Risk Analysis process provides a numerical estimate of the 917  overall effect of risk on the objectives of the project, based on current plans 918  and information, when considering risks simultaneously. Results from this type of analysis 919  can be used to evaluate the likelihood of success in achieving project objectives and 920  to calibrate contingency reserves, usually for time and cost that are appropriate to both 921  the risks and the risk tolerance of project stakeholders. 922  It is generally accepted that analyzing uncertainty in the project using quantitative 923  techniques such as Monte Carlo simulation may provide more realism in the estimate of 924  the overall project cost or schedule than the traditional approach which assumes that 925  the activity durations or line-item cost estimates are known with certainty. However 926  it should be recognized that quantitative risk analysis is not always required 927  or appropriate for all projects. For example, qualitative risk analysis may provide 928  enough information for development of effective risk responses, especially for smaller 929  projects. Hence, during the Plan Risk Management process, the benefits of quantitative 930  risk analysis should be weighed against the effort required to ensure that the additional 931  insights and value justify the additional effort. 932  Partial risk analyses, such as qualitative risk analysis, aim at prioritizing individual 933  risks viewed one at a time and hence cannot produce measures of overall project risk when 934  all risks are considered simultaneously. Calculating estimates of overall project risk 935  is the focus of the Perform Quantitative Risk Analysis process. 936  Specific project risks are usually best understood and quantified at a detailed level such 937  as the line-item cost or schedule activity level. By contrast, project objectives such 938  as achievement of the project’s budget or the schedule are specified at a higher level, 939  often at the level of the total project. An overall risk analysis, such as one that 940  uses quantitative techniques, estimates the implication of all quantified risks on 941  project objectives. The implementation of overall risk analysis using quantitative 942  methods requires: 943     •  Completely and accurately representing the project objectives built up from 944  individual project elements. Examples of these representations include the project schedule 945  or cost estimate. 946     •  Identifying risks on individual project elements such as schedule activities 947

 or line-item costs at a level of detail that lends itself to specific assessment 948  of individual risks. 949     •  Including generic risks that have a broader effect than individual project elements. 950     •  Applying a quantitative method (such as Monte Carlo simulation or decision 951  tree analysis) that incorporates multiple risks simultaneously in determining the overall 952  project objective. 953  Results of the quantitative analysis will be compared to the project plan (baseline 954  or current) to give management an estimate of the overall project risk and will answer 955  important questions such as: 956     •  What is the probability of meeting the project’s objectives? 957     •  How much contingency reserve (e.g., reserves or buffers of scope, time, resources, 958  and cost) is needed to provide the organization with the level of certainty it may require 959  based upon its risk tolerance? 960     •  What are those parts of the project, such as line-item costs or schedule activities, 961  which contribute the most risk when all risks are considered simultaneously? 962     •  Which individual risks contribute the most to overall project risk? 963   964  Estimating overall project risk using quantitative methods helps distinguish those projects 965  where quantified risks threaten objectives beyond the tolerance of the stakeholders from 966  those for which the objectives are within acceptable tolerances even when risk 967  is considered. The former may be targeted for vigorous risk responses aimed at protecting 968  those objectives most important to the stakeholders. 969  A high-level comparison of quantitative and qualitative risk analysis processes is presented 970  in Figure 7-1.

971

 

972  Figure 7-1. Comparison of Qualitative and Quantitative Approaches 973  

974

 

7.2 Critical Success Factors for the Perform Quantitative Risk Analysis Process

975  Success in achieving the objectives of quantitative risk Aanalysis depends explicitly on 976  at least the factors described in 7.2.1 through 7.2.7.

977 

7.2.1 Prior Risk Identification and Qualitative Risk Analysis 978  The Perform Quantitative Risk Analysis process occurs after the Identify Risks and

979  Perform Qualitative Risk Analysis processes have been completed. Reference to a prioritized 980  list of identified risks ensures that the Perform Quantitative Risk Analysis process 981  will consider all significant risks when analyzing their effect quantitatively.

982 

7.2.2 Appropriate Project Model 983  An appropriate model of the project should be used as the basis for quantitative 984  risk analysis. Project models most frequently used in quantitative risk analysis include 985  the project schedule (for time), line-item cost estimates (for cost), decision tree 986  (for decisions in the face of uncertainty) and other total-project models. Quantitative 987  risk analysis is especially sensitive to the completeness and correctness of the model 988  of the project that is used.

989

 

7.2.3 Commitment to Collecting High Quality Risk Data 990  Often high-quality data about risks are not available in any historic database and must 991  be gathered by interviews, workshops, and other means using expert judgment of those 992  present. Collection of risk data requires resources and time taken from other work as well 993  as management support.

994 

7.2.4 Unbiased Data 995  Success in gathering qualitative risk analysis data requires the ability to recognize 996  when biases occur and combating that bias or developing other unbiased sources of the 997  data. Bias in risk data can occur for many reasons, but two common sources of bias 998  are cognitive bias and motivational bias.

999 

7.2.5 Overall Project Risk Derived from Individual Risks 1000  The Perform Quantitative Risk Analysis process is based upon a methodology that correctly 1001  derives the overall project risk from the individual risks. In risk analysis of cost 1002  and schedule, for example, an appropriate method is Monte Carlo simulation. In each of 1003  these methods, the risks are specified at the level of the detailed tasks or line-item 1004  costs and the model of the project such as the schedule or the cost estimate derives 1005  the implication for the entire project by combining those risks. A decision tree is 1006  an appropriate method for making decisions when future events are not certain, using 1007  the probability and impact of all risks, and combining their effect to derive an overall 1008  project measure such as value or cost.

1009 

7.2.6 Interrelationships Between Risks in Quantitative Risk Analysis 1010  Attention should be given to the possibility that the individual risks in the project model 1011  are related to each other. For example, several risks may have a common root cause and 1012  hence are likely to occur together. This possibility is sometimes addressed by correlating 1013  the risks that are related, ensuring that they generally occur together during the 1014  analysis. Another common way to represent the risks which occur together is by using the 1015  risk register listing of the risk or root cause and attaching it to several project elements 1016  such as schedule activities or cost elements. When the risk occurs the affected elements 1017  will all experience the risks’ effect together.

1018

 

7.3 Tools and Techniques for the Perform Quantitative Risk

Analysis Process 1019  Tools and techniques used appropriately for quantitative risk analysis have 1020  several characteristics, as follows:

1021 

7.3.1 Comprehensive Risk Representation 1022     Risk models permit representation of many if not all of the risks 1023  that operate on an objective simultaneously. They also permit the representation of 1024  both opportunities and threats to the project’s objectives. 1025     7.3.2 Risk Impact Calculation 1026  Impact models facilitate the correct calculation of the implication of combining many 1027  risks, which are typically identified and quantified at a level of detail below the 1028  total project, for the project objectives, which are typically described at the level of 1029  the total project.

1030

 

7.3.3 Quantitative Method Appropriate to Analyzing Uncertainty 1031  Probability models use a quantitative method that is appropriate to analyze uncertainty 1032  because risk is an uncertain event or condition. Specifically, the methods must be able 1033  to handle the way uncertainty is represented, predominantly as probability of an 1034  event’s happening or as probability distributions for a range of outcomes. A good example 1035  of this is the use of Monte Carlo simulation tools that permit the combination 1036  of probability distributions of line-item costs or schedule activity durations, many 1037  of which are uncertain.

1038

 

7.3.4 Data Gathering Tools 1039  Data gathering tools used in this process include assessment of historical data 1040  and workshops, interviews, or questionnaires to gather quantified information— for example, 1041  on the probability of a risk occurring, a probability distribution of its potential impacts 1042  on cost or time, or relationships such as correlation between risks.

1043 

7.3.5 Effective Presentation of Quantitative Analysis Results 1044  Results from the quantitative tools are generally not available in standard deterministic 1045  project management methods such as project scheduling or cost estimating. Good examples 1046  of these are the probability distribution of project completion dates or total costs and 1047  the expected value of a project decision. These results, when all risks are 1048  considered simultaneously, include the following: 1049     •  Probability of achieving the project objective such as finishing on time or on budget. 1050     •  Amount of contingency reserve in cost, time, or resources needed to provide 1051  the required level of confidence. 1052     •  Identity or location within the project model of the most important risks. A 1053  good example of this is a sensitivity analysis in a cost risk analysis or a criticality 1054  analysis in a schedule risk analysis. 1055  The elements of a quantitative risk analysis are illustrated in Figure 7-2.

 

1056

1057  Figure 7-2. Structure of a Quantitative Risk Analysis 1058  

1059 

7.3.6 Iterative Quantitative Risk Analysis 1060  The success of the Perform Quantitative Risk Analysis process is enhanced if the process 1061  is used periodically throughout the project. It is impossible to know in advance all of 1062  the risks that may occur in a project. Often quantitative risk analysis must be repeated 1063  as the project proceeds. The frequency of this effort will be determined during the Plan 1064  Risk Management process but will also depend on events within the project itself (see Monitor 1065  and Control Risks, chapter 9).

1066 

7.3.7 Information for Response Planning 1067  Overall project contingency reserve in time and cost must be reflected in the project’s 1068  schedule and budget. Quantitative risk analysis provides information that may be used 1069  to modify the project plan. If the overall risk to time and cost indicates that 1070  an adjustment in scope is needed, the scope changes will be agreed upon and documented and 1071  a new quantitative risk analysis will be carried out to reflect the new aspects of 1072  the project.

1073

 

7.4 Documenting the Results of the Perform Quantitative Risk Analysis Process

1074  The contingency reserve calculated in quantitative project cost and schedule risk analysis 1075  is incorporated, respectively, into the cost estimate and the schedule to establish 1076  a prudent target and a realistic expectation for the project. Contingency reserves may also 1077  be established to provide for the capture of opportunities that are judged to be priority 1078  for the project. If the contingency reserve required exceeds the time or resources 1079  available, changes in the project scope and plan may result. 1080  Also, the results of the analysis may provide more or less urgency to risk responding 1081  (see Plan Risk Responses, chapter 8) depending on the probability of achieving the

1082  plan’s results or the amount of contingency reserve required to provide the necessary level 1083  of confidence. The results of a quantitative risk analysis are recorded and passed on to 1084  the project management for any further implied actions.

1085

 

Chapter 8 Plan Risk Responses 1086  The Plan Risk Responses process determines effective response actions that are appropriate 1087  to the priority of the individual risks and to the overall project risk. It takes into 1088  account the stakeholders’ risk attitudes and the rules specified in the Risk Management 1089  Plan, as well as the constraints and assumptions determined as the risks were identified 1090  and analyzed.

1091

 

8.1 Purpose and Objectives of the Plan Risk Responses Process 1092  The objective of the Plan Risk Responses process is to determine the set of actions which 1093  most enhance the chances of project success while complying with applicable organizational 1094  and project constraints. 1095  Once risks have been identified, analyzed, and prioritized, plans should be developed 1096  for addressing every risk the project team considers to be sufficiently important, 1097  either because of the threat it poses to the project objectives or the opportunity 1098  it offers. The planning entails agreeing upon the actions to be taken and the potential 1099  changes to budget, schedule, resources, and scope which these actions might cause. 1100  Contingent risk response actions need to be executed at the optimum time. For this reason, 1101  the response specification for each risk should include a description of any corresponding 1102  trigger conditions. 1103  The responsibility for monitoring the project conditions and implementing the corresponding 1104  actions should be clearly assigned. Every risk should have been allocated to a risk owner 1105  as part of the Identify Risks process, and each of the corresponding risk responses should 1106  now be assigned to a specific risk action owner. The risk owner is responsible for ensuring 1107  that the risk response is effective and for planning additional risk responses if required, 1108  whereas the risk action owner is responsible for ensuring that the agreed-upon risk responses 1109  are carried out as planned, in a timely manner. The role of the risk owner and that of 1110  the risk action owner may be assigned to a single person. 1111  Responses, when implemented, can have potential effects on the project objectives and, 1112  as such can generate additional risks. These are known as secondary risks and have to 1113  be analyzed and planned for in the same way as those risks which were initially identified. 1114  It is never feasible or even desirable to eliminate all threats from a project. Similarly, 1115  there is also a limit to the extent to which opportunities can be proactively managed. 1116  In part because of these limitations, there may be residual risks that will remain after 1117  the responses have been implemented. These residual risks should be clearly identified, 1118  analyzed, documented, and communicated to all relevant stakeholders. 1119  All the approved, unconditional actions arising from risk response planning should 1120  be integrated into the project management plan in order to ensure that they are carried 1121  out as part of normal project implementation. The corresponding organizational and 1122  project management rules should also be invoked, including the following: 1123     •  Project change management and configuration control 1124     •  Project planning, budgeting, and scheduling rules 1125     •  Resource management 1126     •  Project communication planning.

1127 

8.2 Critical Success Factors for the Plan Risk Responses Process 1128  A range of factors are important for the success of the Plan Risk Responses process. These 1129  are described in Sections 8.2.1 through 8.2.8. and shown in Figure 8-1.

1130

 

1131  Figure 8-1. Main Considerations for Risk Response Planning 1132  

1133

 

8.2.1 Communicate 1134  Communication with the various stakeholders should be maintained in an open and appropriate 1135  manner. The resulting plans should be disseminated and approval obtained in order to ensure 1136  full acceptance by all stakeholders. 1137  In addition, if organizational causes of risks, such as culture or attitudes, are present, 1138  they should be addressed openly. This may require involving the organization’s management 1139  or other stakeholders.

1140 

8.2.2 Clearly Define Risk-Related Roles and Responsibilities 1141  The risk response success will be dependent upon the full support and involvement of 1142  the project team and allied stakeholders. The key roles for Project Risk Management are 1143  those of risk owner and risk action owner. A single risk owner should be assigned to 1144  every identified risk, and each agreed-upon risk response should have a single risk 1145  action owner. The people with the corresponding responsibilities should be aware of what 1146  is expected of them, and the other project stakeholders should understand and accept 1147  the needs and authority of these roles. 1148     Management may take ownership of risks with political, organizational 1149  or people-related causes. In addition, senior management should approve and track 1150  any risk-related contingency reserves.

1151 

8.2.3 Specify Timing of Risk Responses 1152  Agreed-upon responses should be integrated into the project management plan and will therefore 1153  be scheduled and assigned for execution. The responses that depend on uncertain conditions 1154  should also be monitored so as to be performed if the conditions warrant them.

1155 

8.2.4 Provide Resources, Budget, and Schedule for Responses

1156  Each response should be planned in detail in accordance with the methodology of the project 1157  and integrated into the project management plan. This will entail estimating the resources, 1158  costs, and duration; updating the budget and schedule; obtaining approval from management; 1159  and obtaining commitment from the risk owners and risk action owners. Management’s role 1160  at this stage is vital for supporting the project manager in developing risk responses 1161  and authorizing the corresponding resources.

1162 

8.2.5 Address the Interaction of Risks and Responses 1163  Responses may be developed to address risks related either by cause and effect or by common 1164  root cause. Categorization, for example by using a risk breakdown structure, may help identify 1165  and address this situation. There is also a need during the Plan Risk Responses process 1166  to consider the risks aggregated during the Perform Quantitative Risk Analysis process 1167  (e.g., ten small, related risks combined may pose a big risk to the project), and then 1168  to develop generic responses where possible. Another interaction effect that may occur 1169  is when one risk, if it occurs, may lead to others in a chain of implication. 1170  Deciding on the response strategy may require a selection of the best compromise, since 1171  some proposed responses may be mutually exclusive or counterproductive. For example mitigating 1172  a threat to time could cost money, thereby increasing pressure on the budget. Risk 1173  response planning also needs to take a holistic view of all proposed responses, and make 1174  sure they are coherent. 1175  The challenge therefore in planning responses to risks is the need to control the potential 1176  effects of the strategy developed for treating the original risk. If this is overlooked, 1177  the total level of threat in a project can actually increase, or the potential 1178  for opportunities can be compromised.

1179 

8.2.6 Ensure Appropriate, Timely, Effective, and Agreed-Upon Responses 1180  In general, responses should be appropriate, cost-effective, actionable, achievable, 1181  agreed upon, assigned, and accepted. Any proposed risk response plan needs to be assessed 1182  against the following criteria: 1183     •  Consistency with organizational values, project objectives, and stakeholder expectations 1184     •  Technical feasibility 1185     •  Ability of the project team or outside risk action owners to carry out 1186  the corresponding actions 1187     •  Balance between overall impact of the response on the project objectives and 1188  the improvement in the risk profile of the project.

1189

 

8.2.7 Address Both Threats and Opportunities 1190  Risk response planning should combine responses that address the threats as well as those 1191  that provide for opportunities into a single, integrated plan. If either threats 1192  or opportunities are not fully addressed, the combined set of response strategies will 1193  be incomplete and may even be invalid.

1194

 

8.2.8 Develop Strategies before Tactical Responses 1195  Risk response planning should be carried out in an open-minded manner rather than adopting 1196  the first response that seems to be feasible. The responses should be planned at a 1197  general, strategic level and the strategy validated and agreed upon, prior to developing 1198  the detailed tactical approach. 1199  Once the responses have been planned at a strategic level, they should be expanded

1200  into actions at the tactical level and integrated into the Project Plan (e.g., schedule, 1201  budget, and resource assignments). This activity may generate additional secondary risks, 1202  which will need to be addressed at this time.

1203

 

8.3 Risk Response Strategies 1204  The project manager must develop risk response strategies for individual risks, sets 1205  of risks, and project-level risks. An overview of the steps in arriving at a complete set 1206  of response plans is given in Figure 8-2. 1207  The affected stakeholders should be involved in determining the strategies. Once 1208  the strategies have been selected, the project sponsor or owner of the business case 1209  must approve them. There are four strategies to address individual risks for threats 1210  and opportunities, as described in 8.3.1 through 8.3.4 (see also Fig. 8-2).

1211 

8.3.1 Avoid a Threat or Exploit an Opportunity 1212  This strategy involves taking the actions required to ensure that a threat either cannot 1213  occur or can have no effect on the project or, for an opportunity, to ensure that it 1214  will occur and that the project will be able to take advantage of it.

1215

 

8.3.2 Transfer a Threat or Share an Opportunity 1216  This strategy entails entering into an agreement with a third party that is better positioned 1217  to address the threat or opportunity.

1218 

8.3.3 Mitigate a Threat or Enhance an Opportunity 1219  Mitigation and enhancement are the most widely applicable and widely used response strategies. 1220  Here, the approach is to identify actions that will decrease the probability and/or 1221  the impact of a threat, and increase the probability and/or the impact of an opportunity.

1222

 

8.3.4 Accept a Threat or an Opportunity 1223  This strategy applies when the other strategies are not considered applicable or 1224  feasible. Acceptance entails taking no action unless the risk actually occurs, in which 1225  case contingency or fallback plans may be developed ahead of time, to be implemented if 1226  the risk presents itself.

 

1227

1228  Figure 8-2. The Steps Involved in Planning Risk Responses

1229 

8.3.5 Applying Risk Response Strategies to Overall Project Risk 1230  In addition to responding to individual risks, the four risk response strategies can 1231  be applied to address overall project risk as follows: 1232     •  Cancel the project, as a last resort, if the overall level of risk remains unacceptable. 1233     •  Set up a business structure in which the customer and the supplier share the risk. 1234     •  Re-plan the project or change the scope and boundaries of the project, for example, 1235  by modifying the project priority, resource allocations, delivery calendar, etc. 1236     •  Pursue the project despite a risk exposure that exceeds the desired level. 1237  The corresponding actions can be unconditional (i.e., integrated into the project management 1238  plan) or conditional on a trigger condition and predefined as a contingency response strategy.

1239

 

8.4 Tools and Techniques for the Plan Risk Responses Process 1240  There are four categories of tools and techniques, as follows: 1241     •  Creativity tools to identify all potential responses 1242     •  Decision-support tools for determining the optimal potential response 1243     •  Strategy implementation techniques designed to turn a strategy into action

1244     •  Tools to transfer control to the Monitor and Control Risks process. 1245  These categories of tools can be used respectively to identify potential responses, select 1246  the most appropriate, translate strategy into planning, and assign the corresponding actions.

1247 

8.4.1 Response Identification 1248  Risk response planning builds on the available information about the potential risks and 1249  aims to determine the optimal set of responses. For this reason, it should involve subject 1250  matter experts and employ creativity techniques in order to explore all of the options. 1251  Project planning and execution techniques are then required to evaluate the potential effects 1252  of the various options on the project’s objectives.

1253 

8.4.2 Response Selection 1254  Once the set of potential responses for the risks being addressed is established, 1255  decision-support techniques may need to be applied to select the best possible subset 1256  from these responses. The selection process should take into account the cost of 1257  the responses, the impact on the project objectives, uncertainty of outcomes and the 1258  possible secondary and residual risks. The risk identification, analysis, and response 1259  planning processes may then need to be applied to the resultant project management plan 1260  and the residual and secondary risks that it would entail. This iterative approach continues 1261  until all of the risks are deemed acceptable and the overall risk is within a predefined threshold.

1262 

8.4.3 Action Planning 1263  Project planning tools should be used to turn the chosen strategies into concrete actions 1264  and to integrate these into existing plans.

1265

 

8.4.4 Ownership and Responsibility Assignment 1266  The project manager needs to use resource assignment processes to ensure the availability 1267  of an owner for each risk and for each response action, so that each associated risk 1268  is managed and each corresponding risk response is carried out in a timely and effective manner. 1269  To enable risk monitoring to identify the imminence or actual occurrence of the corresponding 1270  event, every contingency response strategy should include a set of trigger conditions. 1271  The responsibility for monitoring these conditions should be clearly assigned in the Plan 1272  Risk Responses process and managed in the Monitor and Control Risks process. 1273  The strategic definition of risk responses should include measurable criteria for success 1274  of the response. Risk action owners should monitor their assigned risks, take agreed-upon 1275  actions as required, and provide the risk owners with relevant information on status 1276  or changes to the risk characteristics. Risk owners should assess the effectiveness of 1277  any actions, decide whether additional actions are required, and keep the project 1278  manager informed of the situation.

1279

 

8.5 Documenting the Results of the Plan Risk Responses Process 1280  Risk response planning is based on the information placed in the risk register during execution 1281  of the risk identification and analysis processes. The corresponding risk response information 1282  is often referred to as the risk response plan, although it may in fact be an integral part 1283  of the risk register.

1284 

8.5.1 Add Risk Responses to the Risk Register 1285  The response-related information for each risk should be recorded in the risk register 1286  and updated regularly. Any interested stakeholder should be able to rapidly access all 1287  the information required to verify their responsibilities and manage the risk in accordance 1288  with the risk response plan. The set of residual risks and their priorities should 1289  be clearly identified and recorded.

1290 

8.5.2 Add Corresponding Risk Responses to the Project Management Plan 1291  While developing the detailed set of risk responses, the project-related implications should 1292  be evaluated for inclusion in a modified project management plan. These include costs, 1293  resource assignments, scheduling details, and changes to project documentation. Until 1294  these changes are formally approved along with the additional risks that they may carry, 1295  risk response planning cannot be considered complete.

1296 

8.5.3 Review and Document Predicted Exposure 1297  Once the risk responses have been defined and integrated into the project management plan, 1298  the individual and overall residual risks related to this plan should be evaluated in order 1299  to determine whether additional response planning is required, as shown in Figure 8-2. 1300  This evaluation should provide an estimate of both the expected post-response situation 1301  and the potential improvement of the risk exposure assuming that the proposed responses 1302  are effective. The evaluation should be documented.

1303

 

Chapter 9 Monitor and Control Risks 1304  The effectiveness of Project Risk Management depends on the way the approved plans 1305  are carried out. These plans should be executed correctly, reviewed, and updated regularly. 1306  If this is carried out correctly, the invested effort will be rewarded and future projects 1307  will benefit from this project’s experience.

1308

 

9.1 Purpose and Objectives of the Monitor and Control Risks Process

1309  The primary objectives of risk monitoring and controlling are to track identified risks, 1310  monitor residual risks, identify new risks, execute risk response plans, and evaluate 1311  their effectiveness throughout the project life cycle. 1312  In addition to tracking and managing the risk response actions, the effectiveness of all 1313  of the Project Risk Management processes should be reviewed to provide improvements to 1314  the management of the current project as well as future ones. 1315  For each risk or set of risks for which a conditional response has been defined, 1316  the corresponding set of trigger conditions should have been specified. It is 1317  the responsibility of the action owner to ensure that these conditions are effectively 1318  monitored and that the corresponding actions are carried out as defined, in a timely manner. 1319  Once the Plan Risk Responses process is complete, all of the approved unconditional 1320  response actions should have been included and defined in the current project management 1321  plan. The first action of risk monitoring and controlling should be to check whether this 1322  is the case and take any appropriate action if necessary, such as invoking the change 1323  management process with respect to any missing actions. This will then ensure that 1324  the agreed-upon actions are carried out within the normal project execution framework. 1325  The risk owners and action owners need to be briefed on any changes that may affect

1326  their responsibilities. Effective communication needs to be maintained between them and 1327  the project manager so that the designated stakeholders accept accountability for controlling 1328  the potential outcomes of specific risks, apply their best efforts to track the associated 1329  trigger conditions and carry out the agreed-upon responses in a timely manner. 1330  In addition to the response actions and trigger conditions, a mechanism for measuring 1331  the effectiveness of the response is provided by the Plan Risk Responses process. The 1332  risk action owner should keep the risk owner aware of the status of the response actions 1333  so that the risk owner can decide when the risk has been effectively dealt with, or 1334  whether additional actions need to be planned and implemented. 1335  As the project progresses, additional information becomes available and the project environment 1336  may well change, as some risks occur, whether foreseen or unforeseen, and others become 1337  or cease to be relevant. The planning should therefore be kept current and the project 1338  manager should ensure that periodic risk reassessment, including risk identification, analysis, 1339  and response planning, is repeated at reasonable intervals without generating 1340  excessive administrative overhead. Typical reasons for risk reassessment are: 1341     •  Occurrence of a major unexpected risk 1342     •  Need to analyze a complex change request 1343     •  Phase end review 1344     •  Periodic review to ensure that the information remains current. 1345  In the event of major organizational changes, risk management planning may need to 1346  be revisited prior to reassessing the risks. 1347  In addition to the regular status reviews, an analysis should be performed periodically 1348  to determine strengths and weaknesses in handling risks within the project. These periodic 1349  audits aim to identify any barriers to effectiveness or keys to success that can lead 1350  to immediate improvements in the way in which the management of the current project addresses 1351  and deals with risk. 1352  At the end of the project, an integrated analysis of the risk management process should 1353  be carried out with a focus on long-term process improvements. This analysis consolidates 1354  the findings of the periodic audits to identify lessons that would be applicable in general 1355  to a large proportion of the organization’s projects in the future, such as appropriate 1356  levels of resources, adequate time for the analysis, use of tools, level of detail, etc. 1357  At project closure, the project manager should ensure that a description has been given 1358  of the closure of every risk in the risk register, for example: (a) did not occur; 1359  (b) occurred and contingency plan invoked; or (c) occurred and impact to the project 1360  scope (i.e., time, cost, quality). 1361  The output of the audit of the risk management process should be consolidated with 1362  specific information with respect to the project’s experience of risks, and any 1363  generally applicable guidelines for the organization should be highlighted and potential 1364  actions proposed for applying them. This can lead to an update to the corresponding 1365  organizational process assets. 1366  An overview of the steps involved in the Monitor and Control Risks process is given 1367  in Figure 9-1.

1368

 

1369  Figure 9-1. Schematic Representation of the Monitor and Control Risk Process 1370  

1371

 

9.2 Critical Success Factors for the Monitor and Control Risks Process

1372  Critical success factors relate to maintaining risk awareness throughout the project 1373  and include the characteristics and capabilities detailed in 9.2.1 through 9.2.3.

1374

 

9.2.1 Integrate Risk Monitoring and Control with Project Monitoring and Control 1375  From the start, the project management plan must include the actions required to monitor 1376  and control the effect of risk on the project. This should be set up early in the 1377  project planning cycle, and then adjusted in view of the risk response planning decisions 1378  adding, for example, the actions associated with monitoring specific conditions or metrics. 1379  Once risk response planning has been carried out, the project schedule should include all 1380  of the agreed-upon, response-related actions so that they can be carried out as a normal 1381  part of project execution and tracked accordingly.

1382

 

9.2.2 Continuously Monitor Risk Trigger Conditions 1383  Risk response planning will have defined a set of actions to be carried out as part of 1384  the project schedule as well as actions whose execution is dependent on a predefined 1385  trigger condition. Checking for specifically defined risks that may trigger conditional 1386  responses is the responsibility of the risk action owner, in close collaboration with 1387  the risk owner under the overall authority of the project manager.

1388

 

9.2.3 Maintain Risk Awareness 1389  Risk management reports must be a regular item on every status meeting agenda, to ensure 1390  that all team members remain aware of the importance of risk management and to ensure that 1391  it is fully integrated into all of the project management decisions.

1392  The project’s senior-level sponsor should require regular reports on the risks and 1393  the planned responses to ensure that stakeholders are aware of the importance of keeping 1394  a focus on risk. Sponsor feedback will also motivate the project team by demonstrating 1395  senior-level interest in project risk management. 1396  Stakeholders’ perception of the effectiveness of risk management is conditioned in part 1397  by the way in which risks are handled as they occur, and by the number or characteristics 1398  of such events. It is therefore crucial, whenever a risk occurs, that information about 1399  the event, as well as the progress and effectiveness of the responses, be communicated 1400  at regular intervals and in an honest manner adapted to the needs of each stakeholder. 1401  This should be supported by a well-executed communications plan.

1402

 

9.3 Tools and Techniques for the Monitor and Control Risks Process

1403  In addition to standard project management monitoring and control capabilities, 1404  risk monitoring and controlling requires a focus on the tools which will support its 1405  key success factors for tracking overall risk as well as individual risks.

1406 

9.3.1 Managing Contingency Reserves 1407  Reserves may have been allocated separately to cover time-related and cost-related 1408  risks. Techniques are required that allow the project manager to assess at any point in 1409  the project whether these provide the required level of confidence in the success of 1410  the project. 1411  Tools for managing time buffers must be closely integrated into the project’s scheduling 1412  techniques, whereas those for managing cost must be compatible with the financial practices. 1413  Tools are required to identify trends and forecast future outcomes to determine whether 1414  the reserves will remain sufficient. Tools are also required for tracking progress 1415  and spending in a consolidated manner.

1416 

9.3.2 Tracking Trigger Conditions 1417  Trigger conditions and the corresponding metrics are defined during the Plan Risk 1418  Responses process. Tools are required to evaluate and track these conditions against 1419  the project baseline or specified thresholds, based on actual status. They can be chosen 1420  to provide information on risks related to the deliverables, such as performance, as well 1421  as on project-related features such as time and cost.

1422 

9.3.3 Tracking Overall Risk 1423  Tools are required in order to determine, as the project progresses, whether the responses 1424  are having the expected effect on the project’s overall level of risk.

1425 

9.3.4 Tracking Compliance 1426  In order to monitor the quality of the execution of the risk-related plans and processes, 1427  a set of quality metrics must be tracked and recorded. These metrics will normally have 1428  been defined in the risk management plan.

1429 

9.4 Documenting the Results of the Monitor and Control Risks

Process 1430  The final control action of risk monitoring and controlling is to record actual data 1431  for future use. This should include all of the relevant information relating to 1432  risk management from start to finish of the project. The definition of what this 1433  information includes, as well as the storage mechanism, should have been specified in 1434  the risk management plan. 1435  The goal is to ensure that the significant risk management information is recorded 1436  to provide concrete data to the lessons learned process. Typical information includes 1437  the following: 1438     •  For each identified risk or type of risk, whether it occurred and, if so, when 1439  and how often. All relevant data should be recorded: impact, effectiveness of detection 1440  and of response, and any unplanned, additional actions that were carried out 1441     •  Effectiveness of avoidance and exploiting actions 1442     •  Effectiveness of risk transfer and sharing 1443     •  Unexpected risks which occurred and data about them. 1444   1445  Consolidated information should be provided on the level of effort expended. Costs 1446  and benefits to the project of risk management activities should also be provided. 1447  This information will need to be archived and indexed in a manner that will facilitate 1448  retrieval for easy review during the project, at closure, and for future projects, when 1449  the need arises.