Inability to attract and retain key 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;
• 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 risks, 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.

What is a Risk?

It may seem obvious but, fundamental to the effective management of risk, is the understanding of what a risk is. Unfortunately, in my observation, this understanding does not exist. This starts with an inability across regulatory bodies, legislative frameworks and international standards to present a common definition of risk or one that appropriately defines a risk.

I consider the most commonly utilised definition of risk management as provided by the ISO 31000 (the effect of uncertainty on objectives)[1] to be confusing, and, quite frankly, utterly ineffectual as a definition.

Effect is defined as “a change which is a result or consequence of an action or other cause”.[2] An effect is an outcome or consequence, so if we substitute that into the definition it actually becomes: the consequence of uncertainty on objectives.

In this definition, the focus is on evaluating the likelihood of the consequences of the uncertainty, rather than what the actual uncertainty is, or more specifically, the risk.

The definition I have developed is focused purely on identifying the event or incident that we are trying to prevent:

A possible event/incident that, if it occurs, will have an impact on organisational performance, outcomes, and/or objectives

This definition focusses on the event or incident, 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 has occurred, so, this definition makes much more sense.

Risks as Incident or 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 incidents or 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 train crash in Germany 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, expressing our risks as events or incidents 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. Instead there were “risks” such as patient harm, patient aggression, and clinical administration.

My belief 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 because 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 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 assessment of the control environment as being effective is accurate.

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

To that end, risk analysis is a 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:

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 materialise as incidents.

My Risk Statement Hall of Fame

I listed a range of risks at the start of this risk tip, but, as you can imagine, I have seen some absolute head scratchers during my career. Here, for the first time, is my Risk Hall of Fame (and no, I have not made any of these up).

I rest my case

[1] AS/NZS ISO 31000:2018: Risk Management Guidelines, Page 1

[2] AS/NZS ISO 31000:2018: Risk Management Guidelines, Page 1