Instructions

Risk Plan Overview
Risk Event Description
What is the event?
A Source of a risk or hazard – the thing which has the potential to harm or assist e.g. a dangerous chemical, competitors, government.
An Event or Incident – Something that occurs such that the source of risk has the impact concerned e.g. a leak, competitor expands into or leaves your market, new or revised regulations, or some level of observation reaching a particular trigger level.
A Consequence, outcome or impact on a range of stakeholders or assets e.g. environmental damage, loss or increase of market/profits, regulations increase or decreased competitiveness
Risk Drivers
What are the conditions, actions, or events that are likely to trigger the risk event to occur or is a leading indicator to the risk event occurring?
There are two beneftits to identifying risk drivers: – Focus attention on the probable root cause(s) to aid in developing a Risk Response Strategy – Identify events or trends that should be monitored
Response/ Mitigation Strategy
What action(s) will be taken to limit the likelihood of these event occurring or limiting the impacts?
Accept:	This response accepts or ignores the risk. This may be the appropriate choice when the impact or likelihood of the risk is so low that it does not warrant further attention or if you have no control whatsoever over the impact or likelihood of the risk. (e.g. the risk that your project will be terminated or be placed on hold due to a company merger).
Transfer:	This response involves moving all or part of the risk to another party. (e.g. purchase automobile insurance and transfer the risk to the insurance company, for a small monthly fee of course). Transferring risk comes with a cost.
Mitigate:	This response involves reducing the likelihood that the risk will happen, reducing the impacts of the risk or both. This is what most people are referring to when they are discussing risk management. Most risks can be mitigated with some effort. Although it is unlikely that you can reduce the impact and likelihood of occurrence to zero, this would in essence be eliminating the risk, it is often possible to significantly reduce them. For example, if you have a technical team member who is critical to the success of the project and if that person left, the project schedule would be at risk, you may be able to mitigate the risk by training a backup person to reduce the impact or offer that individual a bonus or incentive to stay reducing the likelihood of occurrence.
Avoid:	This response focuses on eliminating the risk from the project. This sounds like a great choice, so you might ask why we don’t choose this all the time. The reason, it often comes at great cost. To eliminate a risk generally requires that you remove the source of the risk from scope. For example, you may have a schedule risk associated with a new version of software that has not been released yet by the vendor. Although the customer may be expecting this software as part of their project, removal from scope would eliminate this risk.
These general response strategies can be used in combination to address a single risk event. This may be done in the event that your chosen strategy is not working effectively or as a way to attack certain types of risks. For example, you may begin by mitigating a risk reducing both the likelihood and impact. The remaining risk could then either be avoided by a smaller scope reduction, transferred to a vendor or accepted.
Contingency Plan
What action(s) will be taken if this event occurs?
Complete the “Contingency Plan” column for all risk events that the Project Manager deems necessary to adequately address the risks of the project.
The contingency plan describes what needs to be done in the event that the risk actually occurs. When the risk event actually occurs, it is no longer a risk event; it is simply an event and may require a response or plan to be activated. The project manager will need to determine what the criteria are to trigger the need for a contingency plan. One method is to use the “Total Score” column of the risk plan template to determine a threshold that requires the development of a contingency plan. For example, a total score of 85 or higher may be the threshold which triggers the need for a contingency plan to be developed. However, there may be a need to develop a contingency plan for a risk event that scores much lower due to likelihood, but has a high impact. In the end, the project manager must be comfortable with the decision around when to develop a contingency plan.
Risk Timeframe
Critical date(s) or period of exposure
Some risks are related to specific events, milestone dates or time periods. These critical dates should be documented to focus attention on the associated risk at the appropriate time.

Impacts Defined

Risk impact level Matrix
Likelihood	Low	Medium	High
Unlikely	Likely	Almost Certain
Impacts	Low	Medium	High
Schedule	No Impact to Critical Path or Field Work	Potential to Affect Critical Path or Field Work	Certain to Affect Critical Path or Field Work
Cost	Less Than	$ 100,000	$ 100,000	to	$ 500,000	Greater Than	$ 500,000
Quality	Minor impact to product deliverables	Moderate impact to product deliverables	Major impact to product deliverables
Safety	No Impact to worker safety	Minor impact to worker safety	Major impact to worker safety
Scope	< 1%	2% to 5%	> 5%

Risk Plan

Yes

Project Name: Risk Plan

Date: ##/##/##

Impacts

Risk Event Description What is the event?

Category Sub-project, Project Phase, Location etc. (Optional)

Likelihood

Schedule

Cost

Quality

Safety

Scope

Total Score

Risk Event Drivers What are the conditions, actions, or events that are likely to trigger the risk event to occur or is a leading indicator to the risk event occurring?

Response/ Mitigation Strategy What action(s) will be taken to limit the likelihood of these event occurring or limiting the impacts?

Contingency Plan What action(s) will be taken if this event occurs?

Owner

Risk Timeframe Critical date(s) or period of exposure

Organizational or Cross-Project Impacts

Comments

Status

Insufficient number of skilled internal technical resources available to support the development of the new system.

Development

Drivers to monitor: – Development schedules slips – Excessive overtime is needed to keep pace with the schedule – High number of quality errors discovered during the testing cycle Drivers that have occurred: –

Planned Actions: – Train additional internal resources – Hire additional contractors – Add contingency to the budget to allow for overtime work Completed Actions: –

Planned Actions: – Outsource portions of the development to an outside vendor – Adjust project schedule and budget

Jane Smith

3/1/11 – 6/30/11

Yes

ERROR:#REF!

Drivers to monitor: – Drivers that have occurred: –