When you’re starting out managing risks, it can feel like you’re staring at a blank spreadsheet or database. What is it that you are supposed to start recording about these things?
Project and business risks vary, but what we need to know about each risk is always the same. Here are 10 things you should be including in your risk database for each risk.
1. Name or title
Most obviously, you need to know how you are going to refer to the risk! Give it a title or name that is descriptive but not too long. You can also assign a risk number for tracking purposes, as that can identify an individual risk even more clearly than a simple name.
This is where you can add more detail to describe the risk. Explain the scope of the risk, how it is going to affect the business or project and who would be affected if it happened.
This should be a paragraph or two, and you can always link out to other documentation if you need to make reference to further explanations.
Next, add some information about the nature of the risk. This helps you classify risk by area affected, cost impact or timescale. You can create categories that are meaningful and relevant for your business, and assign the risk to the appropriate categories.
Make a list of the stakeholders for this particular risk. This can include people who will be affected by any impact and those who are part of the team to carry out the risk response.
5. Risk tolerance
It’s worth noting down how this risk fits within your business’ risk appetite. Record what the tolerance levels are for this risk and any other limits you must adhere to (or steer clear from). This section is the area that will be helpful to the PMO or enterprise risk team as they build up a view of how all the risks interact with each other and create the cumulative risk profile for the business.
6. Likelihood and consequences
We now get to the part many people jump to! You have to record the likelihood of the risk occurring. Then you also have to note the magnitude of the impact. This is a statement describing the consequence should the risk materialize.
Many businesses choose to record the original likelihood and impact, and then residual likelihood and impact – in other words, what position the organization will be in after the risk management actions have taken place. Hopefully, once you have mitigated a risk with a negative impact on the business, the likelihood and impact will be lower, but you might not be able to clear it totally. Talking about residual risk helps people see what you’ve done to manage the risk, and also makes transparent the fact that you might not be able to remove the risk completely.
You can use risk modelling tools to help inform how to document what the impact of your management actions might be. Using standard categories or scales for these elements helps compare risks accurately across the portfolio.
7. Target risk level
You might not need to eliminate a risk completely. That’s why target risk level is a useful thing to record.
Target risk level is where you need the risk to be, for the situation to be at an acceptable level to the project, the business or the management team.
Again, use a standard way of classifying risk to document your target risk level. You could use the likelihood and impact/consequences classifications to maintain the naming convention that’s already in use.
For example, if a risk has currently been analyzed as having a ‘Major’ risk impact with a ‘High’ likelihood of occurrence, your target risk level could be that it’s considered to have a ‘Minor’ risk impact and ‘Low’ likelihood of occurrence.
It’s your management plan actions that move the risk from where it is currently to the target risk level, so let’s look at that next.
8. Management plan
We haven’t yet recorded what we are going to be doing about the risk, so this section is the prompt to do that!
Write down what actions will be taken to manage the risk. These could include existing control methods where you already have standard business processes that will help address the risk. On top of your existing mechanisms, you may be planning to take specific action targeted at addressing this risk. Record those planned activities too.
There should be an owner for the action plan you have prepared to manage the risk. Someone needs to take responsibility for getting the work done, and also monitoring whether what is being done is having the desired effect. Ideally, these should be two different people, so the person doing the work isn’t responsible for auditing their own activities. This provides a bit more assurance and confidence that the risk is being managed as effectively as possible, and the extra pair of eyes might help spot some easy wins to further manage the risk.
Delegate out as much as you can, as unless you are a dedicated risk manager, it’s likely you’ll have other responsibilities and things to do in the day! The more you can share the risk management responsibilities with the rest of the team, the better.
10. Previous experience and lessons learned
It’s always worth looking back through previous experience and project lessons learned to see what you can glean from the past. There might be some useful information that will help shape your action plan.
Project lessons learned often talk about what went well and what didn’t go well. If you can analyze past performance, you can make better decisions about what will work this time.
Ultimately, your risk database needs to contain enough information for you to be able to manage risks effectively across the business and your project team. If you need more information, store it. If you find that a category above isn’t adding any value for you, don’t store it.
As you improve risk management maturity, you’ll find you’ll want to change up what you record so your approaches evolve over time. Keep looking at your risk management processes and making sure they remain fit for purpose as you gain more experience and maturity managing risks.