Automated Versus Manual Estimating
Having been in the industry for decades I have seen a lot of projects get into trouble with inadequate estimating. Watching the estimation methodologies (or lack therein) I have seen a variety of techniques. Over the years, analyzing these I have made several observations:
Developers are not too bad at estimating what it will take to make the software do what it should (the go path)… They are not so good at estimating what it will take to make the software not do what it shouldn’t.
- Manual estimates can very greatly even from the same person, depending on their current frame of mind.
- People have poor memories as to what it really takes to build and deliver acceptable software.
- Estimating effort directly (e.g. that take should take 3 months) rarely produces an optimized plan.. And without repeatability no one can figure what went wrong.
- Manual estimates at the lowest (1-2 week) level can actually make projects take longer since tendencies are to estimate those tasks at a higher probability and use all the time, even when things go well.
- Parametric estimating provides a language, methodology, and repeatability to the process.
- When people don’t want to take the time to estimate their project is already in trouble.
- Agile projects don’t eliminate the need to estimate. Stakeholders are not comfortable with “we will be done when we are done” answers.
 The folllowing table summarizes some of the estimating methods:
| Model Category | Description | Advantages | Limitations |
| Guessing | Off the cuff estimates | Quick.. Can obtain any answer desired | No Basis or substantiationNo ProcessUsually Wrong |
| Analogy | Compare project with past similar projects. | Estimates are based on actual experience. | Truly similar projects must exist or a repeatable process for adjusting should be in place |
| Expert Judgment | Consult with one or more experts. | Little or no historical data is needed; good for new or unique projects. | Experts tend to be biased; knowledge level is sometimes questionable; may not be consistent. |
| Top Down Estimation | A hierarchical decomposition of the system into progressively smaller components is used to estimate the size of a software component. | Provides an estimate linked to requirements and allows common libraries to size lower level components. | Need valid requirements. Difficult to track architecture; engineering bias may lead to underestimation. |
| Design To Cost | Uses expert judgment to determine how much functionality can be provided for given budget. | Easy to get under stakeholder number | Little or no engineering basis. |
| Simple CER’s | Equation with one or more unknowns that provides cost / schedule estimate | Some basis in data | Simple relationships may not tell the whole story Historical data may not tell the whole story.. e.g using simple productivity from prior projects misses people, process, technology issues. |
| Comprehensive Parametric Models | Perform overall estimate using design parameters and mathematical algorithms. | Models are usually fast and easy to use, and useful early in a program; they are also objective and repeatable. | Models can be inaccurate if not properly calibrated and validated; historical data may not be relevant to new programs; optimism in parameters may lead to underestimation. |
 Capers Jones research shows “when an estimate under 1,000 function points a manual estimate is acceptable.”  Unfortunately even in cases when the estimate is correct manually, it is not repeatable when done manually. Â
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Related posts:
- Why Manual Estimates Are So Bad
- Lines of Code Versus Functon Points Versus Use Cases For Sizing
- Barriors to Adopting Estimation Technology & Applications
- Learning Curves and the Lore of The Slope
- Agile Estimating User Stories
Related Posts Computer Generated
Comments
2 Responses to “Automated Versus Manual Estimating”
Leave a Reply
Manual estimating may also work better with smaller scale projects. For example, planning poker (an agile-inspired method) is probably used, by programmers, at pretty much the latter commit phase of a project, around when specific components are being developed.
[...] the problem – not just what you want to estimate, but why you want to estimate [...]