CHAPTER 14
Risk Management in Practice

DAVID HILLSON, PHD, PMP, FAPM, FIRM; RISK DOCTOR & PARTNERS

The word “risk” is a common and widely used part of our daily vocabulary, relating to personal circumstances (health, pensions, insurance, investments, etc.), society (terrorism, economic performance, food safety, etc.), and business (corporate governance, strategy, business continuity, etc.). One area where risk management has found particular prominence is in the management of projects, perhaps because of the risky nature of projects themselves. All projects to some extent are characterized by the following:

• Uniqueness

• Complexity

• Change

• Assumptions

• Constraints

• Dependencies

• People.

Each of these factors introduces significant risk into every project, requiring a structured and proactive approach to the management of risk if the project is to succeed.

Many see risk management as a key contributor to the success of both projects and businesses. This arises from the clear link between risk and objectives, embodied in the definition of the word. For example, the PMBOK^® Guide states: “Risk is an uncertain event or condition that, if it occurs, has an effect on at least one project objective.”¹ Other international standards and guidelines use similar definitions, always linking risk with objectives.

This is why risk management is so important and not just another project management technique. Risk management aims to identify those uncertainties with the potential to harm the project, assess them so they are understood, and develop and implement actions to stop them occurring or minimize their impact on achievement of objectives. It also has the goal of identifying, assessing, and responding to uncertainties that could help achieve objectives. Because it focuses attention on the uncertainties that matter, either negatively or positively, risk management is a Critical Success Factor for project (and business) success. Where risk management is ineffective, a project can only succeed, if the project team is lucky. Effective risk management optimizes the chances of success, even in the face of bad luck.

Fortunately risk management is not difficult. The process, tools and techniques outlined in the PMBOK^® Guide and similar guides offer a straightforward way of implementing an effective approach to managing risk on projects.

DEFINITION OF RISK

Before describing the risk management process, it is obviously important to understand what it is we are trying to manage. The definition of “risk” quoted above clearly includes one distinct types of uncertainty: those that if they occur will have a negative effect on a project objective. But the standard also acknowledges that there are “risk events” that create the possibility of a positive outcome. In other words, risk includes both threat and opportunity. At first sight this causes some hesitation for people new to the concept: “Surely everyone knows that risk is bad! Risk is the same as threat, but isn’t opportunity something different?”

In adopting an inclusive mindset about risk, the Project Management Institute is not unusual, but it is completely consistent with the current trend in international best-practice risk management. Many other leading standards and guidelines from project management organizations worldwide take a similar position.²

Taking this position has significant implications for all aspects of risk management, including thinking, language, and process.³ That is why, as the body of knowledge documents have evolved, they have come to include a wider definition of risk. For example, in the PMBOK^® Guide, Fourth Edition, both threat and opportunity are treated equitably, and the objectives of risk management are stated as “to increase the probability and impact of positive events, and decrease the probability and impact of events adverse to the project.”⁴ The aim is to use the same risk process to handle both threats and opportunities alongside each other, giving double benefits from a single investment.

PROCESS SUMMARY

Risk management is not rocket science, and the risk process simply represents structured common sense. The steps in the process follow a natural way of thinking about the uncertain future, by asking and attempting to answer the following questions:

• What are we trying to achieve? (Planning)

• What uncertainties could affect us, for better or worse? (Identification)

• Which are the most important uncertainties to address? (Analysis)

• What could we do to tackle these uncertainties, and what will we do? (Response planning)

• Let’s do it—and how do things change as a result? (Monitoring and control)

These questions are reflected in the risk management process outlined in the PMBOK^® Guide:

• Risk management planning—deciding how to conduct risk management activities for a project.

• Risk identification—determining which risks might affect the project.

• Qualitative risk analysis—prioritizing risks for subsequent further analysis or action.

• Quantitative risk analysis—numerically analyzing the effect on overall project objectives of identified risks.

• Risk response planning—developing options and actions to enhance opportunities and to reduce threats to project objectives.

• Risk monitoring and control—tracking identified risks, monitoring residual risks, identifying new risks, executing risk response plans, and evaluating effectiveness.

Various tools and techniques can be used to assist with each step, and they can be implemented at differing levels of detail on different projects. Successful risk management, however, only requires structured thinking and action, following a common-sense process in the face of uncertainty.

Risk Management Planning

The first step of the risk management process is not risk identification. Because risk is defined in terms of objectives, it is necessary first to define those objectives that are at risk, that is, the scope of the risk process. The PMBOK^® Guide describes this as “the process of deciding how to conduct the risk management activities for a project.”

