Taking on Project Management Myths, Part 4

From the Voices on Project Management Blog
by , , , , , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog


View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Conrado Morlan
Kevin Korterud
Peter Tarhanidis
Vivek Prakash
Cyndee Miller
David Wakeman
Jen Skrabak
Mario Trentim
Shobhna Raghupathy
Roberto Toledo
Joanna Newman
Christian Bisson
Linda Agyapong
Jess Tayel
Rex Holmlin
Ramiro Rodrigues
Taralyn Frasqueri-Molina
Wanda Curlee

Recent Posts

Mix & Match

Agile Evolves

3 Tips to Enhance Your Leadership IQ

3 Tips for Becoming a Better Listener—and a Better Project Manager

Maximizing the Value of Agile

Categories: Risk Management

Part four of my taking-on-the-myths series will challenge our statistically minded segments: the risk managers.
Myth 4: Using Monte Carlo simulations to generate contingency budgets or schedules is an appropriate approach and should be more widely adapted.
Truth: Monte Carlo simulations are needlessly complex and shouldn't be used.
Of the three most common risk analysis methods used in creating a contingency schedule or budget--risk classification, decision tree analysis or Monte Carlo analysis--the latter is by far the most complex, so naturally it has the reputation for being the most robust.
But is it really?
Consider the data points your Monte Carlo simulation driver asks of you: original budget (or duration), one or two "things-going-wrong" alternatives, their odds and costs, and at least one "things-go-great" scenario, with its odds and estimated costs.
This is the exact same data set that would support a single-tiered decision tree analysis, except that the Monte Carlo version invokes a random-number generator to fill in hundreds (or even thousands) of other data points, which can then be used to analyze confidence intervals--at least supposedly.
But all of these other data points are artificial! The ensuing confidence intervals are far from reliable, hoopla notwithstanding.
Myth 3: Risk management is so important to project management that it should be employed throughout the project's life cycle.
Truth: After the baseline is set, formal risk management is pretty useless.
This last assertion is guaranteed to invoke a passionate debate, but consider your personal performance. Do you function better when you are confident or when you are worried? And what does formal risk management bring to the table once the project is underway, other than institutional worrying?
Analyzing ominous trends or performance information indicating a problem in order to head off threats to project success is what project managers do on a daily basis. Spending excess time quantifying those threats doesn't improve your odds of success.
Posted by MICHAEL HATFIELD on: October 27, 2009 01:02 PM | Permalink

Comments (10)

Please login or join to subscribe to this item
Peter Stansbury
I think you are right that myth 3 will spark some debate. By and large I disagree that this is a myth. However there are many angles from which I would agree: having a register packed full of risks is probably no help at all. Certainly packing it with risks such as "project may finish late" (I'm not making this up, it's often there) is totally counter-productive—this sort of uncertainty should be addressed elsewhere (and making a risk entry is not an excuse for failing to project manage).

However there are vital parts of risk management to consider in complex projects, particularly those involving business change, that cannot be covered by a baselined plan. Having identified the key risk events along with their impacts it is vital to monitor for the triggers that might result in the unexpected event occurring. The earlier you react the more options you have (typically).

Finally, however, if you are suggesting that good project managers actively manage risk effectively as a matter of course and just adding a risk manager, a register and some formal process will not help them perform better, then I am once more in agreement.

Shim Marom
Sorry mate, I can stomach your comments re. myth 4 (with some qualifications) but have issues with your conclusion re. myth 3. On a short term project, spending excessive amount of time on risk management is obviously silly.

Long term projects present a different dilemma as circumstances change and the impact of these possible changes needs to be assessed and managed. On one hand you suggest that "After the baseline is set, formal risk management is pretty useless" but on the other hand you propose that "Analyzing ominous trends or performance information indicating a problem in order to head off threats to project success is what project managers do on a daily basis."

Isn't this what risk management is all about? It's not about spending excess time analyzing those threats, but it is certainly about spending the appropriate time analyzing them.


Shim Marom

craig brown
Hi Michael, Let me begin the response on risk.

Constant surveying of the horizon and work in progress to identify risk doesn't engender worry. It's simply paying attention.

If we pick out scope management as a common and problematic example risk; if you take your eye off that ball you'll be in trouble. If you know it's a likely source of problems you can pay attention and solve problems before they escalate.

