How to describe a risk
Describing Risk in a Meaningful Way
Through my time in the risk management profession, the one issue that has been consistently raised relates to how to describe a risk. If you are having trouble with it you are not alone and hopefully this article will help.
The challenge that many organisations face is that they often confuse risks with causes and consequences. As an illustration, here are some of the “risks” I often see in risk registers:
- Lack of staff with the necessary skills and experience (cause);
- Failure to adhere to policy (cause);
- Ineffective maintenance (cause);
- Lack of compliance (consequence);
- Negative impact on reputation (consequence);
- Project schedule is delayed (consequence).
So how do we get it “right”? To answer that, I prefer to work backwards.
When an incident occurs it means that a risk has been realised (whether it was identified or not is inconsequential). After an event, we should conduct a post event analysis which asks (amongst other things):
- What happened?
- What caused it to happen?
- What were the consequences?
- What could we have done to stop it happening?
- What could we have done to reduce the consequences?
As a result of this analysis, the organisation should be able to:
- Strengthen current controls that proved to be ineffective;
- Introduce controls aimed at strengthening the control environment that will reduce the likelihood the event will happen again; and/or
- Develop controls aimed at reducing the consequences if the event does happen again?
When we identify a risk, the questions we are asking are:
- What could happen?
- What would cause it to happen?
- What would the consequences be?
- What can we do to try and stop it happening?
- What can we do to minimise the consequences if it does happen?
If we put those side by side we can see the similarities between the Risk Assessment and the Post Event Analysis. What this means, therefore is that Risk Analysis can be viewed as Post Event Analysis prior to the event occurring and we can implement new controls or strengthen existing controls before the event occurs.
So, let’s turn to some of the risks that may be present in a Council Risk Register (I have listed 20 – but of course there are many more). You may wish to make a comparison with your risk register:
- Cryptosporidium outbreak at the aquatic centre.
- Drowning in the toddler pool at the aquatic centre.
- Death of a child at the childcare centre.
- Unauthorised removal of a child from the childcare centre.
- Food poisoning outbreak at a Council operated food preparation business.
- Council records destroyed by fire in the records office.
- Sewage leak into the adjoining river.
- Animal attack on ranger.
- Parking Ranger assaulted by member of the public.
- Corrupt behaviour by a member of staff around issue of Design Approvals.
- Death of/injury to child on Council owned playground.
- Death of Council worker during tree management activities.
- Loss of/damage to Council servers.
- Virus attack on Council servers.
- Household and commercial waste not removed for a period in excess of X days (this will be determined by the Maximum Acceptable Outage identified by Council as part of its Business Continuity Planning).
- Illegal dumping of waste by contractor engaged by Council.
- Member of staff or the public exposed to un-bonded asbestos.
- Damage to heritage listed building.
- Unauthorised release of commercial in confidence information during procurement process.
- Chemical spill at Council Depot
So what do all of these things have in common? Firstly they are all events and secondly, if they did happen a post event analysis could be conducted. So the broad rule of thumb that I use is:
“If you have a risk in your risk register and you couldn’t conduct a post event analysis on it if it occurred – it is not a risk”.