Project Managers are both the victims and the perpetrators of project schedule credibility gaps. This blog explores the nature of these credibility gaps, their causes, and offers some tips to avoid them. In this blog I’ll focus on schedule credibility gaps, but the ideas and arguments apply equally well to cost estimate credibility. This topic is yet another manifestation of the intimate interdependency between Project, Risk, and Knowledge Management that I discussed in an earlier blog.
When I’ve asked Project Managers about how uncertainties in their project environment impacts the way they perform their jobs, they all acknowledge that it plays a huge role. Yet, when I look at the predominately deterministic way that most project managers make and communicate schedule estimates, you’d never know that uncertainty has ever crossed their minds. That statement may seem harsh, but how often have you seen schedule delivery dates expressed in a way that realistically characterizes the likelihood of achieving them?
At an intellectual level, most project managers understand the concepts of best, worst and most likely estimate variability; probability density distributions; and calculated outcome confidence levels. However, we still typically depict schedule completion dates as single-point estimates. We are usually optimistic when we do this, and even if we verbally characterize the date as “success oriented” or “assuming no problems,” what our customers and our management perceive is that it represents the “most likely” outcome. Now of course, intended or not, we’ve set customer and management expectations that are often uniformed and unrealistic and we’ve added risk and additional challenges to the execution of the project. We’ve also set the stage for customer communications problems because of the unpleasant “surprises” that will no doubt arise as some of the unspoken uncertainties transform themselves into real problems that will take time and money to resolve. (for more about this, check out my blog “Striving for No Surprises Project Management.”)
So why do we do this to our customers, ourselves, our project teams and ourselves?
A key personality trait of most Project Managers is that they are strong competitors with strong egos. This can be both a blessing and a curse. They focus tenaciously on their customers and their project objectives and they stand fast in the face of significant challenges to the triple constraint. On the other hand, they are often reluctant ask for help. They will not admit defeat or display a lack of confidence easily, which sometimes means that when they finally do ask for help it’s too late. They would rather fail heroically than to tell their customers that their requirements and expectations are unrealistic and can’t be achieved.
In addition, we humans have a strong desire for the comfort, false though it may be, of deterministic, predictable outcomes. We want root causes that don’t really exist (see my blog “There Is No Root Cause for Project Failure”). Our brains use past patterns to predict new outcomes and we find the notion of variability in those outcomes to be discomforting. Project Managers know there’s variability (it’s a “Known-Unknown”), but instead of taking it on directly, using a probabilistic approach, we continue to quote singular estimates and then add things like schedule buffers, margins and reserves to protect us from the variability. The use of those risk management techniques is perfectly legitimate and an important project management practice, and I’m not arguing against them. What I am recommending however, is that project managers take a more realistic view of the world, embrace it’s uncertainty and variability and never again quote a schedule date or cost estimate that isn’t accompanied by a confidence level that characterizes its likelihood of realization.
So if you want a more credible, executable, customer friendly project schedule, here are a few tips:
• Layout your project tasks, with their durations and the predecessor and successor logic.
• Force yourself and your team to recognize the task duration variability and make worst, most likely, and best-case estimates.
• Define the critical path and it’s variability. Watch out, the variability of the tasks could introduce more than one critical path
• Pick a probability density function that makes sense in your project context. A 3-Point Triangular approach may be all that’s needed for a relatively simple project, or you can use a Normal Distribution and a Monte Carlo calculation tool.
• Calculate the confidence level for various project finish dates along the critical path(s).
• In conjunction with your customer and management sponsor, use the probabilistic information you’ve just developed to:
o Make more informed decisions on project goals and constraints
o Provide rationale for additional resources or resource re-distribution for “schedule crunching.”
o Plan schedule risk mitigation activities
o Apply schedule buffers
o Define improved project execution performance metrics
You are not using the notion of confidence level correctly.
Jake,
I’m sure that you’re correct in saying that I’m not using confidence level in the correct technical manner and I apologize for that. I was trying to communicate that every estimate should be stated with some kind of analytically derived metric to indicate the probability of it’s realization. I’d be interested in hearing more ideas from you on how I could more accurate way of expressing this. Thanks for your feedback.
Don
Great article. I wish more teams would embrace this approach and awareness. To add, I frequently perform detailed monte Carlo risk analysis with my projects and can be a powerful tool if he results are properly assessed ans acted upon. What’s been the most effective though is to take it a step further by modeling in potential contingency paths to high risk areas of he plan. This involves actually adding temporary tasks to the IMS to model the impact of a realized risk. It provides management with a much better picture of what is likely to happen and ways to mitigate it before its too late. It’s been an extremely effective tool for us.
Thanks
Steve
I’d use probability instead of confidence level. The outcome of a simulation would be a probabilistic density curve. Let’s say, as an example, the curve yielded a project timeframe ranging from six month to 14 months, most likely nine. I choose to target 10 months, which may calculate to be in the 60th percentile. This means I have a probability of 60% of achieving 10 months or less, 40% of exceeding it. This being said, I agree with your entire blog. No one estimates like this. Drives me nuts.
Thanks Jake, I really appreciate your insight and feedback on this.
A good article, thanks. Some of my own humble insights:
> In my experience, not all stakeholders like probability functions. In fact, the higher their rank is, the more prone they are to demand one completion date they can count on.
> When determining the amount of confidence that one date reflects, one must bring into account the business environment. We all know there’s a trade off between predictability and project performance (budget/schedule/content). Your working point might not be comfortable (high probability of hitting targets) if your business environment requires lean planning
> The leaner the planning is, the more stress you need to put on:
– Early identification of changes that are not covered by your buffers
– Acting upon those changes quickly, using your toolkit in a way that reflects the weights of the various parameters you can play with
– Communicate very clearly to management
Actually – I think this is where most people fail, as opposed to the initial planing phase.
> I personally think critical path analysis is over -rated at the planning stage. The reason is that in most cases I’ve witnessed, if resources are efficiently spread there are minor differences between more than a few paths, differences that are well within the “noise level” of probability of unexpected issues. OTOH – during the actual execution phase, identifying the critical path de jour and crunching it is a basic and good technique.
my2c
Eyal