Cost Estimation Summary

This page is derived from the Cost Estimation audio available here and transcribed here.


Cost estimates will probably be a large part of your job. If you ever run a business or go into management, you're going to be making cost estimates quite frequently. This is because estimation of costs is extremely important for making financially sound decisions when you're managing a business.

Cost estimates aren't just about installation costs — you need to estimate the entire cash flow of the project. You're going to find yourself actually making quite a few estimates of cash flows just like we've been doing with the income and cash flow statement. These estimates are important for analyzing and comparing options to make sure that the financial details work out. Eventually you may end up making a spreadsheet that will allow you to quickly see how the cost details of a proposed project will work out.

There are several levels of estimates that you will be using. They differ greatly in the cost and effort you need to put into them and also in the amount of uncertainty of the information they generate.

Three levels of cost estimates

Rough cost estimates

Rough estimates are for the early stages of estimation. They're the type of estimates that you can literally do on the back of an envelope or in a quick little spreadsheet. The idea is that these are supposed to be really cheap rough cuts — what you approximately think it's going to cost.

My favorite example of this one is that I know (from my survey research) that a survey response is going to cost about $40. That's what it's going to cost for a phone survey. The real numbers will bounce around as you change the length of the survey, the number of responses, and the number of open-ended questions as opposed to closed-ended questions. But I know that this figure is a decent estimate for many surveys.

There's always going to be a large amount of uncertainty with these, commonly 30-60%. The uncertainty will be smaller if you always make cost estimates of a certain type. But the uncertainty can't be too low because there will always be things you don't know about a given project.

The other thing about these cost estimates is that they are classically going to be a little bit on the low side. The main principle is that you won't normally forget something that saves you money. Instead, you tend to forget things which cost you money in some way you didn't think of. For example, there may be an extra part that you needed to buy or an extra person that you needed to hire. You didn't realize that you needed them. That's why we have contingencies.

Semi-detailed cost estimates

Semi-detailed cost estimates are the second level of cost estimates. These are estimates where you've put a little more effort into determining the costs than you did with the rough cost estimates. You might have some actual bids to give you a better idea of the actual figures. Or perhaps you've gotten one of your regular contractors to consider your plan. The idea is that you'll be doing this in your early detailed design phases. Uncertainty is typically a little bit smaller than with the rough cost estimates, but it is still greater than with the last level of cost estimation, which is the detailed cost estimate level.

Detailed cost estimates

The most detailed level of cost estimates is that of the detailed cost estimates. These are normally done when you're at the detailed design stage. They're normally done when you have contracts, blueprints, and quotes. Typically the uncertainty is in the 3-5% range, but even with this low level of uncertainty you still have contingencies because you know that there are expenses that you haven't considered.

The Lab Book: Learning from the past

Now what I'm going to ask you to do, and what is probably excellent practice, is for you to take every single one of your cost estimates that you make and keep them in a lab book. You should try to accumulate data on your ability to estimate costs. And you should treat it just like you would with any other kind of scientific endeavor. You should be looking for patterns within the data; empirical patterns that you can use later on to improve your cost estimation accuracy. While it may not look all that important to improve the cost estimates, imagine how much money you could save if you could get the same level of precision in your rough cost estimates as you currently get in your semi-detailed cost estimates.

This is a big deal because semi-detailed cost estimates can be a lot more expensive than the rough cost estimates. Imagine if you could eliminate a 10% bias in your cost estimates — 10% error on the estimation of the project cost that would reduce your profits. Eliminating that kind of bias would be very important to you, so you can see that there can be a great benefit to keeping records of your past cost estimates and analyzing them for the details and patterns of your past cost estimates and their errors.

Besides your cost estimates, you should also keep track of what the actual costs turned out to be after you completed the project. You need to keep track of the actual costs and cash flows so that you can see how far off you were in your estimation from the actual costs. These will also help you to figure out why your estimates were off.


After you've accumulated your data about all of these cost estimates, you should take a close look at what you've recorded to find patterns.

First, you should look for uniform differences between either your rough and your semi-detailed cost estimates or your semi-detailed and your detailed and the actuals. You're going to be looking for things that you're missing or that you're consistently off on for any reason.

Because I've looked at my own data on my cost estimates, I've seen where I make mistakes. My work is primarily statistical and turning data into something that I can use for analysis. I know I make mistakes in the estimates of the costs of getting data from other people. This has to do with figuring out definitions of columns in the data because other people's codebooks don't follow my preferred standards, or perhaps the data has undocumented irregularities. Maybe some of the people were using Zulu Time instead of Standard Time or Daylight Saving Time. In all of these cases I had underestimated how long it would take me, and, for me, time is money. So I know that since I'm usually off, I should multiply my numbers by a factor of, say, 2 or 3 to get the actual number; I know this now since I've done the analysis on my cost estimates.

In the past, I've also underestimated the amount of time I needed to devote to certain kinds of panic meetings that invariably happen near the end of a contract, just before a report needs to be sent out to the board that we're dealing with. I know now that I have to budget in that time. I think, "Oh, they won't panic again this time," and they always panic.

