4 ms·

Unless I missed it in there, there is another reason for estimating work - deciding whether it's likely to be worth the effort to build it. It's rare that a de

Unless I missed it in there, there is another reason for estimating work - deciding whether it's likely to be worth the effort to build it. It's rare that a development organisation has run out of things to build. There's almost always going to be several ideas competing to be the next thing to start, and there's got to be some way of deciding which you should go for. One obvious way is weighing up the likely cost v benefit of each idea, both of which require you to make some form of estimate. Of course those estimates will almost certainly be wrong, but at least starting with a view of whether you think it's going to take a week or 9 months to add a mobile optimised version of your website, or whatever feature you're considering next, is going to be more helpful in making that call than starting with absolutely no idea at all of the effort it's likely to take.

slgeorge 12y ago
Totally agree. Whether you're creating a new product feature, or doing a specific piece of work for a customer you need an estimate to define the cost, resource and time-line. Without it you can't understand whether the work is worth doing. For managing cost and resource the estimating process acts as a way of discovering the complexity in the problem. Yes, it will probably be wrong to some degree, but there are ways of handling that (ie probability) on the effort analysis side. The other thing that helps is to identify the edge of what you can see, if something truly is totally unknown then breaking the work into blocks or discovery stages makes sense. At a practical level time-line is the one that's the least useful to estimate up front, and seems the least amenable to assessment. Without the ability to make some sort of estimate you cannot assess whether the work is likely to be worth the investment.
- humanrebar 12y ago
  > Without the ability to make some sort of estimate you cannot assess whether the work is likely to be worth the investment. I completely agree. But I'll add that without some notion of risk, the estimate is itself risky. In other words, when building a business plan around software estimates, getting a one number as an estimate (30 days) is a bit crazy. It would be much more useful to attach a range or confidence to the estimate What happens now is that Project Manager asks Team Lead for an estimate. Team Lead pads the estimate a little and says 40 days. If Project Manager expects a 20% ROI, there's a significant risk that the project will still end up in the red. Or the team ends up crunching like crazy to "catch up", which is basically the same thing since your spending other things (quality, employee health and goodwill, etc.) instead of budget. Whatever the exposure, there is significant risk that is not clear in the business plan, which is a failure of management. In contrast, maybe Team Lead could give a 50% chance that Project Jabberwocky will be done in 30 days and a 95% chance we'll be done in 120 days. Wait, Project Manager says, that's a wide range of values to plan around! He's right, but the emotional reaction is due to him being educated about risk, not due to the Team Lead dragging his feet or something. So what is a Project Manager to do with that estimate? Take the risk into account. Plan around 95% estimates (keeping in mind that 1 in 20 projects will still miss the mark) or make sure the risk is mitigated in other ways: lots of little projects, relatively low cost projects, projects with huge expected ROI, etc.
  - jacques_chester 12y ago
    DeMarco and Lister of Peopleware fame wrote a book, Waltzing with Bears, which models risk and value as curves. You look for the overlap in the risk/value curves to help you decide whether, on balance, you're on a good thing.
  - cpitman 12y ago
    The book mentioned in this article, 'Software Estimation: Demystifying the Black Art', actually goes into a lot of depth about this. For example, what is statistically likely to happen if you only use single point estimates when they are aggregated together, and how to correctly handle range estimates.
- koonsolo 12y ago
  > Without the ability to make some sort of estimate you cannot assess whether the work is likely to be worth the investment. In case of a product, estimating the development time will be the least of your problems. How do you estimate the revenue of a new feature? Your estimate can easily be off with a factor or 10 or even 100. So in such a case, even with perfect implementation estimates, it's impossible to calculate the profitability of a feature.
  - prof_hobart 12y ago
    Yes - it's impossible to reliably and accurately estimate (which is why it's an estimate). But you've got to have some form of figure, both of cost and revenue - even if it's just back of a beermat guesswork based on a vague hunch - to make any form of sensible trade-off judgement. I do a fair amount of work around business cases for new projects, and simply forcing the proposer to go through an exercise of answering "how do you think this project will increase revenue/reduce costs/whatever, and by how much?" helps weed out ideas that don't really have legs or haven't been properly thought through, as does having a first stab at "What's involved in delivering this? Is this a 2 week project or a 6 month one?"
