RISK MANAGEMENT PLAN
Click here to download the MS Word (295 KB)
• Purpose of Risk Management Plan
This plan describes the standardized, structured process the project/plateau/evolution can use to identify, categorize, analyze, and mitigate risks. This plan also describes the method used to determine risk status and measure the progress of risk mitigation efforts. In addition, this plan contains the results of the risk identification (i.e., a risk list), categorization (i.e., risks grouped by category), analysis (i.e., risk analysis tables), and mitigation planning (i.e., mitigation strategies, analysis of the strategies, planned implementation, and results of implementing the planned mitigations).
The risk management approach documented in this plan is based on proven risk management techniques developed by the Software Productivity Consortium. The Consortium and its members have successfully applied this methodology on numerous projects/projects, and the methodology is reliable, adaptable, and well suited to the current project/plateau/evolution .
The key ingredients of this methodology are:
• A dedicated Risk Analyst is responsible for the risk analysis and management with a reporting line directly to Product Assurance (or management, as appropriate) . The Risk Analyst has been trained in the methodology (or is experienced with the methodology) and has been dedicated to the project/plateau/evolution . The Risk Analyst is also an integral part of the project/plateau/evolution team, thus ensuring a comprehensive appraisal is conducted.
• The risk management method is consistent and comprehensive. This method identifies, analyzes, and evaluates technical and nontechnical risks. Risks are categorized to aid in analysis, selection of mitigation strategies, and tracking related risks; that is, risks that are tightly coupled or linked in some way are assigned to the same category because they are best tracked and evaluated together. Examination of the risk relationships provides insight into how the risks interact and their potential project/plateau/evolution impact. The risk analysis provides criteria for determining which risks are sufficiently significant and must be mitigated and continuously monitored.
• Periodic risk reviews are conducted. During the reviews, significant risks are reanalyzed, and the progress of their mitigation efforts is determined. Also, during the reviews, newly identified risks, or risks that were not considered significant, are reexamined. The methodology is then reapplied.
Section 2 describes in more detail the risk management methodology that is used on the project/plateau/evolution and includes techniques that ensure that risks, once identified, are properly tracked and mitigation strategies implemented at the appropriate time.
• The Risk Management Method
The 7 steps in risk management are:
• Determine Objectives and Stakeholders
• Identify Risks
• Analyze Risks
• Review Risk Analysis
• Evaluate Mitigation Strategies
• Plan Risk Mitigation
• Mitigate Risks
These steps are repeatedly performed, in order, during the life of the project/plateau/evolution .
• Determine Objectives and Stakeholders
Project/plateau/evolution objectives scope the work to be done and ensure the work stays focused on the activities that determine project/plateau/evolution success. Understanding the project/plateau/evolution objectives helps limit the number of risks that must be analyzed, because risks that do not jeopardize project/plateau/evolution success can be eliminated from consideration.
The stakeholders are those who have a vested interest in the project/plateau/evolution or its outcome. Identification of the project/plateau/evolution stakeholders ensures that the stakeholder perspectives are considered during risk identification and mitigation. Although not all stakeholders participate in the risk management process, all stakeholders are represented.
• Identify Risks
Risk identification is achieved by executing the following tasks:
• Examination of project/plateau/evolution documentation . During the examination, the Risk Analyst and stakeholder representatives look for conflicting or ambiguous statements, assumptions, and differences between current capabilities and perceived needs.
• Brainstorming session(s) . Stakeholders meet and discuss possible risk areas.
• Completion of a risk identification questionnaire . A blank questionnaire is attached.
• Risk categorization . Risks are grouped into 6-20 groupings of related risks. Categorization schemes may be faceted or hierarchical depending on the number of risks that have been identified and how they relate to each other.
• Analyze Risks
During risk identification, the stakeholders enter the risks they have identified and grouped into a risk table (see Table 2 and Figure 2.) The table contains a unique identifier for each risk, the risk's name, a brief description of the risk, and the risk's grouping.
Table 2. Risk Table
Original |
Current |
|||||||||||||
Risk ID # |
Risk Name |
Description |
Risk Grouping |
Risk Timing |
Risk Trigger |
P |
C |
RE |
Risk Mitigation |
Results |
P |
C |
RE |
|
The following describes the entries in Table 1
Item 1. Risk ID # - Sequential number
Item 2. Risk Name - Identification of risk - entered by risk identifier (any stakeholder)
Item 3. Risk Description - Description of risk - entered by risk identifier
Item 4. Risk Grouping - Group that relates this risk to other risks that will impact this risk or that will be impacted by this risk - entered by risk identifier, updated by Risk Analyst
Item 5. Risk Timing - When the risk must be mitigated - entered by the risk identifier, updated by the Risk Analyst
Item 6. Risk Trigger - Early warning signs that will indicate the occurrence of the risk - entered by the risk identifier, updated by Risk Analyst
Items 7-9 are computed for original risk
Item 7. P - Probability of risk occurring- determined by the Risk Analyst
Item 8. C - Consequence if risk occurs - determined by the Risk Analyst
Item 9. RE - Risk exposure (Risk Exposure = Probability x Consequence) - computed
Item 10. Risk Mitigation Options - Different strategies that might be used to mitigate the risk - entered by Risk Analyst after talking to affected groups
Item 11. Results - Results of the risk mitigation strategy - entered by those who performed the risk mitigation or the Risk Analyst
Items 12-14 are computed based on the results of executing the risk mitigation as planned
Item 12. P - Probability of risk occurring- determined by the Risk Analyst
Item 13. C - Consequence if risk occurs - determined by the Risk Analyst
Item 14. RE - Risk exposure (Risk Exposure = Probability x Consequence) - computed
Items 10-14 are repeated for every risk iteration.
Figure 2. Risk Table Entries
The Risk Analyst computes the probability and expected consequence for each risk in the risk table. Both probability and consequence are determined by examining the factors that contribute to the risk and calculating a weighted average of the factors. The risk factors for the risk probability, P, are in Figure 3. The risk factors for the risk consequence, C , are in Figure 4. Experience has proven that using risk factors to establish the risk measures helps the Risk Analyst consider all aspects of the risk and, consequently, provides a more accurate analysis of the risk than can be determined by simple inspection.
The Risk Analyst also considers the temporal aspects of the risk. When is the risk most likely to occur? How frequently will the risk occur and will its impact change over time? Consideration of issues like these helps the Risk Analyst determine the profile of the risks over time. After individual risk analysis is performed, the Risk Analyst examines the risk groupings to determine how the risks will interact with each other. As the risk analysis continues, the risk calculations and the groupings are revised so that more accurate risk measures can be created. These risk measures are the main input for creation of the detailed risk management plan.
For each risk, P and C are plotted on an ISO-risk contour (see Figure 5.) The ISO-risk contour helps the Risk Analyst and the stakeholders visually compare the results of the risk analysis. However, the ISO-risk contours are a static representation of the risk analysis. They represent the risk calculations at a specific point in time. Another technique, the risk referent, is used to communicate risk exposure over time. Risk referents help the Risk Analyst and the project manager understand the interaction between the life-cycle phases and the risk groupings. (More details regarding the use of the risk referent are described in Section 2.6.)
|
Maturity Factor |
Complexity Factor |
Dependency Factor |
Stability Factor |
Technology exists and can be used "as is" |
Simple relative to current environment |
Entirely within project control |
External factors will not make any changes |
Technology requires minor change before use (<25%) |
Minor complexity relative to current environment |
Depends on existing product supplied from outside organization |
External factors will make minor changes (<25%) |
Technology requires major change before use (<50%) |
Moderately complex relative to current environment |
Depends on supply and modification of existing product from outside organization |
External factors will make major changes (<50%) |
Technology requires significant design and engineering before use (<75%) |
Significantly complex relative to current environment |
Depends on new development from outside organization |
External factors will make significant changes (<75%) |
State of the art, some research done |
Extremely complex relative to current environment |
Depends of finding development from outside organization |
External factors will make constant changes |
Figure 3. P Table
|
Magnitude |
Capability Factor |
PR Factor |
Cost Factor |
Schedule Factor |
| 0.1 Low | Minimal or no consequences, unimportant | Occasional harsh write-ups in newspapers | Budget estimates not exceeded, some transfer of money | Negligible impact on other development schedules; changes compensated by available slack |
| 0.3 Moderate | Small reduction in capability (10% requirements not met) | Called before legislature or investigative body | Cost estimates exceed budget by 1 to 5% | Minor slip in schedules (less than 1 month), small adjustments in milestones required |
| 0.5 High | Some reduction in capability (25% requirements not met) | Unfavorable public opinion | Cost estimates increased by 5 to 20% | Other schedules slip in excess of 3 months; a few projects are shelved |
| 0.7 Significant | Significant reduction in capability (50% requirements not met) | Budget cuts as political retribution | Cost estimates increased by 20 to 50% | Other schedules slip up to 12 months; many projects are shelved |
| 0.9 Catastrophic | Technical goals cannot be achieved | Severe pressure to replace key officials | Cost estimates increased in excess of 50% | Other schedules slip more than 12 months; most projects are shelved |
Figure 4. C Table
The risk profiles, ISO-risk contours, and risk referents are evaluated by the Risk Analyst. The purpose of the evaluation is to prioritize the risks and determine which risks and risk groupings will have significant impact on the project and warrant risk mitigation. In large projects , all risks cannot be actively tracked and controlled. Prioritizing risks is an approach for determining which risks will be managed.
• Review Risk Analysis
The stakeholders review the results of the risk analysis to ensure that all risks are identified and that the relative impacts of the various risks are consistent. After the review is complete, the Risk Analyst makes changes, as appropriate, based on review comments, and stakeholder consensus is reached. Consensus does not necessarily mean that all stakeholders agree, but that there is no strong minority dissension among the stakeholders.
Figure 5. ISO-Risk Contour Chart
• Evaluate Mitigation Strategies
The Risk Analyst works with stakeholders to develop risk mitigation strategies for each risk or risk group. The results of the risk analysis and the causes, sources, and components of each risk are considered when formulating risk mitigation strategies. The Risk Analyst also considers the interactions of risks and the impact each mitigation strategy may have on other risks. A matrix is developed which maps each mitigation strategy to one or more risks. The matrix provides a visual representation of which risk will be impacted by a specific strategy. Note: impact may be positive or negative. That is, some mitigation strategies will positively impact one risk while negatively impacting another. For example, providing necessary training for selected personnel positively impacts the risk of reduced productivity because the staff has insufficient skills to efficiently perform the necessary tasks. However, there may be a risk of not meeting the schedule commitments based on the number of tasks to be performed and the currently available staff to perform them. This risk would be negatively impacted by the mitigation strategy of sending the current staff to training since it would reduce the hours available to perform the scheduled tasks.
The Risk Analyst evaluates the potential risk mitigation strategies for each risk on the priority list. The Risk Analyst selects the appropriate mitigation strategies based on a prediction of how each of the strategies will impact the probability and consequence of the risk and the costs associated with implementing the strategy. Once a strategy has been selected, the execution of the strategy is added to the project/plateau/evolution plan and the results of the execution of the strategy are recorded in the risk table.
• Plan Risk Mitigation
Planning risk mitigation ensures that the selected mitigation strategies are executed at the correct time. And, in many cases, the timing is critical for a strategy to succeed. Consequently, it is important to look for and recognize the warning signs that indicate the risk condition is approaching. These warning signs are called risk triggers. For example, if 10 skilled staff members are needed to perform a specific task, as that start date for the task approaches, there should be increasing confidence that the identified staff will be available. An appropriate set of risk triggers for this risk is:
Trigger #1 - x% of the needed staff is not identified and committed to the project by 2 months prior to the task start
Trigger #2 - x+y% of the needed staff is not identified and committed to the project by 1 month prior to the start date
Trigger #3 - x+y+z% of the needed staff is not identified and committed to the project by 2 weeks prior to the task start date
And so on. Notice that the triggers indicate what is needed and when it is needed. If any of the trigger conditions occur, the action plan for the selected mitigation strategy is implemented. In the above example, the mitigation strategies are trigger related. The mitigation strategy for the first trigger condition might be to consider outside hires. The mitigation strategy for the second trigger condition might be to consider internal transfers and identify a number of consultants that could provide the skills temporarily, if needed. And the mitigation strategy for the third trigger condition might be to commence contracting with the identified consultants. Thus, risk triggers are a way to ensure the appropriate risk mitigation strategy is implemented at the right time. The risk triggers and their associated mitigation strategies are part of this risk management plan and are input to the overall project/plateau/evolution plan.
The risk referent is a plan for the amount of risk that will be tolerated throughout the contract. A sample risk referent is shown in Figure 6. The risk exposures for all of the risks (or for each risk group) are summed to determine the risk referent for a particular point in time. The planned risk mitigation strategies are then estimated to determine how the risk exposure should be impacted over time. As the project progresses, the risk exposure for the risks are computed and compared with the plan. The deviation of actual risk exposures from the planned risk referent is handled just as deviations from other plans are handled. If the actual risk exposures are within the referent values, no additional action is required. If, however, the actual risk exposures are above the referent values, additional mitigation action is required.
• Mitigate Risks
Risk mitigation is the execution of the risk plan. However, to effectively mitigate risks, the steps in the risk management method (i.e., steps 1-7) need to be performed regularly. The risk table should be reviewed periodically by the Risk Analyst and the other stakeholders, and risk status should be a part of the regular status reports.
Figure 6a. Initial Risk Referent
Figure 6b. Risk Referent Tracked Against Actuals
• Summary
This is a proactive risk management approach. Performing a risk analysis prior to estimating the project parameters enables the team to maintain project/plateau/evolution control and provide quality products within the proposed cost and schedule. We have successfully applied this method in the past on tightly constrained projects/projects and feel comfortable and confident with the approach.