Following my post published two weeks ago, Is it a Risk, a Cause or a Consequence?, I received a very relevant question and decided that I would share it with you: “Now that we know what we need to assess, what would your recommendations be concerning the scales to use?”
I know that a scales related discussion after the holiday season is a delicate topic for most of us, but let me reassure you that these scales are much easier to adjust.
When assessing a risk, there are usually two scales that need to be documented and agreed upon:
- Likelihood - to document the chances of a risk occurring in a foreseeable future;
- Impact - to document the extent of damage that could result should a risk manifest.
Another criteria can be the “velocity” or speed at which the risk can really spread. In this post, I will not be addressing velocity but I do intend to keep it as a separate topic for a future post.
Where to Start?
Here, let me propose an approach that is usually the opposite of what most would think. In most cases, the scales of impact and likelihood directly condition the number of rows and columns in your risk matrix. For instance, a five level impact and likelihood scale will result in a 5 by 5 matrix.
There can, of course, be correspondence and mappings so you can decide to decorrelate the number of levels in your scales and in the matrix, but to me, this just makes it harder for non-specialists to then comprehend. If they see the same scales on the matrix as they used for the risk assessment, they can understand quickly where their risk is positioned.
As a result, start with designing your risk matrix. This will give you the number of levels that you need to document for each scale.
- Likelihood scale, what are the chances?
Now that you know how many levels you need, use internal and external incident repositories to determine the frequency of occurrence of your events. For core business or predictable risks, such as quality defects for instance, internally recorded incidents should be sufficient. Using this information and probability distributions will help you calculate the mean value, the level 3 on a 1 to 5 scale. Then, applying your certainty threshold you can determine the lower and higher values. Hence levels 1 and 5. Levels 2 and 4 can then simply be the mean values between levels 1 to 3 and 3 to 5. For other risks for which you have less data, combine your internally recorded incidents to external incidents databases or analyst reports for a more complete picture to help you calculate the “real” mean value.
- Impact scale, how bad can it be?
For impacts, in addition to working with the incidents recorded, I personally recommend asking top management for their inputs. For each business unit, executives should be able to provide what is an acceptable level of risk - the tolerance, and the materiality threshold - level to which risks and incidents need to be recorded. Taking again the example of a 1 to 5 scale, the risk tolerance would provide you with the mean value, hence level 3. The materiality threshold would be level 2 since level 1 addresses all risks that are insignificant in nature. Level 4 would be the threshold at which management triggers a contingency plan. Level 5 would simply be anything above that and managed in crisis or degraded mode.
What Next?
The only thing left to do now is decide what colors to apply to each cell in the risk matrix.
This might be perceived as a futile exercise, but it actually bears significant meaning. I have seen many cases where there is a strong focus on the “red zone” with the risks everyone actually knows about but with a complete omission of the “yellow zone” that I personally find even more deserving of attention. Indeed, with some sound response strategy, these risks can be lowered to the “green zone” where they are less of a danger. But should they not be monitored or managed properly, risks in the “yellow zone” can shoot quickly to the “red zone” and become serious threats.
What about you, how did you define your risk management scales?
I look forward to reading your thoughts and comments either on this blog or on Twitter (@TFrenehard)!
- SAP Managed Tags:
