CHAPTER 15
Project Risk Management in Practice
The word risk is a widely used part of our daily vocabulary, relating to personal circumstances (such as health, pensions, insurance, and investments), society (such as terrorism, economic performance, and food safety), and business (such as corporate governance, strategy, and business continuity). One area where risk management has found particular prominence is in the management of projects, perhaps because of the risky nature of projects themselves.1 All projects, in varying degrees, are characterized by the following:
• Uniqueness
• Complexity
• Change
• Assumptions
• Constraints
• Dependencies
• . . . and 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 projects and businesses. This arises from the clear link between risk and objectives, embodied in the definition of the word. For example, the Project Management Institute’s Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fifth Edition states, “Project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.”2 Other international standards and guidelines3–10 use similar definitions, always linking risk with objectives, particularly the International Organization for Standardization’s ISO 31000:2009, where the definition of risk is “effect of uncertainty on objectives.”5
This is why risk management is so important and not just another project management technique. Risk management aims to identify those uncertainties that have the potential to harm the project, assess them so that they are understood, and develop and implement actions to stop them from occurring or minimize their impact on achievement of objectives. Risk management 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 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 important to understand what we are trying to manage. The PMI definition of risk quoted above 2 includes one distinct type of uncertainty—that which, if it occurs, will have a negative effect on a project objective. But the standard also acknowledges that there are risks that create the possibility of a positive outcome. In other words, risk includes both threat and opportunity. At first this causes some hesitation for people new to the concept. They might say, “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 (PMI) is not unusual, and 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,3–10 including ISO 31000:2009, which comments that “deviation from objectives can be positive and/or negative.”5
Taking this position has significant implications for all aspects of risk management, including thinking, language, and process.11 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, Fifth Edition, both threat and opportunity are treated equitably, and the objectives of risk management are stated as “to increase the likelihood and impact of positive events, and decrease the likelihood and impact of negative events in the project.”12 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.
There has been one other important development in the way risk is defined for projects: the recognition that there are two distinct levels of risk in every project. This is best illustrated by asking the question “How risky is this project?” The risk register lists all identified risks, prioritized for attention and action, with responses and owners allocated to each risk. But a list of risks cannot answer the “How risky” question. A different concept is needed to describe the overall risk exposure of a project, which is different from the individual risks that need to be managed.
PMI has addressed this in the Practice Standard for Project Risk Management, which has two distinct definitions of risk.8 The first is individual risk, which is defined as “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.” The second is overall project risk, which is defined as “the effect of uncertainty on the project as a whole.” The United Kingdom’s Association for Project Management (APM) also has two similar definitions of risk in its Body of Knowledge.13
This dual concept of risk is important and useful when considering how to manage risk in projects. At one level the project manager is responsible for identifying, assessing, and managing the individual risks that are recorded in the risk register. At another higher level, the project manager is also required to account to the project sponsor, the project owner, and other stakeholders for the overall risk of the project. These two levels might be distinguished as the risks in the project and the risk of the project.
Managing risk requires action at both of these levels. But the typical project risk management process addresses only the lower level of individual risks within the project, which are recorded in the risk register. It is far less common to consider the overall risk exposure of the project as a whole, or to have any structured approach to managing risk at that higher level.
So how can overall project risk be identified, assessed, and managed? The first place to address overall project risk is during the pre-project or concept phase, when the scope and objectives of the project are being clarified and agreed upon. Here the project sponsor or owner defines the benefits that the project is expected to deliver, together with the degree of risk that can be tolerated within the overall project. Each decision about the risk–reward balance involves an assessment of overall project risk, representing the inherent risk associated with a particular project scope and its expected benefits. At this level, overall project risk is managed implicitly through the decisions made about the scope, structure, content, and context of the project.
Once these decisions have been made and the project is initiated, then the traditional project risk management process can be used to address explicitly the individual risks that lie within the project. At key points within the project it will be necessary to revisit the assessment of overall project risk to ensure that the defined risk thresholds have not been breached, before returning to the ongoing task of managing individual risks within the project.
So two levels of risk management are important for projects:
• Implicit risk management, which addresses overall project risk through decisions made about the scope, structure, context, and content of the project
• Explicit risk management, which deals with individual project risks through the standard risk management process to identify, analyze, respond to, and control risks
Both types of risk need to be understood and managed in order to answer the question “How risky is this project?”
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 typical risk management process embodied in the various risk standards and guideline. For example, the risk management process outlined in both the PMI PMBOK® Guide2 and the PMI Practice Standard for Project Risk Management8 includes the following six processes, which clearly map to the questions above:
• Plan risk management—deciding how to conduct risk management activities for a project
• Identify risks—determining which risks might affect the project
• Perform qualitative risk analysis—prioritizing risks for subsequent further analysis or action
• Perform quantitative risk analysis—numerically analyzing the effect on overall project objectives of identified risks
• Plan risk responses—developing options and actions to enhance opportunities and to reduce threats to project objectives
• Control risks—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, requires only structured thinking and action, following a commonsense process in the face of uncertainty.
Plan Risk Management
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® Guide2 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 require a more robust approach to risk management than do 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:
• 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.
• Defining 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 15-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.
Identify Risks
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 the following:
• 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, 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.
It is also important to consider risks arising from a broad range of potential sources, and the RBS provides a useful framework to ensure that no key areas are overlooked.
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.
FIGURE 15-1. EXAMPLE OF A RISK BREAKDOWN STRUCTURE
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 constraints. The most common mistake is to identify causes of risks or the effects of risks, and to confuse these with risks.14
Causes are definite events or sets of circumstances that exist in the project or its environment, and that 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 possibilities that planned productivity targets might not be met, that interest or exchange rates might fluctuate significantly, that client expectations may be misunderstood, or that 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 warrant. One way to clearly separate risks from their causes and effects is to use risk meta-language (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 meta-language 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 non-risks, 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.
Perform 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 warrant 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.
Risk, as we are defining it, two dimensions: uncertainty and its potential effect on objectives. The word probability is usually used to describe the uncertainty dimension (although we might use likelihood or frequency), and impact (or consequence or effect) is used to describe the effect on objectives. For qualitative analysis, these two dimensions are assessed as being high, medium, or low, as 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 other factors such as performance, quality, and regulatory compliance. For threats, impacts are negative (such as lost time and extra cost), but opportunities have positive impacts (such as saved time and reduced cost).
The two-dimensional assessment is used to plot each risk onto a probability-impact matrix, with high, medium, and low priority zones. It is common to use a double mirror matrix, to allow threats and opportunities to be prioritized separately, and creating a central zone of focus (Figure 15-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 makes them easy to capture, and high impact means it is very good).
Another important output from qualitative analysis is the pattern of risk on the project, and it is important to understand whether there are common causes of risk or hotspots of exposure. This can be assessed by mapping risks into the 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.
Perform Quantitative Risk Analysis
On most projects, risks do not happen one at a time or independently of each other. Instead, they interact in groups, with some risks causing others to be more likely and some risks making others impossible. Qualitative 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.
FIGURE 15-2. MIRROR PROBABILITY-IMPACT MATRIX FOR THREATS AND OPPORTUNITIES
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 can also be useful for analyzing key strategic decisions or major option points.
One often overlooked key aspect of quantitative risk analysis models is the need to include both threats and opportunities. If only threats are considered, then the analysis is only modeling the 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 the upside (to produce the minimum/optimistic/best-case estimate) as well as the downside (to produce the maximum/pessimistic/worst-case estimate).
When developing Monte Carlo risk models, it is often too easy to use available software tools to create simple and simplistic 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 threepoint 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 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 qualitative 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, and delivery dates.
Three potential shortfalls should be mentioned when considering quantitative risk analysis techniques. First, the data should be of sufficient quality to avoid the GIGO (garbage in–garbage out) situation, ensuring good quality inputs to the model. Second, outputs from risk models always need to be interpreted, and quantitative analysis will not tell the project manager what decision to make. Third, be prepared to use the results of risk modeling and to make 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.
Plan Risk Responses
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 has an opportunity 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 scattershot 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 actions to implement that strategy, producing a more focused “rifle shot” aimed at managing the risk effectively.
The double-sided nature of risk means that it is vital to have 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 uncertainty, 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 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 analyze 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. Therefore, they should be treated like any other project task. Each risk response should be fully defined, with a duration, budget, resource requirement, owner, and completion criteria. 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.
Control Risks
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® Guide2–10 forms a good basis on which to build effective management of project risk. However, the following issues also must be considered if risk management is to be fully effective. First, 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, biases, and heuristics that affect the risk attitudes adopted by people, operating at both individual and group levels.15–16
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 benefits from minimizing threats and capturing opportunities.
Third, there is a 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.
Fourth, the need for an efficient infrastructure to support the risk process must also be recognized. Software tools, training, templates, and specialized resources 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.
By considering the above factors in addition to the risk process, the team and the organization develop risk maturity. 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.
Not only is risk management essential, it is also 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.
Define project risk, and explain the relationship among uncertainty, risk, threat, and opportunity.
What are the differences between a cause, a risk, and an effect? Use risk meta-language to describe a situation on a project you are familiar with. Does this help you distinguish between them?
Name the basic risk response strategies for threats and opportunities, and give an example of each.
REFERENCES
1 David A. Hillson, Managing Risk in Projects (Farnham, UK: Gower, 2009).
2 Project Management Institute, A Guide to the Project Management Body of Knowledge, 5th edition (Newtown Square, PA: Project Management Institute, 2013), pp. 310 and 558.
3 Association for Project Management, Project Risk Analysis & Management (PRAM) Guide, 2nd edition (High Wycombe, Bucks UK: APM Publishing, 2004).
4 British Standards Institute, British Standard BS 31100:2011 “Risk Management—Code of Practice and Guidance for the Implementation of BS ISO 31000” (London, UK: British Standards Institute, 2009).
5 International Organization for Standardization ISO 31000:2009. “Risk Management—Principles and Guidelines” (Geneva, Switzerland: International Organization for Standardization, 2009).
6 International Organization for Standardization Guide 73:2009. Risk Management—Vocabulary (Geneva, Switzerland: International Organization for Standardization, 2009).
7 International Organization for Standardization ISO IEC 31010:2009. Risk Management—Risk Assessment Techniques (Geneva, Switzerland: International Organization for Standardization, 2009).
8 Project Management Institute. Practice Standard for Project Risk Management (Newtown Square, PA: Project Management Institute, 2009).
9 Canadian Standards Association, CAN/CSA-Q850-97 “Risk Management: Guideline for Decision-Makers” (Ontario, Canada: Canadian Standards Association, 1997; reaffirmed 2002).
10 United Kingdom Office of Government Commerce, “Management of Risk: Guidance for Practitioners,” 3rd edition (London, UK: Office of Government Commerce, 2010).
11 David A. Hillson, Effective opportunity Management for Projects: Exploiting Positive Risk (New York: Marcel Dekker, 2003).
12 PMI, 2013, p. 309.
13 Association for Project Management, APM Body of Knowledge, 6th edition” (Princes Risborough, UK: APM, 2012).
14 David A. Hillson, “Project Risks—Identifying Causes, Risks and Effects.” PM Network, 14 (2000), pp. 48–51.
15 David A. Hillson and R. Murray-Webster, Understanding and Managing Risk Attitude, 2nd edition (Aldershot, UK: Gower, 2007).
16 Ruth Murray-Webster and Hillson D. A. Managing Group Risk Attitude (Aldershot, UK: Gower, 2008).
FURTHER READING
C.B. Chapman and S.C. Ward, Managing Project Risk and Uncertainty (Chichester, UK: John Wiley, 2002).
C.B. Chapman and S.C. Ward, How to Manage Project Opportunity and Risk, updated 3rd edition of Project Risk Management (Chichester, UK: John Wiley, 2012).
R.J. Chapman, Simple Tools and Techniques for Enterprise Risk Management, 2nd edition (Chichester, UK: John Wiley, 2011).
Dale Cooper, P. Bosnich, S. Grey, G. Purdy, G. Raymond, P. Walker, and M Wood. Project Risk Management Guidelines: Managing Risk with ISO 31000 and IEC 62198 (Chichester, UK: Wiley, 2014).
D.A. Hillson, Exploiting Future Uncertainty: Creating Value from Risk (Farnham, UK: Gower, 2010).
D.A. Hillson and P.W. Simon, Practical Project Risk Management: The ATOM Methodology, 2nd edition (Vienna, VA: Management Concepts, 2012).
D.T. Hulett, Integrated Cost-Schedule Risk Analysis (Farnham, UK: Gower, 2011).
N.N. Taleb, The Black Swan: The Impact of the Highly Improbable (London: Allen Lane/Penguin, 2007).
D. Vose. Risk Analysis—A Quantitative Guide, third edition (Chichester, UK: Wiley, 2008).