Risk management -- why?
by Elden F. Jones II, PMP
WHEN ASKED ABOUT risk management (RM), does your answer take on one of the following forms?
■ “All of our risks have been identified and eliminated.”
■ “I have completed my risk assessment for the project and found only a few items of concern.”
■ “What is Risk Management?”
What is Risk Management? This is a common question for which the answer usually develops several forms. When the response is similar to one of the first two above, we are usually only referring to a piece of RM. Seldom do projects go through the rigors of quantifying risk and then come up with ways to handle those risks (although companies are using RM more frequently). The result is that risk is not understood within project management. This article attempts to tell why we must spend the time and effort to explore RM, become proficient in the process, and define a set of common terms.
Anybody who deals in project management or with task deliverables must understand what RM can do.
People regard risk as a negative impact on a project schedule or cost. However, by no means is risk just a negative impact. Risk can open avenues of opportunity, improvement, or new thinking.
RM is the use of a set of skills from an individual or group of individuals, which ensures that all risk events are identified, quantified, and handled for the project. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) breaks risk into four unique tasks: risk identification, risk quantification, risk response development, and risk response control. Each has a unique role and set of responsibilities.
Let's begin with a the definition of a risk set: “A grouping of risk events, either by classification or project.” For further definitions, we look to the PMBOK® Guide:
Elden F. Jones II, PMP, CMII, with Robbins-Gioia Inc., a project management firm where he reviews processes and procedures for improvement within the U.S. DoD, DoJ and Royal Airforce, has worked in the project management arena for over 15 years. He is also involved with the development of configuration management policies and procedures for the Criminal Justice Information Systems Division of the FBI. He served as director of public relations for PMI's San Diego Chapter in 1998 and now serves in the same role for PMI's Risk Management SIG, and he is the founder of PMI's Configuration Management SIG.
Exhibit 1. The decision tree illustrates how a disciplined approach to analyzing RM can benefit the project. (Graphic courtesy of David Hulett.)
■ Risk event—A discrete occurrence that may affect the project for better or worse
■ Risk identification—Determining which risks are likely to affect the project and documenting the characteristics of each
■ Risk quantification—Evaluating risks and risk interactions to assess the range of possible project outcomes
■ Risk response development—Defining enhancement steps for opportunities and responses to threats
■ Risk response control—Responding to changes in risk over the course of the project.
Basic Risk Concepts. Most projects, which are assumed under control, handle risk as an unidentified occurrence and then scramble to manage that risk. A majority of projects handle such occurrence well. However, with a solid RM effort, either risk events are handled ahead of time, or a plan is in place to deal with them when they do occur.
Putting some basic concepts in place gives us a leg up on risk. First, we must identify the risks that may occur on our project. Simply going through the work breakdown structure and asking yourself and your team a few questions will identify most risks; for instance: What would happen if the resources (consumable or renewable) were not available when required? What could happen over which I have no control that would affect this item? What could happen over which I do have control that would affect this item? What is the worst-case scenario? What causes it? How likely is it? What are the consequences?
Reader Service Number 080
Other questions come to mind, but these should start you down the right path. List everything that comes to mind, then, in a later step, determine if we need to handle the risk now or if we can wait for it to happen. No matter what happens, if you have identified the risk and chosen not to handle it, it is better than not identifying it at all.
Next, take all identified risks and place a quantitative value on them. First, group the risks into categories. (For example, “Paint is not available” does not group with “Hinge bolt broken.” However, it does group with “Wrong type of paint available.”) After you have grouped the risks, place a probability value on each risk. A method used often is a probability class assignment such as:
Likely = 85 percent
Probable = 60 percent
Possible = 40 percent
Unlikely = 15 percent
High = 85 percent
Medium = 50 percent
Low = 15 percent
This is for generic probability of a risk occurring and the percentage used in calculations. Another method is to assign a percentage to each risk. The problem with assigning an actual percentage is that very seldom is there enough empirical data to back it up. It is usually an estimate by the person who applied the percentage, which makes it extremely important to select knowledgeable experts to interview about risks. All percentages within a risk set must add up to 100 percent.
Next, add some value to the risk. This can be in either cost or schedule figures—whichever is required by the exercise. For instance, if the purpose were to determine when the project might finish, each scenario would describe some activity duration consequences to the risk scenario. Additional calculations at this stage provide a true value of the risk. Basically, just by calculating the assigned value of the risk multiplied by the probability of the risk occurring, you can determine if the risk warrants your attention now, or if you can afford to wait and let the “bomb” explode.
Reader Service Number 005
Disciplined Approaches: Decision Trees and Simulations. The decision tree in Exhibit 1 illustrates how a disciplined approach to analyzing RM can benefit the project. In the example shown, a “successful project” yields a $20,000 profit, whereas an average project provides $5,000 profit. If the project becomes a “problem project,” it incurs a loss of $15,000. A RM strategy is being considered that costs $7,500. Some argue against the risk mitigation strategy as being too expensive and think that “we ought to take our chances.” Is this the right decision? Use a decision tree.
On its face, this decision is easy—the RM action's cost could be avoided. However, the true decision is otherwise.
The rest of the decision tree illustrates the importance of analyzing the RM action before making the decision. The expected value of spending $7,000 now on a RM action is $7,500, because it increases the likelihood of success to 70 percent from 50 percent and decreases the likelihood of the project becoming a “problem project” to 5 percent from 30 percent. The expected value without the RM is only $6,500. The project manager has an opportunity to increase the likelihood of having a successful project and the expected value of the project by doing proactive RM. The decision tree analysis examines the decision in light of the costs, rewards, and probabilities.
Exhibit 2. Risk quantification using Monte Carlo simulation is effective. (Graphic courtesy of David Hulett.)
The final step is to figure how to mitigate the risks that you want to handle. This is a means to eliminate the possible risks, reduce the risks’ impact, or pass the risks on to someone else. All are means to mitigate the risks; use the method that best fits.
Another approach to quantitative risk analysis is to use a Monte Carlo simulation. Take schedule risk as an example. In standard critical path method (CPM) scheduling, logic and estimates of how long the activities will take determine the completion date. Yet, experienced project managers know that the activities may actually take more or less time, depending on some factors that can be managed or are not controllable. A schedule risk analysis simulates the schedule many (hundreds, thousands) times. Each iteration is a CPM solution, using durations from probability distributions based on estimates of the optimistic, pessimistic, and most likely durations for each uncertain activity duration. The distribution of possible completion dates estimates how likely the CPM date is to be achieved, how much schedule contingency is needed, and which activities in the project contribute the most risk. An example of such a result is shown in Exhibit 2. In that schedule, the risk is 95 percent that the project will overrun the 9 September 1999 CPM date and a one-month contingency will be needed to drive the likelihood of overrun down to 10 percent.
Maintaining the Risk Set. After you have gone though the steps for RM, you can begin the process of maintaining the risk set. Review risk periodically, based on the complexity and duration of the project and whenever a change occurs in the project.
To begin to implement something like this may seem a bit overwhelming and not cost effective. However, the first time you encounter a risk that has been identified and have already figured how to handle it, RM will prove its worth. Just take the first step and start identifying risk at the higher level of the WBS; don't worry about going down to the work-package level. As time warrants, dig farther into the WBS, and eventually you will have laid out those risks associated with your project. After you do this a few times, you will not believe the benefit your project receives. Just remember: Q. How do you eat an elephant? A. One bite at a time.
WE LIVE IN A WORLD OF RISK. We must analyze the risk, determine if we should take it, and look for the benefit in all risk. The benefit of risk management may not be realized until after the project is over, but remember: “He who fails to plan automatically plans to fail.” ■
Reader Service Number 096
PM Network February 2000