krfsm 12y ago
I tend to agree with Tom DeMarco on this issue: "This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value." (From http://www.computer.org/cms/Computer.org/ComputingNow/homepage/mostread/MostRead-SW-SoftwareEngineeringAnIdeaWhoseTimeHasCome.pdf http://www.computer.org/cms/Computer.org/ComputingNow/homepa... )

slgeorge 12y ago

Totally agree. Whether you're creating a new product feature, or doing a specific piece of work for a customer you need an estimate to define the cost, resource and time-line. Without it you can't understand whether the work is worth doing. For managing cost and resource the estimating process acts as a way of discovering the complexity in the problem. Yes, it will probably be wrong to some degree, but there are ways of handling that (ie probability) on the effort analysis side. The other thing that helps is to identify the edge of what you can see, if something truly is totally unknown then breaking the work into blocks or discovery stages makes sense. At a practical level time-line is the one that's the least useful to estimate up front, and seems the least amenable to assessment. Without the ability to make some sort of estimate you cannot assess whether the work is likely to be worth the investment.

humanrebar 12y ago
> Without the ability to make some sort of estimate you cannot assess whether the work is likely to be worth the investment. I completely agree. But I'll add that without some notion of risk, the estimate is itself risky. In other words, when building a business plan around software estimates, getting a one number as an estimate (30 days) is a bit crazy. It would be much more useful to attach a range or confidence to the estimate What happens now is that Project Manager asks Team Lead for an estimate. Team Lead pads the estimate a little and says 40 days. If Project Manager expects a 20% ROI, there's a significant risk that the project will still end up in the red. Or the team ends up crunching like crazy to "catch up", which is basically the same thing since your spending other things (quality, employee health and goodwill, etc.) instead of budget. Whatever the exposure, there is significant risk that is not clear in the business plan, which is a failure of management. In contrast, maybe Team Lead could give a 50% chance that Project Jabberwocky will be done in 30 days and a 95% chance we'll be done in 120 days. Wait, Project Manager says, that's a wide range of values to plan around! He's right, but the emotional reaction is due to him being educated about risk, not due to the Team Lead dragging his feet or something. So what is a Project Manager to do with that estimate? Take the risk into account. Plan around 95% estimates (keeping in mind that 1 in 20 projects will still miss the mark) or make sure the risk is mitigated in other ways: lots of little projects, relatively low cost projects, projects with huge expected ROI, etc.
- jacques_chester 12y ago
  DeMarco and Lister of Peopleware fame wrote a book, Waltzing with Bears, which models risk and value as curves. You look for the overlap in the risk/value curves to help you decide whether, on balance, you're on a good thing.
- cpitman 12y ago
  The book mentioned in this article, 'Software Estimation: Demystifying the Black Art', actually goes into a lot of depth about this. For example, what is statistically likely to happen if you only use single point estimates when they are aggregated together, and how to correctly handle range estimates.
koonsolo 12y ago
> Without the ability to make some sort of estimate you cannot assess whether the work is likely to be worth the investment. In case of a product, estimating the development time will be the least of your problems. How do you estimate the revenue of a new feature? Your estimate can easily be off with a factor or 10 or even 100. So in such a case, even with perfect implementation estimates, it's impossible to calculate the profitability of a feature.
- prof_hobart 12y ago
  Yes - it's impossible to reliably and accurately estimate (which is why it's an estimate). But you've got to have some form of figure, both of cost and revenue - even if it's just back of a beermat guesswork based on a vague hunch - to make any form of sensible trade-off judgement. I do a fair amount of work around business cases for new projects, and simply forcing the proposer to go through an exercise of answering "how do you think this project will increase revenue/reduce costs/whatever, and by how much?" helps weed out ideas that don't really have legs or haven't been properly thought through, as does having a first stab at "What's involved in delivering this? Is this a 2 week project or a 6 month one?"

krfsm 12y ago

I tend to agree with Tom DeMarco on this issue: "This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value." (From http://www.computer.org/cms/Computer.org/ComputingNow/homepage/mostread/MostRead-SW-SoftwareEngineeringAnIdeaWhoseTimeHasCome.pdf http://www.computer.org/cms/Computer.org/ComputingNow/homepa... )