Risk Management

A Project Management Process Area at Maturity Level 3

Purpose

The purpose of Risk Management (RSKM) is to identify potential problems before they occur so that risk-handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.

Tip

RSKM also can apply to identifying, evaluating, and maximizing (or realizing) opportunities.

In a dynamic environment, risk management must be a continuous process of identifying, analyzing, and monitoring risks.

Introductory Notes

Risk management is a continuous, forward-looking process that is an important part of project management. Risk management should address issues that could endanger achievement of critical objectives. A continuous risk management approach effectively anticipates and mitigates risks that may have a critical impact on a project.

Tip

Without a free and open environment, many risks remain undisclosed until they surface as problems, when it is often too late to address them. Free and open discussions should involve customers and other stakeholders when the acquisition strategy is being formulated; involve potential suppliers when negotiations are taking place; and involve suppliers when the supplier agreement is being established and throughout the project.

Effective risk management includes early and aggressive risk identification through collaboration and the involvement of relevant stakeholders as described in the stakeholder involvement plan addressed in the Project Planning process area. Strong leadership across all relevant stakeholders is needed to establish an environment for free and open disclosure and discussion of risk.

Risk management must consider both internal and external sources of cost, schedule, performance, and other risks. Early and aggressive detection of risk is important because it is typically easier, less costly, and less disruptive to make changes and correct work efforts during the earlier, rather than the later, phases of the project.

X-Ref

PP and PMC contain risk-management-related practices: See PP SP 2.2, Identify Project Risks; and PMC SP 1.3, Monitor Project Risks.

When the project identifies and assesses project risks during project planning and manages risks throughout the life of the project, risk identification includes identifying risks associated with the acquisition process and the use of a supplier to perform project work. Initially, the acquisition strategy identifies risks associated with an acquisition. The approach to the acquisition is planned based on those risks. As the project progresses to the selection of a supplier, risks specific to the supplier’s technical and management approach become important to the success of the acquisition.

These risks refer to the capability of the supplier to meet contractual requirements, including schedules and cost targets. When the project selects a supplier and awards the supplier agreement, the acquirer continues to manage project risks, including risks related to the supplier meeting its contractual requirements. Typically, the acquirer does not manage risks being addressed or managed by the supplier.

Hint

Relevant stakeholders external to the project bring perspectives and insight into identifying and evaluating risks. This is particularly true when your project is contributing to a system of systems. It is important to maintain a dialog on related risks pertaining to other systems in the system of systems.

Risk management can be divided into three parts: defining a risk management strategy; identifying and analyzing risks; and handling identified risks, including the implementation of risk mitigation plans as needed.

Tip

For an acquisition organization, sources of risk are not just technical, but are often programmatic and related to funding.

Although it may be valuable to manage risks with the supplier, recognize that there are supplier risks, acquirer risks, and shared risks. Each needs to be managed by the appropriate stakeholders.

Both the acquirer and supplier must understand project risks and how to modify the risk management strategy and plans as a project progresses through its lifecycle. Managing project risks requires a close partnership between the acquirer and supplier. Both must share appropriate risk management documentation, understand the risks, and develop and execute risk management activities.

The complexity of an acquirer–supplier relationship increases the need for early and aggressive risk identification. For example, acquirer capabilities, supplier experience working with the acquirer, financial stability of the supplier, and availability of well-defined dispute resolution processes all influence the risk of a project.

Hint

Make sure you include end users. Capabilities are acquired to mitigate operational risk; however, the deployment of new capabilities may increase operational risk if they are not managed properly.

As represented in the Project Planning and Project Monitoring and Control process areas, organizations initially may focus on risk identification for awareness, and react to the realization of these risks as they occur. The Risk Management process area describes an evolution of these specific practices to systematically plan, anticipate, and mitigate risks to proactively minimize their impact on the project.

X-Ref

To help end users participate in the risk process, see the SEI report, “A Taxonomy of Operational Risks” (CMU/SEI-2005-TN-036).

Although the primary emphasis of the Risk Management process area is on the project, these concepts can also be applied to manage organizational risks.

Related Process Areas

Refer to the Project Planning process area for more information about identifying project risks and planning the involvement of relevant stakeholders.

Refer to the Project Monitoring and Control process area for more information about monitoring project risks.

Refer to the Decision Analysis and Resolution process area for more information about using a formal evaluation process to evaluate alternatives for the selection and mitigation of identified risks.

