identifying causes, risks, and effects
Accuracy is essential; and good techniques exist that simplify the process and eliminate confusion.
by David Hillson, PMP
RISK IDENTIFICATION IS ARGUABLY the most important phase of the risk process, since any risk not explicitly identified is being taken unconsciously and unawares. It is therefore important that risk identification receives proper attention.
There are many alternative techniques available to assist in identifying risks, including brainstorms/workshops, SWOT analysis, assumptions analysis, prompt lists and checklists, Delphi groups, nominal group technique, document analysis, interviews, and diagramming techniques. However, the effectiveness of these approaches will be seriously reduced if those using them are not clear about what they are trying to identify.
Unfortunately, the output of risk-identification techniques frequently includes items that are not risks. This dilutes the value of the risk process, introduces distractions at the early stages, obscures genuine risks, and can lead to frustration and disillusionment among participants. A clear definition of risk is vital to provide a boundary to the risk-identification process, focusing on the two key characteristics of risk; namely, uncertainty and effect on objectives. For example, the revised risk chapter of the PMBOK® Guide states:
Project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on a project objective. A risk has a cause and, if it occurs, an impact.
Using a definition like this should ensure that the output of risk identification does not include known problems or issues which are not uncertain, or irrelevant concerns and worries that cannot affect objectives.
Causes, Risks, Effects. The most common error made during risk identification is to fail to distinguish between causes of risk, genuine risks, and the effects of risks.
Causes. These are definite events or sets of circumstances that exist in the project or its environment, and which give rise to uncertainty. Examples include the requirement to implement the project in a developing country, the need to use an unproven new technology, the lack of skilled personnel, or the fact that the organization has never done a similar project.
David Hillson, Ph.D., PMP, manager of consultancy with Project Management Professional Services Limited in Buckinghamshire, U.K., specializes in risk-technology transfer, assisting organizations to develop in-house risk processes. A regular conference speaker on risk, Hillson is an active member of the PMI® Risk Management SIG and contributed to the recent revision of the risk chapter of the PMBOK® Guide. He is also a Fellow of the U.K. Association for Project Management and an elected member of the U.K. Institute of Risk Management.
Risk. These are uncertain events or sets of circumstances that, if they occur, would affect the project objectives. Examples include the possibility that planned productivity targets might not be met, uncertainty over interest- or exchange-rate fluctuations, the chance that client expectations may be misunderstood, or whether a contractor might deliver earlier than planned.
Effect. These are unplanned variations from project objectives, either positive or negative, which arise as a result of risks occurring. Examples include being late for a milestone, exceeding the authorized budget, or failing to meet contractually agreed performance targets.
It is important to maintain a clear separation between these three types during risk identification. Causes of risk are definite features of the project, and as such they are not uncertain. If they are mistakenly labeled as “risks,” they will distort the risk-assessment phase of the process, since their probability of occurrence is certain (they are facts). This means that those performing risk assessment will rank causes higher than genuine risks, which have a lower probability of occurrence (that is, less than 100 percent). This obscures genuine risks, which may not receive the appropriate degree of attention they deserve. The credibility of the risk process is also undermined, since it is often not possible to tackle causes effectively and it appears that so-called “risks” are not being managed.
Similarly, if effects are included as “risks,” they will distract attention from genuine risks. Effects are contingent events that will not occur unless risks happen, so they are unplanned, potential future variations. The aim of risk management is to tackle genuine risks, and if risk management is effective effects will not be experienced. As effects do not yet exist, and indeed they may never exist, they cannot be managed through the risk-management process. As with causes, inclusion of effects as so-called “risks” will divert attention from genuine risks and will damage the credibility and effectiveness of the risk process.
The risk-management process is designed to address genuine risks; that is, those uncertain events or sets of circumstances that might or might not occur, but that will have an effect on project objectives if they do occur. Risk assessment estimates two dimensions for each risk; namely, the uncertainty (described as “probability of occurrence”) and the effect on objectives if the risk occurs (described as “impact”). Only genuine risks have both of these dimensions, since causes are certain and have no associated “probability” dimension, and effects are simply a description of the “impact” dimension of a risk.
Using Metalanguage to Distinguish Risks. In order to assist participants in the risk-identification phase to clearly separate risks from their causes and effects, an approach is required that forces a distinction. Use of an appropriate metalanguage can provide structure to the description of risk in a way that achieves this separation. Metalanguage uses words or symbols to structure thinking and describe a concept in a systematic and formal way.
Risk metalanguage provides a three-part structured description of a risk that includes cause, risk, and effect. By requiring each element to be explicitly stated using precise words, confusion between the three is minimized.
The three elements of the risk metalanguage can be summarized as follows: “As a result of <definite cause>, <uncertain event> may occur, which would lead to <effect on objective(s)>.”
“A s a result of using novel hardware, unexpected system-integration errors may occur which would lead to overspending on the project.” The use of novel hardware is a definite fact that is a cause of uncertainty and gives rise to risk. The risk itself is the possibility of encountering unexpected errors, which of course might not occur. If, however, the errors were to happen, there would be an effect on the project budget. A proactive approach can be adopted if the risk is correctly identified as “There may be an unexpected level of integration errors.” Planned actions might then include more rigorous preliminary checks or prototyping, use of experienced personnel, or creation of more float for this activity. If, however, “The required use of novel hardware” was wrongly identified as a risk, it might be hard to develop suitable responses, since this fact forms part of the project requirement. Similarly, if “Project overspending” were thought to be the risk, no response would be possible since this would occur only if something else happened.
“Because our organization has never done a project like this, we might misunderstand the customer's requirement, and our solution would not meet the performance criteria.” The definite factual cause is the organization's lack of relevant prior experience. The uncertain event is the possibility of misunderstanding requirements (although lack of experience does not necessarily mean that this will happen), so it is a risk. The contingent future effect would be failure to meet the performance objective.
Reader Service Number 190
“The plan states a team size of 10, but we have only six staff available; so we might not be able to complete the work in the required time and we could be late.” The definite staff shortage is the cause, giving rise to a risk that the available team may be too small for the required scope, with a possible effect on project timescales.
It is possible to identify keywords for each of the three elements of the risk metalanguage, whose use indicates correct separation of cause from risk from effect.
Causesare definite facts or conditions about the project, so their element of the risk metalanguage includes present tense phrases such as is, do, has, has not, and are.
Risksrepresent uncertain future events that may or may not occur, and are described with words like may, might, could, and possibly.
Effectsare conditional future events, contingent on the occurrence of risks. These are the hardest to describe unambiguously due to the imprecise nature of the English language. The subjunctive form would is the proper way to describe effects, but a simple or conditional future tense is often used, namely, will or could.
Recording Identified Risks. The intention behind using the risk metalanguage is to provide a structured framework that leads to proper identification of genuine risks as distinct from causes or effects. It is, however, not essential when recording risks (for example, in a Risk Register) to use all three elements of the metalanguage description.
Some risk register formats include fields for description of the risk, its background (which would include the cause), and the impacts (in words as well as a qualitative assessment). Where this format is used, the three metalanguage elements can be recorded separately.
If, however, a simpler recording format is employed, there may not be separate fields for each of the metalanguage elements. In this case, it is recommended that the “risk description” field should contain only the actual risk, and that the cause and effect need not be included. This will avoid confusion and will focus attention on the genuine risk. The main value of the cause/risk/effect metalanguage is to assist in the thinking process during risk identification, and to ensure that genuine risks are identified. Once this has been achieved, it may not be necessary to write down all the metalanguage elements in full, as long as the real risk is captured.
Separate identification of causes and effects can also be helpful when designing responses to risks, especially risk-avoidance responses, which aim to remove the cause, or break the causal link to the risk, or prevent the resultant effect should the risk occur.
Analysis of causes can also identify common root causes that may be giving rise to several risks. Development of generic responses to root causes can be very effective in addressing multiple risks. Similarly, analysis of effects can reveal “hot spots” of risk exposure where multiple risks might affect the same project objective, leading to development of protective or preventative responses.
GOOD TECHNIQUES EXIST for risk identification, and these are well understood and widely used. However, an accurate and unambiguous description of risks is essential if the vital risk-identification phase is to be effective. In particular, real risks should be identified, rather than difficult or problematic causes of risk, or potential future effects of uncertainty on project objectives.
The use of a structured risk metalanguage provides a framework for shaping the thinking of those trying to identify risks. In our experience, this has proved to be a powerful aid to effective risk management, by focusing attention on genuine risks, revealing underlying causes, and clarifying impacts. Risk metalanguage represents a significant advance in risk-management methodology, enabling risk practitioners to ensure that risk identification identifies risks. ■
Reader Service Number 084
PM Network September 2000