11

PROJECT RISK MANAGEMENT

Project Risk Management includes the processes of conducting risk management planning, identification, analysis, response planning, response implementation, and monitoring risk on a project. The objectives of project risk management are to increase the probability and/or impact of positive risks and to decrease the probability and/or impact of negative risks, in order to optimize the chances of project success.

The Project Risk Management processes are:

11.1 Plan Risk Management—The process of defining how to conduct risk management activities for a project.

11.2 Identify Risks—The process of identifying individual project risks as well as sources of overall project risk, and documenting their characteristics.

11.3 Perform Qualitative Risk Analysis—The process of prioritizing individual project risks for further analysis or action by assessing their probability of occurrence and impact as well as other characteristics.

11.4 Perform Quantitative Risk Analysis—The process of numerically analyzing the combined effect of identified individual project risks and other sources of uncertainty on overall project objectives.

11.5 Plan Risk Responses—The process of developing options, selecting strategies, and agreeing on actions to address overall project risk exposure, as well as to treat individual project risks.

11.6 Implement Risk Responses—The process of implementing agreed-upon risk response plans.

11.7 Monitor Risks—The process of monitoring the implementation of agreed-upon risk response plans, tracking identified risks, identifying and analyzing new risks, and evaluating risk process effectiveness throughout the project.

Figure 11-1 provides an overview of the Project Risk Management processes. The Project Management Risk processes are presented as discrete processes with defined interfaces while, in practice, they overlap and interact in ways that cannot be completely detailed in this PMBOK® Guide.

KEY CONCEPTS FOR PROJECT RISK MANAGEMENT

All projects are risky since they are unique undertakings with varying degrees of complexity that aim to deliver benefits. They do this in a context of constraints and assumptions, while responding to stakeholder expectations that may be conflicting and changing. Organizations should choose to take project risk in a controlled and intentional manner in order to create value while balancing risk and reward.

Project Risk Management aims to identify and manage risks that are not addressed by the other project management processes. When unmanaged, these risks have the potential to cause the project to deviate from the plan and fail to achieve the defined project objectives. Consequently, the effectiveness of Project Risk Management is directly related to project success.

Risk exists at two levels within every project. Each project contains individual risks that can affect the achievement of project objectives. It is also important to consider the riskiness of the overall project, which arises from the combination of individual project risks and other sources of uncertainty. Project Risk Management processes address both levels of risk in projects, and these are defined as follows:

• Individual project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.
• Overall project risk is the effect of uncertainty on the project as a whole, arising from all sources of uncertainty including individual risks, representing the exposure of stakeholders to the implications of variations in project outcome, both positive and negative.

Individual project risks can have a positive or negative effect on project objectives if they occur. Project Risk Management aims to exploit or enhance positive risks (opportunities) while avoiding or mitigating negative risks (threats). Unmanaged threats may result in issues or problems such as delay, cost overruns, performance shortfall, or loss of reputation. Opportunities that are captured can lead to benefits such as reduced time and cost, improved performance, or reputation.

Overall project risk can also be positive or negative. Management of overall project risk aims to keep project risk exposure within an acceptable range by reducing drivers of negative variation, promoting drivers of positive variation, and maximizing the probability of achieving overall project objectives.

Risks will continue to emerge during the lifetime of the project, so Project Risk Management processes should be conducted iteratively. Risk is initially addressed during project planning by shaping the project strategy. Risk should also be monitored and managed as the project progresses to ensure that the project stays on track and emergent risks are addressed.

In order to manage risk effectively on a particular project, the project team needs to know what level of risk exposure is acceptable in pursuit of the project objectives. This is defined by measurable risk thresholds that reflect the risk appetite of the organization and project stakeholders. Risk thresholds express the degree of acceptable variation around a project objective. They are explicitly stated and communicated to the project team and reflected in the definitions of risk impact levels for the project.

TRENDS AND EMERGING PRACTICES IN PROJECT RISK MANAGEMENT

The focus of project risk management is broadening to ensure that all types of risk are considered, and that project risks are understood in a wider context. Trends and emerging practices for Project Risk Management include but are not limited to:

• Non-event risks. Most projects focus only on risks that are uncertain future events that may or may not occur. Examples of event-based risks include: a key seller may go out of business during the project, the customer may change the requirement after design is complete, or a subcontractor may propose enhancements to the standard operating processes.

There is an increasing recognition that non-event risks need to be identified and managed. There are two main types of non-event risks:

• Variability risk. Uncertainty exists about some key characteristics of a planned event or activity or decision. Examples of variability risks include: productivity may be above or below target, the number of errors found during testing may be higher or lower than expected, or unseasonal weather conditions may occur during the construction phase.
• Ambiguity risk. Uncertainty exists about what might happen in the future. Areas of the project where imperfect knowledge might affect the project's ability to achieve its objectives include: elements of the requirement or technical solution, future developments in regulatory frameworks, or inherent systemic complexity in the project.

Variability risks can be addressed using Monte Carlo analysis, with the range of variation reflected in probability distributions, followed by actions to reduce the spread of possible outcomes. Ambiguity risks are managed by defining those areas where there is a deficit of knowledge or understanding, then filling the gap by obtaining expert external input or benchmarking against best practices. Ambiguity is also addressed through incremental development, prototyping, or simulation.

• Project resilience. The existence of emergent risk is becoming clear, with a growing awareness of so-called unknowable-unknowns. These are risks that can only be recognized after they have occurred. Emergent risks can be tackled through developing project resilience. This requires each project to have:

• Right level of budget and schedule contingency for emergent risks, in addition to a specific risk budget for known risks;
• Flexible project processes that can cope with emergent risk while maintaining overall direction toward project goals, including strong change management;
• Empowered project team that has clear objectives and that is trusted to get the job done within agreed-upon limits;
• Frequent review of early warning signs to identify emergent risks as early as possible; and
• Clear input from stakeholders to clarify areas where the project scope or strategy can be adjusted in response to emergent risks.

• Integrated risk management. Projects exist in an organizational context, and they may form part of a program or portfolio. Risk exists at each of these levels, and risks should be owned and managed at the appropriate level. Some risks identified at higher levels will be delegated to the project team for management, and some project risks may be escalated to higher levels if they are best managed outside the project. A coordinated approach to enterprise-wide risk management ensures alignment and coherence in the way risk is managed across all levels. This builds risk efficiency into the structure of programs and portfolios, providing the greatest overall value for a given level of risk exposure.

TAILORING CONSIDERATIONS

Because each project is unique, it is necessary to tailor the way Project Risk Management processes are applied. Considerations for tailoring include but are not limited to:

• Project size. Does the project's size in terms of budget, duration, scope, or team size require a more detailed approach to risk management? Or is it small enough to justify a simplified risk process?
• Project complexity. Is a robust risk approach demanded by high levels of innovation, new technology, commercial arrangements, interfaces, or external dependencies that increase project complexity? Or is the project simple enough that a reduced risk process will suffice?
• Project importance. How strategically important is the project? Is the level of risk increased for this project because it aims to produce breakthrough opportunities, addresses significant blocks to organizational performance, or involves major product innovation?
• Development approach. Is this a waterfall project, where risk processes can be followed sequentially and iteratively, or does the project follow an agile approach where risk is addressed at the start of each iteration as well as during its execution?

Tailoring of the Project Risk Management processes to meet these considerations is part of the Plan Risk Management process, and the outcomes of tailoring decisions are recorded in the risk management plan.

CONSIDERATIONS FOR AGILE/ADAPTIVE ENVIRONMENTS

High-variability environments, by definition, incur more uncertainty and risk. To address this, projects managed using adaptive approaches make use of frequent reviews of incremental work products and cross-functional project teams to accelerate knowledge sharing and ensure that risk is understood and managed. Risk is considered when selecting the content of each iteration, and risks will also be identified, analyzed, and managed during each iteration.

Additionally, the requirements are kept as a living document that is updated regularly, and work may be reprioritized as the project progresses, based on an improved understanding of current risk exposure.

11.1 PLAN RISK MANAGEMENT

Plan Risk Management is the process of defining how to conduct risk management activities for a project. The key benefit of this process is that it ensures that the degree, type, and visibility of risk management are proportionate to both risks and the importance of the project to the organization and other stakeholders. This process is performed once or at predefined points in the project. The inputs, tools and techniques, and outputs of the process are depicted in Figure 11-2. Figure 11-3 depicts the data flow diagram for the process.

The Plan Risk Management process should begin when a project is conceived and should be completed early in the project. It may be necessary to revisit this process later in the project life cycle, for example at a major phase change, or if the project scope changes significantly, or if a subsequent review of risk management effectiveness determines that the Project Risk Management process requires modification.

11.1.1 PLAN RISK MANAGEMENT: INPUTS

11.1.1.1 PROJECT CHARTER

Described in Section 4.1.3.1. The project charter documents the high-level project description and boundaries, high-level requirements, and risks.

11.1.1.2 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. In planning Project Risk Management, all approved subsidiary management plans should be taken into consideration in order to make the risk management plan consistent with them. The methodology outlined in other project management plan components might influence the Plan Risk Management process.

11.1.1.3 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to the stakeholder register as described in Section 13.1.3.1. The stakeholder register contains details of the project's stakeholders and provides an overview of their project roles and their attitude toward risk on this project. This is useful in determining roles and responsibilities for managing risk on the project, as well as setting risk thresholds for the project.

11.1.1.4 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Plan Risk Management process include but are not limited to overall risk thresholds set by the organization or key stakeholders.

11.1.1.5 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Plan Risk Management process include but are not limited to:

• Organizational risk policy;
• Risk categories, possibly organized into a risk breakdown structure;
• Common definitions of risk concepts and terms;
• Risk statement formats;
• Templates for the risk management plan, risk register, and risk report;
• Roles and responsibilities;
• Authority levels for decision making; and
• Lessons learned repository from previous similar projects.

11.1.2 PLAN RISK MANAGEMENT: TOOLS AND TECHNIQUES

11.1.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with specialized knowledge or training in the following topics:

• Familiarity with the organization's approach to managing risk, including enterprise risk management where this is performed;
• Tailoring risk management to the specific needs of a project; and
• Types of risk that are likely to be encountered on projects in the same area.

