Risk management is generally accepted as a fundamental part of project management. Most project governance standards require you to define a risk management plan, which describes how you will manage risk on the project. In this article, we describe the elements that will be present in a typical risk management plan.
Risk Strategy
The risk strategy is an overview of your approach to managing risks on this project. It should specify what organizational policies you comply with and whether you are adopting a qualitative or quantitative risk management approach. Integral to the risk strategy is risk scope, which outlines the specific elements of the project that fall within the purview of the risk management process. You might exclude particular components from the risk scope because another department manages them. For instance, the procurement department might handle all risks associated with vendors - such as supply chain disruptions, vendor compliance issues, or contractual disputes.
Methodology
The methodology covers the specific processes, tools, and sources of information that the team will use to manage risk. For instance, your project might use the PMBOK risk management process and store all risks in Jira. Typical sources of risk information would be the project plan, requirements specification, schedule, issues log, and so on.
Roles and Responsibilities
This section describes who is responsible for various parts of the risk process. Typical responsibilities include:
Preparing the risk management plan
Approving the risk management plan
Organizing and chairing risk workshops
Attending risk workshops and other meetings
Development of risk response plans
Creation and maintenance of the risk register
Reporting risk status
Ensuring the risk process is being adhered to
Funding
Funding is a crucial part of the risk management plan as it lays out the resources available for managing risk. It should cover the cost of all risk-related resources, including staff and tooling. It should also indicate how the project funds both treatment strategies and contingency plans. For example, any contingency plan under $25,000 might be funded from the general project contingency, whereas plans over that amount require the approval of the project sponsor.
Timing
The timing aspect of the plan specifies when and how often risk management activities will be conducted. You would typically schedule a risk workshop at the start of a project and then have regular risk review meetings as the project progresses.
Risk Categories
Risk categories provide a structure for classifying risks, which helps both in identification and reporting. A typical risk breakdown structure is as follows:
Technical
Management
Organizational
Commercial
External
You can also categorize risks according to a work breakdown structure, a cost breakdown structure, an organization breakdown structure, etc.
Definitions of Risk Probability and Impacts
Your organization likely has standard definitions for risk probability and impact, but you may need to customize them for your project. Attaching specific dollar amounts to each impact level, proportionate to your project budget, is common. For example, a low-impact risk might have a threshold of $10,000 in your project but a higher amount in a larger project.
Risk Matrix
A risk matrix is an essential risk management tool that calculates the risk level by cross-referencing the impact and probability. The matrix typically takes the form of a heat map, with each risk level given a color.
Stakeholder Risk Appetite
Understanding the risk tolerance of key stakeholders enables you to define how much risk your project can bear. Document this by way of strategies for dealing with various levels. For instance, the plan could specify that all low-level risks can be ignored, but high-level risks must be treated until they are medium-level or lower. If you use quantitative risk management, you can specify a numerical threshold for the risk appetite.
Reporting Formats
This section defines how you will communicate the outcomes of the risk management process. At a minimum, it must describe the risk register's contents; it should also specify the format, frequency, and audience of any risk summary reports.
Tracking
The tracking section describes how risk activities will be recorded and audited. A risk management system typically handles the recording aspect, while a Project Management Office might be responsible for auditing, depending on the size of your organization.
Risk Register by ProjectBalm is the ideal tool for implementing your risk management plan