This statement indicates that risk management is not “one-size-fits-all.” It is necessary to scale the risk process to meet the risk challenge of each particular project. Projects that are risky or strategically important will require a more robust approach to risk management than those that are simple or routine. Scalable aspects include methodology, tools and techniques, organization and staffing, reporting requirements, and the update and review cycle.

A number of other factors need to be decided before embarking on the risk management process. These include:

• Setting the thresholds of how much risk is acceptable for the project by identifying the risk tolerances of key stakeholders, resolving any differences, and communicating the conclusions to the project team.

• Defining terms for qualitative analysis of probability and impact on the project, related to specific project objectives. Where terms such as “high,” “medium,” and “low” are used, their meanings must be agreed on to provide a consistent framework for assessment of identified risks.

• Definition of potential sources of risk to the project. This may be presented as a hierarchical Risk Breakdown Structure (RBS), perhaps drawing on an industry standard or an organization template. An example RBS is given in Figure 14-1.

The decisions made during this step of the process are documented in a Risk Management Plan, which forms an integral part of the Project Management Plan. The Risk Management Plan should be reviewed during the project and updated where necessary if the risk process is modified.

FIGURE 14-1. EXAMPLE RISK BREAKDOWN STRUCTURE (RBS)

Risk Identification

Because it is not possible to manage a risk that has not first been identified, some view this initial step as the most important in the risk process. Many good techniques are available for risk identification, the most common of which include:

• Use of brainstorming in a workshop setting, perhaps structured into a SWOT Analysis to identify organizational strengths/weaknesses and project opportunities/threats

• Checklists or prompt lists to capture learning from previous risk assessments

• Detailed analysis of project assumptions and constraints to expose those that are most risky

• Interviews with key project stakeholders to gain their perspective on possible risks facing the project

• Review of completed similar projects to identify common risks and effective responses.

For each of these techniques, it is important to involve the right people with the necessary perspective and experience to identify risks facing the project. In addition, use a combination of risk identification techniques rather than relying on just one approach—for example, perhaps using a creative group technique, such as brainstorming, together with a checklist based on past similar projects. The project manager should select appropriate techniques based on the risk challenge faced by the project, as defined in the Risk Management Plan.

Another good idea is to consider immediate “candidate” responses during the risk identification phase. Sometimes an appropriate response becomes clear as soon as the risk is identified, and in such cases it might be advisable to tackle the risk immediately if possible, as long as the proposed response is cost effective and feasible.

Whichever technique is used, it is important to remember that the aim of risk identification is to identify risks. While this may sound self-evident, in fact this step in the risk management process often exposes things that are not risks, including problems, issues, or complaints. The most common mistake is to identify causes of risks or the effects of risks, and to confuse these with risks.⁵

Causes are definite events or sets of circumstances which 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 before. Causes themselves are not uncertain because they are facts or requirements, so they are not the main focus of the risk management process. However, tackling a cause can avoid or mitigate a threat or allow an opportunity to be exploited.

Risks are uncertainties that, if they occur, would affect the project objectives either negatively (threats) or positively (opportunities). Examples include the possibility that planned productivity targets might not be met, interest or exchange rates might fluctuate significantly, the chance that client expectations may be misunderstood, or whether a contractor might deliver earlier than planned. These uncertainties should be managed proactively through the risk management process.

• Effects are unplanned variations from project objectives, either positive or negative, which would arise as a result of risks occurring. Examples include being early for a milestone, exceeding the authorized budget, or failing to meet contractually agreed performance targets. Effects are contingent events, unplanned potential future variations that will not occur unless risks happen. As effects do not yet exist, and indeed they may never exist, they cannot be managed directly through the risk management process.

Including causes or effects in the list of identified risks can obscure genuine risks, which may not then receive the appropriate degree of attention they deserve. One way to clearly separate risks from their causes and effects is to use risk metalanguage (a formal description with required elements) to provide a three-part structured “risk statement” as follows: “As a result of (definite cause), (uncertain event) may occur, which would lead to (effect on objective(s)).” Examples include the following:

• “As a result of using novel hardware (a definite requirement), unexpected system integration errors may occur (an uncertain risk) that would lead to overspend on the project (an effect on the budget objective).”

• “Because our organization has never done a project like this before (fact = cause), we might misunderstand the customer’s requirement (uncertainty = risk), and our solution would not meet the performance criteria (contingent possibility = effect on objective).”

• “We have to outsource production (cause); we may be able to learn new practices from our selected partner (risk), leading to increased productivity and profitability (effect).”

