A friend asked me on the spur-of-the-moment to give a short talk on estimating for his team-lead meeting. They were facing the somewhat daunting task of estimating and planning phase three of a large enterprise software adoption project.
Trying to provide help to another team made me reflect on this question: Why is estimation so hard, and so disliked by technical staff?
I’ll be making a series of posts on what we’ve learned at Atomic about how to improve estimates and the estimation process.
Why is estimation hard and universally unloved? For one thing, it’s a discouraging problem: ambiguous, fuzzy, imprecise, full of unknown factors, risky, consequential. You never have all the information you want. You worry about your second order ignorance (what you don’t know, you don’t know).
On the other hand, it’s not like we have a choice about tackling this thorny problem. The business needs to synchronize other decisions with the work we do: they have to plan sales and marketing, to budget, do return analyses, schedule resources, etc. And we certainly have selfish reasons to participate and do this well: missing a schedule commitment or overrunning a budget should injure our professional pride. It can also result in pressure to work beyond our sustainable pace and make personal sacrifices to our jobs.
When it comes to effective estimation, we should remember Voltaire’s caution about perfection being the enemy of the good.
Happily, there are some simple techniques we’ve learned to significantly increase our effectiveness and accuracy on this important work. I decided to organize my impromptu talk around the shortcomings of a typical, un-enlightened estimation effort.
Here’s what I’ve seen is pretty typical when a team makes a genuine effort to estimate, but isn’t familiar with some of the techniques I’m going to describe. Naive estimates are usually:
- made on very big things,
- constructed by the manager or team-lead only,
- not data-driven,
- based on little or no concrete investigation,
- expressed in absolute values of time,
- expressed to a false level of significance,
- created from single point estimates,
- independent of the calendar,
- independent of risks or assumptions.
I’ll be making future posts that address how to improve each of these aspects of the estimation process. I’ll fill in the hyperlinks above as I post each section.
[…] of a series on Making better estimates. Probably the simplest way of improving your project estimates is to explicitly de-couple duration […]
[…] We’ve done approximately 400 projects in our ten years of working together. From this experience, and drawing upon the data in our time tracking system, we can give clients a ballpark guess about project size without making a full responsible estimate. […]
[…] of a series on Making better estimates. Estimates require making assumptions. Assumptions violated are like risks realized. Both can be […]
[…] of a series on Making better estimates. Estimation is frustrating: fuzzy, difficult, inexact. You can simplify the process, reduce the […]
[…] « Making better estimates: decomposition Greasemonkey On My Back! » Making better estimates: team estimates By Carl Erickson | […]
[…] « Making better estimates Making better estimates: team estimates » Making better estimates: decomposition By Carl […]
[…] of a series on Making better estimates. Single point estimates don’t accurately represent the natural variation in a task. A range […]
[…] case, they flex the scope rather than the price.) You should also check out their whole series on […]
Comments are closed.