CASE STUDIES

Week 5 - Chapter 11 - Managing Project Risk (PMBOK 11)

Contents I. Managing Project Risk - PMBOK 11 1 On Risk 3 Module Highlights, Commentary, and Lecture - Managing Project Risk - PMBOK 11 4 Some Definitions and General Comments on Risk 5 Risk Identification 6 Risk Categories 6 Critical risks that "they" don't want you consider 6 High-level risks 7 Risk Response Planning 7 Risk Handling 8 Risk Maintenance 8 Brainstorming 8 More to follow 9 Bibliography 9

Figure 1 Risk : Tightrope, roller coaster, thin ice, juggling knives, slot machine, weighing dice

Screen Beans Art © A Bit Better Corporation

Project risk management is one of my favorite topics in project management -- not because it's so much fun (that's in the eye of the beholder) but because it's so important.

In its simplest essence, a risk is an uncertainty, in this case about the project. A risk is essentially a possibility that something may go wrong in the future. It has not gone wrong yet (if it had, it would be a problem or an issue, not a risk), but it may in the future. Project planning looks into the future to plan now what we'll do then; no area in PM is more future-oriented than risk management. The whole point of risk management is to think in advance of what might go wrong, and plan in advance how to forestall it so that it doesn't go wrong, or how to handle it successfully if it does go wrong.

Since the goal of a project is to succeed and not fail, managing risk is critical. As RADM Bill Carlson says, "if you're not managing risk , you're managing the wrong thing."

We can drive the management of a project entirely by managing risk. Put another way, we can manage an entire project from a risk perspective. It's that key to everything. Personally, I'd argue that it's even more important than quality. After all, we can manage quality by managing risk (i.e., by managing the risk of poor quality).

Actually, the above discussion is an oversimplification.  Risk isn't really the possibility that something may go wrong.  Risk is actually uncertainty that can impact a project.  It can actually be the uncertainty of a good thing as well as the uncertainty of a bad thing.  (More about this as we go on.)

Risk management is another area that many people would add as a 4th (or 5th) element of the triple constraint (along with cost, schedule, and scope, and some add quality).

"If you're not managing risk, you're managing the wrong thing."

-- Rear Admiral Bill Carlson

“Effective risk management underpins a successful project."

The textbook (and PMBOK) definition of project risk says in essence that risks are uncertainties. Another valid perspective is that risks are problems that haven't happened yet. In short, as Alexey, a former IFSM 438 student, put it "everything that does not match the plan is a risk."

The flip side is that problems are materialized risks, i.e., risks that have actually happened.

Issues, then, are problems that we can't solve ourselves and must elevate to higher management for handling.

