Risk Management Overview

I noted earlier that I would write a series of posts on risk management. That series will largely be based on the Project Management Body of Knowledge (PMBOK), Fourth Edition. But I thought it best to first discuss and frame the issue of risk management. Why would we do it? And what are the impediments in an organization to doing it effectively? First let’s deal with the issue of why we do risk management and why I would maintain that you are not truly doing project management if you are not performing risk management.

Every project, according to the PMBOK, is “a temporary endeavor undertaken to create a unique product, service or result.”¹ It goes on to say that, “The end is reached when the project’s objectives have been achieved … “^2, Since the endeavor is unique and has, by definition, never been done before, there is an element of uncertainty. And in that uncertainty there is risk. PMBOK again: “Risk is an uncertain event or condition that, if it occurs, has an effect on at least one project objective.”³ So if we put these all together, we have a temporary unique endeavor with uncertainty that may have an effect on project objectives. And since the project is complete only when the project’s objectives have been reached, doesn’t it make sense to address and perhaps reduce the amount of uncertainty in the project?

So how do we accomplish this? We do it by looking at the project systematically to figure out where risk is and how we will try to deal with it proactively. Remember, a risk is something that MIGHT happen, not something that has already happened. So we are to some extent looking into a crystal ball.

PMI identifies 6 different processes involved with Risk Management. They are:

1.       Plan Risk Management

2.       Identify Risks

3.       Perform Qualitative Risk Analysis

4.       Perform Quantitative Risk Analysis

5.       Plan Risk Responses

6.       Monitor and Control Risks

While this may seem like a daunting amount of work, it’s really not. Especially for the results you achieve. We’ll go into more detail later, but typically planning for risk management happens up front, perhaps with the involvement of senior management and/or sponsor. So you write a plan that talks, for example, about your probability/impact scales (more later on that), risk tolerance and budget.

Then you get in a room with your team and work on items 2 through 5. (And very often, item 4, Perform Quantitative Risk Analysis doesn’t get done. We’ll see why later). I maintain that a team of subject matter experts can get most of their initial risk planning done in a single day for all but the most complex projects (say, decommissioning a nuclear plant). At the end of the day – or let’s say even two maximum – the team should have a fully fleshed out risk register which lays out what might happen, what the probability and impact are of each and how the team would respond should the risk occur. Note – this is very much a team process and it is very much subjective. By that I mean that experienced team members decide what the risks are. And they also decide what the impact of the risk might be as well as its probability. So is the event 60% likely to happen? Or 30%? Big difference. But I would maintain that the more the team has been together and worked on similar projects, the better their guesstimating will be.

While it’s not my intention to go into great detail on each process I do intend to at least summarize what each of these processes mean and how you might go about conducting one of these sessions. At the end of the series, after I’ve laid out what a fantastic tool this is, I will then have the unfortunate task of advising you of why this might not be readily adopted in your organization and what steps you might take to overcome that.

1. A Guide to the Project Management Body of Knowledge, (online edition), page 5.

2. Ibid, page 5.

3. Ibid, page 275.

Comments are closed.