You probably do things quite similar to this when you do household projects. You know that however long you think the project is going to take, it usually ends up taking three times as long to finish it. It always take three trips to the hardware store to finish the project. It's the same kind of idea here. Once you see a pattern, you can adapt to the pattern so that your estimates get closer. You haven't necessarily fixed the issue that skews your estimates; you're just following a rule that compensates for it in the estimates.

Which estimates did you need to come up with?

You should also look at the pattern of cost estimates you have within a project. For example, did you do a rough cost estimate and then another rough cost estimate followed by a semi-detailed and then a detailed, or did you follow some other pattern? The issue here is that making semi-detailed and detailed cost estimates can cost you time and money because they're expensive. You can do rough cost estimates on the back of an envelope. They might take you a couple of hours but they're still relatively inexpensive and it's okay to do a lot of them. Semi-detailed cost estimates, in some domains, can easily end up costing you $5,000 per estimate. I was dealing with a relatively small construction project and that's just what I needed to spend ($5,000) in order to figure out what I was going to do and what it was going to cost. Detailed cost estimates are even more expensive, of course. They can go up to the $40,000 range.

You can end up spending a lot of time on these cost estimates. If you've ever responded to a request for proposals with a proposal, you could imagine that there are 10 people working on the proposals for 3 days. That's quite a bit of effort and money needed to produce a cost estimate. So you can see that you should try to reduce the number of detailed and semi-detailed cost estimates and try to favor the rough cost estimates.

Good patterns for estimates can look something like this:

  • One rough cost estimate.

This is a good pattern because you did the rough cost estimate and you saw right away that the plan wasn't feasible and you immediately abandoned the plan. You're done. You didn't need to go through any of the more expensive estimation processes.

Here's another good pattern:

  • A rough cost estimate,
  • followed by another rough cost estimate.

Once again, you halted the project before you needed to spend all of the time and money on the more expensive cost estimates.

You should try to arrange things so that each cost estimate gives you the possibility of changing or cancelling the current plan or moving on to the next most detailed cost estimate. For example, maybe you've decided to do a kitchen remodel. You go and get a rough cost estimate for the kitchen and you immediately decide that it costs way too much. So you start over, change your requirements for the project, get another rough cost estimate and see that it's closer to what you were expecting it to cost. Then you move on to the semi-detailed cost estimate, where any oddities will probably reveal themselves and then you can move on to the detailed cost estimate if you like what you've seen so far. At each stage, you're hoping to either move forward to the next stage or abandon what you've been doing and halt the project.

The worst pattern you can see would be something like this:

  • Rough cost estimate,
  • Semi-detailed,
  • Detailed,
  • Followed by another round of rough,
  • Semi-detailed,
  • Detailed.

This is an extremely painful pattern because it means that you've had to make major, expensive revisions to the project several times.

Client management issues and scope drift

The bottom line is that you should try to minimize the number of detailed cost estimates that you need to make good costing decisions. The solution to this problem oftentimes involves client management issues. You'll often see this as something that's called "scope drift." The key to solving this is to make detailed notes on what your client is looking for. You need to thoroughly document what's going on. And you need to be the one who takes responsibility for sending out the summarizing memo. You need to write up what criteria is going to be used. And you need to do this primarily because you're going to be the one who pays if something bad happens. So please take charge of documenting this because you know it's going to be expensive when things go wrong.

Don't be worried about a little scope drift; it's common during the very early stages of the process. That's why you have rough cost estimates. But once you're at the detailed cost estimate stage, changes are going to be extremely expensive. Avoid them at all costs.

Compare your actuals to your predictions

Now let's look at how good your predictions were. Did they actually jibe with reality? What you're looking at here is the hard numbers. If you thought that the project was going to cost you $100,000 and it ended up costing you $101,000, you probably did a really good job of estimation. That's impressive! It shows that you were doing things the right way, and if you're consistently hitting numbers like that, that's even more impressive. But if you notice that you're off by large factors, that could be an indication that you still have some skills that you need to acquire. They could be skills that you yourself need to learn or maybe you need to bring in some experts.

One thing I discovered when I was working on the cost of some projects was that I realized that some of things we were doing required some coding in PHP. I didn't know PHP. I kind of thought I could hammer it out myself because I know enough programming languages that I could pick it up quite easily. But, in order to get the project into the shape I needed, it ended up taking me much longer than I thought it was going to take initially. So now I know that in future projects, whenever I need to do this kind of cost estimation, I need to bring in somebody who can do PHP and can tell me if things are trivial or if they are going to end up being more expensive. So you sometimes need to bring in those kinds of people.