So the progression in time is: risks, to problems (if they materialize), to issues (if they can't be solved). Any of the above may also generate project or product changes in order to handle the risks or solve the problems (or alter the factors in the triple constraint if management so directs). They may also, of course, generate process changes and other effects.

To reiterate: If we don't identify risks up front and plan for how to handle them if they should occur, then like it or not, we will have to handle them later on as problems and issues, and that will cost more and put the project (and the project manager) in greater jeopardy than dealing with them up front as risks.

(More on this later.)

Risks are ubiquitous. Like Chicken Man on the old radio show, "They're everywhere! They're everywhere!"

As I mentioned above, we can drive the management of a project entirely by managing risk. Put another way, we can manage an entire project from a risk perspective. It's that critical to everything. Personally, I'd argue that it's even more important than quality. After all, we can manage quality by managing risk (i.e., by managing the risk of poor quality), but we can't really manage risk by managing quality because there are a lot more risks than simply quality issues alone.

Just like team conflict (remember Chapters 9 & 10 on Managing Project Teams and Managing Project Communications?), there can be good risk and bad risk, positive risk and negative risk. And just like conflict, we tend to concentrate on the bad side. However, there can be a risk of something good happening also. How can that be? Remember that risks are uncertainties. So there can be a possibility, an uncertainty, that some identified or postulated good thing may happen on the project, also.

Did you see the TV commercial a few years ago about a small start-up .com that put up its first public Web site. They sat there and stared at the computer screen for a while and nothing happened. After little while, it registered their first sale! They cheered! A little while longer and more sales started to come in. They cheered some more. Then it started to snowball. Within a few minutes, it was ringing up hundreds of thousands of sales. They got really quiet and somber. What to do now?! They hadn't planned on that. They didn't have the capacity to handle all of that. High sales was a good thing, to be sure; but not being able to handle it was a bad thing. Either way, it was an unplanned uncertainty, a risk, and they hadn't foreseen it or planned on how to handle it.

(Aside: I've mentioned this before, but if you can find an online video of that TV commercial -- I think it was by IBM -- then please post the URL so we can all see it! I may even be able to give a small amount of bonus point(s) for it if you do.)

As noted, we can view this either as a positive risk, the unplanned uncertainty of very high sales, which of course is good; or as a negative risk, the unplanned uncertainty of not being able to handle the volume and potentially even of crashing the server because of it.

In the one view, this scenario highlights a negative aspect of what is a good thing, of a good risk. It's the opposite of a "silver lining" (a good aspect of something bad or of a negative risk). A silver lining is not the same as a "positive risk". The situation in the commercial, the negative aspect of a good thing, is not the same as a "positive risk", either. (More on this later.)

Unfortunately, the risks of good things happening seem to be much less likely than the risks of bad things happening, so we tend to ignore the possibility. As in dealing with bad risk, there's little point in worrying about or planning for risks that are extremely unlikely. For instance, there's not much point in wasting effort on planning how to handle the risks to the project if an asteroid destroys the earth, or the risk of Bill Gates or the Sultan of Brunei donating several billion dollars to our office Web page project. On the other hand, it would have been good if that .com in the TV ad had planned how they might handle the risk of sales beyond their capacity.

Most project managers I've been familiar with have been too reticent with risk management. That is, they've been reluctant to identify or admit risks and when identified have been too eager to either ignore them or sweep them under the rug. The opposite approach would better facilitate project success.

I've known PMs who said that risk management is the business only of the PM (or of the risk manager, if the project has an identified risk manager). Again, the opposite approach would be much, much better: Everyone at every level should be engaged to identify risks. It is normally much more likely that workers will be able to identify risks in their own areas, with which they are intimately familiar, after all. Outsiders and higher-ups just aren't familiar enough with the nitty-gritty daily details of other areas to be able to identify risks in them very well.

If necessary, brainstorming (see below) can be used to identify risks.

Risks should be specific, not general. There is little benefit in making the risk is so general that it's vague. Tha's not very useful for pinning down the actual risks to an actual project nor developing a risk handling plan for them.

Needless to say, there should be no recriminations or penalties for surfacing or identifying risks. Identifying risks, after all, is a good thing, not a bad thing.

The Schwalbe ITPM textbook discusses an entire Risk Breakdown Structure (RBS) of categories of risks in Chapter 11. This is a summary of the RBS of the PMBOK, which is a bit more extensive. According to Fuller (2008), the basic risk categories are: Technical risks, Project management risks, Organizational risks, and External risks. These correspond roughly to the top tier of risks in both Schwalbe and in the PMBOK (each of which has several subordinate, lower level risks). However, we must certainly add categories for Funding risks, and I think that reasonably, we might well elevate Executive Support risks to an equal level, as well.

In our ITP-5i Risk Assessment deliverable, we will want to show the risk categories of the risks that we identify. For this class project, we will want to identify them using at least the extended top-level risks listed above. Using additional lower-level risks from the RBS is also good.

… Stakeholders, that is, especially executive sponsors.

In my experience, there are some kinds of risks that stakeholders don't want to admit and that PMs don't think to consider but that are very real, that can absolutely decimate a project, and that should therefore be included in all risk registers, lists, and handling plans. These include things like budget cuts, inadequate funding, customer/stakeholder non-responsiveness, lack of strong and vocal sponsor/stakeholder support, public reaction and its impacts, and the like. And in public projects, special interest groups, outside agitators, and lawsuits. They are generally project-level risks (as opposed to technical or other risks affecting only one or a few work package tasks), and they can be real killers. But the stakeholders often get upset if they see them listed in a risk register. List them anyway! Identifying them and planning for how to handle them could make or break your project.

Other high-level, project-level (Level 0 of the WBS) risks might include things like requirements risks (are the requirements accurate and complete? was anything left out? are they stable or is there significant volatility and scope creep?), project communications with stakeholders and among the team (is it good? is it poor? is everyone getting the information they need when they need it?), and similar risks. Try some Brainstorming if you need to (see below). These are important.

Level 1 of the WBS is the project phases or major components. Are there any risks in those phases or are they risk-free smooth sailing? Is there adequate funding in the initiation phase? Do customers and billpayers always agree with cost estimates? Do they ever think they should get something for nothing? How about non-responsive customers or sponsors in, well, any phase? Mis-steps in planning? A lack of information, perhaps? Certainly execution encompasses most of the project, is there anything that could go wrong there? Scope creep in execution is a big one? Budget cuts never happen, right? Oh, and don't forget natural disasters. Could anything be unknown (risky) in any of these phases? Ponder these kinds of things for a few minutes and I'm sure you'll come up with lots of different risks (and different kinds of risks) for many phases and for many levels.

Each identified risk should be analyzed and documented in the risk register. If it is a serious risk (both reasonably likely and reasonably severe, as evaluated by qualitative and quantitative risk analysis), then a risk response plan should be prepared. The response plan for a risk tells what to do to forestall and prevent the risk, and/or what to do if the risk actually occurs. (Remember, risks are potential future events.)

If, for instance, the risk is that we're building a data center in a flood zone, then a way to forestall or prevent that might be to build it elsewhere outside the flood zone, to build it on high ground, or at least to not put it in the basement! (Don't laugh. I've seen a data center built in the basement of buildings that were known to flood in heavy rains. Sure enough, the data center flooded, too. It's a pity nobody listened when that risk was identified -- repeatedly.)

Other risks can't be prevented, so the risk response plan tells what to do to reduce or mitigate the damage if the risk actually occurs. For instance, if the risk is of fire, then we can install sprinklers or the like.

The risk register should be kept up to date. Just because we went through the exercise of thinking about risks once at the beginning of the project doesn't mean that no further risks can ever arise! A constant eye must be kept on conditions to see whether there are new risks that need to be considered, as well as to see whether any of the risks are materializing. Periodic project team meetings are a good place and time to consider and keep tabs on risks.

I've seen brainstorming done so poorly that it's counterproductive. Many people have heard the term but apparently don't really know how to do it effectively. Here are some observations and suggestions: