Risk Registers
Challenging technical projects often have multiple risks, whether technical or organizational. Without a mechanism of capturing, tracking, and eliminating these risks, projects have a higher probability of being either late or worse technically unsuccessful.
The risk register is a mechanism for collecting and prioritizing project risks. It is meant to focus attention on the most important risks. The register is a table of risks that could result in a negative outcome to the project. Since there are usually many risks, both large and small, the project team needs a mechanism of prioritizing risks, and tracking their mitigation over time. The risk register, and its frequent review, form that mechanism.
Risk Register Structure
Each row in a risk register has a number of entries. First comes the risk description. This is the event that would cause a problem. Tips on structuring the description are provided in the next section. Next is the consequence of the risk on the project. We prefer separating the risk from the effect to force the writer to describe the project impact explicitly.
Next is the probability of the risk occurring, followed by the severity if it does occur. Some project managers use qualitative labels of “high”, “medium” and “low” or similar for these entries. Instead, we prefer using numeric values as they enable immediate computation of the “risk score”, which is the product of probability and severity. The risk register should be continuously sorted by this risk score.
This computation bubbles up high probability and high severity risks to the top and moves low probability, low severity risks to the bottom. As the project goes on, and initially identified risks are mitigated, or new risks emerge, the continuous sorting allows the team to focus on the most important risks.
Let’s continue with the other entries. Each risk should have an assigned owner, and a mitigation. The mitigation entry should contain the plan to reduce the risk and clarify whether the goal is to decrease the probability of the event or reduce its severity (or both). Estimates of the resulting values, and corresponding risk score should be included. Depending on the tracking methodology, teams may want to add a column for the target date for implementing the mitigation.
Another useful, but optional, entry is the risk category. Risk categories may be that of results, or causes. Result categories include schedule risk (project will be late), technical risk (product may not work well), acceptance risk (product won’t be used by customers). Cause categories include items such as resource, expertise, or legal risk. These categories are especially valuable when reviewing with leadership who is not familiar with the project specifics.
Finally, each risk should get its own ID. Descriptions change over time, and it is useful to have a short tag to refer to a risk.
Risk Register Example
This example is from a real situation faced by a startup in the fall of 2011. They had a semantically-based news search engine and were launching an iPad-based news reader app based on existing services infrastructure. There were existing customers, such as the Washington Post that relied on robust operation of those services. The team had never launched an iOS product before. Further, information sources including Twitter and Facebook had to be integrated at the service level, but without modifying existing SQL-based schemas. Let’s take a look.
Best Practices for Each Column
Description
The conventional method of risk description is to describe a single event that will lead to the negative effect. We prefer listing a chain of events, similar to the “5 Whys” approach, and working backwards to the original concern. This does take up more room, but makes the reasoning chain explicit and informs readers who are unfamiliar with the project. It also encourages the risk author to think through the chain of events.
Team members often have good intuition about a technical concern, but can use prompting by the project manager to articulate the causality chain. The concern is often valid, but the team member may not have the larger picture of the consequence. In many situations, team members may see a valid problem, and will to iterate with the program management or system engineering team to convert to a business risk.
Consequence
This column is the consequence to the project, expressed as quantitatively as possible. Rather than saying “high impact to the schedule”, offering range of delays, for example “3-5 months” is more useful to the reader.
To save table space, some teams prefer to use the category type (as described above) as the first word in the consequence description.
Probability
This is the estimated probability of the event, and should be expressed as a number, so that it can be used in the “Score” computation. The probability should be rounded to the nearest 10% to discourage gaming the impact score. Some teams prefer to round to the nearest 20% (equivalent to a 1-5 range).
Severity
This is the severity or impact to the project. A 1-week schedule delay may or may not be significant, depending on whether a specific public demonstration milestone is met. Similarly, a cost increase of $50,000 may not be serious if it accelerates a 10-person team for a month.
We suggest using severity of 1-5, with 5 being the most severe. This is opposite of most “Severity” labels at technology companies, where a “Sev1” is most severe. If the team prefers to use “1” as the most significant severity, that can be accommodated by changing the calculation of the “Score” below.
Risk Score
Team attention and focus are one the most precious resources in complex projects. The “Risk Score” is the key element of the table as it is the main focussing tool. It is defined as the product of probability and severity. The table should be continually re-sorted by the score and the project team should be focussed on the top risks.
One refinement to the straightforward multiplication computation is to apply an exponent to the severity value. This prevents high probability but low severity items from cluttering the top of the risk. For example, a severity 5 risk, which could endanger the entire project, but only at a probability of 20%, would end up with a score of 1 in the multiplication method. Yet a severity 2 risk with a probability of 70% would have a score of 1.4, and occur higher in the table.. Squaring the severity (an exponent of 2), would lead to scores of 5 and 2.8 respectively, which are more representative of the right focus.
Mitigations
Risks can be dealt with in many different ways. One can eliminate the risk from happening, reduce the probability the risk could happen, reduce the severity of the risk should it happen, and/or mitigate the effects after it has happened. Related to these risk mitigations is the ability to detect the risk has occurred. For example, being able to automatically detect and then alarm on a risk can reduce the time it takes to mitigate the risk, and can therefore limit the severity of the risk.
It is reasonable for a mitigation to be temporary while a longer-term solution is implemented. For example, a manual kill switch held by a human observer can be used until an automated safety system is developed.
The team should brainstorm all possible mitigations, and then can prioritize based on available resources and implementation cost.
In some cases, the mitigation may be so expensive that the team would prefer to invest in a fast, small project to better understand the probability or the severity. Consider an example of a team developing a video game, and being concerned that the existing game engine may render the scenes too slowly. They may choose to create a static scene of comparable complexity to measure the render speed. That would not be an actual mitigation (since knowing how fast something runs does not make it run faster) but should also be captured in the mitigation column. We refer to efforts like these as “discoveries”.
Mitigations may be proposed or implemented. Once implemented, the probability (and less often the severity) should be reduced. If proposed only, then the estimated future probability should be listed in the proposal.
Creating and Applying Risk Registers
Developing a risk register
List all risks using a broad-level brainstorming session.
As a group, assign a first-pass probability and severity, and compute risk score
Sort risks by risk score and focus in priority order (highest risk score first)
Brainstorm mitigations. These mitigations may cause you to reevaluate your probability or severity. For example, if you found a way to eliminate the risk, then reassign the probability to 0%.
Continue this process until you feel that the team has the right top-level risks.
Team members may disagree on the probability and severity of risks, but there can be only one number in the computation. In early phases, the team should assume the worst case. These risks will bubble up in risk score and be discussed in priority order.
In later phases, differences of opinions are usually caused by one or the other party having incomplete information or differences in mental model. They should discuss together to understand why each scores the probability or severity differently. Usually there is an aha moment where they align and then agree. If they continue to disagree, defer to the person with more experience in this area and/or the person who is more directly responsible for the risk. In cases of disagreement, it is useful to capture a dissenting opinion in the comments. The dissenting team member will feel heard, and their opinion captured for posterity, while the team can move on to other risks.
Until the team becomes more internally calibrated, risks will bubble up and down dynamically. This is a natural part of the process, rather than a sign of dysfunction.
Register Implementation
Ideally, the risk register will be implemented in an online spreadsheet such as Google Sheets or Quip. These spreadsheets compute the risk score automatically, and enable sorting and filtering.
In an ideal case, the spreadsheet will be embedded live in a text document that contains a paragraph or so describing the risk and mitigation in more detail than a single cell entry in a table.
For large projects with multiple contributing teams, there are often too many tactical risks that need to be addressed by the subteams but would clutter the top-level risk register (TRR). In that situation, it is best to keep a separate per-team risk registers and bubble up risks to the TRR once they reach a score threshold.
OnGoing Use
The Risk Register is most valuable when used weekly to review key risks and monitor ongoing mitigations. At the very least, the top 3 risks for any project should be reviewed weekly.
Once risks have been mitigated, they should be retained on the risk register, with the lowered probability or severity score. Many people bring up the same issues, or have FUD (fear, uncertainty, and doubt) around certain risks. Clever mitigations might have found a way to make these issues not matter, but keeping them on the risk register allows people who are new to the program to know that they have already been addressed.