To learn more about EpiX Analytics' work, please visit our modeling applications, white papers, and training schedule.
Page tree
Skip to end of metadata
Go to start of metadata

 

A risk register is a document or database that lists each risk pertaining to a project or organization, along with a variety of information that is useful for the management of those risks. The risks listed in a risk register will have come from some collective exercise to identify risks. The following items are essential in any risk register entry:

 

  • Date the register was last modified

  • Name of risk

  • Description of what the risk is

  • Description of why it would occur

  • Description of factors that would increase or decrease its probability of occurrence or size of impact (risk drivers)

  • Semi-quantitative estimates of its probability and potential impact

  • P-I scores

  • Name of owner of the risk (that person who will assume responsibility for monitoring the risk and effecting any risk reduction strategies that have been agreed)

  • Details of risk reduction strategies that it is agreed will be taken (i.e. strategy that will reduce the impact on the project should the risk event occur and/or the probability of its occurrence)

  • Reduced impact and/or probability of the risk given the above agreed risk reduction strategies have been taken

  • Ranking of risk by scores of the reduced P-I

  • Cross-referencing the risk event to identification numbers of tasks in a project plan or areas of operation or regulation where the risk may impact

  • Description of secondary risks that may arise as a result of adopting the risk reduction strategies

  • Action window - the period during which risk reduction strategies must be put in place

 

The following items may also be useful to include:

 

  • Description of other optional risk reduction strategies

  • Ranking of risks by the possible effectiveness of further risk mitigation [effectiveness = (total decrease in risk)/(cost of risk mitigation action)]

  • Fall back plan in the event the risk event still occurs

  • Name of person who first identified risk

  • Date risk was first identified

  • Date risk was removed from list of active risks (if appropriate)

 

A risk register should include a description of the scale used in the semi-quantitative analysis, as explained in the section on P-I scores. A risk register should also have a summary that lists the top risks (ten is a fairly usual number but will vary according to the project or overview level). The "top' risks are those that have the highest combination of probability and impact (i.e. severity), after the reducing effects of any agreed risk reduction strategies have been included. Risk registers lend themselves perfectly to being stored in a networked database. In this way, risks from each project or regulatory body's concerns, for example, can be added to a common database. Then, a project manager can access that database to look at all risks to his or her project. The finance director, lawyer, etc. can look at all the risks from any project being managed by their departments and the chief executive can look at the major risks to the organization as a whole. What is more, head office has an easy means for assessing the threat posed by a risk that may impact on several projects or areas at the same time. "Dashboard' software can bring the outputs of a risk register into appropriate focus for the decision-makers.

 

 

 


  • No labels