Risk management is a key component of project management and there has been a notable increase of awareness and application over the past decade or so. For example, a recent survey of project management topics in key project management publications found risk management to have one of the highest rates of occurrence (Themistocleous & Wearne 2000).
In Australia, the use of risk management was given a significant boost by the Standards Australia publication AS/NZS 4360: Risk Management in 1995 and its revision in 1999 (Standards Australia 1999). Standards Australia is equivalent to such bodies as the British Standards Institution and American National Standards Institute and is the Australian representative on the International Organization for Standardization.
The author is an academic and consultant in risk management. This paper describes his experiences is applying the risk management process as set out in AS4360, and also provide comparisons between the theory and practice of risk management.
Theory
Project Risk Management (PRM)
Project risk management is fundamentally a decision-making process. The alternative to risk management is “making reckless decisions or making decisions that are not based on a careful consideration of the facts and the risks involved” (MAB/MIAC, 1995). Managing risk demands a methodical approach and project risk management is a formalized disciplined approach consisting of a set of processes for decision-making. Risk management consists of the following stages.
Context-Setting
Interestingly, whilst most risk management literature promotes risk identification as the first step of PRM, Standards Australia commendably highlights the need to firstly understand the strategic, organizational and project contexts. A key context is the ‘project context”: project scope, goal and objectives (e.g., cost, time, quality) and their relative importance must be established; the link between the project and the organization's strategic goals and business plans must be understood.
Risk Identification
Risk identification is “the process of determining what can happen, why and how” (Standards Australia 1999). Risk identification firstly aims to generate a list of risk events and “having identified a list of events, it is necessary to consider possible causes and scenarios” (Standards Australia 1999). There can be several potential causes of a risk event and all significant ones must be identified. The cause of a risk is its most significant feature—“the most important aspects of risk from a management point of view are its causes. Only by influencing the causes can the risk be pro-actively managed” (Carter et al. 1994).
It is helpful to use some form of risk classification as an aid to identifying and analyzing project risks, such as:
• Sources—The most common approach to categorizing risks is into source areas—“sources of risk are categories of possible risk events” (PMI 1996). Examples of risk classification based on sources are (Standards Australia 1999): Commercial and Legal relationships; Political; Economic; Technology and Human Behavior; Natural Events; Individual Activities.
• Project Life Cycle—Risks can be classified by reference to the project life cycle). For example: Planning and proposal stages; Project procurement and management stages (New South Wales Government 1993
Risk Identification—Tools and Techniques.
• Personal Experience—This is a key source for risk identification. The use of previous experience is not an isolated method for risk identification but rather it “will manifest itself across the whole spectrum of identification techniques” (Tweeds 1996). However, the use of experience for risk identification has limitations especially for particularly unique projects. Also, experience is subject to hindsight bias, disregard of relevant information about other possible risks and an inability to anticipate unknown unknowns (Ashley 1989).
• Pondering—Pondering is a simple and most basic approach involving the use of a single person to identify risks and “may serve as a default option if other approaches are not feasible or suitable” (Chapman & Ward 1997). The benefits of using an individual approach is that it is efficient (no facilities or additional staff), expedient and decisive. However, it is myopic, biased, and unilateral (Martin & Heaulme 1998).
• Group Processes—A productive approach is to gather relevant people and conduct creative group processes such brainstorming, preferably under the control of a good facilitator
• Checklists/Prompt Lists—Research indicates that checklists are the most favored approach to risk identification and in heavy use by risk managers (Simister 1994). The checklist should be structured around a suitable risk classification taxonomy. However, checklists tend to provide a narrow view of the project and may lead to non-identification of unusual risks. Chapman and Ward (1997) are particularly critical of checklists and highlight many shortcomings and advised that “if any 'checklist’ is used it should be referred to as a ‘prompt list,’ and used in that spirit as a catalyst and stimulant, not as a definite statement of possibilities” Chapman & Ward 1997). The checklist can be used by the individual working alone, in a group process, or as an interviewing aid.
Exhibit 1
• Structured Interviews—Interviews can be conducted with appropriate personnel (either individual or in groups) such as project members and outside experts. Interviews typically use should checklists and questionnaires to ensure full coverage of all aspects of the project. It has been noted that interviewing experts “is a common technique used to extract information regarding the technical risks of an activity” (Yosua & Hazlett 1988).
• Project Information—Any available project documentation that can be examined in search for risks. Such documents include plans, work breakdown structure, specifications, contracts, schedules, and budgets. For example, a network schedule will highlight interdependencies so that “any event that lies at the start or completion of many activities is a potential risk”(Turner 1993). Also various project control tools and techniques—such as bar charts, earned value, cost estimating, quality assurance—describe in their own specific way the process of execution and provide a basis for identification of risks (Franke 1989).
Risk Analysis
Purpose—The aim of the Risk Analysis phase is to determine which risk events warrant response (PMI 1996). As Grey (1995) points out, “having identified the risks in your project, you will usually have insufficient time or resource to address them all; so the next requirement is to help you to assign realistic priorities.” Once the project risk events have been identified the next stage is to analyze and prioritize them to guide risk management action.
Level of Risk—The level of risk is expressed in terms of a combination of Probability—degree of likelihood of risk event occurring; and Consequence—types and magnitude of the outcome of a risk event, e.g., monetary loss, injury, damage, delay.
Information—Sources of information include past records, relevant experience, specialist, and expert judgments. Techniques include structured interviews with experts and key project team members; group processes (e.g., brainstorming; individual assessments using checklist/questionnaire.
Qualitative Analysis—Qualitative analysis “uses word form or descriptive scales to describe the likelihood of each event arising and its consequences (Standards Australia 1999). Qualitative analysis relies on subjective judgments based on experience and expertise. Subjective judgment is “often possible— indeed it may be the only way forward” (Edwards 1995).
Output—The final outcome of the Risk Analysis stage is an “ordered list of risk, from the most significant down to the least significant. A line if drawn across the list at some point; the risks above the line warrant further consideration of a response” (CCTA 1994). This ranking allows the application of the Pareto Principle; i.e., dealing with the ‘vital few” high risks before the ‘trivial many.” “Minor” risks may be accepted with minimal further management whilst “major” risks will require formal treatment.
Risk Treatment Strategies
Risk treatment consists of the “selection and implementation of appropriate options for dealing with risk” (Standards Australia 1999). In fact, “once a risk has been identified it is frequently obvious how one should respond” (Chapman & Ward 1997). There are four basic approaches to dealing with project risks: avoidance, reduction, retention, and transfer. Risk treatment plans are produced to document how the chosen risk treatment strategy will be implemented. In particular, the risk action plan should set out, for each risk (Standards Australia 1999; CCTA 1994): description of risk event; selected treatment strategy; expected outcome of treatments; responsibility for implementing the treatment strategy; timetable for implementation; resource requirements and/or budget allocation e.g., personnel, equipment, facilities; define the reporting and monitoring process—mechanisms and frequency.
Practice
Case Studies
In the following case studies the author was engaged by the client's project manager to conduct a risk management workshop. For simplicity, the author is referred to as the “risk manager” or “facilitator.” Case study details are set out in Exhibit 1.
Context-Setting
Firstly, a meeting is held between the risk manager and project manager to discuss:
• Project Scope—Questions asked include: what is the project about? What phase is the project at? Why did you decide to undertake a risk management workshop? This provides the risk manager with a broad project context and assists in the formulation of the scope and focus of the risk management workshop. From this is derived the content for the workshop.
• Project Objectives—The project objectives (typically expressed in terms of time, cost and quality) and the product objectives (the purpose and ultimate strategic goal of the project) are recorded. These become the criteria used in the Analysis phase to measure the level of consequences of each identified risk event. (See Exhibit 2.) It is important to separate these two distinct project objectives because it provides clarity when considering the level of consequences of an identified risk event. Assessment criteria in the literature tend to focus on the process objectives (e.g., time, cost, quality) whilst ignoring consideration of whether the risk event might affect the operation of the project's product.
• Process—A facilitated group process was the basis for the risk management process in all case studies in Exhibit 1. This provides an efficient and effective means of tapping into the collective experience and expertise of a diverse set of workshop participants. A common problem, highlighted in the theory, is bias due to the participant's most recent experiences. For example, if a risk of low probability occurred in a recent project there is a tendency to allocate a high probability to the project in hand. The outcomes from the workshop are directly entered into a computer and simultaneously projected onto a screen. This has advantages:
• Efficiency—With little additional editing the text becomes part of the risk management report that is presented to the client within 48 hours.
• Deliberation—As the text is entered the group can view and deliberate over the words used and instantly change them if they do not expressed clearly and precisely what is meant.
• Workshop participants—The success of the workshop process rests heavily upon the quality of the workshop participants and the facilitator. In particular, the full range of stakeholders should be invited to attend as this will help ensure that all possible risk events are identified. For example, stakeholders for the projects in Exhibit 1 included project team members, project sponsors (e.g., government education department), users (e.g., school principal and parent's representative) and specialist experts (e.g., traffic engineers, environmental scientists). Similarly, one project required the proposed building to be constructed under a flight path so an air flight manager from the airport attended the workshop. Exhibit 1 shows that the workshop size varies between 8 and 24. Whilst the theory suggest an optimum size of 6–12, experience suggests that the more complex the project, the bigger the desired group size, up to a maximum of approximately 25.
Risk Identification
The risk identification process goes through each category of the risk classification structures and asks, “What can go wrong?” As shown in Exhibit 1, the two classification categories used were sources and phases, with a combination of both being a typical approach. The selection of the risk categories is determined prior to the workshop in discussion between the risk manager and the project team.
Once the group has exhausted a risk category, the facilitator provides a checklist of possible risk events. The purpose for this is twofold:
• The checklist is given after the brainstorming process so as not to provide a narrow view of possible risks
• The checklist acts as a safety net that highlights possible risks that the group has not identified but which are relevant for the project. Typically, 80–90% of the checklist risks are already identified during the brainstorming process. The risk manager based on research, individual pondering and previous risk management workshops, develops the checklist.
The checklist is derived from previous risk management studies, pre-workshop interviews with the project team, individual pondering by the risk manager with reference to project documentation
The number of risks identified depends on such factors as:
• Time Allowed—Clearly a half-day workshop will usually identify fewer risks than a one-day workshop! Therefore, the projects with the longest duration typically resulted the greatest number of identified risks - see projects A to E
• Number of Participants—The greater the number of workshop members, then typically the more risks identified. As Exhibit 1 shows, the three workshops (A.B.C) with the highest number of participants also generated the highest number of identified risks. However, working against this is the fact that a large workshop naturally tends to result is more discussion and therefore less identified risks.
• Quality of Participants—When the participants are intelligent, thoughtful and have good experience or expertise, then this provides a fertile environment for the identification of many risks. For example, the workshop that identified 319 risks contained many senior management people and well qualified experts.
Exhibit 2
• Facilitator/Project Manager—The facilitator can “push” the workshop process by trying to minimize peripheral discussions and activities. However, the facilitator must be careful not to curtail members’ inputs too harshly as this can alienate them. Also, when the project manager and facilitator are working in tandem to expedite the risk management process, then the number of identified risks tends to be high e.g., projects A and B.
• Scope of Risk Management—Where the focus of the risk management workshop in upon the identification of the all possible risks and not detailed risk analysis or treatment strategies, then it is possible to generate a large number of risks. This was the context for the project A in which 319 risks were identified in one day. Similarly, Exhibit 1 shows that where only partial risk analysis was undertaken then the risks identified exceeded 100.
Whilst the theory highlights the importance of identifying the causes of a risk event, this rarely happens in practice. Possible reasons are:
• Each risk could easily have four or five major causes. It would become unmanageable and extremely time-consuming is one tries to list the causes for each of say 100 identified risk
• Many, if not most identified risks, have some degree of familiarity with the workshop members. Consequently, it seems that they subconsciously distil the causes and the selected treatment strategies often address the causes of the identified risk event
In many cases an event could theoretically be viewed as a cause, and a cause could be viewed as an event! For example, “poor performance by contractor” could be considered as either a risk event, or a cause of other risk events. Clearly, if one tried to identify events and their causes, it could complicate the risk identification process by highlighting this confusion. Consequently, the approach adopted is to accept all members stated risks as events and this works very well in practice. It is not unusual for members to identify “cost overruns” and “time overruns” as risk events. However it can be reasoned that these are the consequences of other risk event, and are typically entered within the Risk Rating Matrix (see Exhibit 2) as a measurement of consequences. Furthermore, if overruns were viewed as events then their treatment strategies would be innumerable to reflect the vast number of possible causes that could cause overruns.
Risk Analysis
The workshops analyze risk qualitatively using a Risk Rating matrix developed by the risk manager, after pre-workshop discussion with the project manager—see Exhibit 2.
This approach has many advantages as describe in the theory section of this paper, in particular it is quick, simple, and the level of risk does not justify a fuller quantitative approach. The qualitative approach is readily accepted by workshop members who typically adopt it with alacrity as a practical and effective means for analyzing risks. It is interesting to note that consensus is usually quickly agreed for the qualitative measure of a risk using Exhibit 2. A collateral gain during the qualitative analysis is the necessary revisiting of the risk event that sometimes results is a subtle re-wording of the event for clarification purposes. Also, discussion of the likelihood and consequence allows a fuller appreciation of the risk and the possible generation of further identified risks. Points to note in Exhibit 2:
• Likelihood matrix is adapted from Australian Standard 4360 (1999) and is the same for each workshop.
• Consequence matrix is formulated for each project to reflect its process and product objectives.
• Final Risk Rating matrix categorizes a risk as either extreme, high, moderate or low based on its likelihood and consequences, based on AS4360. Numbers have been allocated to arrive at this rating. It should be noted that whilst the difference between adjacent likelihood ratings is 1, the numerical value for each successive level of consequence have greater weightings. This reflects the behavioral trait that people are more concerned with consequences than with likelihood. For example, a risk that has a high probability/low consequence profile is considered less of a problem than a risk that that is low probability/high consequence.
Two approaches to the analysis have been used—partial and full. The full analysis requires the determination of the likelihood and consequence for each risk using all matrixes of Exhibit 2. Partial analysis is used where the time allowed for the workshop is tight. It simply entails the workshop members using only the Final Risk Rating matrix to select either an extreme, high, moderate, or low rating, keeping in mind that treatment strategies will only be allocated at the workshop for only extreme and high risks. Whilst this is expedient, it does tend to have some shortcomings. The benefits of deliberating on the likelihood and consequences, as mentioned previously, are lost. Furthermore, f the team is in doubt as the level of risk, there is a tendency to allocate an extreme or high rating “just to be on the safe side.” Exhibit 1 shows that extreme and high risks tend to outnumber moderate and low risks. It might be expected that the use of partial analysis would lead to a greater proportion of extreme and high risks. Whilst projects A and B confirm this assumption, project F shows that it is not always the case.
Treatment
As mentioned previously, the purpose of the risk analysis phase is to prioritize risks so that the risk management effort can focus upon the higher-ranking risks. In the treatment phase, the workshop members determine treatment strategies for the extreme and high risks only. It is expected that normal project management processes can manage the moderate and low risks. Only in Project A in Exhibit 1 were strategies not developed due to time constraints and this was because great importance was place on the identification of all possible risks. Finally, the outcomes of the workshop are a report and risk treatment plan that sets out: Scope of project and risk management workshop; description of risk event; selected treatment strategy; responsibility for implementing the treatment strategy. The report is given to the project manager who disperses the risk treatment strategies to those allocated responsibility within the report and develops a timetable developed for their implementation
Summary
From the author's academic and consultancy experience, there is a strong link between the AS4360 and theory on the one hand, and practice on the other. Theory and practice tend to match in terms of: use of sources as a common risk classification structure, effectiveness of a facilitated group process. However, in contrast with theory, practice shows: a need to segment project objectives into process and product factors; the usefulness of using checklists after the brainstorming process; the number of risks identified depends on a variety of factors; the causes of risks are not overtly stated; causes and events are frequently interchangeably; greater weighting is given to consequences than likelihood; partial analysis can be used in the appropriate circumstances. In comparing the theory and practice, the key difference is the need for theory to clearly emphasize the need for flexibility in one's approach to the risk management process.