What's nice about these estimates is that you don't necessarily have to only use your own data. When you bid on projects, you'll often get the opportunity to see what the winning bid looked like and what the costs of the winning bid were like. So you can use all that information, once it becomes public, to improve your future cost estimates because they'll often see things that you don't see, or they have approaches that you're not aware of for solving problems. So you shouldn't be afraid of using other people's data; don't be afraid of using outside sources. If you're lucky enough to be in an industry that has good costing manuals, you should use them when you can because they are usually extremely well-researched, and their estimates are extremely close to reality.

Learn to expect the unexpected

The next thing you should look for is when you got beat up. I don't necessarily mean this in just a financial context. It's what happens when you get broadsided by a criteria that you weren't expecting to be important. Often this happens when you're not dealing with just a single individual as a client, but instead you're dealing with a client that is actually a group of people. In this case, the client's members can end up having multiple conflicting requirements. One of them says that your project has to make a widget that's red, and another one says that it has to be blue. You're going to get complaints from one or the other because it's not red or it's not blue.

Fixing this, again, is a client management issue. The key is to figure out who is fighting. A lot of the time, it's fairly clear who's doing all the fighting. The next step is to figure out what the fight is all about. Hopefully, they're feuding over the actual technical issues of the project, but sometimes that's not what they're fighting about. Maybe they're fighting because that's just what they do and they've been fighting each other for 20 years. Your job is to get them focused on the criteria that you're being evaluated on. You should try to get them to nail down your particular issues, perhaps by meeting with them individually first to figure out what the problem is, and then getting them together in a room so that they can come to a compromise on the criteria. This is what's important to you. The key is to not let yourself get involved in their battle. Let them fight it out. You just need to say, "I need a criteria out of you two because you're in conflict. You need to sort these things out so that I can move forward." Again, the idea is to stay out the way and keep notes, documenting what the criteria is supposed to be (which they'll hopefully eventually come to) so that you're not stuck being between the horns of a dilemma.

Once you get into this process you will sometimes be in situations where you just can't win. These scenarios are expensive and they're also extremely common. My favorite example of this is a K12 example: it's the DARE program, which is an anti-drug program that you'd see in elementary schools. The DARE program is famous for making lots of people happy. The kids are happy because there are cops in the school, the cops are happy because there's additional pay for participating in the program, the parents are happy because something's being done about drugs, and so on down the line. However, it's not quite a win-win-win situation. Research has shown, evaluation has shown that the DARE program doesn't do anything. There is no difference in the rate of drug and alcohol use depending on whether you have the DARE program or not. It doesn't do anything at all, but it's expensive and it makes everyone happy. This is what can happen when you have your clients split up into many parts and you're busy trying to make them into single cohesive units. So please be aware that there is this possibility of a cost-increasing compromise.

How long did it take?

Finally, you should start clocking in how long it took you to reach a decision. This is somewhat like a test of character. I don't mean that in a good or a bad way; it just depends on your temperament. Some people are very good at glancing over the rough parts of the information and then just coming to a decision. That doesn't mean it's a good decision, but they tend to come to these decisions quickly. Some people prefer to do an awful lot of analysis just to make fairly trivial decisions. So if you're the kind of person who will spend three days doing research on a laptop so you can save $20 and get one additional feature, that's a little too much analysis; it's not a good use of your time if you value it at all.

Some people have been known to just make completely gut decisions on things like buying a house, or they'll insist on almost no research when they decide on what they're going to do for college. Again, that's not a good use of your time. The key that I'm getting at is that the amount of effort you spend on making your decision should be related to the how much your choices differ in value and also your uncertainty about your choices.

Let me go ahead and say that it's a bad idea to do $1,000 worth of research on a $10 question. Just don't do it; it doesn't make sense. The foolishness of this is related to the scale of the differences, but you also need to be aware of your uncertainty. You're going to find out that it's often easier and cheaper to come to a decision if you decide on a criteria before you start collecting data. My best example of this is that I once had some clients that were looking at, and had originally asked for, the fraction of households in the population that had the energy-efficient version of a certain kind of common household object. And they wanted to know what fraction of the households had these things and so I asked them, "What are you trying to do here?" They told me that they wanted to decide whether or not they were going to discontinue a subsidy. So they needed to know the fraction of households that had these things, and that's kind of an obscure thing to need to know.

Well, I said, "Wait a minute. It's expensive to get that data on the percentage of households that have those things. Let's get you to come up with a decision criteria first and we can maybe figure out what you need to do, with less money." And so it turned out that if more than 20% of the population had these items in their household, my clients were perfectly willing to terminate the subsidy. If you know anything about surveys, you know that it's much easier to find out whether or not the number is more than 20% than it is the find out that it's, say, 50% plus or minus 2%. It's a lot cheaper. Often it can be 10 times cheaper depending on what the numbers look like. And so we ended up doing something like that, and it was a way of minimizing the decision-making cost.

So, my advice to you is: if the difference between the choices is relatively small, flip a coin. It's no big deal. Don't engage in any more effort than what you estimate or think the difference is. If your uncertainty is large, that's when you either need to come to a decision criteria before you make your decision, or else you need to spend some money to resolve your uncertainty.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License