The use of risk metalanguage should ensure that risk identification actually identifies risks, distinct from causes or effects. Without this discipline, risk identification can produce a mixed list containing risks and nonrisks, leading to confusion and distraction later in the risk process.

Finally, the risk identification step of the risk process is where the Risk Register is launched, to document identified risks and their characteristics. Where software tools are used to support the risk process, these usually offer a Risk Register format, though some organizations develop their own. The Risk Register is updated following each of the subsequent steps in the risk process, to capture and communicate risk information and allow appropriate analysis and action to be undertaken.

Qualitative Risk Analysis

Risk identification usually produces a long list of risks, perhaps categorized in various ways. However, all risks cannot be addressed with the same degree of attention because of limitations of time and resources. And not all risks deserve the same level of attention. Therefore, risks should be prioritized for further attention to identify the worst threats and best opportunities, which is the purpose of the qualitative risk analysis phase.

The definition of risk we are using indicates that risk has two dimensions: uncertainty, and its potential effect on objectives. The term “probability” is used to describe the uncertainty dimension, and “impact” describes effect on objectives. For qualitative analysis, these two dimensions are assessed using labels such as “high, medium, low,” where these have been previously defined in the Risk Management Plan. The probability of each risk occurring is assessed, as well as its potential impact if it were to occur. Impact is assessed against each project objective, usually including time and cost, and possibly others such as performance, quality, regulatory compliance, etc. For threats, impacts are negative (lost time, extra cost, etc.), but opportunities have positive impacts (saved time or cost, etc.).

The two-dimensional assessment is used to plot each risk onto a Probability-Impact Matrix, with high/medium/low priority zones. A recent innovation is to use a double “mirror” matrix, to allow threats and opportunities to be prioritized separately, and creating a central zone of focus, as shown in Figure 14-2. This zone contains the worst threats (with high probability so they are likely to happen unless managed, and high impact so they would be very bad for the project) and the best opportunities (where high probability means easy to capture, and high impact means very good).

Another important output from qualitative analysis is to understand the pattern of risk on the project, and whether there are common causes of risk or hotspots of exposure. This can be assessed by mapping risks into the Risk Breakdown Structure (RBS) to determine whether any particular causes give rise to large numbers of risks, and by mapping risks into the Work Breakdown Structure (WBS) to identify areas of the project potentially affected by many risks.

Quantitative Risk Analysis

FIGURE 14-2. “MIRROR” PROBABILITY-IMPACT MATRIX FOR THREATS AND OPPORTUNITIES

On most projects, risks do not happen one at a time. Instead they interact in groups, with some risks causing others to be more likely and some risks making others impossible. Quantitative risk analysis considers risks individually and allows development of a good understanding of each one. It is, however, sometimes necessary to analyze the combined effect of risks on project outcomes, particularly in terms of how they might affect overall time and cost. This requires a quantitative model, and various techniques are available, including sensitivity analysis, decision trees, and Monte Carlo simulation.

Monte Carlo is the most popular quantitative risk analysis technique because it uses simple statistics, takes project plans as its starting point, and is supported by many good software tools. However, decision trees are particularly useful for analyzing key strategic decisions or major option points.

One often overlooked key aspect of quantitative risk analysis models that is the need to include both threats and opportunities. If only threats are considered, then the analysis is only modeling potential downside, and the result will always be pessimistic. Because the risk process aims to tackle threats and opportunities, both must be included in any analysis of the effect of risk on the project. Indeed, some vital elements of the risk model, such as three-point estimates, cannot be properly determined without considering both upside (to produce the minimum/optimistic/best-case estimate) as well as downside (for maximum/pessimistic/worst-case estimate).

When developing Monte Carlo risk models, use available software tools to create simple models that do not reflect the complexities of the risks facing the project. In particular, simply taking single values of duration or cost in a project plan or cost estimate and replacing them with three-point estimates is not sufficient to model risk quantitatively. Other modeling techniques should be used to reflect reality, including the following:

• Different input data distributions, not just the typical three-point estimate (for example, the modified triangular, uniform, spike/discrete, or various curves)

• Use of stochastic branches to model alternative logic (these can also be used to model key risks)

• Correlation (also called dependency) between various elements of the model, to reduce statistical variability.

It is important to recognize that additional investment is required to implement quantitative risk analysis, including purchase of software tools, associated training, and the time and effort required to generate input data, run the model, and interpret the outputs. As a result, in many cases the use of quantitative techniques may not always be justified. Often, information can be obtained from quantitative analysis to allow effective management of risks, and quantitative analysis techniques can be seen as optional. Quantitative analysis is most useful when projects are particularly complex or risky, or when quantitative decisions must be made, for example, concerning bid price, contingency, milestones, delivery dates, etc.