11.1.2.2 DATA ANALYSIS

Data analysis techniques that can be used for this process includes but are not limited to a stakeholder analysis (Section 13.1.2.3) to determine the risk appetite of project stakeholders.

11.1.2.3 MEETINGS

The risk management plan may be developed as part of the project kick-off meeting or a specific planning meeting may be held. Attendees may include the project manager, selected project team members, key stakeholders, or team members who are responsible to manage the risk management process on the project. Others outside the organization may also be invited, as needed, including customers, sellers, and regulators. A skilled facilitator can help participants remain focused on the task, agree on key aspects of the risk approach, identify and overcome sources of bias, and resolve any disagreements that may arise.

Plans for conducting risk management activities are defined in these meetings and documented in the risk management plan (see Section 11.1.3.1).

11.1.3 PLAN RISK MANAGEMENT: OUTPUTS

11.1.3.1 RISK MANAGEMENT PLAN

The risk management plan is a component of the project management plan that describes how risk management activities will be structured and performed. The risk management plan may include some or all of the following elements:

• Risk strategy. Describes the general approach to managing risk on this project.
• Methodology. Defines the specific approaches, tools, and data sources that will be used to perform risk management on the project.
• Roles and responsibilities. Defines the lead, support, and risk management team members for each type of activity described in the risk management plan, and clarifies their responsibilities.
• Funding. Identifies the funds needed to perform activities related to Project Risk Management. Establishes protocols for the application of contingency and management reserves.
• Timing. Defines when and how often the Project Risk Management processes will be performed throughout the project life cycle, and establishes risk management activities for inclusion into the project schedule.
• Risk categories. Provide a means for grouping individual project risks. A common way to structure risk categories is with a risk breakdown structure (RBS), which is a hierarchical representation of potential sources of risk (see example in Figure 11-4). An RBS helps the project team consider the full range of sources from which individual project risks may arise. This can be useful when identifying risks or when categorizing identified risks. The organization may have a generic RBS to be used for all projects, or there may be several RBS frameworks for different types of projects, or the project may develop a tailored RBS. Where an RBS is not used, an organization may use a custom risk categorization framework, which may take the form of a simple list of categories or a structure based on project objectives.

• Stakeholder risk appetite. The risk appetites of key stakeholders on the project are recorded in the risk management plan, as they inform the details of the Plan Risk Management process. In particular, stakeholder risk appetite should be expressed as measurable risk thresholds around each project objective. These thresholds will determine the acceptable level of overall project risk exposure, and they are also used to inform the definitions of probability and impacts to be used when assessing and prioritizing individual project risks.
• Definitions of risk probability and impacts. Definitions of risk probability and impact levels are specific to the project context and reflect the risk appetite and thresholds of the organization and key stakeholders. The project may generate specific definitions of probability and impact levels or it may start with general definitions provided by the organization. The number of levels reflects the degree of detail required for the Project Risk Management process, with more levels used for a more detailed risk approach (typically five levels), and fewer for a simple process (usually three). Table 11-1 provides an example of definitions of probability and impacts against three project objectives. These scales can be used to evaluate both threats and opportunities by interpreting the impact definitions as negative for threats (delay, additional cost, and performance shortfall) and positive for opportunities (reduced time or cost, and performance enhancement).

• Probability and impact matrix. Described in Section 11.3.2.6. Prioritization rules may be specified by the organization in advance of the project and be included in organizational process assets, or they may be tailored to the specific project. Opportunities and threats are represented in a common probability and impact matrix using positive definitions of impact for opportunities and negative impact definitions for threats. Descriptive terms (such as very high, high, medium, low, and very low) or numeric values can be used for probability and impact. Where numeric values are used, these can be multiplied to give a probability-impact score for each risk, which allows the relative priority of individual risks to be evaluated within each priority level. An example probability and impact matrix is presented in Figure 11-5, which also shows a possible numeric risk scoring scheme.

• Reporting formats. Reporting formats define how the outcomes of the Project Risk Management process will be documented, analyzed, and communicated. This section of the risk management plan describes the content and format of the risk register and the risk report, as well as any other required outputs from the Project Risk Management processes.
• Tracking. Tracking documents how risk activities will be recorded and how risk management processes will be audited.

11.2 IDENTIFY RISKS

Identify Risks is the process of identifying individual project risks as well as sources of overall project risk, and documenting their characteristics. The key benefit of this process is the documentation of existing individual project risks and the sources of overall project risk. It also brings together information so the project team can respond appropriately to identified risks. This process is performed throughout the project. The inputs, tools and techniques, and outputs of the process are depicted in Figure 11-6. Figure 11-7 depicts the data flow diagram for the process.

Identify Risks considers both individual project risks and sources of overall project risk. Participants in risk identification activities may include the following: project manager, project team members, project risk specialist (if assigned), customers, subject matter experts from outside the project team, end users, other project managers, operations managers, stakeholders, and risk management experts within the organization. While these personnel are often key participants for risk identification, all project stakeholders should be encouraged to identify individual project risks. It is particularly important to involve the project team so they can develop and maintain a sense of ownership and responsibility for identified individual project risks, the level of overall project risk, and associated risk response actions.

When describing and recording individual project risks, a consistent format should be used for risk statements to ensure that each risk is understood clearly and unambiguously in order to support effective analysis and risk response development. Risk owners for individual project risks may be nominated as part of the Identify Risks process, and will be confirmed during the Perform Qualitative Risk Analysis process. Preliminary risk responses may also be identified and recorded and will be reviewed and confirmed as part of the Plan Risk Responses process.

Identify Risks is an iterative process, since new individual project risks may emerge as the project progresses through its life cycle and the level of overall project risk will also change. The frequency of iteration and participation in each risk identification cycle will vary by situation, and this will be defined in the risk management plan.

11.2.1 IDENTIFY RISKS: INPUTS

11.2.1.1 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Project management plan components include but are not limited to:

• Requirements management plan. Described in Section 5.1.3.2. The requirements management plan may indicate project objectives that are particularly at risk.
• Schedule management plan. Described in Section 6.1.3.1. The schedule management plan may identify areas that are subject to uncertainty or ambiguity.
• Cost management plan. Described in Section 7.1.3.1. The cost management plan may identify areas that are subject to uncertainty or ambiguity.
• Quality management plan. Described in Section 8.1.3.1. The quality management plan may identify areas that are subject to uncertainty or ambiguity, or where key assumptions have been made that might give rise to risk.
• Resource management plan. Described in Section 9.1.3.1. The resource management plan may identify areas that are subject to uncertainty or ambiguity, or where key assumptions have been made that might give rise to risk.
• Risk management plan. Described in Section 11.1.3.1. The risk management plan provides information on risk-related roles and responsibilities, indicates how risk management activities are included in the budget and schedule, and describes categories of risk, which may be expressed as a risk breakdown structure (Figure 11-4).
• Scope baseline. Described in Section 5.4.3.1. The scope baseline includes deliverables and criteria for their acceptance, some of which might give rise to risk. It also contains the WBS, which can be used as a framework to structure risk identification techniques.
• Schedule baseline. Described in Section 6.5.3.1. The schedule baseline may be reviewed to identify milestones and deliverable due dates that are subject to uncertainty or ambiguity, or where key assumptions have been made that might give rise to risk.
• Cost baseline. Described in Section 7.3.3.1. The cost baseline may be reviewed to identify costs or funding requirements that are subject to uncertainty or ambiguity, or where key assumptions have been made that might give rise to risk.

11.2.1.2 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to:

• Assumption log. Described in Section 4.1.3.2. Assumptions and constraints recorded in the assumption log may give rise to individual project risks and may also influence the level of overall project risk.
• Cost estimates. Described in Section 7.2.3.1. Cost estimates provide quantitative assessments of project costs, ideally expressed as a range, indicating the degree of risk, where a structured review of the documents may indicate that the current estimate is insufficient and poses a risk to the project.
• Duration estimates. Described in Section 6.4.3.1. Duration estimates provide quantitative assessments of project durations, ideally expressed as a range, indicating the degree of risk, where a structured review of the documents may indicate that the current estimate is insufficient and poses a risk to the project.
• Issue log. Described in Section 4.3.3.3. Issues recorded in the issue log may give rise to individual project risks and may also influence the level of overall project risk.
• Lessons learned register. Described in Section 4.4.3.1. Lessons learned about risk identified from earlier phases of the project are reviewed to determine whether similar risks might recur during the remainder of the project.
• Requirements documentation. Described in Section 5.2.3.1. Requirements documentation lists the project requirements and allows the team to identify those that could be at risk.
• Resource requirements. Described in Section 9.2.3.1. Resource requirements provide quantitative assessments of project resource requirements, ideally expressed as a range, indicating the degree of risk, where a structured review of the documents may indicate that the current estimate is insufficient and poses a risk to the project.
• Stakeholder register. Described in Section 13.1.3.1. The stakeholder register indicates which individuals or groups might participate in identifying risks to the project. It also details those individuals who are available to act as risk owners.

11.2.1.3 AGREEMENTS

Described in Section 12.2.3.2. If the project requires external procurement of resources, the agreements may have information such as milestone dates, contract type, acceptance criteria, and awards and penalties that can present threats or opportunities.

11.2.1.4 PROCUREMENT DOCUMENTATION

Described in Section 12.3.1.4. If the project requires external procurement of resources, the initial procurement documentation should be reviewed as procuring goods and services from outside the organization may increase or decrease overall project risk and may introduce additional individual project risks. As the procurement documentation is updated throughout the project, the most up to date documentation can be reviewed for risks. For example, seller performance reports, approved change requests and information on inspections.

11.2.1.5 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Identify Risks process include but are not limited to:

• Published material, including commercial risk databases or checklists,
• Academic studies,
• Benchmarking results, and
• Industry studies of similar projects.

11.2.1.6 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Identify Risks process include but are not limited to:

• Project files, including actual data,
• Organizational and project process controls,
• Risk statement formats, and
• Checklists from previous similar projects.

11.2.2 IDENTIFY RISKS: TOOLS AND TECHNIQUES

