Risk Buffers – An Example

“President Bush has said that the economy is growing, that there are jobs out there. But you know, it's a long commute to China to get those jobs.”
                                                                                                - Tom Daschle

In The Schedule – Risk Buffers, the concluding post of a series on developing the well-formed schedule, I glossed over the complexity and details of planning project risk buffers.  I’d like to revisit the topic in more depth over the next few posts.

However, before I go into the complexities, I would like to present a very simple example, one I hope everyone can relate to, to demonstrate the concepts.  You are probably quite familiar with your commute:  you’ve driven it many times and you know what time you have to leave to generally get to work on time.  Even so, most commuters are occasionally surprised by unexpected traffic conditions – weather, wrecks, and road work, for example.  To demonstrate how to determine risk buffers, this exercise will touch on four of the six PMBoK Project Risk Management processes:  Identify Risks, Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, and Plan Risk Responses.

For this example “project” we’ll only have one task:  Drive to work.  My next post will focus on identifying risks, so I won’t dwell on that step here.  For this exercise, let’s say you have these risks:

1.       There could be rain
2.       There could be snow or ice
3.       Ice could be so bad that your office closes for the day
4.       You are low on gas and need to refill before you can make it all the way to work
5.       There could be a wreck that causes a slow down
6.       There could be road work that causes a slow down
7.       There could be road work that causes a detour

(Do you see anything noteworthy about “risks” three and four?  I’ll have more to say about these in my next post.)

Something that is often missed or glossed over is dealing with Opportunities (the opposite of risk threats).  If your task is estimated to a 50% probability, there is as equal a chance of it coming in early as there is it coming in late, so you need to factor in and exploit (or enhance, share or accept) the opportunities.  For example:

8.       Traffic could be very light
9.       There could be a wreck in a location that causes your commute to be lighter than normal
10.   All the traffic lights could hit perfect for you today

The next step is to qualitatively assess the risks.  The objective of this step is to determine those risks you are going to seriously pay attention to – those that you will quantify, determine the risk response, and monitor.  It is generally done by assigning subjective Low, Medium and High values to probability (the likelihood that the risk event will occur) and impact (how the project is affected if the risk event occurs).  For example, if it’s August, the likelihood of snow or ice (risk #2) is Low.  From this analysis you generally then disregard the Low-Low risks (though note that these values can change over time, so you must periodically re-asses your risks).

The list is now winnowed down to the select risks that will receive attention.  Determine a specific (time, money or both) cost to the project for each remaining risk (including opportunities) if it occurs.

Most of what I read at this point talks about mitigating the risks, but there’s a lot more to risk response than just mitigation.  For example, add tasks to the project (such as check the weather or turn on the radio to get a traffic update).  In addition, risk responses can be transfer (ask a colleague to be there for you in case you can’t get there in time), avoid (reschedule to another day when it won’t rain) or accept (add the time and cost to the schedule).

Finally, and where this has all been leading up to, is to add a risk buffer to the project as part of the risk response.  For example, if there is a 25% chance that a risk will occur that will add twenty minutes to the commute, then you would add a five minute risk buffer to the project (in our example, you would plan to leave five minutes earlier).  You would sum the values for each appropriate risk and opportunity and add a buffer for the total amount.

With this step, you have again increased the probability of getting to the office on time – er, that is, of completing your project on schedule.

I’ll be delving deeper into risks over the next few posts using this example to demonstrate the concepts.  What about risks – threats and opportunities – would you like to understand better?

© 2013 Chuck Morton.  All Rights Reserved.

The Project Manager’s Cycle – Review Risks & Mitigation Actions

“Jack, we’ve allocated five days in the plan for you to review each of the major deliverables,” Alice, the Sr Project Manager, explained to the Executive VP (HR), during the schedule review.  “If you can complete those reviews and provide signoff within three days, we have the opportunity to knock two weeks off the schedule.  However, if you take longer, that will push out the Go Live date.”

With this post, we reach the midpoint of The Project Manager’s Cycle where this action and the next few actions are deceptively easy to describe, but are considerably more complex to practice.  As a reminder, this series describes the Monitor and Control activities that the project manager repeats each project reporting cycle.

Project Risk Management is, of course, a process documented in A Guide to the Project Management Body of Knowledge (PMBoK) and includes the Monitor and Control Risks activity.  The activity I’m describing in this post is similar to the PMBoK equivalent.  At its simplest, this activity assumes risk identific-ation, quantific-ation, prioritize-ation, and mitigatin-ation have been done and all you do is “process” the risk mitigations assigned to you on the risk register and follow up with others to make sure they are “processing” the risk mitigations assigned to them.

But as someone I admire would say, that’s not “the way of the project manager.”  It’s certainly not all that is required for a best practice.  For example, as you review the risk mitigation actions assigned to you and you get others to review the actions assigned to them, you naturally reassess the risk itself and the risk response;  if anything has changed (assumptions, probability, or impact, for example), then you transition into risk analysis or risk response planning.  Further, processing the risk response actions works best as a team exercise, and a superior project manager will involve all appropriate stakeholders in the activity.

If risk response is required, take appropriate action.  For a seasoned project manager, this means delegating any product work.  Also follow up with everyone else who has a risk response action assigned to them.  Verify their action plan, determine status and issues affecting their risk response, and gently nudge them if necessary.

 If there is an effect on the project, then consider use of contingency reserves (risk buffers), escalation, or project change management.

Have I left anything out?  What else is in your cycle of weekly activities for reviewing risks and risk responses?