Why estimate?

I have been reading with some interest the recent debate around #noestimates.
I think the movement is somewhat misnamed, in that it is not “estimates” which appear to be the problem, so much as the decisions which are taken around them. To some extent, I think this comes from a misunderstanding as to what estimation is (and is not). If the movement calls attention to this misunderstanding, then this is all to the good, and all critical thinking which drives deeper understanding as to how to handle project uncertainty, the better.
I am interested in estimation, mostly owing to the fact that - when left to my own devices - to come up with a single point estimate, I am more than often hugely wrong. But therein lie a couple of the major issues: estimation is not about being right, and it is not an individual effort.

The estimate is not the deliverable

“Here is my estimate.” Seductive words, yet nevertheless, dangerous words. Estimation is an ongoing activity, not a deliverable. Estimates are essentially a form of risk management, a way in which we can deal with uncertainty in order to set co-ordinates and move forward. An estimate can therefore be considered as an impulse to action.

Estimates are for decision-making and lead to commitments

An estimate is an input to a more important process: usually that of decision-making, and this is where I first start to deviate from some of the #noestimates thinking.
Estimates set bounds on the unknowable, but they are not the same thing as targets, nor the same thing as commitments. Communicating this single fact is vitally important in estimation activity.
I may estimate that a project is highly likely to be delivered in Q4 of the current calendar year. The internal Marketing Department may be targeting the beginning of Q4 for launch, and therefore my Project Management team may have committed to a Q3 delivery. Herein lies the actual problem: my high confidence estimate lies outside of the project commitment, so I need to now frame my level of confidence in delivering to the committed date (NOTE: this will of course not be “highly likely”).
Estimates are therefore a management issue, and a political hot potato, and this is doubtless where much of the annoyance with estimates comes from.

The future is uncertain: deal with it!

Estimates, like projects, live in the future, and the future is unknowable, so no one technique is going to help out for all projects, and what is key is to tailor the estimation process to the project in question. however, some general pointers can point everyone in the right direction:

• Start estimation early: this way you can frame the commitment discussion.
• Re-estimate often: this is just tracking actuals against baseline. The “cone of uncertainty” will slim as you approach your target: if you check your direction often, you can make sure you are still on target. You need to learn from your estimation activity, and continually correct for “error”.
• Estimate from what you can measure: accuracy is less important than precision. Try to use the same measures in the same way to estimate. Raise the red flag: when you look like your delivery is straying from your commitment, raise the red flag (as soon as you notice). This will always hurt, but remember, estimates are an input to decision-making: the decision to continue or not is an important one, and relies upon good, timely data.
• Don’t overcommit: this is the hardest line. At least make everyone aware of your level of confidence in any commitment (and if you can manage to have it formally recorded as a risk, then all the better). This is not a CYA: again, your level of confidence is an input to a decision-making process, so don’t edit yourself: speak now or forever hold thy tongue!
• Don’t make an individual estimate: gather several individual estimates from several perspectives, and use these to decide upon best case, likely case, and worst case scenarios. Individual (and particularly expert) estimates have proven to be wrong, group estimates tend to be more accurate.
• Don’t use one technique: again pick three or four techniques to make estimates and centre in on the most likely scenario - for instance, a wideband delphi estimate; an estimate using proxies of effort (e.g. number and length of requirements based upon similar historic projects); a bottom-up estimate using T-shirting all used together will give you some sense of directional likelihood.
• Pick the right techniques for the right point in time/right type of activity: don’t use heavyweight methods for small, rapid projects. Cut your cloth according to the type of project you are working on , and its perceived risk/benefit profile. Don’t invest too much time in estimation - rapid, timely estimates will have more value than a deeply modeled, but effort-intensive approach. All estimates (even the accurate ones) cannot predict the future, they can just help to reduce the uncertainty.
• Check for change: when estimating from historic data or re-estimating in a project, be aware of what has changed and what has stayed the same. Make sure to adjust your model for change.
• When estimating for effort, also estimate for productivity: we all forget that productivity ebbs and flows. A manday of effort is not always equivalent to a one manday delivery: most of us fail to hit anywhere near 100% productivity, and our productivity varies wildly during a project. Maybe assume a 60% productivity rate is more likely or set out with a 100% productivity estimate and then adjust it as you see that delivery never reaches these levels. Don’t let overtime skew the picture: death march projects make ample use of overtime to swell a mayday from 8 hours to 10, 12 ore more hours. If you are using overtime, keep track and don’t let it skew the picture: people are (in general) less productive the more they work, so keep an eye on total hours worked.
• Estimate range and confidence: try, try, try to not give single-point estimates. Try to give a tight range with a level of confidence attached: e.g. "We are 90% confident of hitting Q2 delivery, but only 75% confident of doing so before the end of May". If you are asked to commit to a single-point, remember not to overcommit...

My final recommendations would be to read up on estimation. I really like Steve McConnell’s “Software Estimation: Demystifying the Black Art” as a great overview.
Finally, read the pros and cons of the #noestimates argument: making an informed decision about the right approach to take, at least leads to a mindful project delivery approach. Some good articles I have seen so far are:

• Estimates? We Don’t Need No Stinking Estimates!
• Estimates or #NoEstimates? that is the question
• The NoEstimates Movement
• And for a little framing from a planning perspective: The Fallible Future (and How to Fix It)