Below are the typical columns in the Risk log of a RAID log.
| Column | Description |
| ID | Unique ID for tracking and reference |
| Title, in a “problem statement” | Use a problem statement form: as a result of <definite cause>, <uncertain event> may occur, which would lead to <effect on objectives> |
| State | State of the Risk. Usually a picklist denoting the lifecycle, including:
|
| Description | Detailed description of the risk and its potential impacts and influencing factors |
| Date Raised | Date the risk was added to the log. This is good for tracking new vs old risks |
| Source | Source of the risk – the person who raised it or the forum it was raised in. This is handy when someone says, “where did this come from?” |
| Category | Categorization field for grouping risks for effective planning and management. |
| Probability of Occurrence | Numeric value representing the probability that the risk could happen. Can be a percentage, or a numerical scale (1-5) |
| Impact of Occurrence | Numeric value representing the impact of the risk, should it occur. You could use a monetary value, but assigning an accurate financial value can become quite involved, so it is usually more expedient to assign a numerical scale (1-5 or 1-100) with a definition of each level or a percentage. |
| P*I | Multiple Probability and Impact to arrive at a P*I score, or Risk Score which can be used to stack-rank your risks in order of importance. |
| Owner | The Owner is the person responsible for managing the risk. Most of the time, that will be the PM. But it could also be the technical lead, the Product Owner or Sponsor. The PM should keep on top of the Risk because they are accountable for the success of the project, but the Risk Owner is the one Responsible on the RACI. |
| Trigger Date | The date on which (or by-which) the risk would become an issue if it happens. After this date, the risk is immaterial. |
| Response | This is a text description of how you will respond to the risk. |
| Response Strategy | Picklist describing the strategy used to respond to the risk. This is optional if you have done a good job documenting the Response. It’s more important to understand these options when documenting your detailed response than actually documenting the strategy. Picklist options are:
|
| Response Update | A text field with the latest update on the risk so you can see how your response is coming along. These can be timestamped entries or just the latest update |
| Date Updated | Date the last time the risk was reviewed or updated |
| Date Closed | Date the risk was closed or canceled |
| Reason Closed | Picklist or text describing the reason the risk was closed
|
Here are some additional columns that can be used to extend your Risk log in certain circumstances.
| Column | Description |
| Contract / Charter Reference | Remember that any planning assumptions and constraints are inherently risks to your project if they don’t hold true. So, adding those to your Risk log is a great way to start planning. This column is a reference back to the contract or planning documents, like the charter, where the assumption or constraint was documented. This can be handy if the risk turns into an issue as it can have contractual implications -for you, your suppliers or clients. |
| Impact Category | Some organizations like to be more specific with the Risk Impact and categorize risks by the constraints they may impact. Typical Impact Categories may include:
|
| Date Proximity | Similar to the Trigger Date, many PMs like to measure the date proximity of a potential risk so they can focus more attention on those that are impending. |
| Escalations | If you need to create a paper-trail for who you escalated the risk to, when, and their response, then a special Escalations column can be useful. |
| Response Status | Red/Amber/Green indicator showing the status (on-track, at risk, off-track) of the risk response plan. When this is red, it means that the plan to mitigate the risk is going off track. This can be really useful for very critical risks. |
| Residual Probability | Residual probability is the probability the risk will occur AFTER the response strategy is implemented. It is typically more efficient to simply update the Probability of the risk after implementing your response, but sometimes it is nice to demonstrate the effective impact of your response, and thus the value of your risk planning |
| Residual Impact | Like Residual Probability, Residual Impact is the measure of expected impact after the response strategy. Like Residual Probability, it is more efficient to simply update the Risk Impact score after implementing these measures, but it can be nice to break it out if you have to demonstrate the value of your risk planning. |
| Residual P*I | Residual Probability * Residual Impact |
| Residual Risk description | Explains what risk remains after your risk response is implemented. Even when Residual Probability and Impact are not used, it can be useful to describe what risk is remaining after your response actions, especially for more serious risks. |
| Financial cost of impact | Typically used only for the most impactful risks where EMV is used, this represents the total financial impact if the risk were to occur. If you use this field, then you should have an explanation ready for how you came up with this number. |
| Expected Monetary Value (EMV) | Probability as a percentage * Financial Cost of Impact. This represents the Expected Monetary Value of the risk, which can be useful for more advanced financial analysis. |
| Internal Only (team only) Flag | Flag indicating if this RAID item should be kept internal to your team.
Instead of a flag, you can create data classification picklist of increasing sensitivity, such as “My-eyes only,” “Internal Team Only,” “Internal Org Only” or “All Stakeholders(default)” to allow for easy filtering |