Hint

A precondition to efficient risk management is to have shared and consistent project objectives among customers, the acquisition organization, and suppliers. Project objectives provide focus to risk management and help guide its activities.

Refer to the Solicitation and Supplier Agreement Development process area for more information about establishing supplier agreements.

Specific Goal and Practice Summary

SG 1 Prepare for Risk Management

SP 1.1   Determine Risk Sources and Categories

SP 1.2   Define Risk Parameters

SP 1.3   Establish a Risk Management Strategy

SG 2 Identify and Analyze Risks

SP 2.1   Identify Risks

SP 2.2   Evaluate, Categorize, and Prioritize Risks

SG 3 Mitigate Risks

SP 3.1   Develop Risk Mitigation Plans

SP 3.2   Implement Risk Mitigation Plans

X-Ref

For more information, see “Software Risk Management: Principles and Practices” by Barry Boehm (IEEE Software, 1990); Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide) Third Edition, 2004 (Chapter 11 deals with risk management); and www.sei.cmu.edu/risk/.

Specific Practices by Goal

SG 1 Prepare for Risk Management

Preparation for risk management is conducted.

Prepare for risk management by establishing and maintaining a strategy for identifying, analyzing, and mitigating risks. Typically, this strategy is documented in a risk management plan. The risk management strategy addresses specific actions and the management approach used to apply and control the risk management program. The strategy typically includes identifying sources of risk, the scheme used to categorize risks, and parameters used to evaluate, bound, and control risks for effective handling.

Tip

If your project uses safety and security analysis methods, incorporate these methods as part of the risk management strategy.

SP 1.1 Determine Risk Sources and Categories

Determine risk sources and categories.

Identifying risk sources provides a basis for systematically examining changing situations over time to uncover circumstances that impact the ability of the project to meet its objectives. Risk sources are both internal and external to the project. As the project progresses, additional sources of risk may be identified. Establishing categories for risks provides a mechanism for collecting and organizing risks as well as ensuring appropriate scrutiny and management attention to risks that can have serious consequences on meeting project objectives.

Acquirers initially identify and categorize risk sources and categories for the project and refine those sources and categories over time (e.g., schedule, cost, sourcing, contract management, supplier execution, technology readiness, human safety, reliability-related risks, and other issues outside the control of the acquirer). The supplier is also a source of risk (e.g., financial stability of the supplier and the possibility of the supplier’s acquisition by another organization).

Tip

Under stress, people lose perspective when it comes to risks. Some risks (e.g., those external to the project) may be given too much emphasis and others too little. Having a list of risk sources, both internal and external, helps bring objectivity to the identification of risks.

Typical Work Products

  1. Risk source lists (external and internal)
  2. Risk categories list

Subpractices

  1. Determine risk sources.

    Risk sources are fundamental drivers that cause risks in a project or organization. There are many sources of risks, both internal and external to a project. Risk sources identify where risks may originate.

    Tip

    In a typical project, risks and their status change. A standard list of risk sources enables a project to be thorough in its identification of risks at each point in the project.

    Tip

    Disruption to the continuity of operations is an external source. If neglected, it may have huge consequences. If mitigated, the mitigation is often cost-effective.

    Many of these sources of risk are often accepted without adequately planning for them. Early identification of both internal and external sources of risk can lead to early identification of risks. Risk mitigation plans can then be implemented early in the project to preclude occurrence of risks or reduce consequences of their occurrence.

  2. Determine risk categories.

    Risk categories are the “bins” used for collecting and organizing risks. Identifying risk categories aids the future consolidation of activities in risk mitigation plans.

    Tip

    Categories are used to group related risks that can often be addressed by the same mitigation activities, thereby increasing risk management efficiency.

    Tip

    Risks are often grouped by lifecycle phase.

    A risk taxonomy can be used to provide a framework for determining risk sources and categories.

SP 1.2 Define Risk Parameters

Define parameters used to analyze and categorize risks and to control the risk management effort.

Parameters for evaluating, categorizing, and prioritizing risks include the following:

• Risk likelihood (i.e., probability of risk occurrence)

• Risk consequence (i.e., impact and severity of risk occurrence)

• Thresholds to trigger management activities

Risk parameters are used to provide common and consistent criteria for comparing risks to be managed. Without these parameters, it is difficult to gauge the severity of an unwanted change caused by a risk and to prioritize the actions required for risk mitigation planning.

