Risk identification

download this column in pdf

	I like this column
	880 persons like this column

Within risk management, the phase of risk identification in an important step in constructing the risk register. In short, the risk register is a list of all things that can go wrong, including estimates on the probability and effect of that threat. If the organization has a risk matrix, then this is usually followed by a classification of the risk level (for example High, Medium, Low) or by color coding (Red, Amber, Green) the risk. The relevance of such a characterization is limited: it indicates whether a risk needs mitigation (high or red), should be accepted (low or green) or that you should think about it (medium or amber). The reason is that there are very many things that can go wrong, that arming the organization against all (if possible) would mean the organization does not do anything else. The cure is then worse than the disease. Characterizing risk is more a pragmatic means of prioritizing  attention to deal with a world full of dangers and threats. By only paying attention to the important risk (with the characterization often providing hints for risk mitigation) time is left for fun like skiing, sky diving, smoking and drinking. As long as the risk register is regarded as a pragmatic tool it works fine. However, if the risk register is used beyond this capability it starts to fail. The typical example is summing all risks in the register in order to get an estimate for the expected amount of misery. The temptation is large, as each risk has a probability and consequence and thus an expected value. Summing all partial expected values should give the total expected value, shouldn’t it?

Unfortunately the answer is no. Two things can go wrong. The first is that the sum is much smaller than what is observed in reality. This is the case in the financial world, where risks are generally regarded more or less independent. The probability of coinciding risks  is then systematically underestimated. This happens for example when the materialization of one risks becomes the trigger event for another risk. If the stock market makes a sharp drop, investors may become scared and sell their shares, causing the stock market to drop further. The chain reaction has started and will only grind to a halt in a system crash.  The reverse is the bubble. Even though bubbles and crashes have occurred many times (starting with the tulip mania of the 17^th century) they still manage to surprise us.

The second problem one can encounter is that the sum of all expected values is much larger than what is actually observed. Consider for example the exercise of listing all health risks, like smoking, drinking, road accidents, genetic defects, heart attacks, cancer and many more. For each of those risks the probability of a fatality is estimated and the probabilities are summed. One should not be surprised that according to the calculation, one should die about three times a year: in reality the probability is much more in the neighborhood of once every hundred years. The most important explanation of this gap is the fact that human beings are very bad as estimating probabilities. The last number they heard has impact on the estimation, no matter whether the number is related to the risk or not[1].The professional risk manager solves this by searching for supporting data. But there a second problem arises: the required data is not available as the risk has not materialized yet (what is the probability of a total nuclear war?) or the data contains some filtering of reality. A typical case is the number of traffic fatalities. Does the number include only the ones that die in the accident, or also those that die in the hospital afterwards, or even those that die after being discharged from the hospital. And if someone dies because of drunk driving, is that a victim of traffic or of alcohol abuse? The problem is often solved by very strict definitions, but even then an extended list of risks will generally result in overestimating the total expected amount of misery.  What is happening here?

Actually the explanation is very simple. Misery does not come into existence spontaneously, but is the result of a chain of cause and effect. Such a chain is also known as a risk process. Below our scheme is shown that contains most of the things that can go wrong in distributing energy (electricity and gas).

In general, in a risk identification session aspects of all phases in the risk process will be mentioned. In the scheme below they can be items like excavation works (cause), medium voltage cables (asset), short circuit (reaction) and outage (consequence). That seems a good result for a first round, given that excavation works cause about 50% of the failures, the medium voltage is involved in 50% of the total outage time and short circuiting is responsible for 80% of the outages. But summed this results in 180% of the outages per year. That might be a little overestimation. The lesson to be learnt is that the different phases cannot be summed. A significant part of damage caused by excavation works considers medium voltage cables that short circuit. If they are summed, some aspects are counted twice.

 Without a doubt some wise guys will jump up to suggest that risks should only be identified in one phase to avoid overlap. However, in practice that does not help. A risk is namely identified in the phase where one expects to find the mitigation. So, if the solution is thought to be preventing people from working close to the assets, the risk will be labeled excavation works. This mitigation helps more than one type of asset. But if the solution is protecting the cables (by using armored cables, or putting a concrete slab above them) it is natural to label the risk as vulnerable cable, as the protections works against other causes than only excavation works.

In short, the list of risks may look like a list that can be summed, but it is nothing like that. A risk manager is probably bettor of by stowing away his pocket calculator and fetching his colored pencils from the attic.

<< back to overview