What to Include in Your Project Risk Register

One way to encourage participation in risk management is with good risk register design. A well-designed register will quickly communicate the overall level of risk in the project to you and other project team members. 

It should let users easily access more detail about individual risks when this is required. This, in turn, should stimulate everyone to think in terms of risks—spotting new ones as they arise and monitoring and taking action to mitigate existing risks. 

As a minimum, your risk register should include:

• A unique identifier for each risk
• A description of the risk, including the cause, the risk event, and the effect, such as "Because of heavy rain, there is a threat of the field flooding which would spoil the crops."
• Risk response actions
• Risk owner

You might want to include quantitative measures of probability, impact and overall risk, and residual values following mitigation for riskier projects.

Numerical and fields that are calculated automatically can be helpful if you're 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.

There's no limit to the number of fields you can include, but 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, viewers are taken through to the detail view which shows all the fields for that particular risk when they click on the risk entry in the list view. 

You might want to create a risk register database for each project as well so you're not restricted to a standard set of fields. Although a spreadsheet can help you track your projects, particularly smaller projects, an actual database can be better, such as those you can create in Kahootz or Podio. They make it easier to add documents and large amounts of text when necessary.

It's hard to beat the traffic lights system for visual impact. Users intuitively know that red means high risk, that amber means medium risk, and that green is low risk. This provides quick visual cues to readers to aid their understanding.

You might want to encourage participation by allowing all members of the project team and perhaps some stakeholders to view the risk register. You should set user access rights for your register, however, so only certain project roles, such as Project Manager, Project Support, or Risk Owners, can edit it. You can create an audit trail of who changed what and when.

Senior project team members and stakeholders such as the project board and corporate/program management might 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.

Remember that it's not just about listing risks and mitigation actions when you're designing a project risk register. The aim is to communicate and engage your colleagues in risk management. Your design should reflect this aim with different views for different audiences. A well-designed risk register can improve risk management in your project in this way.