In many of my other posts I've referred to the need for identifying issues and risks and managing them on an ongoing basis. This is done through adhoc informal communication and also formally as part of the weekly status reports and weekly status meetings.
As with the Project Communications Plan, whether or not your project or your customer requires the Risk Management Plan to be an actual deliverable, you should still create the plan and orchestrate your risk mitigation activities accordingly. By creating this plan at the beginning of the project and having the customer signoff on it, you will have done three very important things to set the right tone early on:
- Created a sense of importance and urgency around risk management
- Let your team know that this is important and will be tracked
- Let your customer know that you're on the ball as the Project Manager
The high-level items that should be covered in the Risk Management Plan are:
- Introduction
- Risk Management Planning
- Risk Identification
- Risk Analysis and Response Planning
- Risk Monitoring and Control
- Review/Approval
Introduction
This is merely a high-level description of what the document covers. For the purpose of Risk Management, I usually just put the definition in here to show understanding - something like this:
'Risk management is the systematic process of identifying, analyzing, and responding to project risk. It includes maximizing the probability and consequences of positive events and minimizing the probability and consequences of adverse events to project objectives.'
Risk Management Planning
In this section, we describe what is involved in planning for risk management for the project. Describe how meetings are going to take place to brainstorm on risk management and prioritizing the risks that are identified for ongoing tracking.
Risk Identification
Risk identification involves determining which risks might affect the project and documenting their characteristics. This section should identify the participants in the risk identification process. This is usually going to be the entire delivery team led by the Project Manager, and the customer-side team led by the project sponsor.
It should be noted here that risk identification is an iterative process. Several cuts will be taken by the teams or subsets thereof at the beginning of the project, but the risks list will also be reviewed and revised throughout the project.
Risk Analysis and Response Planning
Risk analysis is the process of assessing the impact and likelihood of the identified risks. Identify in this section how the risks will be analyzed and prioritized. Risk analysis requires that the probability and consequences of the risks be evaluated using established analysis methods and processes and those methods and processes need to be defined and described here in as much detail as possible.
Risk response planning is the process of developing options and determining actions to enhance opportunities and reduce threats to the project's objectives. In other words, identifying ways to mitigate the identified risks as much as possible should they actually occur. The effectiveness of response planning can actually directly determine whether certain risks increase or decrease for the duration of the project. Risk response planning must be appropriate to the severity of the risk, cost effective in meeting the challenge, timely to be successful, realistic within the project context, agreed upon by all parties involved, and owned by an assigned person
Risk Monitoring and Control
Risk monitoring and control is the process of keeping track of the identified risks, monitoring residual risks and identifying new risks, ensuring the execution of the risk plans and evaluating their effectiveness in reducing risk. Risk monitoring and control is an ongoing process for the life of the project.
This section should identify how the risks will be tracked on an ongoing basis. I usually do this with some sort of risk register - which is usually a separate spreadsheet (and may be combined with an issues list depending on the size of the project) or it is a separate ongoing section of the weekly status report.
Review/Approval
It is likely not necessary that the Risk Management Plan be a formal deliverable on the project. However, it is important that it be something that both the delivery team Project Manager and the customer-side project sponsor signoff formally and communicate the importance to team members on both sides of the project. Again, establishing this process and its importance at the beginning of the project will help ensure that everyone is considering and looking out for risk items throughout the engagement.