The Future is Never Certain

September 28, 2008 by
Filed under: Process, Project management 

We can look at what has happened in the past on projects, what is currently
happening, and what is happening in the future. If we are sloppy with our
records, we can easily have different versions of the past. If we are weak in
our communications, we can even have different perspectives of the present. With
care we can avoid both of these issues, but it is safe to say that when we are
looking into the future, we can never be certain of what will happen. This is a
limitation we need to appreciate.

Understand the nature of this uncertainty and we can harness it to our

As we attack our projects, we almost all recognize that the less we know about a
task, the wider the range of corresponding uncertainty should be. The problem
is, though, that most of us will apply an unrealistically small uncertainty to
future estimates, if any at all. We are conditioned to provide a single-point
number when asked for an estimate, and this single point number is usually given
without reasonable consideration for the details of the task. Actually, it is
rarely more than a guess, and we are lucky if it is an educated one.

While the Project Management Body of Knowledge provides some guidance about
ranged estimates, there is little support in telling you how wide a range makes
sense for what you are doing. The reason for this is that uncertainty can vary
dramatically across project domains, across different tasks within a single
project, or for a single task over the lifetime of its completion. Most of the
numbers in the PMBoK show ranges around +-10% or so, and we can easily get the
impression that we’re doing our job if we take our wild-assed guess and slap on
a +-10% caveat on that number. But we couldn’t be more wrong in most cases.

If we have a great deal of experience in building spec houses, we might have
enough historical data to actually estimate cost and schedule within these
narrow ranges and nail our estimates most of the time (and indeed, if we are
within our estimated range 90% of the time with our final numbers, that is
considered a good estimate). Unfortunately, we are not all in the game of
building spec houses, and even fewer of us actually recorded how long it took us
to complete our tasks on our last project.

For technology projects, we are generally at the other end of the spectrum for
uncertainty. We often are tasked to build things we have no experience with, and
don’t have any historical data we could use as a proxy for validating our
numbers. Same thing if we are implementing a PMO for the first time, or building
a fence for the first time, or trying to plan a home renovation. In this
context, +- 10% seems pretty naive, and a single-point number seems downright

So how wide should we go with our range? If we look at what many consider to be
one of the most mature software shops on the planet, let’s look at what the NASA
Software Engineering Lab does. When they are at the end of their requirements
phase (which is after far more analysis than that ‘back of the envelope’ stage
where we are often asked for an estimate), they use a range of +75%, -43%. Why
the precise numbers? These numbers are based on their own precise measurement of
their past performance. They have a solid basis for all of the numbers they use.
Indeed, at one point they do refine their estimates down to around +- 10%, but
that is at the end of the implementation stage on their projects!

Yes, that’s right. Arguably the best software shop around (which also has a
relatively staid hardware environment and management that respects the
safety-critical nature of their product) thinks they are +- 10% with their
estimates after implementation is complete, which is a wider range than most
teams will banter around at the beginning of their project. Let’s turn this
around and ask: how often does your project come in within the original
expectations of scope, cost, time and quality? Really, has it ever?

With reasonable expectations of uncertainty, we can better understand one of the
critical roles the project manager needs to play on the project. A well-running
project team will proactively reduce the uncertainty and risk, and manage
expectations so that successful closure can be safely predicted sooner, rather
than later on the project. Seek out the sources of uncertainty and attack them
first, don’t wait before tackling the big problems. Wrangle uncertainty into
submission, but appreciate the magnitude of the beast to begin with. – JB


Feel free to leave a comment...

  • What’s Happening

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.

    Contact Jim if you would like to connect around any of the upcoming dates:

    • Blissfully at home in Vancouver, BC over the summer!
  • What People are Saying

    The requirements prioritization portion was especially interesting. I can use this next week with a customer directly.

    — Mike Aksmanovic, MDSI Mobile Data Solutions Inc