This is a follow-on article to the one “Key Stages in Modelling Risk and Uncertainty” and focusses on some of the challenges in the risk identification stage.
Risk identification involves identifying which factors of a real-lie situation affect the outcome (whose risk we are trying to assess, such as the value of a contract, the cost of a project, and so in). It can be helpful to work backwards from the outcome asking: “What would make this item’s value different (to the base case, or what we have assumed)?” One can ask this question again for the first set of factors identified, until one has a set that is complete and realistic.
One of the challenges is to know when to stop in the backward process to identify the factors that affect a situation: each stage results in more variables being identified and the number of causal factors increases. For example, generally one would consider the toss of a coin as a random factor that produces either heads or tails. Only in rare circumstances would it make sense to try to determine more precisely the factors that lead to a specific outcome in a specific context (e.g. assessment of wind speed and direction when the coin is tossed in the open air, the direction and momentum of the original toss, the starting position of the coin in the person’s hand etc.).
A related challenge is that of prioritisation (which is often considered as a separate step of the process): factors to be included should be those that are relevant. One example is to ensure that event risks are adequately included. For example, a project may contain several critical sub-elements, phases or tasks, where each is required to succeed for the project to succeed. If each task – on a stand-alone basis – has a good chance of success (say 80%), then a (non-risk-based) quantitative model may often simply assume that the task will succeed (First, it is the most likely outcome, and has a quite high likelihood on an individual basis. Second, it may be politically delicate to highlight that a task or project may fail; the result is that the risk is ignored in the model, and the task and the remaining part of the project are built into the model as if they were definite activities). The quantitative model will be one which shows that the project completes, and will have a value associated with that (net present value, rate of return etc.)
However, if the project in fact involves four such critical tasks, then the chance that the project will succeed in reality is 80% to the power of four, or approximately 41%. Typically, investment will be made upfront and the return or benefit will full occur in only 41% of cases. Thus, the project is far less valuable in principle.
This approach demonstrates the potential “fallacy of the most likely”: The assumption that each item will have its most likely outcome, does not lead to a model whose output is generally the most likely. Similarly, low-probability event risks (e.g. 10% chance) may be ignored in a non-risk model, as there is no way to capture them other than to assume that they do not occur. However, if there are several or the impact of any is severe, then the true outcome may be quite different to the model. Similar remarks can be made when the base case assumptions are slightly biased (optimistically or pessimistically): In general, the assessment of how these biases play out in aggregate can be made only by building a risk model, in which risks, and uncertainties are captured and their aggregate effect on the outcome quantified (e.g. with simulation). Finally, non-linear behaviours within a situation or system may create a high degree of sensitivity between input and output values, so that single point estimates of an outcome could be misleading.
In some cases, the risk analysis can be a politically charged or sensitive step: Whilst a base case model can often be presented as one realistic outcome, the risk assessment process (of performed well) may show a very different set of outcomes in aggregate. Clearly, if this were to put into question a project’s viability, then that could be sensitive. Also, because risk analysis is a more specialised and time-consuming activity than regular financial analysis, it may often be conducted after a project has gained authorisation in priniciple; this makes it all the more difficult to challenge the original decision.