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
advantage.

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
ludicrous.

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

If you enjoyed this post, make sure you subscribe to my RSS feed!

Comments

Feel free to leave a comment...





  • Search by Topic

  • What’s Happening

    September 15, 2016: Thanks to the Vancouver chapter of the IIBA for inviting me to present a talk about Real Analysis agility - the bottom line is thoughtful application of effective analysis over Cargo Cult application of the latest fashionable approach! - fabulous interaction, great feedback!
    November, 2016 - A workshop series to help you develop resilience in the workplace and in your life!
    Next open enrolment sessions start soon - contact us to get involved!
  • 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:

    • March 1-3, 2017 - Winnipeg, MB
    • March 6-8, 2017 - Edmonton, AB
    • March 15-17, 2017 - Victoria, BC
  • What People are Saying

    I learned a lot from Jim, and will always be grateful to have had him as instructor and client. Jim’s class lectures reflect how knowledgeable and well rounded he is – as a person, software developer, and project manager. As a client, Jim is great because he understands the issues that obscure most projects. He made sure we both achieved our goals. It will always be a pleasure working with him.

    — Donabel Santos