Estimation is an important skill required by many professionals. My experience is that there are three distinct levels of how people think of estimates. My goal is to focus on the third level, estimates as probability distributions, in this blog.

Let’s begin with a quick overview of the three estimation mindset levels:

**Estimates as point-specific numbers**. For example, a point-specific estimate would be that this is a million-dollar project that will take six months to complete. In the case both the cost and time estimates are fixed, scalar numbers. This mindset often stems from a desire to have an “exact number” on which to base decisions.**Estimates as ranges**. An example of a ranged estimate is that this project will cost between $800,000 and $1.4 million and take between 4 and 10 months to complete. In fact, PMI’s Practice Standard for Project Estimating (2^{nd}Edition) suggests that a project in the start-up phase, what Disciplined Agile (DA) calls Inception, may have a rough order-of-magnitude (ROM) guesstimate of -25% to +75%. On software projects, Barry Boehm has found that -75% to +300% occurs in practice (see Software Engineering: Barry W. Boehm's Lifetime Contributions to Software Development, Management, and Research). Yikes. This estimation mindset often stems from discovering that “exact” estimates often prove to be unrealistic in practice and as a result they need to be more flexible in practice.**Estimates as probability distributions**. This is an evolution of ranged estimates in that it reflects the observation that there is a chance that a project will come in below budget (or early) and that there is a chance that a project will come in over budget (or late). This is a strategy that I first learned from Murray Cantor, author of Software Leadership, when I worked with him at IBM Rational. This estimation mindset tends to be held by people with a strong background in mathematics, in particular statistics.

Figure 1 depicts an estimate as a probability distribution. It shows a point-specific/fixed estimate, such as $1 million, which is aligned with the peak of the curve. The area under the graph to the left of the fixed estimate point is the chance that the project will come in under budget and the area to the right is the chance that the estimate will come in over budget. This probability curve would be determined from past history of previous projects within your organization. The curve in Figure 1 is “positively skewed” in that there is more area to the right of the curve’s peak than to the left. The implication is that there is a greater chance of the project being over budget than there is of it being under budget.

**Figure 1. Estimates as probability distributions.**

Let’s work through how you actually apply this knowledge in practice. Figure 2 shows an estimate distribution for a fictional project where we are quoting estimates in terms of probabilities. For example, the chance that this project will come in at $900K or less is the area under the graph to the left of that line, in this case it looks like it’s about 8%. The chance that it will come in at $1M or less looks to be about 22%, $1.1M or less about 45%, and $1.2M or less about 65%. The implication is that depending on the level of certainty your stakeholders require you can use this graph to provide an estimate that meets their need. If your stakeholders wanted 95% surety, for example, then you’d find the point on the estimate distribution where 95% of the area is to the left of the line, in this case it looks like it would be around $1.5 or $1.6 million. This would be a lot easier, of course, if you were using software to come up with these sorts of numbers rather simply "eye-balling" a graph. Once again, all of these numbers are based on the past history of previous projects within your organization.

**Figure 2. Quoting estimates as probabilities.**

There are several challenges with the concept that estimates are probability distributions:

**Many people don’t understand the concept of probability**. For example, I just opened the weather app on my phone and it says that there is a 70% of snow this hour. So, if it doesn’t snow in the next hour is the app right or wrong? It’s right, because there was a 30% chance that it wouldn’t snow. But what if the app said there was a 90% chance that it will snow, but then it doesn’t? The app was still right. The point is that many people will hear a probability such as 70% or 90% and assume that it’s a certainty (100%). Conversely, they’ll hear that there is a low probability of an event and then assume that it won’t happen and won’t be prepared if it does.**People who desire “predictability” don’t like this idea**. There are still people who prefer the “certainty” of a point-specific estimate, or at least an estimate with a very tight range. While these expectations might be reasonable on straightforward projects they certainly aren’t on projects where stakeholder needs or implementation strategies evolve constantly (as is typical on software projects, for example).**Estimates don’t follow a normal bell curve****distribution**. As I indicated earlier, estimates tend to follow a positively skewed distribution. This is the result of overly-optimistic estimation or pressure to produce an estimate that is palatable to decision makers. This positive skewing can be frustrating for many people because the implication is that you’re more likely to be over budget or late than you are to be under budget or early respectfully.

In the next blog in this series we’ll work through the strategy of ranged estimates in greater detail.