5 ms·

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

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?"

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?"