11.2.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with specialized knowledge of similar projects or business areas. Such experts should be identified by the project manager and invited to consider all aspects of individual project risks as well as sources of overall project risk, based on their previous experience and areas of expertise. The experts’ bias should be taken into account in this process.

11.2.2.2 DATA GATHERING

Data-gathering techniques that can be used for this process include but are not limited to:

• Brainstorming. The goal of brainstorming (see Section 4.1.2.2) is to obtain a comprehensive list of individual project risks and sources of overall project risk. The project team usually performs brainstorming, often with a multidisciplinary set of experts who are not part of the team. Ideas are generated under the guidance of a facilitator, either in a free-form brainstorm session or one that uses more structured techniques. Categories of risk, such as in a risk breakdown structure, can be used as a framework. Particular attention should be paid to ensuring that risks identified through brainstorming are clearly described, since the technique can result in ideas that are not fully formed.
• Checklists. A checklist is a list of items, actions, or points to be considered. It is often used as a reminder. Risk checklists are developed based on historical information and knowledge that has been accumulated from similar projects and from other sources of information. They are an effective way to capture lessons learned from similar completed projects, listing specific individual project risks that have occurred previously and that may be relevant to this project. The organization may maintain a risk checklist based on its own completed projects or may use generic risk checklists from the industry. While a checklist may be quick and simple to use, it is impossible to build an exhaustive one, and care should be taken to ensure the checklist is not used to avoid the effort of proper risk identification. The project team should also explore items that do not appear on the checklist. Additionally, the checklist should be reviewed from time to time to update new information as well as remove or archive obsolete information.
• Interviews. Individual project risks and sources of overall project risk can be identified by interviewing experienced project participants, stakeholders, and subject matter experts. Interviews (see Section 5.2.2.2) should be conducted in an environment of trust and confidentiality to encourage honest and unbiased contributions.

11.2.2.3 DATA ANALYSIS

Data analysis techniques that can be used for this process include but are not limited to:

• Root cause analysis. Root cause analysis (see Section 8.2.2.2) is typically used to discover the underlying causes that lead to a problem, and develop preventive action. It can be used to identify threats by starting with a problem statement (for example, the project might be delayed or over budget) and exploring which threats might result in that problem occurring. The same technique can be used to find opportunities by starting with a benefit statement (for example, early delivery or under budget) and exploring which opportunities might result in that benefit being realized.
• Assumption and constraint analysis. Every project and its project management plan are conceived and developed based on a set of assumptions and within a series of constraints. These are often already incorporated in the scope baseline and project estimates. Assumption and constraint analysis explores the validity of assumptions and constraints to determine which pose a risk to the project. Threats may be identified from the inaccuracy, instability, inconsistency, or incompleteness of assumptions. Constraints may give rise to opportunities through removing or relaxing a limiting factor that affects the execution of a project or process.
• SWOT analysis. This technique examines the project from each of the strengths, weaknesses, opportunities, and threats (SWOT) perspectives. For risk identification, it is used to increase the breadth of identified risks by including internally generated risks. The technique starts with the identification of strengths and weaknesses of the organization, focusing on either the project, organization, or the business area in general. SWOT analysis then identifies any opportunities for the project that may arise from strengths, and any threats resulting from weaknesses. The analysis also examines the degree to which organizational strengths may offset threats and determines if weaknesses might hinder opportunities.
• Document analysis. Described in Section 5.2.2.3. Risks may be identified from a structured review of project documents, including, but not limited to, plans, assumptions, constraints, previous project files, contracts, agreements, and technical documentation. Uncertainty or ambiguity in project documents, as well as inconsistencies within a document or between different documents, may be indicators of risk on the project.

11.2.2.4 INTERPERSONAL AND TEAM SKILLS

Interpersonal and team skills that can be used for this process includes but are not limited to facilitation (see Section 4.1.2.3). Facilitation improves the effectiveness of many of the techniques used to identify individual project risks and sources of overall project risk. A skilled facilitator can help participants remain focused on the risk identification task, follow the method associated with the technique accurately, ensure clear risk descriptions, identify and overcome sources of bias, and resolve any disagreements that may arise.

11.2.2.5 PROMPT LISTS

A prompt list is a predetermined list of risk categories that might give rise to individual project risks and that could also act as sources of overall project risk. The prompt list can be used as a framework to aid the project team in idea generation when using risk identification techniques. The risk categories in the lowest level of the risk breakdown structure can be used as a prompt list for individual project risks. Some common strategic frameworks are more suitable for identifying sources of overall project risk, for example PESTLE (political, economic, social, technological, legal, environmental), TECOP (technical, environmental, commercial, operational, political), or VUCA (volatility, uncertainty, complexity, ambiguity).

11.2.2.6 MEETINGS

To undertake risk identification, the project team may conduct a specialized meeting (often called a risk workshop). Most risk workshops include some form of brainstorming (see Section 4.1.2.2), but other risk identification techniques may be included depending on the level of the risk process defined in the risk management plan. Use of a skilled facilitator will increase the effectiveness of the meeting. It is also essential to ensure that the right people participate in the risk workshop. On larger projects, it may be appropriate to invite the project sponsor, subject matter experts, sellers, representatives of the customer, or other project stakeholders. Risk workshops for smaller projects may be restricted to a subset of the project team.

11.2.3 IDENTIFY RISKS: OUTPUTS

11.2.3.1 RISK REGISTER

The risk register captures details of identified individual project risks. The results of Perform Qualitative Risk Analysis, Plan Risk Responses, Implement Risk Responses, and Monitor Risks are recorded in the risk register as those processes are conducted throughout the project. The risk register may contain limited or extensive risk information depending on project variables such as size and complexity.

On completion of the Identify Risks process, the content of the risk register may include but is not limited to:

• List of identified risks. Each individual project risk is given a unique identifier in the risk register. Identified risks are described in as much detail as required to ensure unambiguous understanding. A structured risk statement may be used to distinguish risks from their cause(s) and their effect(s).
• Potential risk owners. Where a potential risk owner has been identified during the Identify Risks process, the risk owner is recorded in the risk register. This will be confirmed during the Perform Qualitative Risk Analysis process.
• List of potential risk responses. Where a potential risk response has been identified during the Identify Risks process, it is recorded in the risk register. This will be confirmed during the Plan Risk Responses process.

Additional data may be recorded for each identified risk, depending on the risk register format specified in the risk management plan. This may include: a short risk title, risk category, current risk status, one or more causes, one or more effects on objectives, risk triggers (events or conditions that indicate that a risk is about to occur), WBS reference of affected activities, and timing information (when was the risk identified, when might the risk occur, when might it no longer be relevant, and what is the deadline for taking action).

11.2.3.2 RISK REPORT

The risk report presents information on sources of overall project risk, together with summary information on identified individual project risks. The risk report is developed progressively throughout the Project Risk Management process. The results of Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, Plan Risk Responses, Implement Risk Responses, and Monitor Risks are also included in the risk report as those processes are completed. On completion of the Identify Risks process, information in the risk report may include but is not limited to:

• Sources of overall project risk, indicating which are the most important drivers of overall project risk exposure; and
• Summary information on identified individual project risks, such as number of identified threats and opportunities, distribution of risks across risk categories, metrics and trends, etc.

Additional information may be included in the risk report, depending on the reporting requirements specified in the risk management plan.

11.2.3.3 PROJECT DOCUMENTS UPDATES

Project documents that may be updated as a result of this process include but are not limited to:

• Assumption log. Described in Section 4.1.3.2. During the Identify Risks process, new assumptions may be made, new constraints may be identified, and existing assumptions or constraints may be revisited and changed. The assumption log should be updated with this new information.
• Issue log. Described in Section 4.3.3.3. The issue log should be updated to capture any new issues uncovered or changes in currently logged issues.
• Lessons learned register. Described in Section 4.4.3.1. The lessons learned register can be updated with information on techniques that were effective in identifying risks to improve performance in later phases or other projects.

11.3 PERFORM QUALITATIVE RISK ANALYSIS

Perform Qualitative Risk Analysis is the process of prioritizing individual project risks for further analysis or action by assessing their probability of occurrence and impact as well as other characteristics. The key benefit of this process is that it focuses efforts on high-priority risks. This process is performed throughout the project. The inputs, tools and techniques, and outputs of the process are depicted in Figure 11-8. Figure 11-9 depicts the data flow diagram for the process.

Perform Qualitative Risk Analysis assesses the priority of identified individual project risks using their probability of occurrence, the corresponding impact on project objectives if the risks occur, and other factors. Such assessments are subjective as they are based on perceptions of risk by the project team and other stakeholders. Effective assessment therefore requires explicit identification and management of the risk attitudes of key participants in the Perform Qualitative Risk Analysis process. Risk perception introduces bias into the assessment of identified risks, so attention should be paid to identifying bias and correcting for it. Where a facilitator is used to support the Perform Qualitative Risk Analysis process, addressing bias is a key part of the facilitator's role. An evaluation of the quality of the available information on individual project risks also helps to clarify the assessment of each risk's importance to the project.

Perform Qualitative Risk Analysis establishes the relative priorities of individual project risks for Plan Risk Responses. It identifies a risk owner for each risk who will take responsibility for planning an appropriate risk response and ensuring that it is implemented. Perform Qualitative Risk Analysis also lays the foundation for Perform Quantitative Risk Analysis if this process is required.

The Perform Qualitative Risk Analysis process is performed regularly throughout the project life cycle, as defined in the risk management plan. Often, in an agile development environment, the Perform Qualitative Risk Analysis process is conducted before the start of each iteration.

11.3.1 PERFORM QUALITATIVE RISK ANALYSIS: INPUTS

11.3.1.1 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Project management plan components include the risk management plan as described in Section 11.1.3.1. Of particular interest in this process are the roles and responsibilities for conducting risk management, budgets for risk management, schedule activities for risk management, risk categories (often defined in a risk breakdown structure), definitions of probability and impact, the probability and impact matrix, and stakeholders’ risk thresholds. These inputs are usually tailored to the project during the Plan Risk Management process. If they are not available, they may be developed during the Perform Qualitative Risk Analysis process and presented to the project sponsor for approval before use.

