The Risk Management Plan

The Risk Management Plan is the key element of the Risk Management Process. It defines the Risk Process for the project, including Methodology, Roles and Responsibilities, Timing, Thresholds, Reporting, monitoring and review formats and procedures. You can find several templates on the net (like this one from PMHut), but what is really important is how you will use it, and how well it suits your own risk management processes. Amongst all criteria for judging the maturity of such a document, the two the most important in my eyes are the ability to manage threats as well as opportunities, and the ability to efficiently respond to a risk becomes an issue.

What is the risk? Why might it occur? How likely is it to occur? How bad or good might it be? Does it matter to the project? What can we do about it? When should we act? Who is responsible for the risk? Who is responsible for the response? These are all questions that should find answers in the Risk Register (part of the Risk Management Plan). This document must be reviewed and updated regularly, since new risks might arise during the lifetime of the project, and risks might realize, becoming issues, needing responses that might trigger new risks, etc.

In my Risk Register, I typically have 13 columns:

• The RiskID, which is the unique identification for a risk, used by everyone to refer to that specific risk.
• The ProjectID, which is the unique identification for the project within the corporate portfolio. If a risk is likely to happen in several project, it needs to be documented with several RiskIDs.
• The Risk Category helps predefining responses or owners. It also serves for reporting purposes, thus helping on the predetermination front for future projects.
• The Date Raised serves to track the evolution of the risk profile of a project. The more stable the risk register, the lower the risk profile of a project.
• The Risk Owner has the ultimate responsibility to monitor the risk, and to raise the occurence of the risk to the Risk Manager. This needs to be documented in the Roles and Reponsibilities section of the Risk Management Plan.
• The Risk Description is ... well ... the description of the risk.
• The Impact is the result of the Risk Qualitative Analysis process. This field will usually have three possible values (low/medium/high), or if you want to more precisely rank your risks, five possible values (very low/low/medium/high/very high).
• The Probability is the result of the Risk Quantitative Analysis process. This field will have similar values as the Impact (i.e. 3 or 5 possible values).
• The Priority is a calculated field (which is why I usually use an Excel spreadsheet for my risk registers, unless I have access to an Enterprise Project Management software. It is a combination of Probability and Impact, and you can live without it, it just allows a quicker filtering on those who need your attention.
• The Response Description is ... well ... the description of the response to the risk.
• The Response Type is one of the following: Avoidance, Trnsfer, Mitigation, Acceptance. This will also help monitoring the efficiency of the risk management processes.
• The Response Owner has the ultimate responsibility to act in the event of a risk realized. It can be someone else as the Risk Owner, and it needs to be documented in the Roles and Responsibilities section of the Risk Management Plan.
• The Realized Date is the date when a Risk has triggered. This is the moment when a RiskID leaves the Risk Register to enter the Issue Log to continue being monitored in this document.

I understand this might look a little cumbersome, but in most situations, it can be the difference between saving a project and pulling the plug...