Acquirers should document the parameters used to analyze and categorize risks so they are available for reference throughout the life of the project since circumstances change over time. Using these parameters, risks can easily be recategorized and analyzed when changes occur.

The acquirer may use tools such as failure mode and effects analysis to examine risks such as potential failures in products or processes. A tool may also be used to evaluate risk management priorities for mitigating known threat vulnerabilities.

X-Ref

The risk taxonomies developed at the SEI and mentioned in Barry Boehm’s and Vic Basili’s “Top 10” Software Risks (www.cebase.org/www/AboutCebase/News/top-10-defects.html) are useful even after a decade.

Typical Work Products

  1. Risk evaluation, categorization, and prioritization criteria
  2. Risk management requirements (e.g., control and approval levels and reassessment intervals)

Subpractices

  1. Define consistent criteria for evaluating and quantifying risk likelihood and severity levels.

    Consistently used criteria (e.g., bounds on likelihood and severity levels) allow impacts of different risks to be commonly understood, to receive the appropriate level of scrutiny, and to obtain the management attention warranted. In managing dissimilar risks (e.g., personnel safety versus environmental pollution), it is important to ensure consistency in the end result (e.g., a high risk of environmental pollution is as important as a high risk to personnel safety).

    Tip

    To be effective, risk management must be objective and quantitative. Therefore, you must treat risks consistently with respect to key parameters. Defining criteria for evaluating risks helps to ensure consistency

  2. Define thresholds for each risk category.

    For each risk category, thresholds can be established to determine acceptability or unacceptability of risks, prioritization of risks, or triggers for management action.

    Tip

    In the middle of a project, you often lose perspective. Defining thresholds in advance enables a more objective treatment of risks.

    For each identified risk, establish points at which more aggressive risk monitoring is employed or to signal the implementation of risk mitigation plans. These points can be redefined later in the project as necessary.

    Tip

    These thresholds may need to be refined later as part of risk mitigation planning.

  3. Define bounds on the extent to which thresholds are applied against or within a category.

    There are few limits to which risks can be assessed in either a quantitative or qualitative fashion. Definition of bounds (or boundary conditions) can be used to help define the extent of the risk management effort and avoid excessive resource expenditures. Bounds may include the exclusion of a risk source from a category. These bounds can also exclude any condition that occurs less than a given frequency.

    Tip

    Bounds are intended to scope the risk management effort in sensible ways that help to conserve project resources.

SP 1.3 Establish a Risk Management Strategy

Establish and maintain the strategy to be used for risk management.

Tip

The risk management strategy documents the results of the first two specific practices.

A comprehensive risk management strategy addresses items such as the following:

The scope of the risk management effort

• Methods and tools to be used for risk identification, risk analysis, risk mitigation, risk monitoring, and communication

• Project-specific sources of risks

• How risks are to be organized, categorized, compared, and consolidated

• Parameters used for taking action on identified risks, including likelihood, consequence, and thresholds

• Risk mitigation techniques to be used, such as prototyping, piloting, simulation, alternative designs, or evolutionary development

• The definition of risk measures used to monitor the status of risks

• Time intervals for risk monitoring or reassessment

The risk management strategy should be guided by a common vision of success that describes desired future project outcomes in terms of the product delivered, its cost, and its fitness for the task. The risk management strategy is often documented in an organizational or project risk management plan. This strategy is reviewed with relevant stakeholders to promote commitment and understanding.

A risk management strategy must be developed early in the project so that relevant risks are identified and managed aggressively. The acquisition strategy evolves based on risk identification and analysis. Early identification and assessment of critical risks allows the acquirer to formulate risk-handling approaches and streamline the project definition and solicitation around critical product and process risks.

Tip

Some large acquisition organizations develop a standard risk management strategy template that is tailored to meet the needs of individual projects.

Typical Work Products

  1. Project risk management strategy

Tip

The risk management strategy is often documented as part of a risk management plan, or as a section in the project plan.

All relevant stakeholders must understand fully the risk management strategy.

SG 2 Identify and Analyze Risks

Risks are identified and analyzed to determine their relative importance.

The degree of risk affects the resources assigned to handle the risk and the timing of when appropriate management attention is required.

Tip

Risk identification and analysis is an activity that continues for the duration of the project.

Risk analysis entails identifying risks from identified internal and external sources and evaluating each identified risk to determine its likelihood and consequences. Risk categorization, based on an evaluation against established risk categories and criteria developed for the risk management strategy, provides information needed for risk-handling. Related risks may be grouped to enable efficient handling and effective use of risk management resources.

SP 2.1 Identify Risks

Identify and document risks.

Tip

“Can a project have no risks?” “Can multiple projects have the same risk lists?” If these questions are asked, someone does not understand risks. Some risks may be product-specific, contract-specific, or supplier-specific.

Identifying potential issues, hazards, threats, and vulnerabilities that could negatively affect work efforts or plans is the basis for sound and successful risk management. Risks must be identified and described understandably before they can be analyzed and managed properly. Risks are documented in a concise statement that includes the context, conditions, and consequences of risk occurrence.

Tip

The context, conditions, and consequences of a risk statement provide much of the information that is needed later to understand and evaluate the risk.

Risk identification should be an organized, thorough approach to seek out probable or realistic risks that may affect achieving objectives. To be effective, risk identification should not attempt to address every possible event regardless of how improbable it may be. Using categories and parameters developed in the risk management strategy and identified sources of risk can provide the discipline and streamlining appropriate for risk identification. Identified risks form a baseline for initiating risk management activities. Risks should be reviewed periodically to reexamine possible sources of risk and changing conditions to uncover sources and risks previously overlooked or nonexistent when the risk management strategy was last updated.

Risk identification focuses on identifying risks, not placement of blame. The results of risk identification activities should never be used by management to evaluate the performance of individuals.

Hint

Establish a work environment in which risks can be disclosed and discussed openly, without fear of repercussions. (Don’t shoot the messenger!)

Tip

Many of the methods used for identifying risks use organizational process assets such as a risk taxonomy, risk repository, and lessons learned from past projects. Subject-matter experts may also be utilized. Other methods involve reviewing project artifacts such as the project’s shared vision, project interfaces, and contractual requirements.

Some risks are identified by examining the supplier’s WBS, product, and processes using the categories and parameters developed in the risk management strategy. Risks can be identified in many areas (e.g., requirements, technology, design, testing, vulnerability to threats, and lifecycle costs). An examination of the project in these areas can help to develop or refine the acquisition strategy and the risk-sharing structure between the acquirer and supplier.

The acquirer considers risks associated with a supplier’s capability (e.g., meeting schedule and cost requirements for the project), including potential risks to the acquirer’s intellectual capital or security vulnerabilities introduced by using a supplier.

Typical Work Products

  1. List of identified risks, including the context, conditions, and consequences of risk occurrence

Typical Supplier Deliverables

  1. List of identified risks, including the context, conditions, and consequences of risk occurrence

Subpractices

  1. Identify the risks associated with cost, schedule, and performance.

    Tip

    One approach to identifying risks is to consider the cost, schedule, and performance issues associated with each lifecycle phase. Since each phase typically has a clear set of objectives and a completion milestone, a phase is a suitable context for identifying the risks associated with that phase.

    Cost, schedule, and performance risks should be examined in the acquirer’s intended environment to the extent that they impact project objectives. Potential risks may be discovered that are outside the scope of project objectives but are vital to customer interests. For example, risks in development costs, product acquisition costs, cost of spare (or replacement) products, and product disposition (or disposal) costs have design implications. The customer may not have considered the full cost of supporting a fielded product or using a delivered service. The customer should be informed of such risks, but actively managing those risks may not be necessary. Mechanisms for making such decisions should be examined at project and organization levels and put in place if deemed appropriate, especially for risks that impact the project’s ability to verify and validate the product.

    In addition to the cost risks identified earlier, other cost risks may include those associated with funding levels, funding estimates, and distributed budgets.

    Hint

    When necessary, explain to customers the implications of their requirements, as they may not be aware of the acquisition risks associated with certain requirements. However, once they are aware of the risk, they may decide to keep the requirements as desired.

    Schedule risks may include risks associated with planned activities, key events, and milestones.

    Tip

    Performance risks may be associated with lifecycle phases, new technology, or desired attributes of the product.

    Performance maintenance attributes are those characteristics that enable an in-use product or service to provide required performance, such as maintaining safety and security performance.

    There are other risks that do not fall into cost, schedule, or performance categories.

  2. Review environmental elements that may impact the project.

    Tip

    Environmental risks are often ignored, even though some cost-effective mitigation activities are possible.

    Risks to a project that frequently are missed include those supposedly outside the scope of the project (i.e., the project does not control whether they occur but can mitigate their impact), such as weather, natural or manmade disasters that affect the continuity of operations, political changes, and telecommunications failures.

  3. Review all elements of the work breakdown structure as part of identifying risks to help ensure that all aspects of the work effort have been considered.
  4. Review all elements of the project plan as part of identifying risks to help ensure that all aspects of the project have been considered.

    Refer to the Project Planning process area for more information about identifying project risks.

  5. Document the context, conditions, and potential consequences of each risk.

    Tip

    A good risk statement is fact-based, actionable, and brief.

    Risk statements are typically documented in a standard format that contains the risk context, conditions, and consequences of occurrence. The risk context provides additional information about the risk such as the relative time frame of the risk, the circumstances or conditions surrounding the risk that have brought about the concern, and any doubt or uncertainty.

    Tip

    A standard format for documenting risks makes it easier to train personnel on what is needed in risk statements.

  6. Identify the relevant stakeholders associated with each risk.

SP 2.2 Evaluate, Categorize, and Prioritize Risks

Evaluate and categorize each identified risk using defined risk categories and parameters, and determine its relative priority.

The evaluation of risks is needed to assign a relative importance to each identified risk and is used in determining when appropriate management attention is required. Often, it is useful to aggregate risks based on their interrelationships and to develop options at an aggregate level. When an aggregate risk is formed by a roll-up of lower-level risks, care must be taken to ensure that important lower-level risks are not ignored.

Hint

You can simplify risk management when you can treat a number of risks as one group from evaluation and mitigation perspectives.

Collectively, the activities of risk evaluation, categorization, and prioritization are sometimes called a risk assessment or risk analysis.

The acquirer should conduct a risk assessment before solicitation to evaluate if the project can achieve its technical, schedule, and budget constraints. Technical, schedule, and cost risks should be discussed with potential suppliers before the solicitation is released. Using this approach, critical risks inherent in the project can be identified and addressed in the solicitation.

Typical Work Products

  1. List of risks and their assigned priority

Typical Supplier Deliverables

  1. List of risks and their assigned priority

Subpractices

  1. Evaluate identified risks using defined risk parameters.

    Each risk is evaluated and assigned values according to defined risk parameters, which may include likelihood, consequence (severity or impact), and thresholds. The assigned risk parameter values can be integrated to produce additional measures, such as risk exposure, which can be used to prioritize risks for handling.

    Tip

    Risk exposure is the result of the combination of the likelihood and the consequence of a risk (expressed quantitatively).

    Often, a scale with three to five values is used to evaluate both likelihood and consequence.

    Probability values are frequently used to quantify likelihood. Consequences are generally related to cost, schedule, environmental impact, or human measures (e.g., labor hours lost and severity of injury).

    Risk evaluation is often a difficult and time-consuming task. Specific expertise or group techniques may be needed to assess risks and gain confidence in the prioritization. In addition, priorities may require reevaluation as time progresses.

    Tip

    Determining values for risk likelihood and consequence is easier and more repeatable if objectives are stated clearly, criteria exist for assigning values, relevant stakeholders are appropriately represented, and personnel have been trained.

  2. Categorize and group risks according to defined risk categories.

    Risks are categorized into defined risk categories, providing a means to review them according to their source, taxonomy, or project component. Related or equivalent risks may be grouped for efficient handling. The cause-and-effect relationships between related risks are documented.

  3. Prioritize risks for mitigation.

    A relative priority is determined for each risk based on assigned risk parameters. Clear criteria should be used to determine risk priority. Risk prioritization helps to determine the most effective areas to which resources for risks mitigation can be applied with the greatest positive impact to the project.

    Tip

    Priority assignment can likewise be a repeatable process.

SG 3 Mitigate Risks

Risks are handled and mitigated, as appropriate, to reduce adverse impacts on achieving objectives.

The steps in handling risks include developing risk-handling options, monitoring risks, and performing risk-handling activities when defined thresholds are exceeded. Risk mitigation plans are developed and implemented for selected risks to proactively reduce the potential impact of risk occurrence. Risk mitigation planning can also include contingency plans to deal with the impact of selected risks that may occur despite attempts to mitigate them. Risk parameters used to trigger risk-handling activities are defined by the risk management strategy.

X-Ref

RSKM heavily influences technical management (i.e., to adjust requirements, design, implementation, verification, and validation in light of risks and risk mitigation), project management (i.e., to plan for these activities and monitor thresholds that trigger the deployment of mitigation plans), and agreement management (i.e., to understand how these activities are reflected in the supplier agreement).

SP 3.1 Develop Risk Mitigation Plans

Develop a risk mitigation plan for the most important risks to the project as defined by the risk management strategy.

A critical component of a risk mitigation planning is developing alternative courses of action, workarounds, and fallback positions, and a recommended course of action for each critical risk. The risk mitigation plan for a given risk includes techniques and methods used to avoid, reduce, and control the probability of risk occurrence, the extent of damage incurred should the risk occur (sometimes called a contingency plan), or both. Risks are monitored, and when they exceed established thresholds risk mitigation plans are deployed to return the impacted effort to an acceptable risk level. If the risk cannot be mitigated, a contingency plan can be invoked. Both risk mitigation and contingency plans often are generated only for selected risks for which consequences of the risks are high or unacceptable; other risks may be accepted and simply monitored.

Tip

The risk management literature uses the term contingency plans in various ways. In CMMI, a risk contingency plan is the part of a risk mitigation plan that addresses what actions to take after a risk is realized.

Hint

Reward personnel who prevent crises, not those who allow a crisis to happen and then heroically resolve it.

Hint

One way to identify actions that will avoid, reduce, or control a risk is to perform a causal analysis on the sources of the risk. Actions that eliminate or reduce causes may be suitable candidates for inclusion in a risk mitigation plan.

Often, especially for high risks, more than one approach to handling a risk should be generated.

Tip

A risk mitigation plan should, when its associated threshold is exceeded, return the project to an acceptable risk level.

In many cases, risks are accepted or watched. Risk acceptance is usually done when the risk is judged too low for formal mitigation or when there appears to be no viable way to reduce the risk. If a risk is accepted, the rationale for this decision should be documented. Risks are watched when there is an objectively defined, verifiable, and documented threshold of performance, time, or risk exposure (i.e., the combination of likelihood and consequence) that will trigger risk mitigation planning or invoke a contingency plan.

Thresholds for supplier risks that affect the project (e.g., schedule, quality, or risk exposure due to supplier risks) are specified in the supplier agreement along with escalation procedures if thresholds are exceeded.

Hint

You can establish thresholds for different attributes (e.g., cost, schedule, and performance) and trigger different activities (e.g., contingency plan deployment and risk mitigation planning).

Adequate consideration should be given early to technology demonstrations, models, simulations, pilots, and prototypes as part of risk mitigation planning.

Typical Work Products

  1. Documented handling options for each identified risk
  2. Risk mitigation plans
  3. Contingency plans
  4. Disaster recovery or continuity plans
  5. List of those responsible for tracking and addressing each risk

Typical Supplier Deliverables

  1. Documented handling options for each identified risk
  2. Risk mitigation plans
  3. Contingency plans
  4. Disaster recovery or continuity plans
  5. List of those responsible for tracking and addressing each risk

Subpractices

  1. Determine the levels and thresholds that define when a risk becomes unacceptable and triggers the execution of a risk mitigation plan or contingency plan.

    Tip

    Thresholds trigger actions that may impact the work of personnel and relevant stakeholders. Thus, it is important to ensure that the motivation for particular thresholds and the actions they invoke are well understood by all who will be affected.

    Risk level (derived using a risk model) is a measure combining the uncertainty of reaching an objective with the consequences of failing to reach the objective.

    Risk levels and thresholds that bound planned or acceptable performance must be clearly understood and defined to provide a means with which risk can be understood. Proper categorization of risk is essential for ensuring an appropriate priority based on severity and the associated management response. There may be multiple thresholds employed to initiate varying levels of management response. Typically, thresholds for the execution of risk mitigation plans are set to engage before the execution of contingency plans.

    Tip

    Assigning responsibility for risk mitigation is easier to do if mitigation activities and responsibilities are documented in a plan, such as the project plan.

  2. Identify the person or group responsible for addressing each risk.
  3. Determine the cost-to-benefit ratio of implementing the risk mitigation plan for each risk.

    Risk mitigation activities should be examined for benefits they provide versus resources they will expend. Just like any other design activity, alternative plans may need to be developed and costs and benefits of each alternative assessed. The most appropriate plan is selected for implementation.

    Tip

    Alternative risk mitigation plans may be formally evaluated (using DAR) to choose the best one. Relevant stakeholders may play an important role in such an evaluation (particularly for risks that impact them).

  4. Develop an overall risk mitigation plan for the project to orchestrate the implementation of individual risk mitigation and contingency plans.

    The complete set of risk mitigation plans may not be affordable. A tradeoff analysis should be performed to prioritize risk mitigation plans for implementation.

    Hint

    If you integrate all risk mitigation plans and find that the result is not affordable, trim the list using the priorities assigned in SP 2.2 or reprioritize them using a group-consensus approach (e.g., multivoting within risk categories).

  5. Develop contingency plans for selected critical risks in the event their impacts are realized.

    Risk mitigation plans are developed and implemented as needed to proactively reduce risks before they become problems. Despite best efforts, some risks may be unavoidable and will become problems that impact the project. Contingency plans can be developed for critical risks to describe actions a project may take to deal with the occurrence of this impact. The intent is to define a proactive plan for handling the risk, either to reduce the risk (mitigation) or to respond to the risk (contingency), but in either event to manage the risk.

    Some risk management literature may consider contingency plans a synonym or subset of risk mitigation plans. These plans also may be addressed together as risk-handling or risk action plans.