Al Gubiotti
Can you send to me your complete myths?? Also do you do chapter meeting presentations? These myths would be good for one of our meetings.
Thank you,
Al Gubiotti

Steve Romero, IT Governance Evangelist, PMP
Myth 3: I agree with this myth, but not for the same reasoning you describe. First, it may simply be a matter of semantics. As you imply, Risk Management is absolutely critical when chartering a project. Risks must be aggressively identified and subsequently accepted, mitigated or transferred. Once this is sufficiently addressed, the project can begin. Once initiated, any new risks are actually "issues," because they were risks that were not identified at the onset of the effort, which is a problem. The other issue could be with the initial decision to either accept, mitigate or transfer the risk. Again, once a project is initiated, the Project Manager may find the risk management decision was flawed and that has now created a problem for the project. Which gets me to where I am certain I disagree with you. The only way a Project Manager will determine if there are new risks (which are now actually issues) or if a risk management decision was flawed (which results in a new issue) is if they are aware of what is going on with the project. A project manager's insight into risks and the problems risks create for a project is born of a systematic and rational approach to maintain a sufficient level of awareness that results in the appropriate management and decision-making to ensure project success. This awareness is not necessarily (and I argue it shouldn't be) born of "worry." It is born of the fearless desire to identify and destroy any issue that stands in the path of project success. Steve Romero, IT Governance Evangelist http://community.ca.com/blogs/theitgovernanceevangelist/

PM Hut
I don't think Myth #3 is debunked properly. Even the argument employed, "Do you function better when you are confident or when you are worried?", is not relevant (or maybe I wasn't able to see the relevancy).

Formal risk management is probably overhead, but it's well worth it and it's never useless.

Maureen Gan
It was interesting read on the various responses to this topic. As a practitioner, it is normal that we would apply theory to practice.

At the start of the business need, typically, project or program risks are identified. If these could be prioritized and acted upon, they would be mitigated accordingly once the contract was signed with the customer.

Getting this started at project initiation also gives the project manager a basis to plan and analyse any assumptions or constraints. By doing so, it helps to plan better and to baseline the project.

By balancing on the immediate risks and those that would have a big impact at occurrence, the project manager would monitor and manage the risks during the project execution.

Acting on the top 3 risks would serve to mitigate project failures and assure a comfort level towards meeting the project objectives.

Templates, risk logs, tools and software are means to achieve the objective.

Hope this helps. Your insights have been helpful.

Maureen Gan

José Finocchio Junior
That's completely absurd what the author have written. I wonder how he published the post under PMI site. Should I burn the PMBOK ?????? I completely disagree with the author of the post. MonteCarlo simulation is widely and sucessfully used since second world war for risk management and for contingency sizing.

Farhad Abdollahyan,MSc., PMP, MSP & PRINCE2 Practitioner
Dear Michael,

I haven't seen the rest of your Myth list, but surely and definitely reject Myths No. 3 & 4.

A project, specially large complex one's, may have several phases and you elaborate it progressively. You may have an overall baselined plan in terms of general objectives (scope, time and cost), and a risk log that goes with it, but you should formally review the log at each phase or stage to make sure that the risks identified have not changed (in nature, urgency or size).

I have used Monte Carlo with high success at proposal as well as delivery stages of multi-million dollar deals with ease. Simulations - including Monte Carlo - can be done nowadays using software such as SPIDER Project, @RISK and Crystal Ball (just to mention some) that makes it possible to analyze rapidly large amount of data (say 3.000 or more activity schedules or 100+ Excel lines of data).

The problem with solution is not its data limitation handling, but the real issues lies between the chair and the PC keys and mouse path. If the person entering the data, modeling and analyzing the data is a fool then he continues to be a fool only with a simulation tool that makes him more dangerous!

Brad Edmonds, PMP, RMP
The belief that risk management is pretty much useless once the baseline schedule is firmed up — is a risk.

Risk management has six (6) processes. Monitor and control risks is one of these processes. This process includes managing the project risk to the risk management plan and risk response plans per the risk register. Activities will involve monitor, measure, corrective action, evaluate effectiveness, reassess, and refine. Risk auditing should be part of the risk management plan since risk response audits will certainly play an important part in lessons learned.

Project risk management is not a one-time event. Risk management is throughout the project lifecycle.

Please Login/Register to leave a comment.


"Life is what happens to us while we're making other plans."

- John Lennon