Estimating time in a single, fixed number (single-point estimation) is a popular practice, yet it has several interrelated and detrimental effects on project outcome. Estimate padding, estimate negotiation, and delayed resolution of uncertainty are all made worse by the use of single-point estimates. This article examines the chain of cause and effect in each of these behaviors and suggests that estimating in ranges can produce significantly better project outcomes.
What is an Estimate?
|
Estimating Using Ranges
While informally polling people about how long it takes them to drive to work, the author has often received responses such as “twenty minutes to an hour if the traffic is bad.” That is a factor of three difference between the best and worst case estimates.
This is for a commute that the estimator knows precisely. A commute he has likely driven hundreds of times.
Should we expect the range of best case and worst case to be any less for a task which is seldom performed?
No, we should look with suspicion upon an estimate with any smaller range.
|
A dictionary definition of estimate: 1: the act of appraising or valuing. 2: an opinion or judgment of the nature, character, or quality of a person or thing . 3a: a rough or approximate calculation. 3b: a numerical value obtained from a statistical sample and assigned to a population parameter. 4: a statement of the cost of work to be done. (Merriam-Webster Online Dictionary, 2008)
This article compares two different types of estimates: single-point and ranged estimates. A single-point estimate is a fixed estimate of time, such as two days or one week. A ranged estimate, on the other hand, is a range of time, such as 2-4 days or 1-2 weeks. Ranged estimates provide a best and worst case scenario for when the task will be completed.
It is a popular misconception that ranged estimation lacks accountability or in some way implies freedom to just “get it done whenever you get it done.” This misconception is perpetuated by outdated project management tools that lack the ability to calculate schedules based on ranged estimates, and therefore force the user into single-point estimation. From this failing comes all manner of project ills.
An estimate is really just a statement of probability. An estimate is deemed “good” if the actual result falls within the expected range of outcomes. But the purpose of an estimate is not prediction.
The primary purpose of estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them (McConnell, 2006).
That is, good estimates do not need to be perfect predictors. Rather, good estimates need to give the project manager enough visibility to control the project and meet business objectives. As will show be shown, one critical aspect of visibility is the ability to see the amount of uncertainty in a given estimate. This is impossible using single-point estimates.
Single-Point Estimates and Padding
When you give a single-point estimate (SPE) you are saying, “I think it will take less than X amount of time to complete this task.”
In this sense, single-point estimates act like promises. You are making a social contract to get the work done in less than the estimated time. Since most of us make promises with caution, you most likely add a buffer and estimate high. In other words, you pad your estimates. And yet, even with padding in the schedule, projects are continually late. How can this be?
A padded estimate provides a false sense of security, making it tempting to either expand the scope of work (Parkinson’s Law) or put the work off until the last minute, known as Goldratt’s Student Syndrome (Goldratt, 1997). Both of these leave you with little or no risk buffer when something goes wrong. You padded your original estimate expressly so you could still recover if something unexpectedly went wrong. But now, with little or no buffer remaining, Murphy’s Law
|
Targets vs. Estimates
A target is a biased business objective. It motivates the seeking of a business goal. An example of a target is, “We want to have the corporate re-branding completed by May so our new branding hits the peak sales season.”
An estimate should be an unbiased, analytical approximation. An example of an estimate is, “We think it will take 3 to 5 months to complete the corporate re-branding if we include all of the listed items.”
Both targets and estimates are necessary and good. It is important to understand the distinction between them since confusing one for the other leads to poor communication between the project team and the business stakeholders.
|
strikes, something goes wrong, and you end up late.
Ranged estimates offer much more flexibility. With a ranged estimate, you naturally feel less need to pad the estimate because you are not locked into a single promise date. It is clear from the outset that you are not promising to complete the task in the shortest possible time. Rather, you are committing to get the task done sometime within the low and high range of the estimate. If you consistently finish tasks near the top of your range, then you need to increase the size of your estimates in general. Likewise, if you consistently come in near the bottom of the range, you can safely decrease the overall size of your estimates. In this way, ranged estimates become a valuable project planning tool. And because they reflect how most people naturally think and work, ranged estimates are more realistic.
Single-Point Estimates and Estimate Negotiation
The second problem with single-point estimates is that they are almost always inaccurate. It’s plain to see, actually, but the world of project management has ignored this fact. For example, if someone says it will take two days to do something, it is very unlikely that it will take exactly two days. It may take a little less time or it may take a lot more time, but you can be quite certain that it will not take exactly two days.
Since a single-point estimate is most likely both padded and inaccurate, it is not only hard to trust, it is open to negotiation within teams. Negotiation of task estimates seldom results in a larger estimate because the project manager’s need is to keep the schedule ahead of or on time. So, more often than not, single-point estimates get negotiated down until it cannot be proven impossible to complete the task in the allotted time. This is sometimes referred to as “the least defensible estimate” (McConnell, 2006). Estimate negotiation usually ends up reducing or eliminating the risk buffer; with little or no buffer, again Murphy ’s Law strikes and you end up late.
Estimating in a range changes the dynamic of the negotiation. While the best case scenario, or the low end of the estimate, remains easily negotiable, the worst case is hard to argue (provided that it is reasonable and well thought out). Additionally, by using a range for the estimate in all documentation, a clear distinction is made between the estimate and the goal or target. This distinction can lead to earlier identification of projects that are unlikely to meet business goals. And if the project is unlikely to meet the goals, then scope changes, additional resources, or time on the schedule can be built into the project plan before it’s too late.
Single-Point Estimates and Hidden Uncertainty
The third problem with single-point estimates is that they obscure uncertainty. When given an assignment composed of both well-defined, cut-and-dried tasks and ill-defined, nebulous tasks, it is likely that the well-defined tasks will be worked on first, given our natural tendency to want to “get something done.” While this inclination seems only reasonable, the desire to get to work and start checking tasks off your project list can inadvertently lead to missed deadlines. When you start with the well-defined tasks, putting the more nebulous tasks off until the end, you may end up with a shortfall in your buffer at the tail end of the project. And the risk may go undetected if there is no way to measure and report the existence of uncertainty in the project schedule.
Here’s a closer look at how uncertainty plays out in the project plan.
Ill-defined tasks are full of uncertainty. When you defer these tasks until late in the project, whatever risk buffer you have remaining is likely too small to accommodate the uncertainty. But because uncertainty is virtually impossible to detect when using single-point estimates, the project manager is often completely unaware that the schedule is very likely to slip, even if common sense says it is so. Since, in this scenario, you are unaware that you need to adjust your schedule to retain sufficient risk buffer, you end up with little or no buffer, Murphy strikes, and the project is late.
Had you used ranged estimates, the uncertainty would have been evident, allowing you to adjust the plan and avoid painful project delays.
There is a big difference between two tasks that have both been estimated to take on average 4 
days when one estimate is 3-5 days and the other is 1-7 days. Most notably, the 1-7 day estimate holds a much greater degree of uncertainty than the 3-5 day estimate. The ability to see this difference provides valuable insight that helps drive your decisions. You can begin to look at lingering uncertainty in a schedule or plan as what it is; added risk. The real value is that once you can observe the uncertainty, you can begin to control it as well. Tasks with a lot of uncertainty can be pulled forward in the schedule so that if something goes wrong, there is still time (the essential buffer) left in the plan to recover.
Notice that all of these project scenarios lead to Murphy’s Law. Each starts with a single-point estimate and, through various paths, ends up being late. All of them rely on something unexpected going wrong. But even if nothing goes wrong with an individual task, single-point estimates play another role in late projects, when multiple tasks are being worked on by multiple people at once (parallel work streams).
Load Balancing and Single-Point Estimates
Parallel work streams lead to load balancing, or the equal distribution of work among team members. It is smart project management to load balance wherever possible to make sure all resources are being utilized effectively. However, the practice plays out poorly with single-point estimates.
Let’s think about it in terms of a real project plan. When a deadline is looming and one person is overloaded and likely to come in late, the best thing to do is redistribute some of that person’s work to others on the team. This results, ideally, in all work streams being well balanced and finishing up at nearly the same time.
However, even though individual work streams will finish around the same time, the project is not likely to finish on time because of the interaction of single-point estimates. To illustrate, let’s look at how a classic project management tool schedules a completely load-balanced project plan.
Project X consists of 100 days of work effort divided evenly among ten people. Because we want it to be perfectly load balanced, we have given each person 10 days of work.
The schedule for Project X looks good on the surface, but at closer glance, and in reality, two main assumptions of the schedule are highly unlikely:
- Each individual will finish all of their tasks in 10 days.
- The project will finish in 10 days (because each person will be finished).
In order to understand why this is unlikely in reality, we must delve even deeper into the role of uncertainty.
When we created the schedule using single-point estimates, we were conservative and estimated high at 10 days. Still, it is unlikely that every person on the project will finish in 10 days because of inevitable uncertainty in every task and plan. The single-point estimate schedule doesn’t allow us to see this uncertainty, so we forge ahead, blindly following the schedule even when our intuition tells us it won’t work.
Using ranged estimates provides a different scenario. Suppose, instead, that each person will finish their tasks in 5-10 days 80% of the time (an 80% confidence estimate). That means that of the 10 people on the project, you expect two, or 20%, of them to finish their work either sooner or later than this estimate. In the best case, your people are accurate estimators and one of them finishes early. You are still virtually guaranteed that at least one of them will finish late.
This is one reason why projects planned using single-point estimates rarely finish on time. It is not a problem of any one person being a bad estimator. Rather, it is an effect driven by underlying uncertainty and its effect on parallel work streams.
In the single-point estimate scenario, the schedule reflects no uncertainty and says that everyone will finish in 10 days. In the ranged-estimate scenario, the difference is that we have set the best case estimate to be earlier at five days. Common sense would say that this should move the project timeline in rather than pushing it later, but it does just the opposite. Adding more parallel tasks makes this effect even more pronounced.
This is a really exciting result!
It is exciting because even if we were managing projects well, our math was off so it’s no wonder things ended up late. The tools we use can cause project failure by forcing us to use single-point estimates.
Conclusion
Many project management tools rely solely on single-point estimates. This article has shown that single-point estimates can have multiple detrimental effects on project schedules. Avoiding single-point estimates by simply giving estimates in ranges can improve the accuracy of schedules as well as the communication and interaction between project team members and project stakeholders.
Estimating in ranges helps to avoid:
- unnecessary padding of estimates and schedules
- negotiation over every estimated task
- masking of uncertainty in project schedules
- unintended detrimental effects of load balancing
Bibliography
Brooks, F. (1975). The Mythical man-Month. Addison-Wesley.
DeMarco, T. (1982). Controlling Software Projects. Prentice-Hall.
Goldratt, E. M. (1997). Critical Chain. North River Press.
McConnell, S. (2006). Software Estimation: Demystifying the Black Art. Microsoft Press.
McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.
Merriam-Webster Online Dictionary. (2008).
Project Management Institute Standards Committee. (1996). A Guide to the Project Management Body of Knowledge. PMI.
Bruce P. Henry, Director of Rocket Science. Bruce earned his title by completing an undergraduate degree in math and both undergraduate and master’s degrees in physics. After sensibly deciding not to complete yet another degree, his doctorate, Bruce began his technology career as a Software Test Engineer for Microsoft. He later joined Expedia as a Software Test Lead, moving up through the ranks to serve as Director of Release Technology and, ultimately, Senior Director of Quality Management before joining former colleagues Charles and Jason at LiquidPlanner. An experienced software development executive, Bruce has a keen interest in entrepreneurial ventures, startups, and building high-performing teams. 3/09