Three potential shortfalls should be mentioned when considering quantitative risk analysis techniques. The first is the importance of data quality, to avoid the GIGO (garbage in-garbage out) situation, and attention to ensuring good quality inputs to the model. Secondly, outputs should always be interpreted from risk models, and quantitative analysis will not tell the project manager what decision to make. Finally, be prepared to use the results of risk modeling and take decisions based on the analysis. We should beware of “analysis paralysis,” because quantitative risk analysis is merely a means to an end and must lead to action.

Risk Response Planning

Having identified and analyzed risks, it is essential that something be done in response. As a result, many believe that the risk response planning phase is the most important in the risk process, since this is where the project team get a chance to make a difference to the risk exposure facing the project.

When introducing tools and techniques for risk response planning, the PMBOK^® Guide uses an important word, stating the following: “Several risk response strategies are available” [italics mine]. It is important to adopt a strategic approach to developing risk responses to focus attention on what is being attempted. Too often, project teams resort to a “scatter-gun” approach, trying a wide range of different responses to a given risk, some of which may be counterproductive. It is better first to select an appropriate strategy for a particular risk, and then to design action to implement that strategy, producing a more focused “rifle-shot” aimed at managing the risk effectively.

A recent development in the evolution of PMI’s standard is to introduce strategies for addressing opportunities along with threat-focused strategies. The opportunity strategies match the common threat strategies, creating three pairs of proactive response strategies, and a final last-resort strategy:

Avoid/Exploit: For threats, the aim of avoidance is to eliminate the risk to the project, making the threat impossible or irrelevant. To exploit an opportunity means to make it definitely happen, ensuring that the project gains the additional benefits.

Transfer/Share: These strategies require involving another person or party in managing the risk. For threats, the pain is transferred, together with the responsibility for managing the potential downside. In a similar way the potential gain from an upside risk can be shared, in return for the other party taking responsibility for managing the opportunity.

Mitigate/Enhance: Mitigation of a threat aims to reduce its probability and/or impact, while enhancing an opportunity seeks to increase it.

Accept: For residual threats and opportunities where proactive action is not possible or not cost-effective, acceptance is the last resort, taking the risk either without special action or with contingency.

Having chosen a strategy, the project team should then develop specific actions to put the strategy into practice. This is the point at which most risk management processes fail. Whichever response strategy is selected, it is vital to go from options to actions, otherwise nothing changes. Many project teams, however, identify and assess risks, develop response plans, write a risk report, and then “file and forget.” Actions are not implemented, and the risk exposure remains the same.

The key to making sure risk responses are implemented is not to allow risk responses to be seen as “extra work” to be done when project tasks are complete. Risk responses are genuine project tasks, that is, work to be done for the project to succeed. They should therefore be treated like any other project task. Each risk response should be fully defined, with a duration, budget, resource requirement, owner, completion criteria, etc. A new task should then be added to the project plan for each agreed risk response, and these should be completed, reviewed, and reported on like all other project tasks.

Risk Monitoring and Control

The purpose of this final phase of the risk process is to ensure that the planned responses are achieving what was expected and to develop new responses where necessary. It is also important to determine whether new risks have arisen on the project and to assess the overall effectiveness of the risk management process. These aims are best achieved through a risk review meeting, although it is possible on smaller projects to review risk as part of a regular project progress meeting.

This step also involves producing risk reports at various levels and for different stakeholders. It is important to communicate the results of the risk process, since the aim is to actively manage the risks, and this is likely to require action by stakeholders outside the immediate project team. Risk reports should form a basis for action and include clear conclusions (“What we have found”) and recommendations (“What should be done”).

Risk management is a cyclic iterative process and should never be done just once on a project. Risk exposure changes daily, as a result of external events, as well as from the actions (and inactions) of the project team and others elsewhere in the organization. To optimize the chances of meeting the project’s objectives, it is essential that the project team have a current view of the risks facing the project, including both threats and opportunities. For risk management, standing still is going backward.

OTHER ISSUES

The risk process outlined in standards and guidelines such as the PMBOK^® Guide is well accepted and forms a good basis on which to build effective management of project risk. However, a number of other issues must be considered if risk management is to be fully effective. It is beyond the scope of this chapter to present these in detail, but they deserve at least a mention.

First is the fact that all risk management is done by people. This introduces the human factor into the picture, requiring proactive management like any other aspect of the risk process. The risk attitudes of both individuals and groups exercise a major influence over the risk process, which must be recognized and managed. The situation is complicated by the action of subconscious perceptual factors and heuristics that affect the risk attitudes adopted by people.⁶

