01Good Risk Register Design
One way to encourage participation in risk management is with good risk register design. A well-designed risk register will quickly communicate to you and other project team members the overall level of risk in the project. And let users easily access more detail about individual risks when required. This, in turn, will stimulate everyone to think in terms of risks: spotting new risks as they arise and monitoring and taking action to mitigate existing risks.
02The Right Fields
As a minimum your risk register should include:
- A unique identifier for each risk
- A description of the risk (including the cause, risk event and effect e.g. Because of heavy rain, there is a threat of the field flooding which would spoil the crops)
- Risk response actions
- Risk owner
For low-risk projects, this might be enough, but for riskier projects consider including quantitative measures of probability, impact and overall risk, and residual values following mitigation. Numerical and automatically calculated fields can be helpful if you are using a risk evaluation technique like the Monte Carlo method or expected monetary value. Other useful fields include key dates, risk category, risk response category, proximity, mitigation costs, and status.
I like to create my risk register database for each project because I prefer not to be restricted to a standard set of fields. While a spreadsheet can help you track your projects, particularly for smaller projects, an actual database is better (such as those you can create in Kahootz or Podio for example), where it is easier to add documents and/or large amounts of text if necessary.
There is no limit to the number of fields you can include. However, only key fields should be displayed in the list view of all risks. Otherwise, the list view can become swamped with too much detail. Ideally, when viewers click on the risk entry in the list view, they are taken through to the detail view which shows all the fields for that particular risk.
For visual impact, it is hard to beat the traffic lights system. Users intuitively know that red means high risk, amber, medium risk and green, low risk. So it provides quick visual cues to readers aiding their understanding.
To encourage participation, you may want all members of the project team and perhaps some stakeholders to be able to view the risk register. However, you should set user access rights for your risk register so only certain project roles (Project Manager, Project Support, Risk Owners) can edit it, with an audit trail of who changed what when.
05Summary Risk Profile
Senior project team members and stakeholders such as the project board and corporate/programme management may not have time to digest the list view of every risk. For them, a summary risk profile gives a picture of the aggregated risk presented by the project at a quick glance. It illustrates the number of risks at each probability and impact level.
When you are designing your project risk register, remember it is not just about listing the risks and mitigation actions. The aim is to communicate and engage your colleagues in risk management. So your design should reflect this aim with different views for different audiences. That way a well-designed risk register can improve risk management in your project.
About the Author
Claire Dumbleton is the founder of Accentive Training, providing PRINCE2 project management online courses and certification. Accentive Training are e-learning specialists, helping busy professionals improve their project management skills.
Things to Include in Your Project Risk Register
How often have you seen a risk register languish in the filing system? They are created at the start of the project and then forgotten, becoming quickly out of date. We all know that good risk management requires regularly identifying new risks, reviewing existing risks and planning mitigation activities. So how can we make this more likely to happen?