Is it possible to estimate a software project well if it’s over, say, a month in duration? Or can you only give meaningful estimates to work that’s less than a week? And is it right to say No to any requests for estimates of work of substantial size?
These are questions that arose most recently in a post by Rob Bowley. It’s well worth a read, with lots of good references, and there’s a terrific discussion underneath. My own answer to these questions is that any estimate can be useless or misused (even those of an hour), and any estimate must be placed in a context to be meaningful.
Estimation considered harmful
Rob makes a lot of good points. Here are some I agree with:
- Misuse of estimates is the root of many, if not most, failed software projects being considered a failure.
- Almost all of us are really bad at estimating in these situations.
- For most organisations the definition of tech success is “on time and on budget”
- When asked for long range estimates it’s irresponsible to just say No and walk away.
And here’s what I disagree with:
…we should start being brave and just saying no to requests to provide estimates on anything more than 1 or 2 months (at most) work. […] What’s the least worst situation to be in? Having an uncomfortable situation with your boss now or when – based on your estimates – the project’s half a million over budget and 6 months late? […] My advice to anyone who’s put in the situation of providing long range estimates is to be brave and simply say it’s not something we can do, and then do your best to explain why.
Just saying No isn’t helpful — even with an explanation. The worst that can happen isn’t bringing forward an inevitably-uncomfortable situation with your boss. The worst that can (reasonably) happen is that your boss systematically turns to others who are more on his or her wavelength, and you get seen as a fist-waving problem employee who is consistently sidelined.
The key text is when Rob says that discussing project duration is perfectly valid only if you can say anything meaningful about it. What’s meaningful varies. Even saying something will take one hour may not be sufficiently meaningful in some situations:
Chief: Can you write a script that shuts down all the launch servers?
Technician: Sure. I estimate that will take an hour. [Thinks: I’ll start it after lunch.]
Chief: Thank goodness. Because apparently someone’s hacked them, and they’ve been reconfigured to launch a nuclear strike against Italy in [looks at watch] 1 hour and 2 minutes. But I’m reassured now we’ll be okay.
If that 1 hour estimate is out by just 3 minutes then there are very bad consequences. Suddenly it looks as though the estimate didn’t provide the right meaning to the chief.
In the comments on Rob’s piece, Paul Dyson gives two detailed examples of where long range estimates were presented in a meaningful manner. Each was a situation where figures were not presented as standalone numbers, but part of a larger response that made up a business solution: we believe this investment will achieve this outcome, and we will track success continually in a dialogue with you.
Presenting standalone numbers in response to specific questions divorced from the larger context is responding to the wrong question. Having a meaningful dialogue with your peers is more productive.
In my time at the Guardian we built our micro-apps framework with specific intention to support a specific project: our discussion platform. There was a time and budgetary estimate, but the end goal of delivering the discussion platform was what counted.
Guardian in America has a specific budget, too. It launched recently with a new home page focused on a US audience. That’s far from all that will be delivered, but you can be sure the project’s early goals are being met with that early delivery, and there is a feedback loop which comes from using this for real. One day the budget will be used up, but before then the priority of individual features will have changed in the light of real-world experience. That in turn means the priority of the project will be on delivering business objectives, not on sticking to a narrow view of on-time-on-budget.
Making estimates part of the bigger picture, to give them appropriate meaning, is what creates success.