Estimating part 1


I once worked with a client that made equipment for commercial aircraft. Their business model was similar to that of today’s inkjet printer manufacturers - give the product away and make your money selling supplies. While they didn’t quite give their products away, they did make most of their money by selling parts, spares, and service agreements to the airlines.

This client was also an early proponent of Six Sigma approaches and thus quite sensitive to financial issues. During a management presentation for an important new product, their financial analyst noted that the cost of the initial design and development project would have to exceed its budget by more than 100% before the return-on-investment calculation would be affected!

But their project manager didn’t take this as a license to spend money. Rather, he understood the real import of the message - when faced with trade-offs among cost, quality, schedule, and features, he could afford to spend more money in order to meet the stakeholders’ needs in the other areas. This project manager understood that his cost baseline was not carved in stone; that it was yet another tool to help him communicate with and satisfy his stakeholders.



Many of the terms related to estimating are used either inconsistently or imprecisely. Before we get started on the “how to” of this article, let’s take a minute to establish some common terminology.


An estimate is an informed assessment of an uncertain event. Informed means that you have an identified basis for the estimate. Uncertain recognizes that multiple outcomes are possible. For example, if I tell you that there are two people standing outside the door, that one is male and the other female, and that one is 6’ 7” (200 cm) tall and the other is 5’ 2” (158 cm) tall, which would you predict is the female?

Most people will predict that the short person is female. Most people will make an informed assessment of this uncertain event based on their knowledge that men tend to be taller than women, that few women are as tall a 6’ 7”, and that few men are as short as 5’ 2”. But what if I said the woman was a professional basketball player and the man was a horse-racing jockey? Most people will now predict that the tall person is female.


A guess is a special kind of estimate—one where we do not have enough information to make an informed assessment. Note that in the above examples I used predict rather than guess since you do have enough information to make an informed assessment. For example, if I asked you to predict which person outside the door was taller, the person on the right or the person on the left, you would be forced to guess. In my experience, it is rarely necessary to make a true guess when estimating effort for a project.


Effort is an expenditure of physical or mental effort on the part of a project team member. We almost always measure effort in terms of staff hours. In many domains, most project estimates will be effort estimates. If you purchase resources from outside your organization, you may not see the effort estimates that were used to develop cost estimates, budgets, and prices, but they’re there somewhere.


Cost is a measure of resource usage - employees and contractors must be paid, equipment must be bought or rented, and so on. Cost is usually expressed in monetary terms (dollars, euros, renminbi, etc.), but it can also be expressed in terms of hours of effort. One advantage of using monetary units instead of effort hours is that it should make comparisons between projects or among activities on the same project easier.

Another advantage of using monetary units to express cost is that the financial people in your company understand the language of money. One disadvantage is that monetary units can distort the numbers if the hourly rates are not reasonable. For example, if you use a rate of $100 per hour for an employee making $50,000 per year, and the same $100 rate for someone making $150,000 per year, your numbers will misrepresent the actual cost of any project that has a preponderance of effort from one or the other.


A price is what you charge someone for something. Prices are always (well, almost always) expressed in monetary units. Prices can reflect rates (e.g., $100 per hour) or totals ($5,000,000 for the entire project).

Pricing is a business decision. It is usually derived from the estimate, but the estimate is not the price - if we are selling products or services to someone, we can charge more or less than our estimated costs. Even if we know for certain what the costs are or will be, we can still charge a different price.

In my articles on estimating, I’m going to assume that most readers are either managing internal projects (new product development, information systems, process change, etc.) or developing estimates in order to support a pricing decision that will be made by someone else (as is often the case for project managers working for a consulting firm). As a result, I am not going to cover pricing past the point of defining it.


A budget is a management control or metric (I prefer the term metric since control has negative connotations to some). A budget is a type of plan. Most people use the term only with regard to monetary metrics, but you can have effort budgets or schedule budgets as well. Project budgets should be derived from the project estimates.

Project budgets are not absolutes! Or at least they shouldn’t be. If a project is budgeted for $1,000,000, all of the stakeholders should understand that that number is a target. It is what the team expects to spend based upon what it knows today. If the team can find a way to spend less and still deliver all of the scope, it should do that. If it needs to spend more, that should generate a discussion with the funders to decide what to do.

The project budget is not the same as the project price, even for a project done under contract. The supplier can price the work for an amount that is different from its internal management metric.


A baseline is very nearly a synonym for budget. There are two subtle differences.

First, project baselines are normally time-phased. While I might say that the budget for my project is $500,000, I wouldn’t really have a baseline unless I had also defined when I expected to spend that money - how much in week 1, week 2, and so on. Second, the term baseline implies some level of formal approval. I can prepare a budget for an activity or a project, but it isn’t really a baseline until the appropriate stakeholders have agreed to it.

Estimating is a forbidding topic for some. I’ve even heard intelligent, experienced project managers assert that it is “impossible” to estimate the work on their project. I think that these people just don’t understand estimating.

I think that these people may be confusing estimating (making informed assessments of uncertain events) with extra sensory perception (making exact predictions of uncertain events). Or in some cases, they may be trying to prepare budgets or prices in the absence of estimates.

I know that accurate estimates are possible. I have done it myself (one of my projects had a most likely estimate of 1,300 hours of effort and was completed for 1,302 hours), and I have taught thousands of others to do it as well. Recall Clarke’s Law: any sufficiently advanced technology is indistinguishable from magic.

Good estimating is a skill like any other—it can be developed with practice to the point where it may seem like magic to the uninformed. In the following articles in this series, I will cover the mechanics of how to estimate effort and how to deal with some of the more difficult challenges of estimating on projects.


Please consider allowing cookies to be able to share this page on social media sites.

Change cookie settings
No history has been recorded.
Back to top