Risks don’t need to be a scary thing. Identifying them early can help you avoid issues that can sink a project.

You can organise risks into the following categories (PESTLE):

1. Political: what is the current government attitude/policy?
2. Economical: how is the economy faring?
3. Social: what is the impact of cultural and lifestyle factors?
4. Technological: what level of technology exists?
5. Legal: what laws do you need to abide by?
6. Environmental: what is the impact of climate change?

Risk workshop

To capture risks, I like to run a risk workshop. The purpose of this session is to understand the team’s worries and concerns. I ask team members, subject matter experts and senior stakeholders to attend.

In the first 30 minutes, I get the team to capture ‘everything they think could go wrong’. In the final 30 minutes, I get the team to think about mitigating these risks.

It looks something like this (the pink are risks and the green are mitigations):

Risk log

The workshop doesn’t make it easy to track risks. This is why I convert the workshop outputs into a risk log.

My risk log contain the following information:

• Reference code: this can help team members find the risk in the log.
• The strategic risk: you can use PESTLE risk categories or your own (technical, delivery, user research, design).
• The risk description: a few sentences summarising what the risk is.
• Date added: the date you added the risk to the log.
• Impact of risk: this is the effect of the risk.
• Probability of risk: how likely the risk is to occur.
• Risk score: this is the impact of the risk multipled by its probability. I like to use a table below to show stakeholders what their risk score means. So if the impact of a risk is ‘Severe (5)’ and ‘Almost Certain (5)’, the risk score is 25 (red).

Likelihood and Impact Model Image by The ALS Group: https://info.thealsgroup.com/blog/erm-risk-assessment-phase-two-risk-analysis

• Actions to mitigate: this is how the team plans to mitigate the risk.

• Risk owner: who is responsible for this risk, and in charge of making sure the mitigations will take place. Have one person own the risk to ensure accountability.

• Status: is the risk open (a live issue) or is it closed (no longer an issue). If the issue is ‘closed’ you can hide the row in a spreadsheet to make the log easier to navigate.

• Notes: you can put anything useful here for team members to learn more about the risk.

• Date last updated: this is when the risk has been last reviewed.

You can see what a completed risk log entry looks like below.

Monitoring risks

I review the risk log at least twice a week. I update the ‘date last updated’ column once I’ve done this. I highlight the risks that have a high risk score to stakeholders at weekly governance meetings. I like to flag these risks in weekly updates too so people are aware of potential dangers down the road.

Conclusion

Keeping an eye on risks can help your project succeed. How do you track risks? Let me know by getting in touch.

Thank you to Laura, Ayesha and others who have helped me when thinking about risks.