Simple Steps for Setting Up A Project Risk Register

Lightning

Written by: Andrew Steioff

Reviewed by:
Updated: April 28, 2023

Table of contents

Every project—from remodeling a bathroom to landing on the Moon—carries the risk that it won’t succeed.

Typically, the more sophisticated the project, the higher the chances that something doesn’t go according to plan. This is why project managers who successfully execute large, complex undertakings all have one trait in common: a relentless focus on managing risk.

What if regulatory approval doesn’t come through for clinical trials of a pharmaceutical drug? What if protesters disrupt a political convention? What if foreign currency fluctuations erode the profitability of an overseas investment? The adverse possibilities are endless.

Especially for large projects, it’s vital that a portion of the overall budget gets set aside for identifying and addressing potential risks such as these. The best risk management plans are created during the planning stages, and are subject to the same approval process as the rest of the project.

The document resulting from the planning stages is called a risk register, and it forms the backbone of a sound risk management plan. Creating, maintaining, and utilizing a risk register are critical activities that contribute to a project’s success.

In this post, we’ll take a look at the parts of a project risk register and how to get started making one of your own.

KRI Guide

What is a Risk Register?

The Project Management Body of Knowledge defines a risk register (sometimes called a risk log) as a document in which the results of risk analysis and risk response planning are recorded. In its simplest form, it’s an itemized list of the risks that could derail a project.

Typically created in spreadsheet form, the register allows project stakeholders to keep tabs on the identification, assessment, and treatment of risks. It also contains information about the individual project risks, including potential impact, severity, and actions required to keep them in check.

What’s included in a Risk Register?

Risk registers are unique to their projects; thus, there is no “standard” risk register. Still, risk registers typically contain some common features. The categories below are a good starting point, but you should modify your risk register to match your unique project and situation.

Some of the most widely used components are listed below. You’ll notice that the risk register addresses risk management in four key steps: (1) identifying and classifying risks, (2) analysis, (3) evaluation, and (4) solutions and monitoring.

Elements 1–3 listed below involve the identification of risks.

  1. Risk Category – This is where you assign your risk to a category, such as scope, time, budget, environmental, political, or something else. Risks can be categorized in additional ways, too, such as how they relate to the delivery of a project’s benefit or the project phase. What matters is that the categories help group risks for future reference and easy understanding by outside parties.
  2. Risk Description – Just like it sounds, this is simply a brief description of the potential risk.
  3. Risk ID – This is a unique identifier used to identify and track the risk in the risk register. Depending on the sophistication of your project, it may or may not be necessary.

Elements 4 and 5 record the results of analysis of the identified risks.

  1. Project Impact – A description of the potential consequences that could occur to the project if the risk becomes an issue. This might include, for example, the impact to budget and timeline if a key supplier fails to deliver. This can be quantitative (such as 1–10) or qualitative, such as low/medium/high.
  2. Likelihood – This is the estimated probability that the risk will occur at some point and turn into an issue. This can again be quantitative or qualitative.

Elements 6 and 7 record the evaluation of the risks.

  1. Risk Score – This is the magnitude or the level of the risk. If quantitative measurements are used, this is typically the product of the risk’s impact and likelihood. For example, if the impact is 5 and the likelihood is 8, the risk score is 40.
  2. Risk Trigger – Also known as key risk indicators (KRIs), these are the signifiers or “red flags” that would indicate the risk has occurred or there’s a need to implement contingency plans.

These last four elements explain and record the treatment of the risks.

  1. Prevention Plan – This is the set of countermeasures that should be enacted to achieve one of four things: prevent or avoid the risk, mitigate or reduce it, transfer it elsewhere (such as to a third party), or accept it. For example, arranging for backup power systems when primary power gets knocked out by a natural disaster would mitigate the risk, while buying insurance would transfer it.
  2. Contingency Plan – This is an action plan to address the risk if it does occur. Evacuation plans are a common example.
  3. Risk Owner – This is the person responsible for managing the risk and implementing the prevention or contingency plans. Stakeholders, members of the project team, the Project Manager, and the Project Sponsor can all be risk owners.
  4. Status This should include the most recent activities that have been taken pertaining to the risk, along with the date the register was updated.

How can I get started making a Risk Register?

It’s best to start with the risk register sections listed above and move from top to bottom.  First, you’ll want to make a list of all the potential risks to your project or organization. This can be accomplished in several ways.

  • Brainstorming: Challenge yourself and your team to consider all of the possible ways a project could go off the rails. At this stage, no idea is too strange—there will be time for assessment later. Focus on quantity over quality.
  • Subject Matter Experts: At most organizations, there are people who have the background and experience to offer you perspective on the risks inherent in your project. You’d be wise to loop them in.
  • Lessons Learned: You or someone else at your organization may have taken on a similar project in the past, and kept a risk register. Repurposing this document can be a great way to see the identified risks as well as how they played out.
  • Assumptions Analysis: What are the key assumptions you’re making that would need to be right for the project to be a success? How could you be wrong? This can be a useful way to tease out and categorize risks.

There are a number of other approaches too, including SWOT Analyses, the Delphi technique, FAIR Methodology, and more. Do some research and see if any of these are relevant to your project or industry.

Of course, it’s not possible to list out every possible risk that could happen, nor is that an advisable goal. You wouldn’t, for example, include the potential for an asteroid hitting the earth among the risks to your product marketing plan. You should focus on the risks that matter.

A Living Document

While a project is in progress, the risk register should be kept close-at-hand and updated consistently. You’ll want to schedule thorough reviews with your team on a regular basis, so it’s always current and reflective of the best possible information. Be rigorous about identifying risks, checking that risk responses are in place, and that people are held accountable. Risk management does not end at the planning stages, it just begins.

Your risk register will change over the life of the project—and that’s a good thing. You’ll be presented with new risks, old risks will be mitigated or prevented altogether, and some risks will simply go away. The risk register helps you stay on top of these developments and keep your team in the know. Flexible technology such as LogicGate's Enterprise Risk Management platform can help your risk register stay agile and responsive to risks as they crop up.

At its core, a risk register helps to maximize the chances that a project will be a success. It helps project managers keep a clear view of the status of a project, as well as any factors that could decrease those chances. It is, in many ways, a project manager’s best friend.

 

For more on Enterprise Risk Management, check out LogicGate's eBook below on How to Build Organizational Support for ERM.

Download eBook

 

 

Related Posts