Abstract
Although the practice of risk management is now a recognized and mature discipline, there is a lack of consensus around the definition of what a risk really is. This confusion stems from the fact that all of the current definitions are incomplete in that they only describe one of the several components that, together, determine a risk. A new definition is proposed that encompasses the principal current definitions as well as providing a firmer basis on which to build risk assessment and management processes. Since a risk, once it has occurred, becomes an issue, the definition and management of issues is also addressed to bring it in line with the new definition of risk. This has the advantage of providing a consistent view of the management of risk, from identification right up to the resolution of any contingent issues.
Introduction
The definition of risk has been the subject of a number of debates between practitioners over the years. One heated debate addressed the question as to whether a risk should only have a negative connotation—a threat—as is understood in everyday use, or whether the term should also cover opportunities. Once this debate had calmed down at the end of the last century in favor of the broader definition, it was felt that the major disagreements around the definition of risk had been resolved. However, an even more fundamental question was still outstanding and, like all unresolved issues, it has refused to go away. The symptoms of this problem are shown, for example, in “Introduction to PRINCE2™” (Office of Government Commerce [OGC], 2009, p. 30) in which there are two mutually incompatible statements about risk:
- “A risk is an uncertain event that could have an effect on the achievement of objectives…”
- “A risk consists of a combination of the probability of […] occurring and the magnitude of its impact on objectives.”
To add to the confusion, the ISO 31000 standard “Risk management—Principles and Guidelines” [ISO 2009] states the risk is the effect of the uncertainty. The Standards Australia/Standards New Zealand (AS/NZS) (2004) says that risk is “the chance of something happening that will have an impact on objectives,” although they do note that “A risk is often specified in terms of an event or circumstance and the consequences that may flow from it.” (p.3, Note 1). So now, we have four incompatible definitions: is a risk a situation, a combination of quantities, an effect, or a probability?
Each View Is Wrong, All Views Are Right
This is similar to the tale of the blind men and the elephant (Jainworld.com, n.d.) where each man only identified a small part of the entire animal and argued endlessly about who was right.
The various descriptions of risk given earlier are another example of selecting one of the features of the subject and ignoring the others, or at least considering them only as characteristics associated with the chosen feature, for example, “Risk is an uncertain occurrence that has two essential characteristics…” or “An elephant is like a rope that has pillar, branch, pipe and other characteristics.”
Redefining Risk
From Common Usage to A Formal Definition
It is often useful to start with a blank slate when trying to resolve a disagreement. So, how is the concept of risk used?
The concept of risk triggers a number of images, principally: uncertainty (inability to state something definitely); situation (the risk event, or condition); and effect (which may have a quantifiable impact on objectives). Each image on its own is only part of the picture. Applying the term risk uniquely to any one of them is therefore unsatisfactory. All of the existing definitions, however, do this: the Project Management Institute and most other organizations pick a “situation” (which is sometimes called “uncertainty” to mean the “uncertain situation”); ISO picks “effect.” For the third option, a search of the Web shows how many people use “risk is the probability ….” To add to the confusion, the term risk is also associated with the product of two of the dimensions (i.e., the “expected value” as stated in the OGC document). A great example of confusing several of these in a single Web page is given by a U.S. government briefing on environmental hazards [Environmental Protection Agency [EPA], 1991]. At one point, it says that “Health Risk = Hazard x Exposure”, and a few lines further on: “Health risk is the probability, or chance, that exposure to a hazardous substance will make you sick”. Is it the product of two quantities or is it a probability? It is of course neither on its own—and more than both!
The reason for this confusing state of affairs is that risk is a multidimensional concept and should be explained as such; otherwise, it only gives part of the picture.
The following definition is proposed to remove this confusion: “Risk consists of an uncertain event or set of conditions (“risk situation”), the probability that this situation will occur, and the impacts (which can be positive or negative) that the situation would have on a defined set of objectives.” The term “impact” is used in the definition rather than “effect” since the “effect” of a situation is the change to the relevant environment due to the situation, whereas “impact” is the measurable result of this effect on an objective. Also, the term “occurrence” will be used throughout this paper to designate a risk situation that has actually occurred.
This definition of risk raises an additional question on risks: If a relevant situation has occurred, but you are not yet sure about it (e.g., because the information has not yet had the time to reach you), is it still a risk? In other words, there are two categories of risk corresponding to two categories of uncertainty (Haimes, 1998): 1. The uncertainty relates to whether (and the manner in which) the situation might occur (objective or aleatoric risk); and 2. It relates to your degree of knowledge about the past, current of future occurrence of the situation (subjective or epistemic risk). Logically and practically, risk management needs to address both categories of uncertainty. In addition, for still greater generality, the degree of uncertainty can be measured either in terms of probability of a single occurrence, or with respect to the frequency with which the situation is expected to occur. To encompass all of these additional concepts, the term “likelihood” should therefore be used to encompass the concept of these: the probability or the number of times that the situation could occur and affect the project objectives within a defined timespan.
Adoption of these concepts gives “Risk consists of an uncertain event or set of conditions (“risk situation”), the likelihood of the situation, and the impacts (which can be positive or negative) that the occurrence of the situation would have on a defined set of objectives.”
Is this sufficient?
Review of the Definition
It is often useful to go back to basics to review ideas. For projects, the fundamental concept is the “triple constraint” of interdependent objectives of time, cost, and scope, and complying with any other relevant constraints (Exhibit 1).
This raises an interesting question: If a project changes in such a way that the specified product scope is not delivered or some constraints are not respected, but all of the objectives are met, is the project still a success? If the answer to this can ever be “no,” the definition would have to be expanded to read: “Risk consists of an uncertain situation, the likelihood of the situation, and the impacts (which can be positive or negative) that the occurrence of the situation would have on a defined set of objectives or on the specified product scope or compliance with constraint.”
Although it might be argued that every project has an objective to deliver the product as specified, the expanded definition does make sure that scope change is explicitly considered as a potential risk impact. For simplicity, the term “project success” will denote achieving the objectives and delivering the scope while complying with project constraints. In this way, the definition becomes: “Risk consists of an uncertain situation, the likelihood of the situation, and the impacts (which can be positive or negative) that the occurrence of the situation would have on project success.”
In this way, the analysis has led to the definition of risk, which will be used for the rest of this article, and will be shown to be a source of understanding and insights into the processes associated with the effective management of risk.
Everyday View of Risk
People can of course use shorthand between themselves to discuss concepts, but the full definition should be kept in mind as a common, formal basis of understanding.
It can happen that formal definitions clash with the everyday understanding of an idea. That is not the case for this definition. Consider the following statements you may hear about a given risk:
- “There is a considerable risk that the airline will go on strike”; in this case, the word risk refers to the likelihood.
- “The risk is that the airline could go on strike”; in this case, the word risk refers to the event.;
- “The risk is that (because of the strike) I will not be able to get to my meeting”; in this case, the word “risk” refers to the effect.
In this example, the context helps to understand which component of the risk is actually being described. This is not a problem in general use, but can lead to faulty reasoning in a formal environment if the concepts are not clearly defined.
Applying the New Definition to Risk Management
Risk Identification
The advantage of the three-part definition of risk is that its correlates well with other useful concepts in risk management; for example, the structured description of a risk (also known as “risk metalanguage”). This takes the following form: “Because of <one or more causes>, <risk situation> may occur, leading to < one or more effects>”. Knowledge of the potential causes allows you to evaluate the likelihood; identification of the effects provides a basis for quantifying the impact.
Risk Prioritization
Other characteristics often associated with risk are also compatible with the new definition, since they are functions of one or more of the components. For example,
- Expected value is not the risk itself, but the product of two components: impact of the effect and probability. This is often considered to be “the size of the risk” (Schuyler 2001). This can be used as one of the criteria for prioritizing the risks.
Risk Response Planning
The multipart definition also has the advantage of allowing the current standard set of response categories to be more precisely understood and applied. This leads to a new approach based on distinguishing between the types of actions for addressing the situation, those for addressing the impact, and those for addressing the probability. This is valuable because the type of action required to affect the probability will usually be very different from one that changes the impact of the event on the relevant objectives. The way in which the current categories, for each of threats and opportunities, can be subdivided with respect to situation, impact, and probability and a proposed new set of terms is shown in Exhibit 2.
Risk Attitudes
The U.K.'s Cabinet Office Strategy Unit's report “Risk: Improving Government's Capability to Handle Risk and Uncertainty” [Cabinet Office, 2002] states that risk refers to “uncertainty of outcome, whether positive opportunity or negative threat, of actions and events. It is the combination of likelihood and impact, including perceived importance” (p. 26). The important addition in this definition is that risk perception is brought into the definition.
David Hillson (2010) provides an informal definition of risk as “uncertainty that matters” (p. 84). He also describes attitude as “a chosen response to a given situation” which is affected by perception of the situation (p. 155). He combines these two definitions to state that risk attitude is “a chosen response to uncertainty that matters, influenced by perception” (p. 155). Replacing the informal definition of risk in this definition with the new definition raises a number of interesting insights into risk attitudes.
Using the expanded definition of risk, risk attitude becomes “a chosen response, based on perception, to an uncertain situation, the likelihood of the situation, and the impacts (which can be positive or negative) that the occurrence of the situation would have on project success.” Since the chosen response is based on perception, risk attitude is influenced by the person's perception of each of the components of risk.
Perception of the Risk Situation
Although it is difficult to separate the perception of a situation from its impact (Kahneman, Slovic, & Tversky, 1982), this can be done by considering the affective factors associated with the situation: loss of a loved one, for example, is a situation that affects some people much more than others. In addition, of course, one person's loved one may be someone else's sworn enemy; once again the perception of the situation will be totally different.
Perception of the Likelihood
There are numerous studies that show how people's perception of the likelihood of a situation can be influenced illogically by cognitive biases: lack of understanding, wishful thinking, anchoring, “affect,” framing, groupthink, confirmation bias, self-serving bias, etc.
Perception of the Effect
Envisaging the effect of a future situation often requires some form of storytelling or scenario analysis (Fahey & Randall, 1997). The way that this is done can have a considerable influence on a person's perception of what the situation would actually imply.
Perception of the Impact
This falls into the domain of “utility theory.” That is to say that each person's perception of a given objective impact is strongly conditioned by his or her circumstances. For example, a loss of €1000 on a €1 million project might be considered insignificant, whereas the loss of the same sum to an individual might be considered dramatic. The analysis of this area is covered by expected utility theory (Piney, 2003) as well as the variant, prospect theory (Kahneman & Tversky, 1979).
Perception of the Objectives and the Scope
Most projects have a number of stakeholders with different goals. Even when the stakeholders agree on the set of project objectives and the specified scope, they are unlikely to hold identical views on the importance of each individual objective or component of the scope. For this reason, their perception of the importance of what is impacted is very likely to differ considerably between stakeholders.
Perception is, of course, just as important in dealing with the risk once it occurs.
From Risks to Issues
The confusion around the definition of the term “risk” extends in a different way to the definition of an “issue.”
Issues are of interest in the context of risk because “A project risk that has occurred can also be considered an issue” (Project Management Institute, 2008, p. 275).The standards, however, are not at all consistent on the definition of the term “issue,” if they address it at all. It is also disappointing that the approach taken by these standards is to consider that, once a risk becomes an issue, the risk management problem is solved—despite the fact that the management of issues of this type is not addressed appropriately.
OGC (OGC, 2009) defines issue as “a relevant event that has happened, was not planned, and requires action” (Glossary p.98).
PMI (2008) presents a different view in the PMBOK® Guide: “A point or matter in question or in dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements” (Glossary, p. 437). These two definitions seem difficult to align. The OGC definition is clearly action-oriented because it aims at reacting appropriately to the event. The PMI definition seems to be solely addressing the fact that there are opposing views and “issue resolution addresses obstacles that can block the team from achieving its goals” (Issue Log. p. 240) and adds elsewhere, “issues usually do not rise to the importance of becoming a project or activity but are usually addressed in order to maintain good, constructive working relationships among various stakeholders, including team members” (Issue Log, p. 263) However, the statement “A project risk that has occurred can also be considered an issue” seems more compatible with the OGC definition than the PMI definition—apart from the OGC qualifier—“that…was not planned” because a risk can be either foreseen or unforeseen, and a response to it either planned or not.
Based on this reasoning and the decision that likelihood relates to the knowledge about the occurrence, a more generally applicable definition of an issue would be “A situation that is known to have occurred and that could affect project success.” The qualifier “and requires action” used in the PRINCE2 definition has been deliberately omitted since the need for action—or not—depends on the prioritization of the situation, and that, in turn, depends on the relative importance of the other current occurrences. In the same way as for a risk, a situation can be “accepted” and no action planned.
The value of this new definition for developing a consistent risk and issue management process is explained in the following sections.
Issues as Risk Occurrences
Therefore, simply, a project situation that can affect project success and that is known to have occurred (i.e., is now certain) can be considered an issue. This is because the preceding definition makes it clear that the occurrence would have an effect on the project's objectives. Seen another way, whereas risk is a three-dimensional concept (situation, likelihood, impact), once the situation is certain, likelihood ceases to be a component, and what was a risk collapses down into an (two-dimensional) issue (i.e., situation and impact).
The Dual Nature of Issues
So, once a risk situation is certain, the occurrence becomes an issue. This raises a fundamental point to be discussed: because the impact of a risk can be positive or negative, the effect of an issue on the project's objectives can also be positive or negative. Although the everyday understanding of an issue is that it creates obstacles, for the purpose of effective project management in general, and risk management in particular, the definition of issue needs to be extended to include positive as well as negative impacts. This mirrors the way that the dual view of risk has now gained wide acceptance at a technical level.
The terminology also needs to be addressed to support this dual nature: In the same way as risks are either threats (negative impact) or opportunities (positive impact), issues can be problems (negative impact) or advantages (positive impact).
The corresponding definition of an issue would therefore be “A situation that is certain and that could affect project success in a positive or negative manner.”
In the same way that the risk management process caters effectively for both threats and opportunities, as will be explained in the following, the issue management process addresses advantages as well as problems.
In this way, issue management becomes an integral part, or natural follow-on of the risk management cycle, and a risk can simply be seen as “a potential issue.”
The Issue Management Process
The same process can be used for managing both issues arising from identified risks as well as those that emerge unexpectedly. This is important to understand and implement for two reasons:
Avoiding the unfortunately frequent failure in projects to treat a risk once the situation occurs, since each such risk automatically becomes a candidate for issue management
Ensuring that the interactions between the management of issues and the treatment of risks are all taken into account in an appropriate manner (see Exhibit 4).
The main steps of the issue management process (lower left in Exhibit 4) are similar to those of the risk management cycle (upper right in Exhibit 4) and are explained in the following. These are the main steps:
• plan issue management: tailoring and parameterization of the overall issue management process;
• issue identification and documentation;
• issue analysis and prioritization;
• issue action planning; and
• issue monitoring, control and resolution.
Tailor the Issue Management Process
The details of the process for managing issues need to be defined early on in the project. Because of the definition of an issue, this should is closely linked to the definition of the project's scope and objectives, as well as the roles and responsibilities of team members.
Issue Identification and Documentation
In the same way that a formal structure (“metalanguage”) is valuable in defining risks, a similar approach should be used for issues. The proposed format is:
“Given that <issue situation> has occurred, the current status <brief description of status>, affecting <project objectives> as follows <description of impact – quantified if possible; action-oriented if possible>.” For example:
Problem: Given that the technical architect and the work-stream leader cannot agree as to the technical solution, (the status is that) implementation is halted, affecting time, cost, and product scope in a way that threatens the total project.
Advantage: Given that Project X has finished early, (the status is that) additional installation engineers are available, affecting time as follows: we can save 3 weeks by deploying these additional resources in our project.
Issue Analysis and Prioritization
Once the issues are well defined, they need to be assigned for analysis and prioritization. In the case where the effect of the situation is unclear or uncertain, risk management tools have to be invoked as shown by the “uncertain effects” arrow in Exhibit 4. Where deemed sufficiently important, the treatment of the issue needs to be planned, assigned, executed, monitored, and controlled.
Issue Action Planning
Since an issue is a risk from which the uncertainty has been removed, the table of risk responses proposed earlier (Exhibit 2) can be adapted for dealing with issues by removing all of the actions aimed at affecting the likelihood. The resulting approach is shown in Exhibit 5.
Taking the examples presented earlier for issue identification:
Problem example: Given that the technical architect and the work-stream leader cannot agree as to the technical solution, the status is that implementation is halted, affecting time, cost, and product scope in a way that threatens the total project.
○ address the situation
• [adapt] organize a definitive technical review of potential solutions to which the technical architect and work-stream leader must contribute, and comply, or
• [adapt and/or reassign] explain to the work-stream leader that the technical architect has overall responsibility: “put up or get out!”
○ address the impact
• [shift] outsource the implementation.
Advantage example: Given that Project X has finished early, (the status is that) additional installation engineers are available, affecting time as follows: we can save 3 weeks by deploying these additional resources in our project.
○ address the situation
• [improve] make sure that the engineers will be assigned to your project by contacting your sponsor, their managers and the engineers themselves
○ address the impact
• [augment] investigate whether the client is willing to pay a bonus for early delivery;
• [capture] organize a planning meeting to assess the best way of integrating the extra people into the teams, and re-optimizing the schedule accordingly.
It is also possible to decide not to take any action at all. This may be the best decision if the impact of the issue is sufficiently small or sufficiently far off in time, or if all available resources are occupied with higher-priority issues.
Before these actions are approved, an analysis of the resultant risks must be carried out to evaluate the coherence of the actions and their viability with respect to the project objectives. This is shown in the ‘secondary effects” arrow from “Plan Issue Responses” shown in Exhibit 4. Once the actions have been approved, the corresponding project documents must be updated and the agreed actions formally assigned to “issue action owners”.
Execution, Monitoring, Control and Resolution
Once the agreed actions have been assigned and integrated into the project documents, the actions will be tracked by standard project monitoring processes, including monitoring for emerging risks as shown by the semi-transparent arrow from issue execution to risk identification in Exhibit 4. It is the responsibility of the issue owners to make sure that the relevant information is made available to them so that they can carry out their related responsibilities of overseeing, reporting on, and finally closing the issues for which they are responsible. The link between issue management and project governance must also be understood.
Major Review Points for Issue Management
Phase boundaries. Whereas the risk register can help to provide a good indication at any point in time of the risk exposure and level of uncertainty of a project, the issue register provides an indication of the degree to which the project is under control. This is a topic to review whenever the project reaches a major review milestone such as a phase boundary: Some issues may need to be resolved before a phase can finish and, similarly, some issues may be obstacles to starting a new phase. Come what may, it is important on major reviews to update the list of lessons learned based on the set of issues encountered and the effectiveness of their treatment.
Project closure. One point that is often poorly understood is that, once a project closes, there are no outstanding project issues. This is a direct consequence of the definition of an issue as “a situation that…could affect project success”; so, whether the project is a success or not, once it has terminated, it is too late for any situation to affect it any further. However, in the same way as for risks, the list of issues that had not been resolved by the time the project was closed should be reviewed in case any of the corresponding situations has implications on the post-project environment. This analysis should form part of the project closure and handover report.
Conclusion
The definition in this paper extends and encompasses pre-existing definitions of risk in standards and other relevant documents, while remaining as compatible as possible with the everyday uses of the term. These can be considered as partial subsets of it, for example, “uncertainty that matters” can be considered correct and very useful, as a simplification of a broader concept. The fundamental message, however, is that risk cannot be equated with any of its components: It is not the likelihood, not the impact, not even the event or condition, and is most certainly not a single value such as expected value, calculated from a combination of any of these. It is broader than and different from any one or two of its components, and its existence requires the existence of all three. An issue is the limiting case of a risk, where the uncertainty disappears and the situation therefore becomes certain.
It has been shown that the new definitions are conducive to effective risk and issue management as they align well with risk management best practice as defined in the current literature.
The analysis has been extended to deal with risks once they are known to have occurred, and have therefore become issues. The definitions in this area have been adapted accordingly and extend the dual nature of risks into the concept of issues and issue management. Together with the new definition of risk, this provides a full end-to-end “situation lifetime” management process, from the very start with the identification of potentially relevant situations (i.e., risks), to the final resolution of any issues that these situations could create. Risks and issues are different stages in the evolution of a situation, and should be treated in a consistent manner by means of an integrated process.
The remaining challenge will be to share the message in such a way that the new definitions become widely known, applied and included in future professional publications in the following form:
Project success: “Achieving the objectives and delivering the scope, while complying with project constraints.”
A situation: “An event or set of conditions.”
An effect: “The change to the relevant environment due to the situation.”
An impact: “The measurable result of an effect on an objective.”
Likelihood: “The probability or number of times that a specific situation could occur and affect the project objectives within a defined timespan.”
Risk: “An uncertain situation, the likelihood of the situation, and the impacts (which can be positive or negative) that the occurrence of the situation would have on project success.”
Risk attitude: “A chosen response based on perception, to an uncertain situation, the likelihood of the situation, and the impacts (which can be positive or negative) that the occurrence of the situation would have on project success.”
Certain: “Known definitively.”
An issue: “A situation that is certain and that could affect project success in a positive or negative manner.”
An advantage: “A positive issue.”
A problem: “a negative issue.”
Issue management: “A process by which the situation or its impact are influenced to enhance project success.”
Risk: “A potential issue.”
Risk management: “Proactive issue management.”