11.3.1.2 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to:

• Assumption log. Described in Section 4.1.3.2. The assumption log is used for identifying, managing, and monitoring key assumptions and constraints that may affect the project. These may inform the assessment of the priority of individual project risks.
• Risk register. Described in Section 11.2.3.1. The risk register contains details of each identified individual project risk that will be assessed during the Perform Qualitative Risk Analysis process.
• Stakeholder register. Described in Section 13.1.3.1. This includes details of project stakeholders who may be nominated as risk owners.

11.3.1.3 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence Perform Qualitative Risk Analysis include but are not limited to:

• Industry studies of similar projects, and
• Published material, including commercial risk databases or checklists.

11.3.1.4 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence Perform Qualitative Risk Analysis include but are not limited to information from similar completed projects.

11.3.2 PERFORM QUALITATIVE RISK ANALYSIS: TOOLS AND TECHNIQUES

11.3.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with specialized knowledge or training in the following topics:

• Previous similar projects, and
• Qualitative risk analysis.

Expert judgment is often obtained through facilitated risk workshops or interviews. The possibility of expert views being biased should be taken into account in this process.

11.3.2.2 DATA GATHERING

Data-gathering techniques that can be used for this process include but are not limited to interviews. Structured or semi-structured interviews (Section 5.2.2.2) can be used to assess the probability and impacts of individual project risks, as well as other factors. The interviewer should promote an environment of trust and confidentiality in the interview setting to encourage honest and unbiased assessments.

11.3.2.3 DATA ANALYSIS

Data analysis techniques that can be used during this process include but are not limited to:

• Risk data quality assessment. Risk data quality assessment evaluates the degree to which the data about individual project risks is accurate and reliable as a basis for qualitative risk analysis. The use of low-quality risk data may lead to a qualitative risk analysis that is of little use to the project. If data quality is unacceptable, it may be necessary to gather better data. Risk data quality may be assessed via a questionnaire measuring the project's stakeholder perceptions of various characteristics, which may include completeness, objectivity, relevancy, and timeliness. A weighted average of selected data quality characteristics can then be generated to give an overall quality score.
• Risk probability and impact assessment. Risk probability assessment considers the likelihood that a specific risk will occur. Risk impact assessment considers the potential effect on one or more project objectives such as schedule, cost, quality, or performance. Impacts will be negative for threats and positive for opportunities. Probability and impact are assessed for each identified individual project risk. Risks can be assessed in interviews or meetings with participants selected for their familiarity with the types of risk recorded in the risk register. Project team members and knowledgeable persons external to the project are included. The level of probability for each risk and its impact on each objective are evaluated during the interview or meeting. Differences in the levels of probability and impact perceived by stakeholders are to be expected, and such differences should be explored. Explanatory detail, including assumptions justifying the levels assigned, are also recorded. Risk probabilities and impacts are assessed using the definitions given in the risk management plan (see Table 11-1). Risks with low probability and impact may be included within the risk register as part of a watch list for future monitoring.
• Assessment of other risk parameters. The project team may consider other characteristics of risk (in addition to probability and impact) when prioritizing individual project risks for further analysis and action. These characteristics may include but are not limited to:

• Urgency. The period of time within which a response to the risk is to be implemented in order to be effective. A short period indicates high urgency.
• Proximity. The period of time before the risk might have an impact on one or more project objectives. A short period indicates high proximity.
• Dormancy. The period of time that may elapse after a risk has occurred before its impact is discovered. A short period indicates low dormancy.
• Manageability. The ease with which the risk owner (or owning organization) can manage the occurrence or impact of a risk. Where management is easy, manageability is high.
• Controllability. The degree to which the risk owner (or owning organization) is able to control the risk's outcome. Where the outcome can be easily controlled, controllability is high.
• Detectability. The ease with which the results of the risk occurring, or being about to occur, can be detected and recognized. Where the risk occurrence can be detected easily, detectability is high.
• Connectivity. The extent to which the risk is related to other individual project risks. Where a risk is connected to many other risks, connectivity is high.
• Strategic impact. The potential for the risk to have a positive or negative effect on the organization's strategic goals. Where the risk has a major effect on strategic goals, strategic impact is high.
• Propinquity. The degree to which a risk is perceived to matter by one or more stakeholders. Where a risk is perceived as very significant, propinquity is high.

The consideration of some of these characteristics can provide a more robust prioritization of risks than is possible by only assessing probability and impact.

11.3.2.4 INTERPERSONAL AND TEAM SKILLS

Interpersonal and team skills that can be used for this process include but are not limited to facilitation (see Section 4.1.2.3). Facilitation improves the effectiveness of the qualitative analysis of individual project risks. A skilled facilitator can help participants remain focused on the risk analysis task, follow the method associated with the technique accurately, reach consensus on assessments of probability and impacts, identify and overcome sources of bias, and resolve any disagreements that may arise.

11.3.2.5 RISK CATEGORIZATION

Risks to the project can be categorized by sources of risk (e.g., using the risk breakdown structure (RBS); see Figure 11-4), the area of the project affected (e.g., using the work breakdown structure (WBS); see Figures 5-12, 5-13, and 5-14), or other useful categories (e.g., project phase, project budget, and roles and responsibilities) to determine the areas of the project most exposed to the effects of uncertainty. Risks can also be categorized by common root causes. Risk categories that may be used for the project are defined in the risk management plan.

Grouping risks into categories can lead to the development of more effective risk responses by focusing attention and effort on the areas of highest risk exposure, or by developing generic risk responses to address groups of related risks.

11.3.2.6 DATA REPRESENTATION

Data representation techniques that can be used during this process include but are not limited to:

• Probability and impact matrix. A probability and impact matrix is a grid for mapping the probability of each risk occurrence and its impact on project objectives if that risk occurs. This matrix specifies combinations of probability and impact that allow individual project risks to be divided into priority groups (see Figure 11-5). Risks can be prioritized for further analysis and planning of risk responses based on their probability and impacts. The probability of occurrence for each individual project risk is assessed as well as its impact on one or more project objectives if it does occur, using definitions of probability and impact for the project as specified in the risk management plan. Individual project risks are assigned to a priority level based on the combination of their assessed probability and impact, using a probability and impact matrix.

An organization can assess a risk separately for each objective (e.g., cost, time, and scope) by having a separate probability and impact matrix for each. Alternatively, it may develop ways to determine one overall priority level for each risk, either by combining assessments for different objectives, or by taking the highest priority level regardless of which objective is affected.

• Hierarchical charts. Where risks have been categorized using more than two parameters, the probability and impact matrix cannot be used and other graphical representations are required. For example, a bubble chart displays three dimensions of data, where each risk is plotted as a disk (bubble), and the three parameters are represented by the x-axis value, the y-axis value, and the bubble size. An example bubble chart is shown in Figure 11-10, with detectability and proximity plotted on the x and y axes, and impact value represented by bubble size.

11.3.2.7 MEETINGS

To undertake qualitative risk analysis, the project team may conduct a specialized meeting (often called a risk workshop) dedicated to the discussion of identified individual project risks. The goals of this meeting include the review of previously identified risks, assessment of probability and impacts (and possibly other risk parameters), categorization, and prioritization. A risk owner, who will be responsible for planning an appropriate risk response and for reporting progress on managing the risk, will be allocated to each individual project risk as part of the Perform Qualitative Risk Analysis process. The meeting may start by reviewing and confirming the probability and impact scales to be used for the analysis. The meeting may also identify additional risks during the discussion, and these should be recorded for analysis. Use of a skilled facilitator will increase the effectiveness of the meeting.

11.3.3 PERFORM QUALITATIVE RISK ANALYSIS: OUTPUTS

11.3.3.1 PROJECT DOCUMENTS UPDATES

Project documents that may be updated as a result of carrying out this process include but are not limited to:

• Assumption log. Described in Section 4.1.3.2. During the Perform Qualitative Risk Analysis process, new assumptions may be made, new constraints may be identified, and existing assumptions or constraints may be revisited and changed. The assumption log should be updated with this new information.
• Issue log. Described in Section 4.3.3.3. The issue log should be updated to capture any new issues uncovered or changes in currently logged issues.
• Risk register. Described in Section 11.2.3.1. The risk register is updated with new information generated during the Perform Qualitative Risk Analysis process. Updates to the risk register may include assessments of probability and impacts for each individual project risk, its priority level or risk score, the nominated risk owner, risk urgency information or risk categorization, and a watch list for low-priority risks or risks requiring further analysis.
• Risk report. Described in Section 11.2.3.2. The risk report is updated to reflect the most important individual project risks (usually those with the highest probability and impact), as well as a prioritized list of all identified risks on the project and a summary conclusion.

11.4 PERFORM QUANTITATIVE RISK ANALYSIS

Perform Quantitative Risk Analysis is the process of numerically analyzing the combined effect of identified individual project risks and other sources of uncertainty on overall project objectives. The key benefit of this process is that it quantifies overall project risk exposure, and it can also provide additional quantitative risk information to support risk response planning. This process is not required for every project, but where it is used, it is performed throughout the project. The inputs and outputs of this process are depicted in Figure 11-11. Figure 11-12 depicts the data flow diagram for the process.

Perform Quantitative Risk Analysis is not required for all projects. Undertaking a robust analysis depends on the availability of high-quality data about individual project risks and other sources of uncertainty, as well as a sound underlying project baseline for scope, schedule, and cost. Quantitative risk analysis usually requires specialized risk software and expertise in the development and interpretation of risk models. It also consumes additional time and cost. The use of quantitative risk analysis for a project will be specified in the project's risk management plan. It is most likely appropriate for large or complex projects, strategically important projects, projects for which it is a contractual requirement, or projects in which a key stakeholder requires it. Quantitative risk analysis is the only reliable method to assess overall project risk through evaluating the aggregated effect on project outcomes of all individual project risks and other sources of uncertainty.

Perform Quantitative Risk Analysis uses information on individual project risks that have been assessed by the Perform Qualitative Risk Analysis process as having a significant potential to affect the project's objectives.

