In my experience, there are a number of traps that organizations fall into when they are identifying the risks they face. The traps make it very difficult to manage the risks.
#1 – The Broad Statement
Some organizations fall into the trap of capturing “risks” that are broad statements as opposed to events or incidents. Examples include:
• Reputation damage;
• Compliance failure;
• Fraud
• Environment damage
These terms tell us nothing and cannot be managed – even at a strategic level. Knowing that you might face, say, reputation damage doesn't help you understand what might hurt your reputation or how you prevent those incidents from happening.
#2 – Causes as Risk
The most common issue I see with risk registers is that many organizations fall into the trap of capturing “risks” that are actually causes as opposed to events/incidents.
The wording that indicates a cause as opposed to a risk include:
• Lack of …. (trained staff; funding; policy direction; maintenance; planning; communication).
• Ineffective …. (staff training; internal audit; policy implementation; contract management; communication).
• Insufficient …. (time allocated for planning; resources applied).
• Inefficient …. (use of resources; procedures).
• Inadequate …. (training; procedures).
• Failure to…. (disclose conflicts; follow procedures; understand requirements).
• Poor….. (project management; inventory management; procurement practices).
• Excessive …. (reporting requirements; administration; oversight).
• Inaccurate…. (records; recording of outcomes).
These "risks" also tell us very little and, once again, cannot be managed. Knowing that you might face a lack of training, for instance, doesn't tell you what incidents might occur as a result or help you prevent them.
#3 – Consequences as Risk
Another trap that organizations fall into when identifying risk is capturing “risks” that are actually consequences as opposed to events or incidents. Examples include:
• Project does not meet schedule;
• Department does not meet its stated objectives
• Overspending
Once again – these are not able to be managed. Having a project not meet schedule is the result of a series of problems, but understanding the potential result doesn't help you prevent it.
So, if these are the traps that organizations fall into, then what should our list of risks look like? The answer is simple – they need to be events.
I look at it this way – when something goes wrong like a plane crash, a train derailment, a food poisoning outbreak, major fraud .etc. it is always an event. After the event, there is analysis to determine what happened, why it happened, what could have stopped it from happening and what can be done to try to keep it from happening in the future. Risk management is no different – we are just trying to anticipate and stop the incident before it happens.
The table below shows the similarities between risk management and post-event analysis:
To that end, risk analysis can be viewed as post-event analysis before the event's occurring.
The rule of thumb I use is that if the risk in your register could not have a post-event analysis conducted on it if it happened – then it is not a risk!
If you apply this approach to your list of risks events, you will:
• Reduce the number of risks in your risk register considerably; and (more importantly)
• Make it a lot easier to manage those risks.
Try it with your risk register and see what results you get.
A Risk Is a Risk
Commonly, people talk of different types of risk: strategic risk, operational risk, security risk, safety risk, project risk, etc. Segregating these risks and managing them separately can actually diminish your risk-management efforts.
What you need to understand about risk and risk management is that a risk is a risk is a risk -- the only thing that differs is the context within which you manage that risk.
All risks are events, and each has a range of consequences that need to be identified and analyzed to gain a full understanding. For example;
You have a group identifying hazard risks, isolated from the risk-management team (a common occurrence), and they tend to look at possible consequences in one dimension only – the harm that may be caused. Decisions on how to handle the risk will be made based on this assessment. What hasn’t been done, however, is to assess the consequence against all of the organizational impact areas that you find in your consequence matrix. As a result, the assessment of that risk may not be correct; for instance, there may be significant consequences in terms of compliance that don't show up as an issue in terms of safety.
If you only look at risk in one dimension, you may make a decision that creates a downstream risk that is worse than the event you're trying to prevent. For instance, you may mitigate a safety-related risk but create an even greater security risk.
The moral of the story: Managing risk in silos will diminish risk management within your organization.
In about 80% of cases, you can’t do anything about the consequences of the event; what you are trying to do is stop the event from happening in the first place.
To that end, risk analysis can be viewed as post-event analysis before the event's occurring.
The rule of thumb I use is that if the risk in your register could not have a post-event analysis conducted on it if it happened – then it is not a risk!
If you apply this approach to your list of risks events, you will:
• Reduce the number of risks in your risk register considerably; and (more importantly)
• Make it a lot easier to manage those risks.
Try it with your risk register and see what results you get.
A Risk Is a Risk
Commonly, people talk of different types of risk: strategic risk, operational risk, security risk, safety risk, project risk, etc. Segregating these risks and managing them separately can actually diminish your risk-management efforts.
What you need to understand about risk and risk management is that a risk is a risk is a risk -- the only thing that differs is the context within which you manage that risk.
All risks are events, and each has a range of consequences that need to be identified and analyzed to gain a full understanding. For example;
You have a group identifying hazard risks, isolated from the risk-management team (a common occurrence), and they tend to look at possible consequences in one dimension only – the harm that may be caused. Decisions on how to handle the risk will be made based on this assessment. What hasn’t been done, however, is to assess the consequence against all of the organizational impact areas that you find in your consequence matrix. As a result, the assessment of that risk may not be correct; for instance, there may be significant consequences in terms of compliance that don't show up as an issue in terms of safety.
If you only look at risk in one dimension, you may make a decision that creates a downstream risk that is worse than the event you're trying to prevent. For instance, you may mitigate a safety-related risk but create an even greater security risk.
The moral of the story: Managing risk in silos will diminish risk management within your organization.
In about 80% of cases, you can’t do anything about the consequences of the event; what you are trying to do is stop the event from happening in the first place.
