Guest post from Susan de Sousa
When you first start off in project management, spending time writing a contingency plan can seem like a complete waste of time. After all there are so many other things which appear to have a much higher priority, that planning contingency for risks which might never happen doesn’t seem like a good use of time.
Contingency Plan? - by Clearly Ambiguous via Flickr
I have to admit that I certainly fell into this category when I first started off, and in fact even having a risk log appeared to be an alien concept. Certainly when confronted by a sub-section of project managers who are process bound and spend an inordinate amount of time raising risks whilst developing ever more convoluted contingency plans, this can seem like a smart shortcut. However I have learned over 13 years of interim project management that project managers who avoid this completely are simply storing up problems for the future.
The key thing to remember is that simply doing this work will not give you any tangible additional benefit, in much the same way that simply having a risk log won’t help much either by itself. What is important is knowing how to raise the potential problems which really matter and then understand which of these could benefit from being mitigated. This is much harder than it sounds. Get it wrong and your whole delivery could be in jeopardy over something minor, which you overlooked.
Therefore the top 2 reasons for contingency planning are:
1. Successful Project Manager’s know that without this work, the delivery effort is essentially running on a wing and a prayer with the PM desperately hoping that nothing unforeseen occurs to derail it. Of course in these cases the worst always does tend to happen.
2. Top notch Project Manager’s know that by being smart and understanding what to concentrate on and prioritize, it is possible to ensure no matter what happens, you as the Project Manager look “good” and in total control of the delivery. This of course means that you as the Project Manager are in the ideal “win win” situation
Of course it is one thing to know that you should do contingency planning, it is a whole different ball game to be able to do it successfully. It is after all, something which is usually extremely time intensive; something which no Project Manager ever has the luxury of.
Therefore you need to really understand how to balance this work and make sure your efforts are effective enough, whilst not jeopardizing the future of the project, because you weren’t spending enough time controlling it.
Check out my-project-management-expert which provides you with all the information you must know in order to effectively project contingency plan, as well as explaining what is contingency planning
Related posts:
{ 37 comments… read them below or add one }
Here’s a thought on this important topic…
http://herdingcats.typepad.com/my_weblog/2009/08/risks-and-issues-are-not-the-same.html
Here’s a thought on this important topic…
http://herdingcats.typepad.com/my_weblog/2009/08/risks-and-issues-are-not-the-same.html
Excellent Susan.
I see contingency as a subset of risk management, essentially the uncertainty arising from unknown risks to your estimates or project schedule.
There are some great methods of trying to quantify the “unknown unknowns” in your project and providing for reasonable contingency based on that uncertainty.
For example I’ve dabbled with some of them using monte carlo analysis with inputs of confidence and range of 3-point estimates on individual tasks, to produce a CDF. The difference between the desired confidence interval and PERT or averaged 3-point estimates is then translated into $$ for management reserve.
I’ve found this to do a decent job of providing a basis for appropriate management reserve for the amount of uncertainty a project team has about their estimates.
Josh,
The classification of “unknown risk” is not delt with in the risk management plan (RMP). The RMP is part of the Project (Program) Management Plan. Here’s a sampel PMP sepo.spawar.navy.mil/PMP_Template.doc
I’d suggest qualififyt UNK UNK is not a waste of time – for the simple reason they are not actionable. Take a look at the work Loch and De Meyer at INSEAD for some of the best guidance on the four levels of risk and uncertainty management.
As well the penultimate book on risk is Conrow’s Effective Risk Management: Some Keys to Success, 2nd Edition, AIAA Press. Most of the stuff floating around PMI is how shall I say “unacceptable.” Look at the DoD Risk Managament Guidebook as well.
As well PERT itself has up to a 27% unfavorable bias due to “merge bias.” Do Not use the PERT formaulas for anything.
We use Risk+ to provide schedule reserve from the “no slack” schedule to the need protect (schedule margin).
Agree with Glen re UNK-UNKs. These are risks that are “unknown as to what, unknown as to when.” By definition, you can’t identify or quantify them. If you can do either, they aren’t UNK-UNKs. The best you can do is have a reserve for them.
Re PERT: two small points. My experience is that many people equate PERT with any kind of range estimating. Technically, PERT is only event-based (not duration-based) schedule estimates. On the other hand, a simulation should reflect the impact of merge-bias.
Bill,
In the orginal PERT formulation and the current implementations in MSFT Project, Primevera, and others the role of the Optimistic, Most Likey, and Pessimistic is DURATIONS of the upper and lower stadn deviations of the Beta curve that was reverse engineered.
The units in the formula Estimated Duration = (O +4ML + P)/6 are durations of the task.
I must be missing something when you say PERT is only event based – not duration based.
I know of now Monte Carlo simulation that “represents” merge bias. David T. Hulett speaks to merge bias on many of his briefings. But tools like Risk+ can “exhibit” merge bias when tasks are in parallel. But I know of now way to “see” this bias in any measureable way from the results of the simulation.
If you know of any references for Riak+ or @Risk for Project, they’d be very useful in our weekly simualtion assessments.
Sorry I wasn’t clear. I was referring to the ORIGINAL PERT approach (see Jim O’Brien’s 1969 “Scheduling Handbook” or Al Battersby’s 1964 “Network Analysis for Planning and Scheduling.” I also have copies of some of the original proceedings from the early 1960s). I realize that PERT concepts today are typically applied to both durations and cost or effort estimates.
I’m not sure what you mean by “representing” merge bias. When running a Monte Carlo simulation, the effects of merge bias should be reflected in the expected durations of any paths affected. I do not believe, however, that there is any way to separate the effects of merge bias from the effects of the underlying duration uncertainties that cause it.
Bill,
I know of no application of PERT to cost in the Earned Value world we work in.
The “merge bias” from PERT unfavorably predicts up to 27% error variance in the completion date. There are a dozen or so papers that define the outcomes.
The merge bias that results from parallel tasks is structural. This is why PERT is not used in DoD and Monte Carlo is mandated in DID 81650.
Glen, that 27% data point for merge bias isn’t industry specific, is it?
It’s industry independent. It’s the topological impacts of parallel tasks with variable duration times. The range is dependent on the PDF applied to each task.
“PERT Completion Times Revisted,” Ted Williams, September 2005, No. 2005-02, School of Management, University of Michigan,
Some further discussion on PERT and it’s problems.
http://herdingcats.typepad.com/my_weblog/2009/08/why-pert-has-problems.html
Excellent Susan.
I see contingency as a subset of risk management, essentially the uncertainty arising from unknown risks to your estimates or project schedule.
There are some great methods of trying to quantify the “unknown unknowns” in your project and providing for reasonable contingency based on that uncertainty.
For example I’ve dabbled with some of them using monte carlo analysis with inputs of confidence and range of 3-point estimates on individual tasks, to produce a CDF. The difference between the desired confidence interval and PERT or averaged 3-point estimates is then translated into $$ for management reserve.
I’ve found this to do a decent job of providing a basis for appropriate management reserve for the amount of uncertainty a project team has about their estimates.
Josh,
The classification of “unknown risk” is not delt with in the risk management plan (RMP). The RMP is part of the Project (Program) Management Plan. Here’s a sampel PMP sepo.spawar.navy.mil/PMP_Template.doc
I’d suggest qualififyt UNK UNK is not a waste of time – for the simple reason they are not actionable. Take a look at the work Loch and De Meyer at INSEAD for some of the best guidance on the four levels of risk and uncertainty management.
As well the penultimate book on risk is Conrow’s Effective Risk Management: Some Keys to Success, 2nd Edition, AIAA Press. Most of the stuff floating around PMI is how shall I say “unacceptable.” Look at the DoD Risk Managament Guidebook as well.
As well PERT itself has up to a 27% unfavorable bias due to “merge bias.” Do Not use the PERT formaulas for anything.
We use Risk+ to provide schedule reserve from the “no slack” schedule to the need protect (schedule margin).
Agree with Glen re UNK-UNKs. These are risks that are “unknown as to what, unknown as to when.” By definition, you can’t identify or quantify them. If you can do either, they aren’t UNK-UNKs. The best you can do is have a reserve for them.
Re PERT: two small points. My experience is that many people equate PERT with any kind of range estimating. Technically, PERT is only event-based (not duration-based) schedule estimates. On the other hand, a simulation should reflect the impact of merge-bias.
Bill,
In the orginal PERT formulation and the current implementations in MSFT Project, Primevera, and others the role of the Optimistic, Most Likey, and Pessimistic is DURATIONS of the upper and lower stadn deviations of the Beta curve that was reverse engineered.
The units in the formula Estimated Duration = (O +4ML + P)/6 are durations of the task.
I must be missing something when you say PERT is only event based – not duration based.
I know of now Monte Carlo simulation that “represents” merge bias. David T. Hulett speaks to merge bias on many of his briefings. But tools like Risk+ can “exhibit” merge bias when tasks are in parallel. But I know of now way to “see” this bias in any measureable way from the results of the simulation.
If you know of any references for Riak+ or @Risk for Project, they’d be very useful in our weekly simualtion assessments.
Sorry I wasn’t clear. I was referring to the ORIGINAL PERT approach (see Jim O’Brien’s 1969 “Scheduling Handbook” or Al Battersby’s 1964 “Network Analysis for Planning and Scheduling.” I also have copies of some of the original proceedings from the early 1960s). I realize that PERT concepts today are typically applied to both durations and cost or effort estimates.
I’m not sure what you mean by “representing” merge bias. When running a Monte Carlo simulation, the effects of merge bias should be reflected in the expected durations of any paths affected. I do not believe, however, that there is any way to separate the effects of merge bias from the effects of the underlying duration uncertainties that cause it.
Bill,
I know of no application of PERT to cost in the Earned Value world we work in.
The “merge bias” from PERT unfavorably predicts up to 27% error variance in the completion date. There are a dozen or so papers that define the outcomes.
The merge bias that results from parallel tasks is structural. This is why PERT is not used in DoD and Monte Carlo is mandated in DID 81650.
Glen, that 27% data point for merge bias isn’t industry specific, is it?
It’s industry independent. It’s the topological impacts of parallel tasks with variable duration times. The range is dependent on the PDF applied to each task.
“PERT Completion Times Revisted,” Ted Williams, September 2005, No. 2005-02, School of Management, University of Michigan,
Some further discussion on PERT and it’s problems.
http://herdingcats.typepad.com/my_weblog/2009/08/why-pert-has-problems.html
I like the basic thrust of Susan’s article, but I am less enthused about the fact that she appears to be using contingency planning as the only option for mitigating risk. Thinking about ways to lower the probability of a risk or lessen its impact BEFORE it turns into a problem are the mark of a competent project manager.
Lowering the probability of a risk or lessening its impact is the basis of risk management. The PM is a participant in this process, but the Risk Management Plan spells out the actions needed to generate those outcomes and the resulting benefits to the program.
Sorry again. I didn’t mean to imply that the project manager does all of the thinking himself or herself. I just meant that the PM is responsible for seeing that this is done.
As to whether or not the PM actually does the work, I think it depends on the size of the effort. For the kinds of large undertakings that you are dealing with, I would agree that the PM is most likely to be just one of many participants. On the other hand, I would hazard a guess that better than 90% of the readers of PM Student are working on projects where the entire project team consists of fewer than 10 people. In those cases, the PM was probably a major contributor to the development of the RMP and thus more than just a “participant.”
True. On my last project, we had a full time risk manager who facilitated the process, and there were many project managers and lead engineers who were engaged in the process.
Most projects, like Bill said, are smaller than this and in those cases the project manager and lead(s) are probably the most involved…although the process should always be open to the entire team.
We did a brainstorming session a few months back to help uncover risks we hadn’t yet been addressing, and included much of the team in that. It was very productive. We not only identified new candidate risks, it also got everyone’s juices flowing in general.
Josh,
In the Risk Management guidance ALL team members are in the risk identification business. Only after identification can classification and handling processes be useful.
Uncovered risks are an Issue.
Just to be clear, I agree. At the same time, it’s unreasonable to put 200 people in an RMB or risk identification session. We did risk management in IPTs as well, but the brainstorming session I was referring to was cross-cutting across elements and disciplines within the project.
I like the basic thrust of Susan’s article, but I am less enthused about the fact that she appears to be using contingency planning as the only option for mitigating risk. Thinking about ways to lower the probability of a risk or lessen its impact BEFORE it turns into a problem are the mark of a competent project manager.
Lowering the probability of a risk or lessening its impact is the basis of risk management. The PM is a participant in this process, but the Risk Management Plan spells out the actions needed to generate those outcomes and the resulting benefits to the program.
Sorry again. I didn’t mean to imply that the project manager does all of the thinking himself or herself. I just meant that the PM is responsible for seeing that this is done.
As to whether or not the PM actually does the work, I think it depends on the size of the effort. For the kinds of large undertakings that you are dealing with, I would agree that the PM is most likely to be just one of many participants. On the other hand, I would hazard a guess that better than 90% of the readers of PM Student are working on projects where the entire project team consists of fewer than 10 people. In those cases, the PM was probably a major contributor to the development of the RMP and thus more than just a “participant.”
True. On my last project, we had a full time risk manager who facilitated the process, and there were many project managers and lead engineers who were engaged in the process.
Most projects, like Bill said, are smaller than this and in those cases the project manager and lead(s) are probably the most involved…although the process should always be open to the entire team.
We did a brainstorming session a few months back to help uncover risks we hadn’t yet been addressing, and included much of the team in that. It was very productive. We not only identified new candidate risks, it also got everyone’s juices flowing in general.
Josh,
In the Risk Management guidance ALL team members are in the risk identification business. Only after identification can classification and handling processes be useful.
Uncovered risks are an Issue.
Just to be clear, I agree. At the same time, it’s unreasonable to put 200 people in an RMB or risk identification session. We did risk management in IPTs as well, but the brainstorming session I was referring to was cross-cutting across elements and disciplines within the project.
Josh, they all don’t have to be in the room at the same time. That’s the role of the risk manager to collect everyone’s candidate risks.
They all don’t turn into risks, just candidates. Only after passing a “smell” test.
But if you don’t have full coverage, you’re not during risk management, you’re pre-filtering the risks.
Hi Guys,
Let me just add something really controversial to this thread. Well what else would you expect from me?
I personally tend not to run any risk workshops at all on my projects / programs because bluntly speaking, it’s not rocket science deducing what the top 10 risks are. Now I know what you’re all thinking is, “well she probably never manages any big projects so that’s OK”. In fact I manage projects and programs which are a minimum of $10m in budget up to $100m, and which have team sizes of 150 or more in various countries.
The reason I’m not a fan of risk workshops is simple. I am brought in to deliver the impossible projects / programs or turn around those which are failing. My clients aren’t interested in risks, which are perceived as being nothing more than excuses. All they are interested in is one thing. That come hell or high water what they want delivered, will be, to the timeframes required. No excuses. No non delivery. They expect you as the person in charge to get it delivered no matter what.
Obviously this appears to be a very different environment from that which you all appear to have worked in. But what surprises me the most is that this “get it in no matter what and hang the risks” attitude is as prevalent at large FTSE 100 or DOW 30 companies as at small ones. In fact it’s even more prevalent at large companies where non delivery to insane timeframes is not an option.
It is for that reason I don’t spend time on Risks. Just on contingency planning for the one’s likely to happen and actively troubleshooting the issues which have occurred.
Just my opinion so don’t all jump on me at once! Remember, much as there are numerous types of project manager so there are numerous ways to skin a cat.
Cheers
Susan de Sousa
Site Editor http://www.my-project-management-expert.com
Hi Guys,
Let me just add something really controversial to this thread. Well what else would you expect from me?
I personally tend not to run any risk workshops at all on my projects / programs because bluntly speaking, it’s not rocket science deducing what the top 10 risks are. Now I know what you’re all thinking is, “well she probably never manages any big projects so that’s OK”. In fact I manage projects and programs which are a minimum of $10m in budget up to $100m, and which have team sizes of 150 or more in various countries.
The reason I’m not a fan of risk workshops is simple. I am brought in to deliver the impossible projects / programs or turn around those which are failing. My clients aren’t interested in risks, which are perceived as being nothing more than excuses. All they are interested in is one thing. That come hell or high water what they want delivered, will be, to the timeframes required. No excuses. No non delivery. They expect you as the person in charge to get it delivered no matter what.
Obviously this appears to be a very different environment from that which you all appear to have worked in. But what surprises me the most is that this “get it in no matter what and hang the risks” attitude is as prevalent at large FTSE 100 or DOW 30 companies as at small ones. In fact it’s even more prevalent at large companies where non delivery to insane timeframes is not an option.
It is for that reason I don’t spend time on Risks. Just on contingency planning for the one’s likely to happen and actively troubleshooting the issues which have occurred.
Just my opinion so don’t all jump on me at once! Remember, much as there are numerous types of project manager so there are numerous ways to skin a cat.
Cheers
Susan de Sousa
Site Editor http://www.my-project-management-expert.com
“Contingency / workaround plans”, or “Exception plan” [3] should be viewed as a stem of the Risk Plan. A bud, which can sprout quickly and strongly, because it has all the information (DNA, if you have a boy who loves biology) is contained in the trunk.
“Contingency / workaround plans”, or “Exception plan” [3] should be viewed as a stem of the Risk Plan. A bud, which can sprout quickly and strongly, because it has all the information (DNA, if you have a boy who loves biology) is contained in the trunk.