Risk Tip # 8 – Capturing the right risks in your risk register

Lack of qualified staff would have to be one of the risks that I see most often in risk registers.  You may even have it in yours.  Other risks that I see on a regular basis in risk registers include:

• lack of funding;
• failure to meet the Government’s reform agenda;
• project does not meet its objectives;
• lack of staff morale;
• ineffective testing of IT system;
• lack of or ineffective contract management;
• lack of stakeholder engagement;
• loss of corporate knowledge;
• reputation damage;
• cyber-attack;
• increased staff turnover;
• failure to meet compliance obligations; and/or
• failure to maintain a safe working environment.

These ‘risks’ are not actually able to be managed, they are factors that can lead to a risk materialising i.e. they are causes; or they are the impacts if the event does occur i.e. they are consequences.

In this Risk tip I will highlight how we get the right risks into our risk register.

Risks as events

For me, the risks should reflect what we are trying to stop from happening and not some of the causes that would lead to it occurring or the consequences if it does occur.  To that end they need to be expressed as events.

Let me pose several questions:

• Are we going to initiate an investigation on the lack of aircraft maintenance or is it going to be initiated after there is an aircraft crash? The lack of maintenance of the aircraft may emerge as a contributing factor, however, it was the aircraft crashing that led to the investigation.
• Are we going to initiate an investigation on the lack of attentiveness of a signal worker or is it going to be initiated after two trains have collided? Once again, the lack of attentiveness of a signal worker may (and did in the case of the ) emerge as a contributing factor, however, it was the trains colliding that led to the investigation.
• Are we going to initiate the investigation on the crew who were distracted at the time or the failure of proximity warnings or is it going to be initiated after the ship has run aground?
• Was an investigation conducted on the lack of auditing within Queensland Health or did it emerge as a significant factor in the investigation surrounding the fraud conducted by Joel Barlow that led to $16.6 million being embezzled?

For me, this is the absolute key to changing the way we look at risk management.  We conduct an investigation after an incident has occurred to see if there are ways it can be prevented in the future, but do we align our incident register to the risks in our risk register?

Let me use an illustration.

In every hospital in Australia there is a database that is used to record every incident.  Incidents such as wrong medication provided to a patient; or wrong surgery conducted on a patient; or instruments left in patients during surgery; or assault of staff, to name but a few, are all captured in the database when they occur.  The whole purpose of risk management should be to do everything possible to prevent these things occurring, however, when reviewing a range of hospital risk registers, they were not included.

So, my theory is this: an incident database is a ‘reverse risk register’.  What I mean by this is that every incident that occurs in your organisation should be able to be linked back to a risk in your risk register.  In this way, we will be able to achieve several outcomes:

• First and foremost, it allows us to strengthen, where appropriate, the control environment where there has been a breakdown;
• It allows us to identify if the incident occurred as a result of a cause that we had not foreseen; and
• It allows us to verify the veracity of the assessment we have made on the effectiveness of the control environment.

This last point is crucial.

In Risk Tip #1 I put forward an alternate view on how the likelihood of a risk occurring should be assessed.  I have further refined the table that I included in that blog to that shown below:

Ratings	Descriptors
Almost Certain	Less than 10% of the critical controls associated with the risk are rated as either Effective or Mostly Effective. Without control improvement, it is almost certain that the risk will eventuate at some point in time.
Likely	10-30% of the critical controls associated with the risk are rated as either Effective or Mostly Effective. Without control improvement, it is more likely than not that the risk will eventuate.
Possible	30-70% of the critical controls associated with the risk are rated as either Effective or Mostly Effective and, if there is no improvement the risk may eventuate.
Unlikely	70-90% of the critical controls associated with the risk are rated as either Effective or Mostly Effective. The strength of this control environment means that it is more than likely that the risk eventuating would be caused by external factors not known to the Agency.
Rare	90% or more of the critical controls associated with the risk are rated as either Effective or Mostly Effective. The strength of this control environment means that, if this risk eventuates, it is most likely as a result of external circumstances outside of the control of the Agency.

If we link the incident database to the risk database this allows us to verify our assessment of control effectiveness.

We may have assessed the controls associated with the risk: wrong surgery conducted on a patient to be effective.  We may have assessed that all of the controls are effective because we have procedures and processes and checklists, however, in our incident database we may have recorded several such incidents.  The linking of the two databases allows us to question whether the effective assessment is accurate.

This relationship between risk management and post-event analysis is further demonstrated in the table below:

Post Event Analysis	Risk Analysis
What happened?	What could happen?
What caused it to happen?	What would cause it to happen?
What were the consequences?	What would be the consequences?
What could we have done to stop it happening?	What can we do to try and stop it happening?
What could we have done to reduce the consequences?	What can we do to minimise the consequences if it does happen?

To that end, risk analysis is post event analysis prior to the event occurring.

I have a rule of thumb (in fact, my most important rule of thumb) in relation to the risks in a risk register:

If a risk in your risk register was to eventuate and you could not conduct a post event analysis on it – then it is most likely not a risk

Try reviewing the risks in your risk register to see how many of them you could conduct a post event analysis on if they were to eventuate.

Until next time ….