WCS logo

Your Source for Project Management Training

Home Page | Course Overview | Partnering with Westwind | FAQ | Testimonials | Free Project Process Charts
Some Articles we have Written | The Project Management Guide | Our Books | How to Contact Us | Our Corporate Profile

Project Management Articles

A Primer on Managing Project Risks

In Why Things Bite Back – Technology and the Revenge of Unintended Consequences, the science editor Edward Tenner tells the tragic story of the “world-class American yachtsman Michael Plant [who] died after his sixty-foot sloop capsized during a solo transatlantic voyage in October 1992; concerned to arrive in France in time for the beginning of an around-the-world race, he had not registered his Emergency Position Indicating Radio Beacon. Had its signals been recognized promptly, Plant might well have survived.”

Apparently, Plant recognized the risks, otherwise he would not have installed the beacon, but in a disturbing parallel with the manner in which many project managers treat risks, he did not take the necessary actions to manage them. Now some may object to this analogy, arguing that not managing risks is less severe for them than it was for Plant because they are in a safer activity. Be warned, however, that Tenner documents cases in which computer bugs have killed people. Some risks have more serious consequences than others.

Introduction to Risks

In my interviews with project staff, I have rarely failed to get a comprehensive reply when I ask for a list of project risks, but my next two questions, “How risky is each risk?” and “What have you done to mitigate them?” are usually met with puzzled evasions. Project managers seem to believe that once they have identified the risks, they have completed the process, but in the field of risk management, they have barely started.

Before we talk about how to manage risks, two points need to be made. First, risks are not problems to be solved, they are potential problems to be mitigated. I have often asked project staff to identify a major risk, only to be told something like, “Well, last week the server crashed.” That’s unfortunate and you’d better fix it, but it has nothing to do with risks unless you’re talking about it crashing again.

The second point is that all risks get resolved. Some never materialize, some are handled with varying degrees of discomfort, and some escalate into crises that destroy projects and reputations. The purpose of risk management is to confine risks to the first two categories. If you manage this, you will have taken a giant step toward one of the goals of project management: managing it so well that the participants wonder why you were needed.

There are five steps in managing risks: identifying them, categorizing them, mitigating them, preparing contingency plans for them, and tracking them.

Identifying Risks

The first step is to identify risks. For that, you need a checklist which you and your team will scan at the start of each project, identifying which risks apply. Your current project is a good starting point for you to create your own list, which will grow with time and pain. To illustrate, one new risk arose when I ordered a computer that had to be manufactured. I had followed the practices of managing the vendor, keeping visibility into the production processes, so I was confident that the machine would arrive on time. When it didn’t, I indignantly called the sales rep and was told, “Your company hasn’t paid its last bill and we’ve put you on credit hold.” That risk is now included on my list.

Categorizing Risks

After you have identified the risks from your checklist, the second step is to categorize them. How risky is each one? Formal risk management is complex, demanding a knowledge of inferential statistics that is beyond most of us. It is also overkill for the kinds of risk management we need to do in IT projects. Risk is a function of two factors: the probability that the risk will materialize and the impact if it does. Some risks have a high probability and a low impact. For example, there is a highly probable risk that someone will get sick for two or three days, but that kind of impact can usually be managed with minimum disruption. Other risks are the reverse: A fire destroying the development site would be catastrophic, but the probability is almost nonexistent. However, some risks carry both a high probability and a high impact. These are the dangerous ones. For example, a rare and irreplaceable resource may be assigned to another, higher-priority project. It is this kind of risk that demands your attention.

The table below illustrates the relationship of probabilities and impacts to risks. You do not need to get over-precise in quantifying probability or impact; a simple “High,” “Medium,” or “Low” categorization is sufficient. The intersection of probability and impact provides the corresponding degree of risk. The ones that will concern you are those that are extreme or high, those shaded in the table below. While you may feel uneasy about paying less attention to the others, you have limited time, which is best spent focusing on the riskiest of the risks and on the other project management activities that need attention. Besides, you will not ignore the others. We’ll get back to them later.

High Medium Low
Impact High Extreme High Medium
Medium High Medium Low
Low Medium Low Minimal
Mitigating Risks

Now that you have identified the most dangerous risks, your third step is to mitigate each one, which means to reduce its degree of risk. Since riskiness is a function of probability and impact, you lower it by reducing either of those factors. For example, consider the risk that you will lose a key resource. You reduce its probability by staking your claim in advance, informing whomever assigns staff when and for how long you need each person. You could reduce the impact by introducing a form of understudy program in which someone with less experience is asked to spend some time with the expert learning that skill. As another example, consider the risk of a virus infecting the development environment. You might reduce the probability by imposing standards for the import of executables and the handling of unexpected e-mail attachments and you would reduce the impact by maintaining a strict backup process.

You need to go through each of the major risks and define what steps you will take to reduce the probability that it will materialize, the impact if it does, or both. If you can reduce the degree of risk to medium, you have done well.

Contingency Planning

The fourth step in risk management is to establish contingency plans. What exactly will you do when the risk becomes a problem? In most cases, the contingency plan defines the execution of some recovery strategy that you identified during your risk mitigation. For example, if you have reduced the impact of losing a key resource by appointing an understudy—let’s call him Fred—you now need to shove Fred onto center stage. This may mean having handover meetings, bringing in someone else to take over Fred’s former responsibilities, and re-working your project plan to account for the longer durations caused by his inexperience. Similarly, if you have mitigated the risk of a virus infection by taking regular backups, you will now need to execute a purge and recovery plan. However, before you can carry out any of these plans, you need to prepare them. Contingency planning is making the plans before you need them, even though you may never have to carry them out.

Tracking Risks

The fifth step in risk management is the ongoing process of tracking risks. Unfortunately, risks are not predefined, static demons, they change. Some risks disappear, some become less risky, some more so, and new risks pop up. Remember the risks that you identified at the start of the project that you categorized as medium or low and have, therefore, set aside so that you could focus on the serious ones? The probability or impact of these can change as the project progresses. For example, I had categorized as medium the risk that a server delivery would be late because, although the probability was high (the vendor was notorious for over-promising and under-delivering), the impact was low; I had an understanding that if our server was delayed, we could share another project’s already installed machine. One week before the planned delivery date, after hearing a rumor that the other project had switched operating systems, I checked with their project manager who confirmed that they had indeed switched from NT to UNIX. That option was not open to my project, which meant that the impact of a late delivery had suddenly jumped to high and the risk category had switched from a comfortable “medium” to a sweaty-palmed “extreme.” Had I not been monitoring risks, this one’s materialization would have been a nasty setback.

This fifth step is the one that is most commonly and most seriously disregarded; project managers tend to confine risk management to the planning stage of the project. Of course it belongs there, but it must also be part of project execution. At least once a week, you need to pull out your list of risks and re-categorize them. If you are diligent, you will find that you begin to question some of the conditions that prevailed when you made your first pass, and that the risks have shifted under you.

One of the major sources of “risk news” is your team. You need to acquaint them with the risks and, at each team meeting, conduct a round table soliciting comments on risk conditions. Most people will pass, but occasionally you will hear a nugget of information that will cause you a moment of panic. Believe it or not, this is what you want: the opportunity to panic when there’s time to respond. Summary To summarize, you manage risks by following five steps: identify them, categorize them, mitigate them, plan how to handle them, and track them. If you do this, you will have a much better chance of emerging at the end of the project with everyone saying, “That was easy. We sure didn’t need a project manager for this one.”


Back to Articles | Return to top | Return to Home Page