Project managers constantly think about risks, both threats and opportunities. What if the requirements are late? What if the testing environment becomes unstable? How can we exploit the design skills of our developers? Let’s consider a simple but powerful tool to capture and manage your risks—the Risk Register.
What to Include in a Risk Register
The Risk Register is simply a list of risk-related information including but not limited to:
- Risk Description. Consider using this syntax: Cause -> Risk -> Impact. For example: “Because Information Technology is updating the testing software, the testing team may experience an unstable test environment resulting in adverse impacts to the schedule.”
- Risk Owner. Each risk should be owned by one person and that person should have the knowledge and skills to plan and execute risk responses.
- Triggers. Triggers indicate when a risk is about to occur or that the risk has occurred.
- Category. Assigning categories to your risks allows you to filter, group, analyze, and respond to your risks by category. Standard project categories include schedule, cost, and quality.
- Probability Risk Rating. Probability is the likelihood of the risk occurring. Consider using a scale of 1 to 10, 10 being the highest.
- Impact Risk Rating. Impact, also referred to as severity or consequence, is the amount of impact on the project. Consider using a scale of 1 to 10, 10 being the highest.
- Risk Score. The risk score is calculated by multiplying probability x impact. If the probability is 8 and the impact is 5, the risk score is 40.
- Risk Response Strategies. Strategies for threats include: accept the risk, avoid the risk, mitigate the risk, or transfer the risk. Strategies for opportunities include: accept the risk, exploit the risk, enhance the risk, or share the risk.
- Risk Response Plan or Contingency Plan. The risk owner should determine the appropriate response(s) which may be executed immediately or once a trigger is hit. For example, a risk owner may take immediate actions to mitigate a threat. Contingency plans are plans that are executed if the risk occurs.
- Fallback Plans. For some risks, you may wish to define a Fallback Plan. The plan outlines what would be done in the event that the Contingency Plan fails.
- Residual Risks. The risk owner may reduce a risk by 70%. The remaining 30% risk is the residual risk. Note the residual risk and determine if additional response planning is required.
- Trends. Note if each risk is increasing, decreasing, or is stable.
Other Risk Register Tips
The Risk Register may be created in a spreadsheet, database, risk management tool, SharePoint, or a project management information system. Make sure that the Risk Register is visible and easy to access by your project team members.
The initial risk information is entered when identifying risks in the planning process. For example, project managers may capture initial risks while developing the communications plan or the project schedule. The initial risk information may include the risks, causes, triggers, categories, potential risk owners, and potential risk responses.
As you evaluate your risk in the planning process, you should assign risk ratings for probability and impact and calculate the risk scores.
Next, validate risk owners and have risk owners complete response plans.
Lastly, review and update your risks during your team meetings. Add emerging risks. Other reasons for updating the risk register include change requests, project re-planning, or project recovery.
Project Risk Register Template
Perhaps you need a risk register template. I've got you covered.