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.
Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.