ITP-3 - Project Risk Assessment
Project Risk Management
Project Risk Management Page 1 of 5 January 2020
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
Some Definitions and General Comments on Risk
Project risks can be defined as uncertainties. Another valid perspective is that risks are problems that haven't happened yet. In short, 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.
Risks are ubiquitous. As 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. You could even 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.
There can be good risk and bad risk, positive risk and negative risk. 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.
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
2 of 5
R i sk I denti fi c ati on
Project managers tend to be reticent with risk management. That is, they are 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.
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.
Ri s k C ateg or i es an d Mi ti g ati on
This week's reading, Managing Project Risk, has example categories for potential risks. It also explains the different approaches to mitigating risk. Feel free to use them or other examples that you find during your research.
C r i ti c al r isks that "th ey " do n' t w ant y o u c onsi der
… 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.
Hi g h-l ev el r i sks
Other high-level, project-level 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
3 of 5
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.
Ri sk Response Pl an ni n g
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.
Ri sk Mai nte na nc e
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.
B r ai nstor mi ng
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:
• "Brainstorming, familiar to nearly every citizen of the developed world, is the preferred and obvious way to jumpstart a stalled problem solving process. The freewheeling and uncensored atmosphere of tossing out ideas without debate or discussion is just what is needed. In fact, brainstorming incorporates into its procedures another of the great process meta-rules." -- Larry Constantine, "Habits of Productive Problem Solvers", Software Development Online, August 1, 1999.
• Branistorming, then, is group outside-the-box thinking.
• "Take, for example, brainstorming. By now, most of us in business have learned how to brainstorm properly. We sit at the table, politely waiting our turn while the facilitator asks for our ideas in strict rotation, writing them down verbatim while we all take great care to avoid offering even the slightest appearance of criticism lest it intimidate the flow of creative thought. Then we get our milk and cookies and take a nap." -- Bob Lewis, "Braindrizzling", Inforworld, Sept. 30, 2002.
• Of course, he's being facetious and ironic. He's advocating the opposite. Unfortunately, that actually is how far too many people view brainstorming. Worse, all too many practitioners omit the part about avoiding criticism; they encourage jumping in and severely criticizing anything that's different from the current politically accepted view. (I'm referring to corporate office politics, of course, not Washington
4 of 5
politics.) We immediately notice that Lewis's facetious paragraph is essentially the opposite of Larry Constantine's view, above.
• Brainstorming should be an unstructured, rapid-fire, throwing out of ideas -- preferably outside-the-box ideas -- in any order, regardless of reasonability, feasibility, or anything else. The time for analysis and consideration is after brainstorming is completed, not during. It is definitely not round-robin. Anyone who gets an idea should immediately throw it out without waiting for his "turn", even if he has several ideas in a row. It's okay -- in fact, it's good -- to piggy-back off others' ideas if that triggers a thought. Conversely, people who don't have any ideas shouldn't be required to think of one just because it's "their turn".
• A contrived example may help: Brainstorm what's in this small box that I'm holding. (It's contrived because we can just open the box to see what's in it, but please bear with me -- there's a point.) Everyone should throw out whatever ideas they have. … But you're being too conservative and not thinking outside the box. For instance, nobody said that there's an elephant in the box. An elephant is far too big and couldn't possibly fit in this box, you say? True. But if you said "an elephant", it might well have prompted someone else to say "a picture of an elephant". And that, as you can see, is what's in this little box.
• Perhaps you can see how this free-wheeling outside-the-box thinking can be a good way to think of possible risks. Not everything thrown out in a brainstorming session will be useful. After the session, the ideas should be considered, analyzed, and evaluated. Some of them may yield potential risks that should be documented and handled.
5 of 5
B i bl i og r aphy
Anonymous (n. d.). "Quantitative Risk Analysis". King Fahd University of Petroleum & Minerals . Retrieved December 3, 2011 from http://faculty.kfupm.edu.sa/CEM/alkhalil/PDF_CEM_516/L05%20Quantitative%20Risk%20Analysis.pdf
Elyse (2007, February 7). ”Qualitative Risk Analysis". AntiClue. Retrieved December 3, 2011 from http://www.anticlue.net/archives/000817.htm
Fuller, Mark A, Joseph Valacich, and Joey F. George (2008). Information Systems Project Management: A Process and Team Approach. Upper Saddle River, NJ: Pearson Prentice-Hall.
Kuras, M., Zajac, A. (n.d.) "Information Systems Pitfalls: How To Reduce IT Risks". Retrieved December 2, 2011 from http://ki.ae.krakow.pl/~zajaca/artykuly/Ostris97.htm
Lewis, Bob (Mar. 19, 2012). "Why 'premortem' really stands for 'prevent mortem' ". Keep the Joint Running blog. Retrieved from http://www.weblog.keepthejointrunning.com/?p=4602. [Note: this is more about risk management than post-mortem assessments. -- ks]