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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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/.
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.
If your project uses safety and security analysis methods, incorporate these methods as part of the risk management strategy.
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).
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
Subpractices
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.
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.
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.
Risk categories are the “bins” used for collecting and organizing risks. Identifying risk categories aids the future consolidation of activities in risk mitigation plans.
Categories are used to group related risks that can often be addressed by the same mitigation activities, thereby increasing risk management efficiency.
A risk taxonomy can be used to provide a framework for determining risk sources and categories.
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.
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
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).
For each risk category, thresholds can be established to determine acceptability or unacceptability of risks, prioritization of risks, or triggers for management action.
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.
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.
Establish and maintain the strategy to be used for risk management.
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.
Some large acquisition organizations develop a standard risk management strategy template that is tailored to meet the needs of individual projects.
Typical Work Products
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.
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.
“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.
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.
Establish a work environment in which risks can be disclosed and discussed openly, without fear of repercussions. (Don’t shoot the messenger!)
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
Typical Supplier Deliverables
Subpractices
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.
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.
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.
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.
Refer to the Project Planning process area for more information about identifying project risks.
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.
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.
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
Typical Supplier Deliverables
Subpractices
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.
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.
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.
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.
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.
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).
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.
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.
Reward personnel who prevent crises, not those who allow a crisis to happen and then heroically resolve it.
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.
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.
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
Typical Supplier Deliverables
Subpractices
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.
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.
The complete set of risk mitigation plans may not be affordable. A tradeoff analysis should be performed to prioritize risk mitigation plans for implementation.
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.
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.
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 Supplier Deliverables
Subpractices
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.
Refer to the Project Monitoring and Control process area for more information about tracking action items.
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.
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.
3.15.25.131