What's in YOUR risk register?

 

Tracking and reporting risk information is a standard part of any project management approach.

How we do it will vary based on the context of the project being managed, the needs of the stakeholders and the policies or standards governing the practice, but in general, a risk register is a common standalone artifact, RAID log section or information radiator.

As with all other information, capturing it for the sake of doing so is pointless. Minimal sufficiency should be the goal we strive to in terms of meeting the informational needs of your stakeholders but more important, helping risk and risk response owners to effectively address identified risks.

Given this, is it possible to come up with a minimum set of risk information elements which we'd want to capture on most projects?

Here's my list:

• Description: without this, you don't have a risk! Beyond that, we need to ensure that the description identifies the uncertain event clearly and provides a specific understanding of the immediate impacts if the event occurs. If it doesn't create the desired sense of urgency you'd like to see, it should be rephrased.
• Probability and impact: while it might be tempting to combine these two attributes into a single severity or priority value, doing so would rob stakeholders of information which would help guide their behavior towards the risk. While a low probability, high impact risk might be calculated as being of moderate severity, a stakeholder with a low tolerance for risk might act in a different manner if they understand that the impact is high than if they assumed it was moderate based on the combined rating.
• Response: PMI and other associations have defined lists of risk responses but what is of greater value to response owners is understanding the proposed plan for addressing the risk. They have the right to modify the recommendation but at least they should see that the team has done its homework. For risks which are only going to be monitored (e.g. put on a watchlist), that recommendation should also be documented.
• Response owner: When I've reviewed risk registers for other project managers, I rarely see a response owner identified. While sometimes this responsibility might fall on the project manager or the risk owner, that is not always the case. Why wait till a risk is realized to assign response ownership?
• Status: At a minimum, this field should distinguish between those risks which are identified but not responded to, those which have been responded to and are being monitored, those which have occurred and might still recur, those which have occurred and can be closed, and those which are closed without occurrence. These status values will simplify the reporting process as well as enabling the team to evaluate the effectiveness of their overall risk management strategy.
• Updates: This is a journal which can be used to track changes to the risk, capture risk response status updates and to also serve as a reminder to the team if excessive time has passed since the risk was last reviewed.

Am I missing any? Are any unnecessary? Please let me know in the comments below!