Plan

1
 What is
Planning?
 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.
 Risks are planned by those who have the knowledge, expertise, background,
and resources to effectively deal with the risks.
 Planning answers the questions:
• Is it my risk? (responsibility)
• What can I do? (approach)
• How much and what should I do? (scope and actions)

2
 What is
 ThePlanning?
objectives of the Plan function are to:
• Make sure consequences and sources of the risk are known
• Develop effective plans
• Plan efficiently (only as much as needed or will be of benefit)
• Produce, over time, the correct set of actions that minimize risk and
impacts (cost and schedule) while maximizing opportunity and value
• Plan important risks first

3
Inputs and Outputs of the Plan Function

4
Inputs and Outputs of the Plan Function

5
Inputs and Outputs of the Plan Function

6
Inputs and Outputs of the Plan Function

7
Planning Decision Flow Chart
 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, and the plan is developed and
implemented.
* Planning Decision Flow Chart 8
Which Risks are Mitigated?
 Not all risks have to be mitigated, although all risks should be reviewed by
personnel familiar with the issues.
 Attempts to plan for the elimination of all risks are almost always futile efforts.
 The result of planning is a risk action plan. The types of risk action plans are:
• Research Plans: Strategy, actions, responsibilities, schedules, etc., for
conducting the research, evaluating, and reporting the results.
• Acceptance Rationale: Reasons for accepting the risk, including the current
conditions and assumptions that support the decision.
• Tracking Requirements: The indicators, thresholds, and tracking requirements
for watching the risk.
• Mitigation Plan: The mitigation strategy, actions, due dates, responsibilities,
etc., for mitigating the risk.
9
Methods and Tools for
Planning

10
Assign Responsibility: Is it My Risk?
 Once risks are identified and analyzed, they are reviewed by a project
manager or a designated person(s) to determine what to do with them.
 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:
• Keep the risk (it's yours).
• Transfer the risk upward within the organization or to another
organization.
• Delegate the risk within your own organization.

11
Assign Responsibility: Is it My Risk?
 The objectives of assigning responsibility for risks are to:
• Ensure that no risks are ignored, i.e., "fall through the cracks"
• Make effective use of expertise and knowledge within the project
• Ensure that risks are being managed by those with the appropriate abilities,
knowledge, and authority to commit resources for mitigation.

12
Assign Responsibility: Is it My Risk?

13
Responsibility Options
 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.

14
Responsibility Options

15
Responsibility Options

16
Questions to Consider
 This is a list of the type of questions to consider when assigning
responsibility for a risk or set of risks.
• Who could solve this risk?
• Who would have the power and authority to allocate resources?
• Who is accountable or can be held accountable for this risk?
• Who has the time to manage this risk?
• Who has the opportunity to take action?

17
Transfer Considerations
 While a transferred risk may be important to the one doing the transferring,
the receiver of the risk may not have the same viewpoint or give the risk the
same priority.
 The originator of the risk may need to develop a contingency plan in case the
transferee chooses not to mitigate the risk.

18
Methods and Tools for Assigning Responsibility

19
Determine Approach: What Can I Do?
 If the risk is your responsibility, then decide how to approach mitigating it.
• Do you know enough about the risk to decide? If not, research it.
• If the risk becomes a problem, can you live with the impact? or can the
problem be more efficiently dealt with later as opposed to now? If so,
accept the risk and expend no further resources managing it.
• If the risk can't be accepted, is there action you can take or must take (now
or later)? If so, mitigate the risk, develop and implement a mitigation plan.
• If there is no reasonable mitigation action that can or needs to be taken, but
you cannot accept the risk, watch the risk.

20
Determine Approach: What Can I Do?
 The objectives of determining a mitigation approach are to:
• Ensure that you know enough to make an informed decision.
• Pick an appropriate approach for effective management of the risk(s).
• Establish measurable mitigation goals to provide a target for evaluating
success and direction during the development of action plans.

21
Determine Approach: What Can I Do?

22
 Additional Project
Considerations
 When deciding what approach to take, consider these questions:
• What is currently important to the project, management, customer, or user?
• Are there critical milestones the project is currently facing?
• What limits and constraints does the project, organization, group, or
manager have?
• What milestones and limits are fixed? flexible?
• What resources are available for mitigation?
• How does this risk fit into the overall project issues and concerns?

23
Range of Mitigation Approaches

24
Range of Mitigation Approaches

25
Risk Action Plans

26
Planning Constraints
 There are many constraints that can affect risk planning. Some of these are:
• Project schedule limits or hard milestones
• Available personnel
• Hardware restrictions
• Total cost of risk impact
• Facility capacity and availability
• Risk management budget (e.g., certain percentage set aside for mitigation)

27
Using Existing Mitigation Plans
 When looking at a risk and deciding what approach to take, consider its
classification.
 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, then those
plans can be used.
 The following diagram shows that the newer risk M can use the existing
mitigation plan for a set of risks related to "incomplete requirements"
through the addition of two new actions.

28
Using Existing Mitigation Plans

29
Methods and Tools for Determining Approach

30
Define Scope and Actions: How Much and What Should I Do?
 Once mitigation has been chosen, the following questions must be answered:
• How complex will the mitigation be?
• How should it be documented?
• What is the strategy?
• What are the tasks?
 There are generally two choices, based on the nature of the risk, complexity of the
plan, and available resources:
• Action item list for less complex mitigation (one or more actions)
• Task plan with schedules and budgets for complex sets of actions
 The objective is to take a balanced approach in developing effective actions to mitigate
risk(s). In other words
• Avoid overplanning
• Don’t oversimplify 31
Define Scope and Actions: How Much and What Should I Do?
 The most effective solution is not always the first, most obvious, or
immediate one, particularly with complex risks.

32
Mitigation Goals
 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 of less than perfect
solutions.
 Mitigation plans should be periodically reviewed to ensure the mitigation
goals are still sound and being met.

33
Action Item List Vs. Task Plan
 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.

34
Action Item List Vs. Task Plan

35
What Type of Mitigation Plan is Sufficient?
 The type of mitigation plan needed for a risk(s) depends on many factors,
including the following:
• Relative importance of the risk(s)
• The complexity of the issues
• The breadth of expertise required to develop mitigation strategies
• Probability and impact of the risk (particularly catastrophic)
• Available planning resources (particularly personnel)

36
Return on Investment (ROI)
 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.
 Rule of Thumb: Don't spend more than $ 100 to mitigate a risk that will cost
$ 1000 if it becomes a problem.
 One way to measure this is to use the original risk impact.
 Note: Remember that mitigation actions can cause additional risks. Consider
those risks when determining the total cost of a mitigation plan.

37
Approval and Responsibility
 The responsible person for the risk gets whatever approvals are necessary for
the mitigation plan.
 Management approval may be needed to ensure that:
• Resources are not overcommitted
• Conflicting mitigation plans are not implemented
• Project objectives and constraints are not unintentionally violated
 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.

38
Project Plans and Mitigation Plans
 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.

39
Methods and Tools for Defining Scope and Actions

40
Methods and Tools for Defining Scope and Actions

41
Considerations for Mitigating a Set of Related Risks
 The most effective means of mitigating risks is to deal with them in sets,
particularly if a large number of risks have been identified.
 The planning process is modified with the following considerations when
dealing with a set of related risks:
• Is there a set of risks that would benefit from coordinated mitigation (a
mitigation area)?
• Do we know enough about these risks to proceed (their relationships,
causes and consequences)?
• What are the goals of mitigating this set of risks (in addition to individual
risk mitigation goals)?
• What strategies will address these risks, particularly the most important?
• What indicators are needed for monitoring a set of risks? 42
Considerations for Mitigating a Set of Related Risks
 The objectives of mitigating a related set of risks are to:
• Increase the cost-effectiveness of mitigation plans by eliminating duplicate
efforts
• Avoid conflicting mitigation goals and actions
• Integrate planning efforts and avoid unnecessary time developing plans.

43
Mitigation Areas
 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.

44
Analyzing a Set of Risks
 In analyzing a set of risks, there are several key things to look for:
• Causes and effects to identify common root causes or common effects that
need to be avoided.
• Interrelationships among risks and causes-cycles of relationships (e.g., A
causes B causes C causes D causes A) that can be broken or redefined.

45
Mitigation Goals for a Set of Risks
 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.

46
Strategies for a Set of Risks
 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.

47
Indicators for a Set of 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.

48
Guidelines and Tips
 Identify specific, implementable actions which will preempt problems.
 Create the desired future state; things will not get better on their own.
 Integrate risk mitigation plans with project plans when those plans affect
project schedules, budgets, and deliverables.
 Communicate mitigation plans to all affected personnel within the project,
organization, customers, subcontractors, etc.
 Do not lose sight of the end product when developing mitigation plans - don't
unknowingly compromise the end product while trying to fix the smaller
details.

49