Developers: Be Less Exact, Make Better Estimates

This is an excerpt from The Project Estimation Guide. If you found this useful, you can download another sample chapter here.

It takes us 3.65 hours to design and implement a contact form.

I used to work for a web agency that wrote fixed quotes based on hourly estimates. When a member of the sales team is on a call, they are going to have to face a common question from clients at some point:

“How much is this going to cost me?”

The way salesmen answered this question was as such:

• Gather requirements from the client, as best they could during the sales call.
• Go back to the development team, and ask them for estimates. This would require feedback from both designers and developers.
• Take those numbers and multiply them by $XXX.
• Report those numbers back to the client.
• The client would then ask for a justification of the price.
• The salesperson would go back to the designers and developers and asked them why it took “so many hours”.
• Designers and developers would either give an answer that the salesman didn’t understand or give the salesman an answer that the client wouldn’t.
• ???
• Profit.

I’m actually not sure how this ever managed to work, but my paychecks never bounced so I presume it did. All of this rigmarole led to a new internal initiative: Developers and designers would track their, time and keep a bank of estimates. That way sales people could patch together estimates based on this data. Pricing web applications would be as easy as ordering off of a Chinese menu.

This new system allowed salesmen to deliver incorrect estimates in a much quicker fashion, and the designers had to deal with the sales team left. Everyone was happy with this arrangement.

Precision != Accuracy

After three projects, we had the following data:

• Project 1 — contact form: 2.47 hours
• Project 2 — contact form: 5.25 hours
• Project 3 — contact form: 3.24 hours

From that, we could average them and decide that a contact page takes on average, 3.65 hours. The sales team takes that number and others like it moving forward and uses them to price out software to clients.

This is an example of being precise without being accurate. Precision is just a reduction in the size of your estimate. Accuracy is how often that estimate hits the mark.

3.65 is about as accurate a number as you can get. We are getting contact forms down to a decimal that represents less than one minute. However, it’s accuracy is 0%. In our sample size so far the agency has never delivered a contact form in 3.65 hours.

Instead, let’s consider offering a different type of estimate:

It takes us between two and six hours to design and implement a contact form.

This estimate is far less precise. However, based on our data, it’s 100% accurate. Every single contact form mentioned was delivered in more than 2 and less than 6 hours.

If you take one thing away from this article, I hope it’s this:

Always Think In Ranges.

Being too precise is our enemy. Programmers don’t get a lot of precision because as soon as we something figured out well enough to be precise, we’ll automate it and the time it takes will approach zero. For each estimate, we are going to think about reasonable worst case and best case scenario. Strive for hitting the mark inside of your range 90% of the time.

Also, be mindful of balancing precision and accuracy. I could estimate any particular feature as “between 5 minutes and 6 weeks” and be right 99% of the time, but that isn’t useful information. That kind of estimate doesn’t reduce uncertainty or risk, which is the only reason anyone ever asks for an estimate in the first place.

using our data, I could refine the estimate to “between 2.5 and 5.5 hours”. This is more precise, and equally accurate, making this an objectively better estimate. We’ll dive deeper into this in a later chapter.

If you or someone else presents more precise information, it is not necessarily more correct.

Quotes, Estimates, and Promises

If you are a freelancer that bills your clients based on an hourly, daily, or weekly basis, I’d strongly recommend always sending your proposals with ranges included. This will help you reinforce with your client that your estimate is just that and that the price is subject to change.

Even though freelancers use the terms quotes and estimates interchangeably, there is a subtle difference in meaning. An estimate is a best guess while a quote is an agreement. If you quote someone ten hours for work, you charge them for those ten hours regardless of how much time the work took.

One quick way to make your quotes more accurate and greatly reduce your chance of underestimate and cutting your effective hourly rate in half is to reconsider the question being asked by a quote. We tend to take the question at face value and think that we are being asked “How long do we think this work will take?”. What we are really being asked is this:

In what timeframe can you guarantee you can deliver the work?

If you think a part of a project will take 3.65 hours, that may be a good guess, but can you guarantee that? You have to leave yourself some margin or you won’t be in business for very long.

If you need to provide quotes / fixed bids, you can still use the system of estimation in ranges. By thinking about the worst case and best case scenario, you are getting yourself to think deeper about the possibilities of the project. If you had to submit a fixed bid, take the higher end of the range.

This is an excerpt from The Project Estimation Guide. If you found this useful, you can download another sample chapter here.