Perfect Estimates Every Time

People hate uncertainty. That is why they love estimates. An estimate plants itself in someone’s mind and replaces uncertainty. It feels really good to have certainty, instead of uncertainty. I know of three ways you can give perfect estimates on every project.

People in the software world demand estimates. Without them, it’s impossible to perform any strategic planning or product plan.

They will come to you for estimates. Estimating is hard to get right. If you give the wrong estimate, you lose a level of trust. If you give great estimates consistently, you build more trust and open up new professional opportunities.

There is a way you can give perfect estimates every time!

If you want to have a perfect estimate, what do you need to know?

What does an estimate include?

• Cost
• Timeline
• Scope of work.

When you order a hamburger at a restaurant, they say, “That will be $8.99. We’re pretty busy today, your burger should be ready in 15 minutes.”

You know how much the burger costs, how long it will take before you get your burger, and what the burger is made with, before you pay anything. A software project is no different, in concept, than this estimate for a hamburger.

A perfect estimate is one that is right more than 99% of the time. There are no truly perfect estimates in our world.

A perfect estimate requires trickery.

Everyone wants a perfect estimate. It doesn’t actually bother them if you provide an estimate that’s a trick, since it still accomplishes the same thing.

Three Estimating Tricks

1. Use historical statistics.

If you have observed enough similar projects, you will be able to nail a number with strong probability. If your confidence interval is greater than 95%, then, by definition, the cost and timeline are known.

Most of us haven’t done a large enough number of similar projects to be able to use this trick. This technique works best for repetitive tasks and more standardized work. If you build the same thing all the time for different clients, this is a great approach. If you are building CRUD apps, UI components, or static websites, you can definitely use this technique.

2. Provide an estimate after some work is finished.

It’s very easy to estimate how long something will take and what it will cost when the final costs and work duration have already been measured.

This is hard to do in practice, since it means that you have to have already finished some of the work.

The trick is that you do a large portion of the project work before giving your estimate. The downside of this approach is the chance that after your provide an estimate the client won’t want to go forward with the project. That will mean you have completed some work that will be unbillable.

But, it’s also possible that you may be able to carry over pieces of work from another similar project. Since that work is effectively done, you can factor it into the current project, and you know that it can’t take any longer, even if some changes or porting is needed.

3. Provide a moving range or worst-case estimate.

If you provide an estimate in the form of a range (9-12 weeks), it sounds to most people like a solid fixed answer; even though, obviously, it is not. The tighter the range, the more it sounds like a perfect estimate.

If you provide an estimate for the worst case scenario, then you can’t be wrong. Suppose you know that a task will typically take 2 weeks, and that if things go wrong, maybe it will take 4. Suppose you know that no matter how badly things go, it will be finished in 8 weeks. Then, by providing a bounded estimate, you provide certainty. Say, “This project will be finished in 8 weeks.” In the best case scenario, you end up looking like a rock star when you deliver significantly ahead of the estimate.

Perfect Estimates

I use all three of these tricks when I estimate software projects.

My favorite is using an estimate range with a worst-case boundary. This technique alone makes it very easy to consistently exceed project expectations. As long as you know the worst case scenario, it’s impossible to bungle this one. If you aren’t sure about the worst case scenario just take your best guess and then double that number.

I use my historical knowledge for estimates when it’s in a domain area that I have a TON of experience.

And, I sparingly use the completed work approach when I’m entering an unfamiliar domain, but want to provide strong certainty for my clients or employer.

What techniques do you use to provide perfect estimates? Tell me in the comments.

If you enjoyed this blog post, you can find more software project techniques in my book Project Management Secrets!