Outputs from Perform Quantitative Risk Analysis are used as inputs to the Plan Risk Responses process, particularly in recommending responses to the level of overall project risk and key individual risks. A quantitative risk analysis may also be undertaken following the Plan Risk Responses process, to determine the likely effectiveness of planned responses in reducing overall project risk exposure.

11.4.1 PERFORM QUANTITATIVE RISK ANALYSIS: INPUTS

11.4.1.1 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Project management plan components include but are not limited to:

• Risk management plan. Described in Section 11.1.3.1. The risk management plan specifies whether quantitative risk analysis is required for the project. It also details the resources available for the analysis and the expected frequency of analyses.
• Scope baseline. Described in Section 5.4.3.1. The scope baseline describes the starting point from which the effect of individual project risks and other sources of uncertainty are evaluated.
• Schedule baseline. Described in Section 6.5.3.1. The schedule baseline describes the starting point from which the effect of individual project risks and other sources of uncertainty can be evaluated.
• Cost baseline. Described in Section 7.3.3.1. The cost baseline describes the starting point from which the effect of individual project risks and other sources of uncertainty can be evaluated.

11.4.1.2 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to:

• Assumption log. Described in Section 4.1.3.2. Assumptions may form inputs to the quantitative risk analysis if they are assessed as posing a risk to project objectives. The effect of constraints may also be modeled during a quantitative risk analysis.
• Basis of estimates. Described in Sections 6.4.3.2 and 7.2.3.2. The basis of estimates used in the planning of the project may be reflected in variability modeled during a quantitative risk analysis process. This may include information on the estimate's purpose, classification, assumed accuracy, methodology, and source.
• Cost estimates. Described in Section 7.2.3.1. Cost estimates provide the starting point from which cost variability is evaluated.
• Cost forecasts. Described in Section 7.4.3.2. Forecasts such as the project's estimate to complete (ETC), estimate at completion (EAC), budget at completion (BAC), and to-complete performance index (TCPI) may be compared to the results of a quantitative cost risk analysis to determine the confidence level associated with achieving these targets.
• Duration estimates. Described in Section 6.4.3.1. Duration estimates provide the starting point from which schedule variability is evaluated.
• Milestone list. Described in Section 6.2.3.3. Significant events in the project define the schedule targets against which the results of a quantitative schedule risk analysis are compared, in order to determine the confidence level associated with achieving these targets.
• Resource requirements. Described in Section 9.2.3.1. Resource requirements provide the starting point from which variability is evaluated.
• Risk register. Described in Section 11.2.3.1. The risk register contains details of individual project risks to be used as input for quantitative risk analysis.
• Risk report. Described in Section 11.2.3.2. The risk report describes sources of overall project risk and the current overall project risk status.
• Schedule forecasts. Described in Section 6.6.3.2. Forecasts may be compared to the results of a quantitative schedule risk analysis to determine the confidence level associated with achieving these targets.

11.4.1.3 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Perform Quantitative Risk Analysis process include but are not limited to:

• Industry studies of similar projects, and
• Published material, including commercial risk databases or checklists.

11.4.1.4 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Perform Quantitative Risk Analysis process include information from similar completed projects.

11.4.2 PERFORM QUANTITATIVE RISK ANALYSIS: TOOLS AND TECHNIQUES

11.4.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with specialized knowledge or training in the following topics:

• Translating information on individual project risks and other sources of uncertainty into numeric inputs for the quantitative risk analysis model,
• Selecting the most appropriate representation of uncertainty to model particular risks or other sources of uncertainty,
• Modeling techniques that are appropriate in the context of the project,
• Identifying which tools would be most suitable for the selected modeling techniques, and
• Interpreting the outputs of quantitative risk analysis.

11.4.2.2 DATA GATHERING

Interviews (see Section 5.2.2.2) may be used to generate inputs for the quantitative risk analysis, drawing on inputs that include individual project risks and other sources of uncertainty. This is particularly useful where information is required from experts. The interviewer should promote an environment of trust and confidentiality during the interview to encourage honest and unbiased contributions.

11.4.2.3 INTERPERSONAL AND TEAM SKILLS

Interpersonal and team skills that can be used for this process include but are not limited to facilitation (see Section 4.1.2.3). A skilled facilitator is useful for gathering input data during a dedicated risk workshop involving project team members and other stakeholders. Facilitated workshops can improve effectiveness by establishing a clear understanding of the purpose of the workshop, building consensus among participants, ensuring continued focus on the task, and using creative approaches to deal with interpersonal conflict or sources of bias.

11.4.2.4 REPRESENTATIONS OF UNCERTAINTY

Quantitative risk analysis requires inputs to a quantitative risk analysis model that reflect individual project risks and other sources of uncertainty.

Where the duration, cost, or resource requirement for a planned activity is uncertain, the range of possible values can be represented in the model as a probability distribution. This may take several forms. The most commonly used are triangular, normal, lognormal, beta, uniform, or discrete distributions. Care should be taken when selecting an appropriate probability distribution to reflect the range of possible values for the planned activity.

Individual project risks may be covered by probability distributions. Alternatively, risks may be included in the model as probabilistic branches, where optional activities are added to the model to represent the time and/or cost impact of the risk should it occur, and the chance that these activities actually occur in a particular simulation run matches the risk's probability. Branches are most useful for risks that might occur independently of any planned activity. Where risks are related, for example, with a common cause or a logical dependency, correlation is used in the model to indicate this relationship.

Other sources of uncertainty may also be represented using branches to describe alternative paths through the project.

11.4.2.5 DATA ANALYSIS

Data analysis techniques that can be used during this process include but are not limited to:

• Simulation. Quantitative risk analysis uses a model that simulates the combined effects of individual project risks and other sources of uncertainty to evaluate their potential impact on achieving project objectives. Simulations are typically performed using a Monte Carlo analysis. When running a Monte Carlo analysis for cost risk, the simulation uses the project cost estimates. When running a Monte Carlo analysis for schedule risk, the schedule network diagram and duration estimates are used. An integrated quantitative cost-schedule risk analysis uses both inputs. The output is a quantitative risk analysis model.

Computer software is used to iterate the quantitative risk analysis model several thousand times. The input values (e.g., cost estimates, duration estimates, or occurrence of probabilistic branches) are chosen at random for each iteration. Outputs represent the range of possible outcomes for the project (e.g., project end date, project cost at completion). Typical outputs include a histogram presenting the number of iterations where a particular outcome resulted from the simulation, or a cumulative probability distribution (S-curve) representing the probability of achieving any particular outcome or less. An example S-curve from a Monte Carlo cost risk analysis is shown in Figure 11-13.

For a quantitative schedule risk analysis, it is also possible to conduct a criticality analysis that determines which elements of the risk model have the greatest effect on the project critical path. A criticality index is calculated for each element in the risk model, which gives the frequency with which that element appears on the critical path during the simulation, usually expressed as a percentage. The output from a criticality analysis allows the project team to focus risk response planning efforts on those activities with the highest potential effect on the overall schedule performance of the project.

• Sensitivity analysis. Sensitivity analysis helps to determine which individual project risks or other sources of uncertainty have the most potential impact on project outcomes. It correlates variations in project outcomes with variations in elements of the quantitative risk analysis model.

One typical display of sensitivity analysis is the tornado diagram, which presents the calculated correlation coefficient for each element of the quantitative risk analysis model that can influence the project outcome. This can include individual project risks, project activities with high degrees of variability, or specific sources of ambiguity. Items are ordered by descending strength of correlation, giving the typical tornado appearance. An example tornado diagram is shown in Figure 11-14.

• Decision tree analysis. Decision trees are used to support selection of the best of several alternative courses of action. Alternative paths through the project are shown in the decision tree using branches representing different decisions or events, each of which can have associated costs and related individual project risks (including both threats and opportunities). The end-points of branches in the decision tree represent the outcome from following that particular path, which can be negative or positive.

The decision tree is evaluated by calculating the expected monetary value of each branch, allowing the optimal path to be selected. An example decision tree is shown in Figure 11-15.

• Influence diagrams. Influence diagrams are graphical aids to decision making under uncertainty. An influence diagram represents a project or situation within the project as a set of entities, outcomes, and influences, together with the relationships and effects between them. Where an element in the influence diagram is uncertain as a result of the existence of individual project risks or other sources of uncertainty, this can be represented in the influence diagram using ranges or probability distributions. The influence diagram is then evaluated using a simulation technique, such as Monte Carlo analysis, to indicate which elements have the greatest influence on key outcomes. Outputs from an influence diagram are similar to other quantitative risk analysis methods, including S-curves and tornado diagrams.

11.4.3 PERFORM QUANTITATIVE RISK ANALYSIS: OUTPUTS

11.4.3.1 PROJECT DOCUMENTS UPDATES

Project documents that can be considered as outputs for this process include but are not limited to the risk report described in Section 11.2.3.2. The risk report will be updated to reflect the results of the quantitative risk analysis. This will typically include:

• Assessment of overall project risk exposure. Overall project risk is reflected in two key measures:

• Chances of project success, indicated by the probability that the project will achieve its key objectives (e.g., required end date or interim milestones, required cost target, etc.) given the identified individual project risks and other sources of uncertainty; and
• Degree of inherent variability remaining within the project at the time the analysis was conducted, indicated by the range of possible project outcomes.

• Detailed probabilistic analysis of the project. Key outputs from the quantitative risk analysis are presented, such as S-curves, tornado diagrams, and criticality analysis, together with a narrative interpretation of the results. Possible detailed results of a quantitative risk analysis may include:

• Amount of contingency reserve needed to provide a specified level of confidence;
• Identification of individual project risks or other sources of uncertainty that have the greatest effect on the project critical path; and
• Major drivers of overall project risk, with the greatest influence on uncertainty in project outcomes.

• Prioritized list of individual project risks. This list includes those individual project risks that pose the greatest threat or present the greatest opportunity to the project, as indicated by sensitivity analysis.
• Trends in quantitative risk analysis results. As the analysis is repeated at different times during the project life cycle, trends may become apparent that inform the planning of risk responses.
• Recommended risk responses. The risk report may present suggested responses to the level of overall project risk exposure or key individual project risks, based on the results of the quantitative risk analysis. These recommendations will form inputs to the Plan Risk Responses process.