SP 3.2 Implement Risk Mitigation Plans

Monitor the status of each risk periodically and implement the risk mitigation plan, as appropriate.

To effectively control and manage risks during the work effort, follow a proactive program to regularly monitor risks and the status and results of risk-handling actions. The risk management strategy defines the intervals at which risk status should be revisited. This activity may result in the discovery of new risks or new risk-handling options that can require replanning and reassessment. In either event, acceptability thresholds associated with the risk should be compared to the risk status to determine the need for implementing a risk mitigation plan.

Hint

Make sure you monitor both the mitigation activity as well as the risk itself. Don’t assume the risk is mitigated simply because the mitigation plan is executed. Unintended consequences or additional complexity may cause the risk exposure to increase when you expect it to decrease.

The acquirer shares selected risks with the supplier. Risks associated with the acquisition process are tracked and resolved or controlled until mitigated. This monitoring includes risks that may be escalated by the supplier.

Typical Work Products

  1. Updated lists of risk status

    Tip

    Weekly or monthly updates to risk status are typical.

  2. Updated assessments of risk likelihood, consequence, and thresholds
  3. Updated list of risk-handling options
  4. Updated list of actions taken to handle risks
  5. Risk mitigation plans

    Tip

    Incorporating risk mitigation plans into the project plan enables their status to be reviewed as part of the project’s regular progress reviews.

Typical Supplier Deliverables

  1. Updated list of risk status
  2. Updated assessments of risk likelihood, consequence, and thresholds
  3. Updated list of risk-handling options
  4. Updated list of actions taken to handle risks
  5. Risk mitigation plans

Subpractices

  1. Monitor risk status.

    After a risk mitigation plan is initiated, the risk is still monitored. Thresholds are assessed to check for the potential execution of a contingency plan.

    A mechanism for monitoring should be employed.

  2. Provide a method for tracking open risk-handling action items to closure.

    Refer to the Project Monitoring and Control process area for more information about tracking action items.

  3. Invoke selected risk-handling options when monitored risks exceed defined thresholds.

    Often, risk-handling is performed only for risks judged to be “high” and “medium.” The risk-handling strategy for a given risk may include techniques and methods to avoid, reduce, and control the likelihood of the risk or the extent of damage incurred should the risk (anticipated event or situation) occur or both. In this context, risk-handling includes both risk mitigation plans and contingency plans.

    Risk-handling techniques are developed to avoid, reduce, and control adverse impact to project objectives and to bring about acceptable outcomes in light of probable impacts. Actions generated to handle a risk require proper resource loading and scheduling in plans and baseline schedules. This replanning must closely consider the effects on adjacent or dependent work initiatives or activities.

    Tip

    To ensure that risk mitigation activities are performed properly, they must be planned, scheduled, and resourced, just like any other project activity.

    Refer to the Project Monitoring and Control process area for more information about revising the project plan.

  4. Establish a schedule or period of performance for each risk-handling activity that includes a start date and anticipated completion date.
  5. Provide a continued commitment of resources for each plan to allow the successful execution of risk-handling activities.
  6. Collect performance measures on risk-handling activities.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.15.25.131