It’s always nice to see examples of project management tools in use, particularly when the project is in the public domain so that the rest of us can see the use of the tool and, if appropriate, get an understanding of the project and its status as well. Here’s a good example of a risk register, or risk log, used in the Arizona Health Information Exchange’s project management plan. (The entire document can be found online here.)

As a reminder, the primary purpose of the risk register is to provide a central location for documenting all of the risks associated with the project and for tracking the status of any agreed-to responses to them. This can be seen along the top of the matrix where the three categories of information are titled “Basic Risk Information,” “Risk Assessment Information” and “Risk Response Information.” Those represent three of the steps in the overall process for managing risks; identification of the possible risk events, assessment of them, and formulating responses.

Let’s look at some of the best practices the Arizona Health Information Exchange team followed in utilizing their risk register.

  1. Consistent method of referring to each risk with a unique risk number.
  2. Reminding users to be specific and to outline impact to the project when documenting a risk event. (See the example in red at the top of the second column concerning bad weather.)
  3. Identifying an owner for each risk event.
  4. Using the risk register on an ongoing basis for tracking the risk events and the planned responses as can be seen in the “Last Update,” “Status of Response,” “Completed Actions” and “Risk Status” columns.
  5. Assessing the impact and probability of each event using a pre-defined scale; low, medium and high in this case. (Numeric values are often used for impact and probability assessments. These can then be multiplied together for each risk yielding a figure known as “exposure.” Exposure provides then a single number for each risk which can then be used to prioritize the risk event against other identified events.)
  6. Providing scales or ratings for use throughout the risk register template, for example in the Timeline and Status of Response fields. Since there may be many risk events and the intent of risk management is in part to determine which should be dealt with, the more standardized the information is the more likely that the more important risk events will rise to the top. (Our preference is for scalar values such as 1 for a low impact risk event, 3 for a medium and 5 for a high which can be added or multiplied together to facilitate ranking of the risk events.)
  7. Facilitates managing by exception. The Last Update, Status of Response and Risk Status columns can all be skimmed to readily identify those events that need to be dealt with.
  8. Extensive use of dates to drive action and to log when it occurred. See, for example, the directions in red for the “Planned Future Actions” column.
  9. Examples and directions to make the template easy for the user and to foster consistency in the way that information is recorded so that it’s easier to subsequently work with.