Chapter 11--it’s not about bankruptcy
Chapter 11 of ANSI/PMI-99-001-2000, A Guide to the Project Management Body of Knowledge (PMBOK® Guide, 2000) describes project risk management. Some practitioners complain the PMBOK® Guide describes a risk management process that is ponderous, expensive, and appropriate only to large government or commercial investment projects. They claim risk management can drive good projects into bankruptcy. However, the PMBOK® Guide describes processes that project managers may tailor to meet their corporate and sponsors’ requirements and their own personal needs. Much as formal scientific method can be either a battering ram or a scalpel (Pirsig, 1974; pp. 107–111), the PMBOK® Guide's risk management processes can be impediments or tools. Astute project managers could even tailor the PMBOK® Guide's project risk management processes to plan personal projects, like business trips or family vacations (Petroski, 1985, pp. 64–66).
For the past six or eight years, various scholars have been trying to synthesize the collected works of Sun Tzu (Clavell, 1983), Miyamoto Musashi (Harris, 1974), and Karl von Clausewitz (Howard & Paret, 1976) into a few simple ideas. The goal is to find a few ideas easily understood and applicable across a range of functional disciplines, natural talents, and learned skills. One idea that rises to the surface often is agility. Academicians and practitioners have discussed agile logistics for a few years, and now other experts make arguments for agile acquisition. In this context, acquisition is a general term encompassing requirements, research and development, and procurement. Project management processes apply to all three areas.
Agility seems to be one of those things that people cannot define, but they will know it when they see it, and they have not seen it yet. It involves improved effectiveness. It involves increased efficiency. It involves reacting rapidly and effectively to changing conditions. If some team could patent an agilometer, they would make a fortune for themselves and their sponsors.
The six risk management steps described in the PMBOK® Guide can easily form the basis of an agile process for project risk management. Project members must understand the six risk management steps to know when they are mandatory rules and when they are optional guidelines. There is a cliché that states: a fool with a tool is still a fool. With understanding, any project manager can develop agile project risk management processes, tailored to the project team's needs and the project's requirements.
A device to help attain agility is to maintain focus. There are three keys to project risk management essential for focus. First, the definition of project risk is “an uncertain event or condition that, if it occurs, has a positive or negative consequence” (PMBOK® Guide, 2000, p. 127). Second, project risk management is a process, not a product. Finally, ignoring risks does not make them go away.
A Tutorial on the PMBOK® Guide Method of Project Risk Management
The PMBOK® Guide defines risk as “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project objective” (PMBOK® Guide, 2000, p. 127). The PMBOK® Guide further defines risk management as “the systematic process of identifying, analyzing, and responding to project risk” (PMBOK® Guide, 2000, p. 127). Finally, the PMBOK® Guide describes a six-step process for risk management; however, risk practitioners will more easily recollect and understand these six steps if they group them into planning, analyzing, and executing steps.
The first step is the Planning step. Planning includes two substeps.
The first substep is risk management planning. Referring to the first step as planning, and also referring to the first substep as risk management planning can be a little confusing, but context usually reveals whether the term “planning” refers to the step or substep. During planning project managers decide upon their risk management strategy. The risk management strategy includes (but is not limited to) things like risk tolerances, tools and methods, and preparing adequate resources to implement the strategy. Most project managers evaluate projects in terms of the “triple constraints” or the “tortured triangle” of performance, cost, and schedule. Strategy also includes documenting the project risk management plan.
Most project managers are familiar with the concept of risk in a negative context. A risk event occurs, and there are adverse effects. However, many project managers have come to view some risks in a positive context. Examples might be evolving technologies that achieve breakthroughs with consequent positive effects, or anticipated price increases in materials or labor actually become price decreases. In the first case, perhaps management tool proactive action to enhance the probability of the breakthrough. In the second case, perhaps management foresaw increases in labor costs. Having foreseen increases in labor costs, that foresight precipitated efforts to redesign the project to require fewer hours of higher skilled labor, similar hours of lower skilled labor, or automated labor that could be spread over multiple projects or depreciated over time. These changes resulted in net benefits (rather than minimized frustrations). Project managers can address opportunities with the same tools they use manage negative risks.
Source: Risk Management Guide, 4th Edition, Defense Systems Management College, February 2001.
There is an ongoing debate in the project risk management community whether project risk management applies to positive risk (i.e., whether project risk management and project opportunity management are the same discipline). The PMBOK® Guide defines risk as something that “has a positive or negative effect” (PMBOK® Guide, 2000, p. 127). However, some respected risk practitioners disagree with the PMBOK® Guide's definition. Dr David Hillson (Hillson 2001a, 2001b) seems to be leading the charge to ensure there is a full and vigorous debate on the issue.
The second substep is risk identification. Risk identification is an iterative and recursive process to develop a catalog of risk events or conditions and to identify risk symptoms. Sources of risk events or conditions include historical files, project files and various information-gathering techniques. Information-gathering techniques mentioned in the PMBOK® Guide include brainstorming; Delphi technique; interviewing; and Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis. Risk symptoms are indications that a risk event has occurred or is about to occur. An example of a risk symptom is a cost or schedule variance on an earned value management report.
The second step is the Analyzing step. Project managers assign values to risk events to help decide which events require priority attention and which may receive lesser attention. The purpose of the analyzing step is to assign values to risk events identified during the risk identification substep of the planning step, and according to the procedures documented in the project risk management planning substep of the planning step.
The value of a risk event is the probability the event will occur times the consequences of the event given that it does occur: value = probability x consequences. Traditionally risk management practitioners express value in terms of money (e.g., dollars), but managers also express value in terms of time or some other unit that has meaning to the project team members.
Usually project managers place more emphasis on assessing the consequences of risk events, rather than their probabilities. Given two risk events with the same value, project managers will choose to devote resources to address risk events with significant consequences and defer spending resources on risk events of little or no consequence to the project goals. For example, risk events with the consequences of maiming or killing a person, threatening the survival of the organization, or bringing unfavorable media attention to the organization probably will attract a great deal of management attention, regardless of the probability of the events occurring.
The first substep of the analyzing step is qualitative risk analysis. Qualitative analyses include nonnumeric analyses ranging from “eyeball analysis” to probability-consequence matrix analysis. The goal of qualitative analysis is to separate the vital few risks from the trivial many. Project managers may then consider the vital few risks for quantitative analysis.
Probability-consequence matrices plot the probability that a risk event will occur against the consequences of the risk event given that it does occur. Typically, probability-consequence matrices are 5 x 5 matrices, but some project managers prefer 3 x 3 or 9 x 9 matrices. Project managers or corporate policies dictate responses based on assessments of where particular risks fall upon the matrix. For example, risks with remote probability and minimal consequences may merit only monitoring, while risks with near certain probability and catastrophic consequences may require executive attention. Responses typically are asymmetric to recognize that management usually is more concerned about the consequences of risk events rather than the probability of the events occurring. Exhibit 1 shows one possible probability-consequence matrix with definitions of probabilities and consequences, and responses required based on assessments.
The second substep of the analyzing step is quantitative risk analysis. Quantitative analyses include numeric tools including (but not limited to) sensitivity analyses, A Fortiori analysis, decision tree analysis (also called expected monetary value), and Monte Carlo analyses.
There is a real risk to quantitative analyses. Effective quantitative analyses used to require individuals with years of advanced training and lots of personnel and physical resources. Now there are many software tools on the market that permit any idiot to do sophisticated quantitative analyses—and many do. The result is quantitative analyses can take on lives of their own as increasing numbers of individuals devote increasing resources to learn more and more about less and less. Eventually, someone declares he knows everything about a particular risk event, only to discover that while his knowledge is precise, it is not accurate, and the knowledge is not useful anyhow. Often a simple sensitivity analysis can be more revealing than sophisticated Monte Carlo simulations. Good quantitative analyses can help the project team to achieve their goals. Bad quantitative analyses can divert resources from more crucial tasks.
The final step is the Executing step. As with the other two steps, the Executing step includes two substeps.
The first substep is risk response planning. Risk response planning is evaluating and implementing strategies to reduce risk value to acceptable levels. There are four classic risk-handling strategies, known by the acronym CAAT.
• Control (or mitigation) is deliberately using the design process to lower risk value to acceptable levels. Control usually involves increased cost or schedule, or trading performance in one area for performance in another area. Consequently, project team members usually make business cases to justify their control proposals. Typical activities include designing processes or systems to make a particular risk event physically impossible or implementing redundant systems.
• Avoidance is changing or removing requirements that represent uncertainty or high-risk value. Typical activities include trading risk value for performance, schedule, cost, or other capability.
• Acceptance is assuming risk because it is low enough in value (probability or consequence). Typical activities include planning budget and schedule reserves. Ignored risks are assumed risks. The ignored risks do not go away; rather the project manager assumes the ignored risk, usually without planning for appropriate reserves in case the risk event takes place.
• Transfer is moving risk from one area to another. Transferring risk gives responsibility for the risk event to another party, but it does not reduce the probability or consequences (i.e., the value of the risk). Typical activities include purchasing warranties or insurance for the risk event.
The second substep is risk monitoring and control, which includes systematically tracking identified risks and evaluating the effectiveness of handling strategies. This final step includes monitoring the project for risk symptoms and events, and then implementing the strategies described in the project risk management plan. Sometimes risk events will occur that the project risk management plan failed to foresee. In those cases, the project team will design and implement a custom workaround for that specific event. While no project risk management plan can foresee all possible risks, if the project team spends inordinate time on workarounds, the project risk management plan probably is flawed, and the project team will need to review and revise their plan.
Tailoring Project Risk Management Processes to Non-Complex Projects
This paper's thesis is project managers can develop agile project risk management processes, tailored to the project team's needs and the project's requirements, where agility is defined in terms of improved effectiveness, increased efficiency, and reacting rapidly and effectively to changing conditions. Consider the case of the project to deliver a person to attend a symposium in San Antonio, Texas, and return him or her safely to home. This case is deliberately trite to emphasize that project managers can use the PMBOK® Guide's risk management processes on projects ranging from simple to complex. While this project is simple, it may represent a crucial task that is vital to the professional success of this individual or the economic success of this individual's firm.
Note: To conform to accepted rules of English grammar, this paper will refer to this hypothetical individual with masculine pronouns. However, this individual may be someone of either gender.
Risk management planning is deciding upon risk management strategy. The risk management strategy includes determining risk tolerances, tools and methods, and preparing for adequate resources.
The strategy for this San Antonio Project is to use standard business software and resources from public libraries or the World Wide Web (Internet) to identify and evaluate project management risks and opportunities. The traveler's boss is the approval authority for the project. The traveler is the project leader and the project risk manager. Delivering the traveler to attend the symposium and return him safely to home is a vital task and time is of the essence. Safety is a primary consideration. Risk events that may lead to the traveler's maiming or death are unacceptable. Costs are important but secondary considerations. The primary tool used to evaluate project risks will be probability-consequence matrices.
Risk identification is an iterative and recursive process to develop a catalog of risk events or conditions and to identify risk symptoms. The primary purpose of risk identification is to produce a catalog or register of potential risk events for further analysis. Project managers may group risks into categories that capture all the identified risks. Analysis may suggest decomposing the risk categories into their component risks may help to understand how risk events affect particular projects. Consulting historical files and brainstorming yields the following risks:
• Airline travel is delayed or disrupted
• Preferred lodging is overbooked
• Local crime rate rises to unacceptable levels
• Symposium is cancelled.
Qualitative risk analysis includes nonnumeric analyses ranging from “eyeball analysis” to probability-consequence matrix analysis. The purpose of qualitative risk analysis is to separate the vital few risks from the trivial many.
• Airline travel is delayed or disrupted. Commercial airline flights into San Antonio International Air port generally are on time according to information available through the Federal Aviation Administration website (http://www.faa.gov/) and the San Antonio International Airport website (http://www.sanantonio.gov/airport/). When delays occur, they are generally limited to a few hours. The project risk manager assesses the probability of delayed or disrupted airline travel is low, but consequences are high. Based on the probability and consequences, the management assessment is a different approach is required.
• Preferred lodging is overbooked. Consulting with the symposium organizers yields the organizers do not keep statistical records of participants who were unable to obtain their preferred lodging. The organizers claim to the best of their recollection they have always been able to accommodate lodging requests when the participants submit their requests by the symposium deadlines (which the organizers publish in their literature and on their website). Consulting with the San Antonio Convention Center and Visitors Bureau website (http://www.sanantoniocvb.com/) shows there are many hotels and alternative lodging in the area. The project risk manager assesses the probability of finding preferred lodging is overbooked is low, and the consequences of overbooking are also low. Based on the probability and consequences, the management assessment is to monitor.
• Local crime rate rises to unacceptable levels. Statistical databases show incidents of crime in San Antonio are generally rising across all categories of crime. Neither the Federal Bureau of Investigation website (http://www.fbi.gov/), the Federal Bureau of Investigation San Antonio Field Office website (http://sanantonio.fbi.gov/), nor the San Antonio Police Department website (www.sanantonio.gov/sapd/) contain information on per capita crime rates or victim populations. The symposium venue is in a generally safe part of town and the hotel has its own security staff. The project risk manager assesses the probability of the traveler becoming a crime victim is moderate because the traveler may not be sufficiently aware of local conditions to avoid high-crime areas and the consequences of becoming a crime victim are high because there is insufficient information to make an informed judgment about consequences. Based on the probability and consequences, the management assessment is attention required.
• Symposium is cancelled. Consulting with the symposium organizers yields the organizers have never cancelled the symposium. The project risk manager assesses the probability of canceling the symposium is low. The project risk manager consults with management, and the group confirms that attending the symposium is vital, but if the organizers cancel the symposium, the effects will be inconvenient, but not catastrophic. The project risk manager assesses the consequences of canceling the symposium are moderate. Based on the probability and consequences, the management assessment is to monitor.
• Quantitative risk analysis includes numeric tools including (but not limited to) sensitivity analyses, decision-tree analysis (also called expected monetary value), and Monte Carlo analyses. The purpose of quantitative risk analysis is to refine the probabilities and consequences of risk events. For the purposes of the San Antonio Project, the project manager assesses the costs of quantitative risk analysis are not worthy of the potential benefits to be realized.
Risk response planning is evaluating and implementing strategies to reduce risk value to acceptable levels. The four classic risk-handling strategies are control, avoid, accept, and transfer.
• Airline travel is delayed or disrupted (probability low; consequences high; assessment: different approach). Although the probability of airline travel delay or disruption is low, the consequences are unacceptably high. The project manager and management control the risk by agreeing the traveler will plan to arrive at the symposium venue a day early to allow time to accommodate unforeseen delays. The project risk manager and management further agree to control the risk by authorizing the traveler to proceed by train, bus, or rental car if airline travel is disrupted.
• Preferred lodging is overbooked (probability low; consequences low; assessment: monitor). The project manager avoids the risk by registering for the symposium and lodging early. Additionally the project manager controls the risk by making a backup (redundant) reservation at a nearby hotel. Management agrees to pay the cancellation fee if the traveler does not use the backup reservation.
Alternatively, the project manager could address this negative risk as an opportunity. For example, the project manager could discover an adjacent hotel property is equally rated for service and comfort, and has a lower financial cost, but at a convenience cost of having to walk across a parking lot to get between the hotel and the symposium venue. The project manager could control or enhance the opportunity by trading convenience for financial cost and adjusting project requirements.
• Local crime rate rises to unacceptable levels (probability moderate; consequences high; assessment: attention required). Ignoring the risk does not make it go away, but viable options are limited. The project risk manager controls some risk by providing the traveler with a corporate briefing on reducing vulnerability to crime while traveling on business. Additionally the project risk manager transfers some risk by ensuring corporate health, disability, and life insurance policies cover the traveler. Finally, the project risk manager and management agree to accept the remaining risk.
• Symposium is cancelled (probability low; consequences moderate; assessment: monitor). The project risk manager controls risk by making plans to attend another symposium.
• Risk monitoring and control is systematically tracking identified risks and evaluate the effectiveness of handling strategies. For the San Antonio Project, the project risk manager (traveler) continues to monitor the information sources already identified and implements risk response plans.
Chapter 11 of ANSI/PMI-99-001-2000, A Guide to the Project Management Body of Knowledge (PMBOK® Guide, 2000) describes project risk management. The approach to project risk management can be a lot like the formal scientific method. Project risk management processes and formal scientific method are both invincible tools that force the most intractable problems to yield. Unfortunately, both tools have the disadvantage that in the hands of some practitioners, they can be ponderous, time-intensive, costly, and biased toward very large projects. Some project managers could apply the project risk management steps and could easily find themselves polarized between expensive, heavyweight exercises on the one hand, and oversimplified checklist approaches for small jobs on the other. Fortunately, skilled practitioners can tailor both tools to the problem at hand.
Focusing on the three keys to help tailor the six project risk management steps can help the project team to develop project risk management processes which are effective, efficient, and react rapidly to changing conditions. The three keys are to identify risk events; to recognize project risk management is a process, not a product; and to appreciate ignoring risks does not make them go away.
Astute project managers may tailor the PMBOK® Guide's project risk management processes to plan personal projects, like business trips or family vacations. In the admittedly trite case of delivering a person to attend a symposium and returning him safely to home, the project risk management process delivers a suitably tailored risk management plan that identifies, analyzes, and handles risks. While some risk practitioners may dismiss these risks and this application as trivial, other practitioners may embrace these risks and this application as vital to the professional success of some individuals or the economic success of their firms.
Clavell, James, ed, 1983. Sun Tzu, 6th Century BCE. The art of war. New York: Delacorte Press.
Defense Systems Management College. 2001. Risk management guide for DoD acquisition, 4th ed. Fort Belvoir, VA: Defense Acquisition University Press.
Harris, Victor, trans. 1974. Miyamoto Musashi, 1645. A book of five rings. Woodstock, NY: The Overlook Press.
Hillson, David. 2001a. Extending the risk process to manage opportunities. PMI Europe 2001 (Fourth European Project Management Conference). London, 6–7 June 2001.
Hillson, David 2001b. Effective strategies for exploiting opportunities, PMI Symposium 2001 (First to the Future). Nashville, TN, 1–10 November 2001.
Howard, Michael, & Peter Paret, ed. 1976. Carl von Clausewitz, 1832. On war. Princeton: Princeton University Press.
Petroski, Henry. 1985. To engineer is human: The role of failure in successful design. New York: St Martin's Press.
Pirsig, Robert M. 1974. Zen and the art of motorcycle maintenance: An inquiry into values. New York: William Morrow & Company.
Project Management Institute. 2000. A Guide to the Project Management Body of Knowledge (ANSI/PMI 99-001-2000). Newtown Square, PA: Project Management Institute.
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio, Texas, USA