11.5 PLAN RISK RESPONSES

Plan Risk Responses is the process of developing options, selecting strategies, and agreeing on actions to address overall project risk exposure, as well as to treat individual project risks. The key benefit of this process is that it identifies appropriate ways to address overall project risk and individual project risks. This process also allocates resources and inserts activities into project documents and the project management plan as needed. This process is performed throughout the project. The inputs, tools and techniques, and outputs of the process are depicted in Figure 11-16. Figure 11-17 depicts the data flow diagram for the process.

Effective and appropriate risk responses can minimize individual threats, maximize individual opportunities, and reduce overall project risk exposure. Unsuitable risk responses can have the converse effect. Once risks have been identified, analyzed, and prioritized, plans should be developed by the nominated risk owner for addressing every individual project risk the project team considers to be sufficiently important, either because of the threat it poses to the project objectives or the opportunity it offers. The project manager should also consider how to respond appropriately to the current level of overall project risk.

Risk responses should be appropriate for the significance of the risk, cost-effective in meeting the challenge, realistic within the project context, agreed upon by all parties involved, and owned by a responsible person. Selecting the optimal risk response from several options is often required. The strategy or mix of strategies most likely to be effective should be selected for each risk. Structured decision-making techniques may be used to choose the most appropriate response. For large or complex projects, it may be appropriate to use a mathematical optimization model or real options analysis as a basis for a more robust economic analysis of alternative risk response strategies.

Specific actions are developed to implement the agreed-upon risk response strategy, including primary and backup strategies, as necessary. A contingency plan (or fallback plan) can be developed for implementation if the selected strategy turns out not to be fully effective or if an accepted risk occurs. Secondary risks should also be identified. Secondary risks are risks that arise as a direct result of implementing a risk response. A contingency reserve is often allocated for time or cost. If developed, it may include identification of the conditions that trigger its use.

11.5.1 PLAN RISK RESPONSES: INPUTS

11.5.1.1 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Project management plan components include but are not limited to:

• Resource management plan. Described in Section 9.1.3.1. The resource management plan is used to help determine how resources allocated to agreed-upon risk responses will be coordinated with other project resources.
• Risk management plan. Described in Section 11.1.3.1. Risk management roles and responsibilities and risk thresholds are used in this process.
• Cost baseline. Described in Section 7.3.3.1. The cost baseline has information on the contingency fund that is allocated to respond to risks.

11.5.1.2 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to:

• Lessons learned register. Described in Section 4.4.3.1. Lessons learned about effective risk responses used in earlier phases of the project are reviewed to determine if similar responses might be useful during the remainder of the project.
• Project schedule. Described in Section 6.5.3.2. The schedule is used to determine how agreed-upon risk responses will be scheduled alongside other project activities.
• Project team assignments. Described in Section 9.3.3.2. Project team assignments can show the resources that can be allocated to agreed-upon risk responses.
• Resource calendars. Described in Section 9.2.1.2. Resource calendars identify when potential resources are available to be allocated to agreed-upon risk responses.
• Risk register. Described in Section 11.2.3.1. The risk register contains details of individual project risks that have been identified and prioritized, and for which risk responses are required. The priority level for each risk can help to guide the selection of appropriate risk responses. For example, high-priority threats or opportunities may require priority action and highly proactive response strategies. Threats and opportunities in the low-priority zone may not require proactive management action beyond being placed in the risk register as part of the watch list or adding a contingency reserve.

The risk register identifies the nominated risk owner for each risk. It may also contain preliminary risk responses identified earlier in the Project Risk Management process. The risk register may provide other data on identified risks that can assist in planning risk responses, including root causes, risk triggers and warning signs, risks requiring responses in the near term, and risks where a need for additional analysis has been identified.

• Risk report. Described in Section 11.2.3.2. The risk report presents the current level of overall risk exposure of the project that will inform selection of the risk response strategy. The risk report may also list individual project risks in priority order and provide additional analysis of the distribution of individual project risks that may inform risk response selection.
• Stakeholder register. Described in Section 13.1.3.1. The stakeholder register identifies potential owners for risk responses.

11.5.1.3 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Plan Risk Responses process include but are not limited to the risk appetite and thresholds of key stakeholders.

11.5.1.4 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Plan Risk Responses process include but are not limited to:

• Templates for the risk management plan, risk register, and risk report;
• Historical databases; and
• Lessons learned repositories from similar projects.

11.5.2 PLAN RISK RESPONSES: TOOLS AND TECHNIQUES

11.5.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with specialized knowledge in the following topics:

• Threat response strategies,
• Opportunity response strategies,
• Contingent response strategies, and
• Overall project risk response strategies.

Expert input may be sought from individuals with particular subject matter expertise relevant to a specific individual project risk, for example, where specialist technical knowledge is required.

11.5.2.2 DATA GATHERING

Data-gathering techniques that can be used for this process include but are not limited to interviews (see Section 5.2.2.2). Development of responses to individual project risks and overall project risk may be undertaken during structured or semi-structured interviews (see Section 5.2.2.2) with risk owners. Other stakeholders may also be interviewed if necessary. The interviewer should promote an environment of trust and confidentiality in the interview setting to encourage honest and unbiased decisions.

11.5.2.3 INTERPERSONAL AND TEAM SKILLS

Interpersonal and team skills that can be used for this process includes but are not limited to facilitation (see Section 4.1.2.3). The use of facilitation improves the effectiveness of developing responses to individual project risks and overall project risk. A skilled facilitator can help risk owners understand the risk, identify and compare alternative possible risk response strategies, choose an appropriate response strategy, and identify and overcome sources of bias.

11.5.2.4 STRATEGIES FOR THREATS

Five alternative strategies may be considered for dealing with threats, as follows:

• Escalate. Escalation is appropriate when the project team or the project sponsor agrees that a threat is outside the scope of the project or that the proposed response would exceed the project manager's authority. Escalated risks are managed at the program level, portfolio level, or other relevant part of the organization, and not on the project level. The project manager determines who should be notified about the threat and communicates the details to that person or part of the organization. It is important that ownership of escalated threats is accepted by the relevant party in the organization. Threats are usually escalated to the level that matches the objectives that would be affected if the threat occurred. Escalated threats are not monitored further by the project team after escalation, although they may be recorded in the risk register for information.
• Avoid. Risk avoidance is when the project team acts to eliminate the threat or protect the project from its impact. It may be appropriate for high-priority threats with a high probability of occurrence and a large negative impact. Avoidance may involve changing some aspect of the project management plan or changing the objective that is in jeopardy in order to eliminate the threat entirely, reducing its probability of occurrence to zero. The risk owner may also take action to isolate the project objectives from the risk's impact if it were to occur. Examples of avoidance actions may include removing the cause of a threat, extending the schedule, changing the project strategy, or reducing scope. Some risks can be avoided by clarifying requirements, obtaining information, improving communication, or acquiring expertise.
• Transfer. Transfer involves shifting ownership of a threat to a third party to manage the risk and to bear the impact if the threat occurs. Risk transfer often involves payment of a risk premium to the party taking on the threat. Transfer can be achieved by a range of actions, which include but are not limited to the use of insurance, performance bonds, warranties, guarantees, etc. Agreements may be used to transfer ownership and liability for specified risks to another party.
• Mitigate. In risk mitigation, action is taken to reduce the probability of occurrence and/or impact of a threat. Early mitigation action is often more effective than trying to repair the damage after the threat has occurred. Adopting less complex processes, conducting more tests, or choosing a more stable seller are examples of mitigation actions. Mitigation may involve prototype development (see Section 5.2.2.8) to reduce the risk of scaling up from a bench-scale model of a process or product. Where it is not possible to reduce probability, a mitigation response might reduce the impact by targeting factors that drive the severity. For example, designing redundancy into a system may reduce the impact from a failure of the original component.
• Accept. Risk acceptance acknowledges the existence of a threat, but no proactive action is taken. This strategy may be appropriate for low-priority threats, and it may also be adopted where it is not possible or cost-effective to address a threat in any other way. Acceptance can be either active or passive. The most common active acceptance strategy is to establish a contingency reserve, including amounts of time, money, or resources to handle the threat if it occurs. Passive acceptance involves no proactive action apart from periodic review of the threat to ensure that it does not change significantly.

11.5.2.5 STRATEGIES FOR OPPORTUNITIES

Five alternative strategies may be considered for dealing with opportunities, as follows:

• Escalate. This risk response strategy is appropriate when the project team or the project sponsor agrees that an opportunity is outside the scope of the project or that the proposed response would exceed the project manager's authority. Escalated opportunities are managed at the program level, portfolio level, or other relevant part of the organization, and not on the project level. The project manager determines who should be notified about the opportunity and communicates the details to that person or part of the organization. It is important that ownership of escalated opportunities is accepted by the relevant party in the organization. Opportunities are usually escalated to the level that matches the objectives that would be affected if the opportunity occurred. Escalated opportunities are not monitored further by the project team after escalation, although they may be recorded in the risk register for information.
• Exploit. The exploit strategy may be selected for high-priority opportunities where the organization wants to ensure that the opportunity is realized. This strategy seeks to capture the benefit associated with a particular opportunity by ensuring that it definitely happens, increasing the probability of occurrence to 100%. Examples of exploiting responses may include assigning an organization's most talented resources to the project to reduce the time to completion, or using new technologies or technology upgrades to reduce cost and duration.
• Share. Sharing involves transferring ownership of an opportunity to a third party so that it shares some of the benefit if the opportunity occurs. It is important to select the new owner of a shared opportunity carefully so they are best able to capture the opportunity for the benefit of the project. Risk sharing often involves payment of a risk premium to the party taking on the opportunity. Examples of sharing actions include forming risk-sharing partnerships, teams, special-purpose companies, or joint ventures.
• Enhance. The enhance strategy is used to increase the probability and/or impact of an opportunity. Early enhancement action is often more effective than trying to improve the benefit after the opportunity has occurred. The probability of occurrence of an opportunity may be increased by focusing attention on its causes. Where it is not possible to increase probability, an enhancement response might increase the impact by targeting factors that drive the size of the potential benefit. Examples of enhancing opportunities include adding more resources to an activity to finish early.
• Accept. Accepting an opportunity acknowledges its existence but no proactive action is taken. This strategy may be appropriate for low-priority opportunities, and it may also be adopted where it is not possible or cost-effective to address an opportunity in any other way. Acceptance can be either active or passive. The most common active acceptance strategy is to establish a contingency reserve, including amounts of time, money, or resources to take advantage of the opportunity if it occurs. Passive acceptance involves no proactive action apart from periodic review of the opportunity to ensure that it does not change significantly.

