One of the most difficult aspect to project management for some individuals is the act of estimating work. Some people are born with it, some acquire the skills and confidence and others never really get it. You have to know your limitations.

Below is another section from Gary Heerkens’ brief case book entitled “Project Management.” This section provides a basic guide to estimating work on a project and covers some common issues with estimating project tasks.

An Introduction to Estimating

Estimating is a big part of project planning. To prepare an accurate, thorough project plan, you’ll need to estimate many things: how long it will take to do the work, how much the work will cost, how much money the project will save or make, the magnitude of the risk and uncertainty involved, and other aspects of the project. With that in mind, it’s worth taking some time to discuss the process of estimating as a subset of planning.

It’s Just a Guess

Estimation Process

Webster defines estimating as “determining approximately the size, extent, value, cost, or nature of something.” As many experienced project managers will gladly tell you, the operative word in that definition is approximately. The nature of project work is such that—even with significant prior experience—the uncertainty inherent in projects simply does not allow for absolute precision in estimates. Yet many people won’t understand this point. And as you manage more and more projects, you will find this to be an issue with some people: they’ll expect more precision and certainty in your estimates than you’re able to provide. Consider this an opportunity to help them learn, to help them understand that, despite your best efforts to provide good estimates, “It’s just a guess, for Pete’s sake!”

Estimating Approaches

OK, so an estimate is essentially a guess. But what can you do to make it the best possible guess?

Here are five methods for obtaining estimates:

  1. Ask the person responsible for doing the work to prepare the estimate.
  2. Ask a subject matter expert—a person with knowledge or experience in that area.
  3. Use historical data and make appropriate adjustments.
  4. Use mockups, trial runs, tests, field studies, or other simulated experiences as a guide.
  5. Prepare the estimate yourself.

Although all of these approaches are valid, some will work better than others. The best approach will depend upon factors such as the availability of historical data, the estimating skills of task performers or subject matter experts, and the amount of time available to prepare an estimate. You may want to try more than one approach, then use your judgment to come up with the best estimate. Remember: estimates should reflect what you believe to be the most likely outcome. Don’t be afraid to apply your own judgment to the input you receive, as long as you have a rational reason to do so.

Estimating Pitfalls

Estimating is difficult. There are many things that can undermine the accuracy or validity of your estimates. Among the most common pitfalls are the following:


  • Poorly defined scope of work. This can occur when the work is not broken down far enough or individual elements of work are misinterpreted.
  • Omissions. Simply put, you forget something.
  • Rampant optimism. This is the rose-colored glasses syndrome described previously, when the all-success scenario is used as the basis for the estimate.
  • Padding. This is when the estimator (in this case almost always the task performer) includes a factor of safety without your knowledge, a cushion that ensures that he or she will meet or beat the estimate.
  • Failure to assess risk and uncertainty. As mentioned earlier, neglecting or ignoring risk and uncertainty can result in estimates that are unrealistic.
  • Time pressure. If someone comes up to you and says, “Give me a ballpark figure by the end of the day” and “Don’t worry, I won’t hold you to it,” look out! This almost always spells trouble.
  • The task performer and the estimator are at two different skill levels. Since people work at different levels of efficiency, sometimes affecting time and cost for a task significantly, try to take into consideration who’s going to do the work.
  • External pressure. Many project managers are given specific targets of cost, schedule, quality, or performance (and often more than one!). If you’re asked to meet unrealistic targets, you may not be able to fight it, but you should communicate what you believe is reasonably achievable.
  • Failure to involve task performers. It’s ironic: an estimate developed without involving the task performer could be quite accurate, but that person may not feel compelled to meet the estimate, since “it’s your number, not mine,” so the estimate may appear wrong.

Contingency: The Misunderstood Component

There are a number of technical definitions for contingency— basically, any time, money, and/or effort added to the project plan to allow for uncertainty, risk, unknowns, and errors. However, I’ve always found it better to describe contingency— and its proper use—in common terms and using logic. So close your eyes and imagine .... (But keep reading!) You’re at the very beginning of a project. You cannot possibly know how everything will turn out. There’s just too much uncertainty and risk ahead. However, you’re required to come up with an estimate that represents your best attempt at predicting the final outcome of the project, most notably in terms of cost and schedule.

A powerful combination of your knowledge of the project, your sense of what you don’t know, your experiences on previous projects, the documented experiences of countless other project managers, and some good old-fashioned project manager judgment of your own leads you to the conclusion that an estimating shortfall exists. In other words, there’s a gap between the sum of your individual work element estimates and where you know you’ll end up at project completion. This gap is created by your inability to understand exactly how to synthesize all of the uncertainties. According to traditional project management practices, the gap is supposed to be plugged using—you guessed it—contingency.

And now the real world ....

There’s relentless pressure to do things faster, cheaper, and better—sometimes unrealistically so. And there’s a general lack of understanding of what contingency is supposed to represent. And finally, there’s the perception by some that contingency is really a slush fund for mistakes, as it’s typically modeled as something tacked onto the project bottom line. Help has arrived, however, and I’d strongly urge you to use it. There are software products that use statistics to help you calculate contingency to accommodate risk, uncertainty, and unknowns in a relatively painless manner. Although there are some slight differences, most work the same way. You provide ranges of possible outcomes for individual elements of work. The tool then simulates the execution of the project as many as one thousand times. The outputs associate a range of project outcomes correlated to various levels of confidence (confidence in your ability to meet or beat that particular outcome).