The third activity Plan of the risk management paradigm is presented. In this activity the participants produce risk action plans for individual or sets of related risks. The participants are the individuals with the knowledge, expertise, background, and resources to effectively deal with the risks. Plan participants answers the questions
Lets go back and visualize Roger L Van Scoy's paradigm [Van Scoy 92, p.9] and what he said about the plan element. To refresh you memory, Van Scoy said:
"Risk planning is needed after a risk is identified and analyzed. This element includes developing actions to address individual risks, prioritizing risk actions, and orchestrating the total risk management plan. An individual risk action plan could take many forms, for example:
The paradigm illustrates a set of functions that are identified as continuous activities throughout the life cycle of a project. The Plan phase is highlighted in Figure Plan Risk Management Paradigm.
Figure Plan Risk Management Paradigm
Planning is the function of deciding what, if anything, should be done with a risk. Planning produces risk action plans for individual or sets of related risks. Those who have the knowledge, expertise, background, and resources to effectively deal with the risks plan risks. Planning answers the questions
The objectives of the Plan function are to:
The Figure Plan Activities shows the inputs and outputs of the plan function.
Figure Plan Activities
The Table Plan Data Items describes the data items shown in the Plan diagram.
The Risk Information Sheet has been processed in the Identify and Analyze phase. The Risk Information Sheet contains the risk statement and its supporting context statement. During the Analyze phase, the risk analyst adds to the risk information sheet for each risk values for impact, probability, timeframe, class, and rank. In the Plan phase the risk analyst adds information to the fields Assigned to, Mitigation Strategy, and Contingency plan and trigger. The Risk Information Sheet for Plan is an example of the areas to be filled in on the Risk Information sheet for Plan.
Risk Information Sheet for Plan
The marked areas indicate that the following fields will be completed during planning:
The Flowchart Planning Decision gives a detailed view of the progressive decisions that are made during risk planning. Risks are reviewed to make sure they are understood and clearly documented (e.g., consequences are added if this was not done during identification). Responsibility for the risk is then assigned, resulting in a risk that is kept, delegated, or transferred. If the risk is kept, an approach for dealing with it is determined by the responsible person or team. Additional research may be needed, the risk could be accepted as is, it could be watched, or it could be mitigated. If the risk is to be mitigated, a mitigation plan needs to be developed. The scope of the mitigation plan is determined (action items or a complete task plan), and the plan is developed and implemented.
Flowchart Planning Decision
This Flowchart Planning Decision gives a detailed view of the progressive decisions that are made during planning.
Throughout the Plan process the flowchart will be discuss along with other possible alternatives. Exercises dealing with each part of the flowchart will be given.
Not all risks have to be mitigated, although personnel familiar with the issues should review all risks. "Attempts to plan for the elimination of all risks are almost always futile efforts" [Charette 89]. The result of planning is a risk action plan. The types of risk action plans are:
All risks cannot be planned simultaneously. Risks are planned in the order of importance, which depends on the goals and constraints of the project, managers, and individuals. However, priorities will change. When deciding what approach to take, consider these questions.
Is it My Risk? Once risks are identified and analyzed, the project manager or a designated person(s) reviews them. They then determine who gets assigned the responsibility for the risk. Risks that are not assigned have a higher probability of being ignored until it is too late to take action. There are three choices in determining responsibility for risks:
It is important to remember at the beginning of planning to review the risk and make sure it is understood. In particular, if the consequences were not originally part of the risk statement, they should be explored (as much as possible) at the plan activity.
The objectives of assigning responsibility for risks are to:
The Figure Determining Responsibility below shows the decision process for determining responsibility.
Figure Determining Responsibility
The Table Assigning Responsibility further describes and provides examples of the three options for assigning responsibility. Accountability defines who is ultimately held accountable for the success or failure of mitigating the risk. Ultimately, the project manager is accountable. Responsibility refers to who is charged with the duty of developing and implementing (or overseeing) the risk action plan. Authority is defined as the right and ability to assign resources for mitigation.
Table Assigning Responsibility
The following is a list of the type of questions to consider when assigning responsibility for a risk or set of risks.
The person who transfers a risk may believe the transferred risk to be very important. However, the receiver of the risk may not have the same viewpoint or they may give the risk the same priority. The originator of the risk therefore, may need to develop a contingency plan in case the transferee chooses not to mitigate the risk.
While there are no specific methods or tools for assigning responsibility; however, the Table Plan Responsibility Methods or Tools summarize the methods and tools that assist this process.
Table Plan Responsibility Methods or Tools
|
Methods or Tools |
Description |
|
Planning Decision Flowchart |
Tool to remind planners of possible responsibility options and the criteria for selecting those options. |
|
Risk Information Sheet |
Template for documenting who is responsible for the risk. |
What Can I Do?
If the risk is your responsibility, then decide how to approach mitigating the risk. The following are ideas for the approach:
The objectives in determining a mitigation approach are to:
The Diagram Determining Approach shows a decision process for determining a mitigation approach.
Diagram Determining Approach
All risks cannot be planned simultaneously. Risks are planned in order of their importance, which depends on the goals and constraints of the project, the managers, and individuals. During the life cycle of the project, the priorities for the risks will change. When deciding what approach to take, consider these additional questions:
The Table Mitigation Approaches provides a description of the range of mitigation approaches that can be used for a particular risk or set of risks.
The Figure Risk Action Plan Approaches identifies four options that can be taken depending on the type of risk action plan type selected.
Figure Risk Action Plan Approaches 5-9
In determining an action plan for a risk or set of risks the four types of action are:
A research plan should document the actions and schedule for:
If the research schedule is lengthy, then indicators may also need to be identified to monitor the risk while it is being researched. Research ends with the action to reassign responsibility (if needed) and determine the next approach to take with the risk (accept, watch, or mitigate). Research can range from making a few telephone calls to prototyping a system component. Once responsibility is determined or verified, the next step is to determine what approach to take with the risk (accept, watch, or mitigate).
Example: Implementing new technology on a project can be a source of risk. If the technology is new enough or not well understood by the project staff, more information about the technology as well as the implications of using it might be required. The research plan would consist of a list of questions.
There is no action plan, however, the accepted risks are generally closed, and the justification or rationale for accepting the risk should be documented in case the conditions change later. These are usually risks that are not significant enough to justify any expenditure. The project is willing to accept the consequences.
If you have 500 risks can you deal with them all? Probably not, you will most likely have to accept some.
Example: Some risks may reflect the concern of one person (For example the software engineer might identify lack of training as a risk, because he/she has not used the JAVA language before; The computer engineer has no experience with designing hybrids boards), but they might not have an adverse impact on meeting project goals when the overall length of the project is considered (e.g., most staff members have received training or have experience in the area of concern). Risks, which have a narrow focus, can often be accepted because their impact on long term project goals is insignificant.
Monitor the risks and their attributes for early warning of critical changes in impact, probability, timeframe or other aspects. Decide what your goals for monitoring the risk are and what indicators will meet those goals [Basili 84]. Watched risks are usually those for which:
Tracking requirements include indicators for monitoring the risk, triggers or thresholds for taking action, and reporting requirements (e.g. how often, by whom, extent of the report, and when) are identified
Example: Possible changes in funding can be a source of risk. There is potential for significant impact if funding is lost, but the probability of losing funding might be low. The organization will monitor the status of funding to prevent being caught by surprise and being unprepared if funding is reduced.
A mitigation plan will document all of the actions required to mitigate the risk as well as supporting information such as tracking indicators and triggers. Mitigation plans may also introduce new risk to the project. There are two possibilities: (1) Action Item List and (2) Task Plan.
The scope of the mitigation plan (Action Item List and Task Plan) is a decision that gets made when you define the scope and actions. This will be covering in next section (Define Scope and Action) of this module.
Example: Schedule risks can be extremely important to time-critical projects. Risks that affect productivity will be ranked high in terms of priority, because low productivity will delay completion of the project and the window of opportunity will be missed. The project manager will likely take action aimed at keeping productivity high. Mitigation plans aimed at increasing productivity (e.g., getting training for the project staff) will be developed.
Contingency Plans
Not all mitigation plans can or should be carried out immediately, for example:
Contingency plans are held in reserve until specific conditions are true or certain events occur. The contingency plan is used to watch for certain conditions and events!
Contingency plans are plans for what to do in the future should something specific occur. The risk analyst does not have to immediately implement every mitigation plan. You risk analyst may find that their mitigation plan is just too expensive to carry out at this point in time. They can hold it in reserve until funds are available. They may not have the right people available to carry out specific mitigation actions so the risk analyst may wait until they have completed their current work assignments.
Management may not want to spend the mitigation funds until they absolutely need to. For catastrophic impact risks with very low probability, and only expensive mitigation options, the team may want to establish contingency plans that will reduce the impact to something more tolerable, if the probability of the risk takes a turn for the worse (i.e., increases).
Or the risk team has implemented a mitigation plan that isn't working and they need to put a contingency plan into effect when a certain trigger is reached. The plan then requires watching the risk so the risk analyst knows when specific conditions or an event occurs in order to implementing the mitigation plan.
There are many constraints that can affect risk planning. These will vary with each project and situation. It is important to identify these and periodically check to make sure the circumstances have not changed. Never take constraints for granted.
Examples:
Consider the risk's classification, when looking at a risk and deciding what approach to take. Classification of risks helps find related risks that may already have mitigation plans in place. If a new risk is already being addressed by other mitigation plans, and then those plans can be used. Risk documentation should be updated to identify the relationship and dependencies.
The Table Methods and Tools summarize the methods and tools for determining an approach for dealing with risks.
How Much and What Should I Do?
Once mitigation has been chosen, the following questions must be answered:
There are generally two choices, based on the nature of the risk, complexity of the plan, and available resources:
The risk teams or groups of analysts are very effective at performing complex tasks that require multiple viewpoints [Scholtes 88], such as planning a complex risk.
The objective is to take a balanced approach in developing effective actions to mitigate risk(s). In other words in defining the scope and actions:
The most effective solution is not always the first, most obvious, or immediate one, particularly with complex risks.
The Diagram Mitigate Approach shows the decision process for developing and documenting mitigation strategies.
Diagram Mitigate Approach
It is important that a goal for mitigation be identified and documented. Goals will change, as circumstances and conditions improve or deteriorate, or as the constraints of the project force acceptance have less than perfect solutions. Mitigation plans should be periodically reviewed to ensure the mitigation goals are still sound and being met.
As an example the development of the requirements for a software or hardware system is behind schedule. The scheduled completion date for system development cannot be delayed. The mitigation goal is to complete the requirements without slipping the overall development completion date.
The Table Action Item List vs. Task Plan summarizes the recommended contents for either an action item list or a task plan. Action item lists are simpler, but are not always appropriate for the complexity of the mitigation. Action item lists and task plans are two extremes. Anything in-between can also be used. It is not recommended that anything less than an action item list be used.
Table Action Plan List vs. Task Plan
An example of a Task Plan for risk ID 7 is given in: Plan Case Study for Risk 7.
The type of mitigation plan needed for a risk(s) depends on many factors, including the following:
In relation to risk mitigation, return-on-investment (ROI) indicates how much benefit or reduction in risk exposure is achieved compared to the costs of planning and implementing the mitigation actions. One way to measure this is to use the original risk impact. A rule of thumb is 1:10 don't spend more than $100 to mitigate a risk that will cost $ 1000 if it becomes a problem. Remember that mitigation actions can cause additional risks. Consider those risks when determining the total cost of a mitigation plan.
The responsible person for the risk gets whatever approvals are necessary for the mitigation plan. Management approval may be needed to ensure that:
Specific actions may be distributed across several people. The responsible person for the risk is also responsible for assigning specific actions and seeing that all actions are effectively carried out
Complex or costly mitigation plans may impact the project plans. The project manager and personnel responsible for risks must keep in mind the impacts mitigation plans have on the current set of project plans. Project plans may need to be changed to reflect the activities being carried out to mitigate risks.
Mitigation Goals and Success Measures
The risk analyst must set a realistic, measurable (or verifiable) goal for mitigating the risk, for example:
Define the success criteria because the risk analyst needs to know when they've succeeded or failed. For example all current change requests implemented by DD/MM/YY will result in no change to the scheduled milestones.
Mitigation goals should give the risk analyst a target to aim for when developing mitigation plans. They are very specific to the risk and to the current circumstances. The mitigation goals should be realistic, and they should be measurable or verifiable through observation or some other technique. Success measures are used to help measure or verify the achievement of the mitigation goals.
Mitigation goals can change as the mitigation plan is developed. For example, it might be determined that there is no way to achieve the goals within a reasonable budget or timeframe, so the goals must change. Goals can also change with time as other, more critical issues arise and affect what success the mitigation plan can have.
For example, suppose, before the mitigation plan associated with the goals/measures can be fully implemented, there is a loss of a key customer, and a new customer with funding is found to pick up the slack. The new customer may have additional changes that it is expedient to accept, even though the scheduled milestones change.
Exercise: For Risk ID 7 what Goals & Success measures would you look for? Give an answer for a possible Goals & Success measure.
Risk ID 7: Science requirements have substantial TBDs; late completion of TBDs likely, with reduction in adequate testing time, possible science application software failure, incorrect science data being captured, hardware damage if incorrect safety limits were provided, extensive rework and substantial cost overruns, mission failure if problems not found before system is in operation.
Answer: Reduce the number of TBDs to 5% and by the date DD/MM/YY.
Exercise: For Risk ID 14 what Goals & Success measures would you look for? Give an answer for a possible Goals & Success measure.
Risk ID 14: Contracting a different test facility for acoustical testing; parts may be insufficiently tested or parts may be damaged with excessive testing.
Answer: Avoid over testing or under testing, set upper or lower limits.
Exercise for a Mitigation worksheet.
This is an example of a Mitigation Planning Worksheet it is NOT the Risk Information Sheet. The manager, J. Johnstone has begun to document the goals of his mitigation activity for risks ID 7 assigned to him. Complete the work sheet and compare you're results with the work sheet after J. Johnstone completed his.
Before is the plan mitigation worksheet-1.
After is plan mitigation worksheet-2.
The Table Methods or Tools relates the type of mitigation plan with the methods or tools used to develop the type of mitigation plan.
Frequently, the most effective means of mitigating risks is to deal with them in sets, particularly if a large number of risks have been identified. Large numbers of risks can be made more manageable by classifying them into related sets. The planning process is modified with the following considerations when dealing with a set of related risks:
The objectives of mitigating a related set of risks are to:
In Analyze classification provides a view into the risks based upon related sets. If the basis for this relationship is the "big picture" of the risks in the project as opposed to identifying sets for mitigation, mitigation areas may need to be identified by looking for a common basis or reason for mitigation (e.g., the subsystem being impacted or who is responsible for the risk). Mitigation areas may include risks that are on the top N list of risks as well as those that are not.
Example: It might make more sense to group all of the compiler risks into a set to determine the common causes, take advantage of common mitigation actions, and ensure an integrated schedule of mitigation actions that will benefit the system component development efforts that depend on the compiler.
In analyzing a set of risks, there are several key things to look for:
Mitigation goals for a set of risks can be considerably more complex than the goals for a single risk. A hierarchy of goals may be appropriate, with a high level goal for the set and lower level goals for specific risks (especially any top N risks). It is important that all goals be identified and documented.
The focus of the planning should be on mitigating the high priority (i.e., top N) risks. While mitigating all of the risks in the set is a desirable goal, it may not be realistic. Therefore, it is important to remember the relative priority or criticality of the risks to insure that the selected strategy deals with the most important or critical risks.
Monitoring a set of risks usually requires a hierarchy of indicators. Indicators can be high level or abstracted, providing a summary status of the set. Additional indicators for specific risks in the set, particularly if there are any top N risks in the set, may also be used. If there are contingency plans, triggers or thresholds for those are also needed.
Guidelines and Tips for Planning:
There are four approaches to Plan and each one has an associated action plan:
[Basili 84] Basili, Victor R. & Weiss, David M. "A Methodology for Collecting Valid Software Engineering Data." IEEE Transactions on Software Engineering SE-IO, 6 (November 1984): 728-738.
[Charette 89] Charette, Robert N. Software Engineering Risk Analysis and Management. New York: McGraw-Hffl, 1989.
[Rowe 88] Rowe, William D. An Anatomy of Risk. Malabar. Fla.: Robert E. Krieger, 1988.
[Scholtes 88] Scholtes, Peter R. The Team Handbook: How to Use Teams to Improve Quality. Madison, Wi.: Joiner Associates, Inc., 1988.
[Boehm 89] Boehm, Barry. IEEE Tutorial on Software Risk Management. New York: IEEE Computer Society Press, 1989.
[Kepner 81] Kepner, Charles H. & Tregoe, Benjamin B. The New Rational Manager. Princeton, N.J.: Princeton Research Press, 1981.
[Lumsdaine 90] Lumsdaine, Edward & Lumsdaine, Monika. Creative Problem Solving. New York: McGraw-Hill, 1990.
[Xerox 92] Xerox Corporation and Carnegie Mellon University, The University Challenge: Problem-Solving Process User Manual. Stamford, Ct.: Xerox Corporation, 1992.
© January 1, 2006 James C. Helm, PhD., P.E.