11.5.2.6 CONTINGENT RESPONSE STRATEGIES

Some responses are designed for use only if certain events occur. For some risks, it is appropriate for the project team to make a response plan that will only be executed under certain predefined conditions, if it is believed that there will be sufficient warning to implement the plan. Events that trigger the contingency response, such as missing intermediate milestones or gaining higher priority with a seller, should be defined and tracked. Risk responses identified using this technique are often called contingency plans or fallback plans and include identified triggering events that set the plans in effect.

11.5.2.7 STRATEGIES FOR OVERALL PROJECT RISK

Risk responses should be planned and implemented not only for individual project risks but also to address overall project risk. The same risk response strategies that are used to deal with individual project risks can also be applied to overall project risk:

• Avoid. Where the level of overall project risk is significantly negative and outside the agreed-upon risk thresholds for the project, an avoid strategy may be adopted. This involves taking focused action to reduce the negative effect of uncertainty on the project as a whole and bring the project back within the thresholds. An example of avoidance at the overall project level would include removal of high-risk elements of scope from the project. Where it is not possible to bring the project back within the thresholds, the project may be canceled. This represents the most extreme degree of risk avoidance and it should be used only if the overall level of threat is, and will remain, unacceptable.
• Exploit. Where the level of overall project risk is significantly positive and outside the agreed-upon risk thresholds for the project, an exploit strategy may be adopted. This involves taking focused action to capture the positive effect of uncertainty on the project as a whole. An example of exploiting at the overall project level would include addition of high-benefit elements of scope to the project to add value or benefits to stakeholders. Alternatively the risk thresholds for the project may be modified with the agreement of key stakeholders in order to embrace the opportunity.
• Transfer/share. If the level of overall project risk is high but the organization is unable to address it effectively, a third party may be involved to manage the risk on behalf of the organization. Where overall project risk is negative, a transfer strategy is required, which may involve payment of a risk premium. In the case of high positive overall project risk, ownership may be shared in order to reap the associated benefits. Examples of both transfer and share strategies for overall project risk include but are not limited to setting up a collaborative business structure in which the buyer and the seller share the overall project risk, launching a joint venture or special-purpose company, or subcontracting key elements of the project.
• Mitigate/enhance. These strategies involve changing the level of overall project risk to optimize the chances of achieving the project's objectives. The mitigation strategy is used where overall project risk is negative, and enhancement applies when it is positive. Examples of mitigation or enhancement strategies include replanning the project, changing the scope and boundaries of the project, modifying project priority, changing resource allocations, adjusting delivery times, etc.
• Accept. Where no proactive risk response strategy is possible to address overall project risk, the organization may choose to continue with the project as currently defined, even if overall project risk is outside the agreed-upon thresholds. Acceptance can be either active or passive. The most common active acceptance strategy is to establish an overall contingency reserve for the project, including amounts of time, money, or resources to be used if the project exceeds its thresholds. Passive acceptance involves no proactive action apart from periodic review of the level of overall project risk to ensure that it does not change significantly.

11.5.2.8 DATA ANALYSIS

A number of alternative risk response strategies may be considered. Data analysis techniques that can be used to select a preferred risk response strategy include but are not limited to:

• Alternatives analysis. A simple comparison of the characteristics and requirements of alternative risk response options can lead to a decision on which response is most appropriate.
• Cost-benefit analysis. If the impact of an individual project risk can be quantified in monetary terms, then the cost-effectiveness of alternative risk response strategies can be determined using cost-benefit analysis (see Section 8.1.2.3). The ratio of (change in impact level) divided by (implementation cost) gives the cost effectiveness of the response strategy, with a higher ratio indicating a more effective response.

11.5.2.9 DECISION MAKING

Decision-making techniques that can be used to select a risk response strategy include but are not limited to multicriteria decision analysis (described in Section 8.1.2.4). One or more risk response strategies may be under consideration. Decision-making techniques can help prioritize risk response strategies. Multicriteria decision analysis uses a decision matrix to provide a systematic approach for establishing key decision criteria, evaluating and ranking alternatives, and selecting a preferred option. Criteria for risk response selection may include but are not limited to cost of response, likely effectiveness of response in changing probability and/or impact, resource availability, timing constraints (urgency, proximity, and dormancy), level of impact if the risk occurs, effect of response on related risks, introduction of secondary risks, etc. Different strategies may be selected later in the project if the original choice proves to be ineffective.

11.5.3 PLAN RISK RESPONSES: OUTPUTS

11.5.3.1 CHANGE REQUESTS

Described in Section 4.3.3.4. Planned risk responses may result in a change request to the cost and schedule baselines or other components of the project management plan. Change requests are processed for review and disposition through the Perform Integrated Change Control process (Section 4.6).

11.5.3.2 PROJECT MANAGEMENT PLAN UPDATES

Any change to the project management plan goes through the organization's change control process via a change request. Components that may require a change request for the project management plan include but are not limited to:

• Schedule management plan. Described in Section 6.1.3.1. Changes to the schedule management plan, such as changes to resource loading and leveling, or updates to the schedule strategy, are incorporated.
• Cost management plan. Described in Section 7.1.3.1. Changes to the cost management plan, such as changes to cost accounting, tracking, and reports, as well as updates to the budget strategy and how contingency reserves are consumed, are incorporated.
• Quality management plan. Described in Section 8.1.3.1. Changes to the quality management plan, such as changes to approaches for meeting requirements, quality management approaches, or quality control processes, are incorporated.
• Resource management plan. Described in Section 9.1.3.1. Changes to the resource management plan, such as changes to resource allocation, as well as updates to the resource strategy, are incorporated.
• Procurement management plan. Described in Section 12.1.3.1. Changes to the procurement management plan, such as alterations in the make-or-buy decision or contract type(s), are incorporated.
• Scope baseline. Described in Section 5.4.3.1. Changes in the scope baseline are incorporated in response to approved changes in scope that may arise from agreed-upon risk responses.
• Schedule baseline. Described in Section 6.5.3.1. Changes in the schedule baseline are incorporated in response to approved changes in schedule estimates that may arise from agreed-upon risk responses.
• Cost baseline. Described in Section 7.3.3.1. Changes in the cost baseline are incorporated in response to approved changes in cost estimates that may arise from agreed-upon risk responses.

11.5.3.3 PROJECT DOCUMENTS UPDATES

Project documents that may be updated as a result of carrying out this process include but are not limited to:

• Assumption log. Described in Section 4.1.3.2. During the Plan Risk Responses process, new assumptions may be made, new constraints may be identified, and existing assumptions or constraints may be revisited and changed. The assumption log should be updated with this new information.
• Cost forecasts. Described in Section 7.4.3.2. Cost forecasts may change as a result of planned risk responses.
• Lessons learned register. Described in Section 4.4.3.1. The lessons learned register is updated with information about risk responses that may be useful for future phases of the project or future projects.
• Project schedule. Described in Section 6.5.3.2. Activities relating to agreed-upon risk responses may be added to the project schedule.
• Project team assignments. Described in Section 9.3.3.2. Once the responses are confirmed, the necessary resources should be allocated to each action associated with a risk response plan. These resources include suitably qualified and experienced personnel to execute the agreed-upon action (usually within the project team) a specific budget and time allowance for the action, and any required technical resources to complete the action.
• Risk register. Described in Section 11.2.3.1. The risk register is updated when appropriate risk responses are chosen and agreed upon. Updates to the risk register may include but are not limited to:

• Agreed-upon response strategies;
• Specific actions to implement the chosen response strategy;
• Trigger conditions, symptoms, and warning signs of a risk occurrence;
• Budget and schedule activities required to implement the chosen responses;
• Contingency plans and risk triggers that call for their execution;
• Fallback plans for use when a risk that has occurred and the primary response proves to be inadequate;
• Residual risks that are expected to remain after planned responses have been taken, as well as those that have been deliberately accepted; and
• Secondary risks that arise as a direct outcome of implementing a risk response.

• Risk report. Described in Section 11.2.3.2. The risk report may be updated to present agreed-upon responses to the current overall project risk exposure and high-priority risks, together with the expected changes that may be expected as a result of implementing these responses.

11.6 IMPLEMENT RISK RESPONSES

Implement Risk Responses is the process of implementing agreed-upon risk response plans. The key benefit of this process is that it ensures that agreed-upon risk responses are executed as planned in order to address overall project risk exposure, minimize individual project threats, and maximize individual project opportunities. This process is performed throughout the project. The inputs, tools and techniques, and outputs of the process are depicted in Figure 11-18. Figure 11-19 depicts the data flow diagram for the process.

Proper attention to the Implement Risk Responses process will ensure that agreed-upon risk responses are actually executed. A common problem with Project Risk Management is that project teams spend effort in identifying and analyzing risks and developing risk responses, then risk responses are agreed upon and documented in the risk register and risk report, but no action is taken to manage the risk.

Only if risk owners give the required level of effort to implementing the agreed-upon responses will the overall risk exposure of the project and individual threats and opportunities be managed proactively.

11.6.1 IMPLEMENT RISK RESPONSES: INPUTS

11.6.1.1 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Project management plan components include but are not limited to the risk management plan. Described in Section 11.1.3.1, the risk management plan lists the roles and responsibilities of project team members and other stakeholders for risk management. This information is used when allocating owners for agreed-upon risk responses. The risk management plan also defines the level of detail for the risk management methodology for the project. It also specifies risk thresholds for the project based on the risk appetite of key stakeholders, which define the acceptable target that the implementation of risk responses is required to achieve.

