By Rod Farrar, Paladin Risk.
It may seem obvious but, fundamental to the effective management of risk, it is essential that we actually understand what a risk is.
From the outset let me be frank, I consider the definition of risk management in ISO 31000 (the effects of uncertainty on objectives) to be confusing, and, utterly ineffectual as a definition.
Effect is defined as “a change which is a result or consequence of an action or other cause”. In essence, an effect is an outcome or consequence, so if we substitute that into the definition it becomes: the consequence of uncertainty on objectives.
In this definition, the focus is on identifying the consequences of the uncertainty, rather than what the actual uncertainty is. Confusing, I know. The now superseded AS/NZS 4360 defined a risk as:
the chance of something happening that will have an impact on objectives.
Whilst this definition at least mentioned events/incidents (something happening), it was more geared towards the chance of something happening (i.e. the likelihood). So, this definition can be expressed as: the likelihood of something happening that will have an impact on objectives.
Neither of these definitions, in my view, captures the essence of what the risk is: the event that we are trying to prevent from happening.
To that end, I have developed a definition that I think more meaningfully describes what a risk is. To me there needs to be a real focus on the actual thing we are trying to stop; in other words, seeing a risk as a potential event, as shown in the definition below:
“A possible event/incident that, if it occurs, will have an impact on the organisation’s objectives”
This definition focuses on the event, not the consequence or the likelihood.
When you hear people say: they obviously didn’t manage the risk very well, it is always after an incident, issue or disaster, so, this definition makes much more sense.
So, what does this mean for us?
It means that we need to focus more on identifying the thing we are trying to stop from happening.
Lack of staff is not a risk
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;
- 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.
If these aren’t risks, then what is?
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 German train disaster in 2016) 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?
For me, this is the absolute key to changing the way we look at risk management. We investigate 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. 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.
Rod Farrar is an accomplished risk consultant with extensive experience in the delivery of professional consultancy services to Government, corporate and not-for-profit sectors.
Rod’s Risk Management expertise is highly sought after as is the insight he provides in his risk management training and workshop facilitation. Rod was recognised by the Risk Management Institution of Australia as the 2016 Risk Consultant of the Year and one of the first five Certified Chief Risk Officers in Australasia.
Rod is the Principal of Paladin Risk Management Services, a Canberra-based specialist risk management consultancy business that has been in business since 2007. Rod established the Paladin Risk Management Training Academy in 2013 with the intent of passing on his knowledge to those working in, or who have a desire to work in, the risk management industry.
Please visit the Paladin Risk Management website.