CHAPTER 11
Managing Risks
When I first started teaching seminars in 1981, there were many managers who objected to discussions of risks because they considered this to be “negative thinking.” They believed that people should always think positively. What they didn’t understand is that there is a difference between being realistic and being either overly positive or overly negative. I don’t believe there are so many managers today who avoid discussing risks, because risk management is much more prevalent than it was in 1981. Furthermore, risk management is conducted in a positive way. You ask what might go wrong and what do we do about it? That is a positive response.
One of the single most important things you can do to ensure a successful project is manage risks. A risk is anything that could adversely affect your schedule, costs, quality, or scope. That is, a risk may impact your PCTS targets. Simply put, either you manage risks, or they will manage you.
A supermacho mentality that doesn’t understand this still exists. “Damn the torpedoes, full speed ahead!” is an approach that sounds glamorous, but it can wreck your project. It may be appropriate in a military setting, but not in projects. In fact, there was a time when the airlines hired a lot of former military pilots, who proceeded to scare the daylights out of passengers by flying the airplane like a fighter aircraft. The airlines had to retrain them to consider the fear factor in their passengers.
I previously mentioned the manager who told me that he didn’t want me to suggest to his people that they pad their schedules. “I want them to be aggressive,” he said. As I have remarked, there is a difference between an aggressive schedule and a foolish one. To reiterate a previous example, if you are doing construction work and are certain that weather could delay your project, you would be derelict in your duty as a project manager by not addressing potential delays. You’d do so by allowing a bit longer for work to be completed than it would take if there were no weather delays. This is called padding the schedule and is proper risk management in construction.
In Step 4 of The Lewis Method, you are asked if SWOT and risks are okay. This was discussed briefly in Chapter 7. You will note that Step 6 also asks if risks are okay. So, there are two specific places in a project where risk management is important—in planning strategy and in implementation planning. It is important that you constantly ask, “What might go wrong?” so that you can anticipate and deal with risks, even in the execution phase of the project.
Also in Chapter 7, I pointed out that there is a difference between threats and risks. A risk is something that you can do yourself, such as having an accident, or that can happen to you in an impersonal way, such as bad weather. A threat, on the other hand, is something that will usually be done to you by some entity, whether a person or an organization. As an example, a threat to project success is that a competitor beats you to market with a new product. In practice, it is okay to lump the two together for the purpose of analysis and contingency planning.
THE RISK MANAGEMENT PROCESS
There are three steps in the risk management process:
1. Identify risks and threats by asking, “What could go wrong?” or, “What kind of threats exist?”
2. Quantify threats and risks by assigning them a risk priority number (RPN).
3. Develop contingency plans to deal with risks that cannot be ignored.
Risk Identification
As I said earlier, you need to identify risks that may impact your strategy and your implementation plan. To revisit another example, if you are developing a new product using cutting-edge technology, the possibility exists that you won’t be able to get the technology to work. The more unproven the technology, the higher the probability that you will have difficulty. One way to manage such risk is to do a feasibility study to see if you can make the new technology work before you launch a full-scale development effort. If you can’t get the results you want, you can fall back on more proven technology.
If you launch a development program using unproven technology and can’t make it work, the consequences are far more serious than if you do a feasibility study and reject the new approach. For one thing, it is more obvious to everyone that a feasibility study is a success regardless of the outcome. If you say yes, we can make it work, that is a success; but so is the negative result, because it will save you a lot of grief trying to make something work that can’t be done.
When you get to the implementation planning stage of your project, you again want to identify potential implementation problems. In this case, the WBS can be used to guide your thinking.
I previously used a yard project as an example of developing a WBS. That WBS is repeated in Figure 11.1.
Figure 11.1 WBS for a Yard Project
Now, suppose I want to do risk management. For each task in the WBS, I ask, “What could go wrong?” Here are some examples for each task:
1. Cleanup. The dump may be closed when we get there, so we have wasted time driving over there. The contingency would be to call and see if the dump is open.
2. Cut grass. It might rain while we are cutting the grass. The contingency would be to check the weather forecast and schedule the activity on a day when good weather is forecast.
3. Trim work. You run out of string for your string trimmer. The contingency would be to keep a supply of string on hand.
4. Prepare equipment. Your mower runs out of gas. The contingency would be to make sure you have plenty of gas before you start.
5. Trim hedge. You might trim unevenly, and the yard would look bad. The contingency would be to have someone who is more skilled at it do the trimming.
I have listed only one risk for each task. Clearly, more than one thing could go wrong on complex tasks, so you list all of them, then quantify them and deal with the more serious ones.
At this stage in planning, be careful that people don’t go into “analysis paralysis.” You will probably identify the most likely risks quickly. Trying to find every single thing that could go wrong is unproductive. However, you should be careful not to reject a risk simply because you consider it highly unlikely to occur. As you will see in a subsequent section of this chapter, there are low-probability events that will have a very severe impact on the project if they do occur. These should never be ignored.
RISK QUANTIFICATION
We know that risks are not all equal in their impact on a project. The question is, how do you decide which ones you can ignore and which ones you should manage? The desired approach would be to find some way to prioritize the risks. This can be done by calculating risk priority numbers (RPNs) for them. Three factors contribute to the RPN. First is the probability that the risk may occur. Second is the severity of the effect on the project if the risk should occur. And third is the question of whether you can detect the risk before it hits you.
This risk management methodology was worked out in an engineering discipline called failure mode effects analysis (FMEA). When designing a product, an engineer is supposed to identify possible modes of failure for various components and then ask what the severity of each failure may be and whether it can be detected. As an example, the dome light in your car may burn out, and you could have your transmission seize up. The probability of both occurrences may be very low. However, the severity of a dome light burning out is far lower than that of the transmission seizing up. Furthermore, you will know immediately if your transmission seizes up, but you may not know until you open your door at night that your dome light has burned out, since you may not notice it during the daylight.
To calculate RPNs, we use three tables. The first assigns a rank of 1 to 10 to probability, based on a logarithmic probability scale. The second table assigns a similar rank to severity, and the third does the same for detection.
In the original FMEA approach, detection means that you may or may not be able to tell that a failure has occurred in a product. For example, if you have manufactured a car that has a crack inside the engine block, you may not be able to detect that crack before the car leaves the factory. On the other hand, if a tire goes flat, that is easy to spot and correct before the car is shipped. If a fault can be detected with certainty, the number assigned is 1. If it absolutely can’t be detected, it gets a rank of 10.
The problem with this approach to detection is that it usually yields a 1 when it is used in project risk analysis, and so it loses its utility. I think a more helpful way to consider detection is to ask whether a failure mode can be detected before it happens.
Table 11.1 is used to quantify risk probability.
TABLE 11.1 Probability of Occurrence
Table 11.2 is used to quantify the severity of the failure. Finally, Table 11.3 is used to quantify detection capability.
TABLE 11.2 Severity of the Effect
TABLE 11.3 Detection Capability
Examples of RPN Calculation
An example that I find helpful for illustrating risk management is to assume that you are riding a bicycle from the East Coast to the West Coast of the United States. You identify several risks that could affect your trip and estimate the numbers shown in Table 11.4.
TABLE 11.4 RPNs for a Bike Trip
You will see that having a flat tire and being hit by a car both have RPNs of 200 points, which would imply that they are equal in importance. However, they are qualitatively very different. The RPN for having a flat tire is 200 points because the probability is high and detection capability is poor. Getting hit by a car has a very low probability, but high severity and poor detection. These two risks demand very different responses. This is why we talk about risk management, not just risk identification.
As a rule, any time severity is in the range of 8 to 10 points, you should require that some action be taken to deal with the risk. This is especially important to consider when probability is low. People tend to ignore risks when they think that there is a very low likelihood of their occurrence.
The Challenger space shuttle disaster is a good example of this. Many of the members of the team responsible for the launch believed that the probability of failure of the O-ring seals was very low. Perhaps it was. Nevertheless, the severity of failure was a 10, as demonstrated by the fact that the explosion killed all the astronauts aboard. Had the team considered severity and followed the rule, they would have delayed the launch until the temperature rose.
Of course, we now also have the Columbia shuttle disaster. According to Wikipedia: “The loss of Columbia was a result of damage sustained during launch when a piece of foam insulation the size of a small briefcase broke off the Space Shuttle external tank (the main propellant tank) under the aerodynamic forces of launch. The debris struck the leading edge of the left wing, damaging the Shuttle’s thermal protection system (TPS), which protects it from heat generated with the atmosphere during reentry. While Columbia was still in orbit, some engineers suspected damage, but NASA managers limited the investigation, on the grounds that little could be done even if problems were found.”
This is certainly no forum for discussing whether this contention was true, but it highlights the issue of severity in managing risks. It would seem that under the circumstances, it would have been prudent to keep Columbia in orbit longer to determine if another solution could be found, such as sending another shuttle up to make repairs.
For a complete discussion of how risks were managed in this situation, go to the following web page: http://en.wikipedia.org/wiki/Space_Shuttle_Columbia_disaster.
The Challenger disaster is also a good example of groupthink, and CRM Learning and YouTube have videos that discuss this. Groups are particularly prone to ignore risks when they are under pressure to get a job done, as was the case with Challenger. If you don’t remember the history, Christa McAuliffe was supposed to address Congress from space. This was a big political event, so the team felt pressured to launch on schedule. For more on groupthink and how to avoid it, see Chapter 15.
Develop Contingency Plans
As I stated earlier, it is not enough to identify and quantify risks. The idea is to manage them. There are several responses to risk:
1. Risk avoidance
2. Mitigation (reduction, such as using air bags)
3. Transfer (as in loss prevention through insurance)
4. Accommodate: accept and live with the risk
5. Ignore the risk (very dangerous)
Risk Avoidance
As my colleague Harvey Levine has said, it is better to avoid a risk than to have to manage it. Delaying the Challenger launch would have been risk avoidance. This is a trap for the obsessive “can-do” manager. He drives on in the face of a risk and pays the consequences later.
Risk prevention is a special case of risk avoidance. Japanese manufacturing has for many years employed “foolproofing” as a risk avoidance strategy. The idea is to set up the assembly process so that it cannot be done incorrectly. One example was the auto plant that, when installing a gas tank in a car, would on occasion find that one of the four mounting brackets had not been welded onto the tank. The solution was to set up a fixture to hold the tank while the brackets were being welded onto it. Feelers were attached to detect the presence of the brackets. If any of the four brackets was not in place, the welding machine would not weld any of them.
In construction projects, we pad the schedule with rain-delay days, based on the weather history for the area and the time of year. This way, we avoid the risk that we will be delayed by bad weather. In engineering design, I mentioned the use of parallel design strategies to avoid the possibility that the deadline might be missed because one strategy proves difficult to implement. In any project, risk aversion or avoidance might be the most preferable strategy to follow.
Mitigation or Severity Reduction
If we can think of contingencies in the event that a risk takes place, we may be able to mitigate its effect. Placing air bags in cars is an attempt to reduce the severity of an accident, should one occur. Stafford Beer (1981) has argued that seat belts and air bags in cars give drivers a false sense of security, so that they take chances they might otherwise not take. We have defined the problem as protecting the driver from being harmed if she is in an accident. Beer argues that it would perhaps be better to redefine the problem as how to keep a driver from having an accident in the first place (risk avoidance). He suggests that if we lined the dashboard of the car with spikes, making it very clear that an accident has serious consequences, we might give drivers incentive to be more careful. His suggestion is not without merit, though the exact implementation would have to be some other mechanism than a spike-lined dashboard.
In projects that involve procurement, sole-sourcing is a risk to consider. The alternative is to second-source all procured parts or equipment. That way, if a supplier can’t deliver on time or at the specified price, the second supplier might be able to step in. This can be thought of as either risk avoidance or risk mitigation.
Temporary workers are used as backups for critical personnel who become ill or are injured. Overtime is used as a contingency when tasks take longer than estimated. This is one reason why overtime should not be planned into a project to meet the original targets, if possible. Rather, it should be kept in reserve as a contingency.
Another possible contingency is to reduce scope to permit the team to meet the original target date and then come back later and incorporate the deferred work to finish the job.
Having a fire evacuation plan in a building can be thought of as both a contingency and a loss-prevention plan.
Transfer or Loss Prevention
Insurance is one way of protecting against loss in the event that a risk manifests itself. Having alternative sites available into which a group can move in the event of a disaster is a loss-prevention strategy. Backup personnel can also be thought of as loss avoidance. When a key person falls ill, if someone else can do the work, there will be no loss to the project. Of course, this is difficult to do with highly skilled personnel.
Cost Contingency
Cost contingency is also called management reserve. Unfortunately, it is misunderstood. Too often it is believed that management reserve is there to cover poor performance. This is incorrect. Management reserve is a fund that is part of a project budget to cover the cost of unidentified work. All projects should have a work budget that covers the cost of identified work, and a management reserve to cover work that has not yet been identified. In addition, on projects that are paid for by a customer, there will be a component of the total job cost called margin. This is the intended profit for the job. Poor performance eats into margin, not into management reserve.
The management reserve account is not touched unless we identify new work that needs to be done. This is a change in scope, of course. At that point, money is transferred from the management reserve account into the work budget, and performance is subsequently tracked against the revised budget. A log should be maintained of all scope changes and their effect on the work budget, management reserve, and margin (if the change has such an effect). In customer-funded projects, the customer may be required to pay for scope changes, and in that case, there is no impact on the management reserve account.
Accommodate
Sometimes we just accept the fact that risk is present, and we take our chances. All of us do this when we drive a car or fly in an airplane. We know that there is a chance of an accident, but if we refused to accept that possibility, we would never get into a vehicle or a plane. This is not the same as ignoring a risk, which is covered next.
Ignore
This is different from accommodating a known risk. It is like putting your head in a hole in the ground and pretending that the risk does not exist. People do this when they practice unprotected sex with partners whose past sexual histories they do not know.
IN SUMMARY