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.
Being meaningful
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.
To me, the truth is in this Twitter exchange I had with Rob, and Rachel Davies, while he was writing the piece:
[View the story “Estimation problems, with Rob Bowley” on Storify]
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.
niksilver.com 
Hello Nik,
You are fortunate to work at an “enlightened organisation” as I put it, no doubt through a lot of hard work on your part. We’re not less unsuccessful because we don’t estimate, but because we appreciate the uncertainty involved. In a safe environment such as this then long range estimation can be useful – at least to know the scale of a project and when it won’t by done by at the earliest :).
However, the vast majority of software development does not go on in such environments – and neither do the massive failures which go with them.
In my epilogue I willingly concede ‘it’s no good just to say “no”‘, but that’s not the same as saying “yes”. You need to explain why and along side that offer the alternative ways to tackle the project. Failing that, “if you can’t change your organisation, change your organisation”.
I would never ever recommend that anyone who works in the kind of organisation where there’s little appreciation for the unpredictable nature of software development and little trust between parties concede to that organisation’s will to know when a large project will be completed. So what if you’re sidelined? Firstly, go and work somewhere better because you deserve to, and secondly that’s surely more preferable than being made the scapegoat when it all goes wrong.