Second, organizational culture has a significant influence over the effectiveness of the risk management process. Where senior management does not recognize the existence of risk or sees risk identification as a sign of weakness or views resources allocated to contingency or risk responses as wasted, risk management will be an uphill struggle. Conversely, the organization that knows how to take risk intelligently will reap the undoubted benefits from minimizing threats and capturing opportunities.

Linked to this is the need for internal sponsorship of the risk process. A risk champion within an organization can promote buy-in for its use at all levels, encouraging project teams and senior management to recognize risk and manage it proactively, sharing best practice and developing corporate experience. This is one of the accepted success factors for risk management and should not be neglected.

The need for an efficient infrastructure to support the risk process must also be recognized. Software tools, training, templates, specialized resources, etc., all have a part to play in making risk management effective. The organization must be prepared to invest in risk infrastructure, and ensure that it is well integrated with project management and other parts of the business.

The aim of paying attention to these factors in addition to the risk process is to develop risk maturity within an organization and its people. This represents a position where all the necessary pieces are in place to allow risk to be managed proactively and effectively, with a supportive culture, efficient processes, experienced people, and consistent application. When these elements are present, together with the tools and techniques described above, risk need not be feared on any project. Instead, it should be welcomed as an opportunity to address the uncertainties inherent in all projects, optimizing the chances of achieving project objectives and delivering successful projects.

Risk management is an essential contributor to project and business success, because it focuses attention on achievement of objectives. By defining project risk as “an uncertain event or condition that, if it occurs, has a positive or negative effect on at least one project objective,” risk management offers a means of tackling those risks with the potential to harm the project (threats) as well as those that could help (opportunities). Concentrating on proactive management of these two aspects maximizes the chance that the project will succeed.

Not only is risk management essential, but also it is not difficult. A simple structured process exists to identify, analyze, and respond to risks, and this can be applied to any project whether it is simple or complex, innovative or routine. The benefits of adopting a structured approach to managing risk are obvious: more successful projects, fewer surprises, less waste, improved team motivation, enhanced professionalism and reputation, increased efficiency and effectiveness, and so on. With these benefits available from adopting such a simple process, risk management deserves its place as one of the most important elements of project management.

REFERENCES

¹ Project Management Institute, A Guide to the Project Management Body of Knowledge, Fourth Edition, Newtown Square, PA: Project Management Institute, 2008: p. 275.

² IEC 62198:2001 “Project risk management—Application guidelines”; ISO/IEC Guide 73:2002 “Risk management vocabulary—Guidelines for use in standards”; Association for Project Management. 2004 “Project Risk Analysis & Management (PRAM) Guide” (second edition). APM Publishing, High Wycombe, Bucks UK: Australian/New Zealand Standard AS/NZS 4360:2004 “Risk management.” Standards Australia, Homebush NSW 2140, Australia, and Standards New Zealand, Wellington 6001, New Zealand; British Standard BS6079-3:2000 Management—Part 3: Guide to the management of business-related project risk.” British Standards Institute, London, UK; BS IEC 62198:2001 “Project risk management—Application guidelines,” British Standards Institute, London, UK; and BSI PD ISO/IEC Guide 73:2002 “Risk management—Vocabulary—Guidelines for use in standards.” British Standards Institute, London, UK.

³ Hillson D. A. Effective opportunity management for projects: Exploiting positive risk. New York: Marcel Dekker, 2003.

⁴ PMI, p. 273.

⁵ Hillson, D. A. “Project Risks—Identifying Causes, Risks and Effects.” PM Network, 14: 2000: 48–51.

⁶ Hillson D. A., & Murray-Webster R. “Understanding and Managing Risk Attitude Using Applied Emotional Literacy.” Gower, Aldershot, UK. 2006.

FURTHER READING

Chapman, C. B., and S. C. Ward. Project Risk Management: Processes, Techniques and Insights (second edition). Chichester, UK: J Wiley, 2003.

Cooper, D. F., S. Grey, G. Raymond, and P. Walker. Project Risk Management Guidelines: Managing Risk in Large Projects and Complex Procurements. Chichester, UK: J Wiley, 2004.

Grey, S. Practical Risk Assessment for Project Management. Chichester, UK: J Wiley, 1995.

Schuyler, J. Risk and Decision Analysis in Projects (second edition). Newtown Square, PA: Project Management Institute, 2001.

Vose, D. Risk Analysis—A Quantitative Guide, Second Edition. Chichester, UK: J Wiley, 2000.

Williams, T. M. Modelling Complex Projects. Chichester, UK: J Wiley, 2002.