# Precision

Precision (or the implication thereof) is perhaps the root problem of most, if not all dysfunction related to estimation. If you really take the time to learn how to analyze risk properly, this will help you figure out the following fact about the outcome of your software project: It is *very* uncertain. To me at least, that’s not super useful, but feel free to keep calculating.

The number of people walking around with the natural assumption that someone is to blame whenever an estimate turns out to be wrong is just sad. When you’re pushed to deliver a low estimate to secure a bid, and then yelled at for not being able to build the product in time afterwards — you just can’t win.

Things are moving in the right direction, but there are still a lot of people (both at the vendor and customer side) out there who falsely believe that estimates can be really precise. We don’t help the case by providing estimates like “550 hours” or “115 days”. The resolution level presented (hours or days) implies a degree of precision that simply isn’t there. Please consider the illustration below.

If your 115 day project was just as likely to be 150–200% over budget as it was to be on time, why on earth would you say 115 days? You should’ve said something like 3–5 months. This would (correctly) imply less precision, and give the customer much better information about the risk involved in the project.

You got customers who insist on the predictability of fixed price? Funny how that happens. Anyway, you’d be mad to take all of that risk yourself. That means someone (yes, your customer) has to pay to reduce that risk. Let’s assume you want to end up in the plus at least 8 times out of 10. Based on the graph above, that means you’d need to charge them roughly 175% of what you believe to be the most likely cost of the project. You also effectively remove any option they have of choosing a cheaper route, if one were to be discovered during the project.

That’s expensive precision.

*Related post: **Predictability*