11.6.1.2 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to:

• Lessons learned register. Described in Section 4.4.3.1. Lessons learned earlier in the project with regard to implementing risk responses can be applied to later phases in the project to improve the effectiveness of this process.
• Risk register. Described in Section 11.2.3.1. The risk register records the agreed-upon risk responses for each individual risk and the nominated owners for each response plan.
• Risk report. Described in Section 11.2.3.2. The risk report includes an assessment of the current overall project risk exposure, as well as the agreed-upon risk response strategy. It also describes the major individual project risks with their planned responses.

11.6.1.3 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Implement Risk Responses process include but are not limited to the lessons learned repository from similar completed projects that indicate the effectiveness of particular risk responses.

11.6.2 IMPLEMENT RISK RESPONSES: TOOLS AND TECHNIQUES

11.6.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with specialized knowledge to validate or modify risk responses if necessary, and decide how to implement them in the most efficient and effective manner.

11.6.2.2 INTERPERSONAL AND TEAM SKILLS

Interpersonal and team skills that can be used for this process include but are not limited to influencing. Some risk response actions may be owned by people outside the immediate project team or who have other competing demands. The project manager or person responsible for facilitating the risk process may need to exercise influencing (see Section 9.5.2.1) to encourage nominated risk owners to take necessary action where required.

11.6.2.3 PROJECT MANAGEMENT INFORMATION SYSTEM (PMIS)

Described in Section 4.3.2.2. Project management information systems can include schedule, resource, and cost software to ensure that agreed-upon risk response plans and their associated activities are integrated into the project alongside other project activities.

11.6.3 IMPLEMENT RISK RESPONSES: OUTPUTS

11.6.3.1 CHANGE REQUESTS

Described in Section 4.3.3.4. Implementation of risk responses may result in a change request to the cost and schedule baselines or other components of the project management plan. Change requests are processed for review and disposition through the Perform Integrated Change Control process (Section 4.6).

11.6.3.2 PROJECT DOCUMENTS UPDATES

Project documents that may be updated as a result of carrying out this process include but are not limited to:

• Issue log. Described in Section 4.3.3.3. Where issues are identified as part of the Implement Risk Responses process, they are recorded in the issue log.
• Lessons learned register. Described in Section 4.4.3.1. The lessons learned register is updated with information on challenges encountered when implementing risk responses and how they could have been avoided, as well as approaches that worked well for implementing risk responses.
• Project team assignments. Described in Section 9.3.3.2. Once the risk responses are confirmed, the necessary resources should be allocated to each action associated with a risk response plan. These resources include suitably qualified and experienced personnel to execute the agreed-upon action (usually within the project team), a specific budget and time allowance for the action, and any required technical resources to complete the action.
• Risk register. Described in Section 11.2.3.1. The risk register may be updated to reflect any changes to the previously agreed-upon risk responses for individual project risks that are subsequently made as a result of the Implement Risk Responses process.
• Risk report. Described in Section 11.2.3.2. The risk report may be updated to reflect any changes to the previously agreed-upon risk response to overall project risk exposure that are subsequently made as a result of the Implement Risk Responses process.

11.7 MONITOR RISKS

Monitor Risks is the process of monitoring the implementation of agreed-upon risk response plans, tracking identified risks, identifying and analyzing new risks, and evaluating risk process effectiveness throughout the project. The key benefit of this process is that it enables project decisions to be based on current information about overall project risk exposure and individual project risks. This process is performed throughout the project. The inputs, tools and techniques, and outputs of the process are depicted in Figure 11-20. Figure 11-21 depicts the data flow diagram for the process.

In order to ensure that the project team and key stakeholders are aware of the current level of risk exposure, project work should be continuously monitored for new, changing, and outdated individual project risks and for changes in the level of overall project risk by applying the Monitor Risks process. The Monitor Risks process uses performance information generated during project execution to determine if:

• Implemented risk responses are effective,
• Level of overall project risk has changed,
• Status of identified individual project risks has changed,
• New individual project risks have arisen,
• Risk management approach is still appropriate,
• Project assumptions are still valid,
• Risk management policies and procedures are being followed,
• Contingency reserves for cost or schedule require modification, and
• Project strategy is still valid.

11.7.1 MONITOR RISKS: INPUTS

11.7.1.1 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Project management plan components include but are not limited to the risk management plan. Described in Section 11.3.1.1. The risk management plan provides guidance on how and when risks should be reviewed, which policies and procedures should be followed, the roles and responsibilities in the monitoring process, and reporting formats.

11.7.1.2 PROJECT DOCUMENTS

Project documents that should be considered as inputs for this process include but are not limited to:

• Issue log. Described in Section 4.3.3.3. The issue log is used to see if any of the open issues have been updated and necessitate an update to the risk register.
• Lessons learned register. Described in Section 4.4.3.1. Risk-related lessons from earlier in the project can be applied to later phases in the project.
• Risk register. Described in Section 11.2.3.1. The risk register has key inputs that include identified individual project risks, risk owners, agreed-upon risk responses, and specific implementation actions. It may also provide other details including control actions for assessing the effectiveness of response plans, symptoms and warning signs of risk, residual and secondary risks, and a watch list of low-priority risks.
• Risk report. Described in Section 11.2.3.2. The risk report includes an assessment of the current overall project risk exposure as well as the agreed-upon risk response strategy. It also describes the major individual risks with planned responses and risk owners.

11.7.1.3 WORK PERFORMANCE DATA

Described in Section 4.3.3.2. Work performance data contains data on project status such as risk responses that have been implemented, risks that have occurred, risks that are active and those that have been closed out.

11.7.1.4 WORK PERFORMANCE REPORTS

Described in Section 4.5.3.1. Work performance reports provide information from performance measurements that can be analyzed to provide project work performance information including variance analysis, earned value data, and forecasting data. This information could be relevant when monitoring performance-related risks.

11.7.2 MONITOR RISKS: TOOLS AND TECHNIQUES

11.7.2.1 DATA ANALYSIS

Data analysis techniques that can be used for this process include but are not limited to:

• Technical performance analysis. Technical performance analysis compares technical accomplishments during project execution to the schedule of technical achievement. It requires the definition of objective, quantifiable measures of technical performance, which can be used to compare actual results against targets. Such technical performance measures may include weight, transaction times, number of delivered defects, storage capacity, etc. Deviation can indicate the potential impact of threats or opportunities.
• Reserve analysis. Described in Section 7.2.2.6. Throughout execution of the project, some individual project risks may occur with positive or negative impacts on budget or schedule contingency reserves. Reserve analysis compares the amount of the contingency reserves remaining to the amount of risk remaining at any time in the project in order to determine if the remaining reserve is adequate. This may be communicated using various graphical representations, including a burndown chart.

11.7.2.2 AUDITS

Described in Section 8.2.2.5. Risk audits are a type of audit that may be used to consider the effectiveness of the risk management process. The project manager is responsible for ensuring that risk audits are performed at an appropriate frequency, as defined in the project's risk management plan. Risk audits may be included during routine project review meetings or may form part of a risk review meeting, or the team may choose to hold separate risk audit meetings. The format for the risk audit and its objectives should be clearly defined before the audit is conducted.

11.7.2.3 MEETINGS

Meetings that can be used during this process include but are not limited to risk reviews. Risk reviews are scheduled regularly and should examine and document the effectiveness of risk responses in dealing with overall project risk and with identified individual project risks. Risk reviews may also result in identification of new individual project risks, (including secondary risks that arise from agreed-upon risk responses), reassessment of current risks, the closing of risks that are outdated, issues that have arisen as the result of risks that have occurred, and identification of lessons to be learned for implementation in ongoing phases in the current project or in similar projects in the future. The risk review may be conducted as part of a periodic project status meeting or a dedicated risk review meeting may be held, as specified in the risk management plan.

11.7.3 MONITOR RISKS: OUTPUTS

11.7.3.1 WORK PERFORMANCE INFORMATION

Described in Section 4.5.1.3. Work performance information includes information on how project risk management is performing by comparing the individual risks that have occurred with the expectation of how they would occur. This information indicates the effectiveness of the response planning and response implementation processes.

11.7.3.2 CHANGE REQUESTS

Described in Section 4.3.3.4. The Monitor Risks process may result in a change request to the cost and schedule baselines or other components of the project management plan. Change requests are processed for review and disposition through the Perform Integrated Change Control process (Section 4.6).

Change requests can include recommended corrective and preventive actions to address the current level of overall project risk or to address individual project risks.

11.7.3.3 PROJECT MANAGEMENT PLAN UPDATES

Any change to the project management plan goes through the organization's change control process via a change request. This may affect any component of the project management plan.

11.7.3.4 PROJECT DOCUMENTS UPDATES

Project documents that may be updated as a result of carrying out this process include but are not limited to:

• Assumption log. Described in Section 4.1.3.2. During the Monitor Risks process, new assumptions may be made, new constraints may be identified, and existing assumptions or constraints may be revisited and changed. The assumption log is updated with this new information.
• Issue log. Described in Section 4.3.3.3. Where issues are identified as part of the Monitor Risks process, these are recorded in the issue log.
• Lessons learned register. Described in Section 4.4.3.1. The lessons learned register is updated with any risk-related lessons learned during risk reviews so these can be used on later phases of the project or in future projects.
• Risk register. Described in Section 11.2.3.1. The risk register is updated with information on individual project risks generated during the Monitor Risks process. This may include adding new risks, updating outdated risks or risks that were realized, updating risk responses, and so forth.
• Risk report. Described in Section 11.2.3.2. As new information becomes available through the Monitor Risks process, the risk report is updated to reflect the current status of major individual project risks and the current level of overall project risk. The risk report may also include details of the top individual project risks, agreed-upon responses and owners, and conclusions and recommendations. It may also include conclusions from risk audits on the effectiveness of the risk management process.

11.7.3.5 ORGANIZATIONAL PROCESS ASSETS UPDATES

Organizational process assets that are updated as a result of the Monitor Risks process include but are not limited to:

• Templates for the risk management plan, risk register, and risk report; and
• Risk breakdown structure.