How to Create a Project Risk Register

One way to encourage participation in risk management is with good risk register design. The right format will quickly communicate the overall level of risk in the project to you and other project team members. 

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

At a minimum, your risk register should include a unique identifier for each risk, a description of it, actions to be taken in response, and the owner of the task.

The descriptions should be brief and to the point. For example, a risk identified as "Rain Damage" might include this description: "Heavy rain could flood field and cause crop spoilage."

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

Numerical fields that are calculated automatically can be helpful if you're using a risk evaluation technique like the Monte Carlo method. 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 at the list view level. Avoid overwhelming users by putting unnecessary detail at the list view level. Ideally, viewers who need fuller information click through to the details. 

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

It's hard to beat the traffic lights system for visual impact. Users know that red means high risk, amber means medium risk, and green is low risk. These quick visual cues help readers scan information more quickly.

You might want to encourage participation by allowing all members of the project team and perhaps some stakeholders to view the risk register. However, you should set user access rights so that it can be edited only by key risk owners and managers. You need an audit trail of who changed what and when.

Senior project team members and stakeholders might not have time to digest the list view of every risk. For them, a summary risk profile gives a quick picture of overall risks to the project. It illustrates the number of risks at each probability and impact level.

Remember that a project risk register does not just list risks and mitigation actions. It is a communication tool that engages your colleagues in risk management. Your design should reflect this aim with different views for different audiences.