Common Flaws in Software Estimation
Any time a new software project comes up in sight it goes through a few rounds of consideration against upcoming or available budgets. In the earliest stages, when little is understood about the project other than that it’s a project that will be executed to achieve a known objective. A budgetary cost estimate is assigned to it, this being selected from any of the following:
- A sincere but uneducated guess
- A carryover from a previous budget
- A number felt to be politically acceptable
- A number linked to the perceived importance of the project
- All of the above
- An expert view based on experience with a similar project
Mixed leadership messages. Sometimes a manager requests an estimate when he already knows that it will likely overrun budgetary allocations. He hopes that he is somehow proven wrong by his experts, then gets disappointed when he is not. That often results in mixed messages that make his team warily modify their estimates the next time in order to suit his expectations. For example, he might say I trust your judgement with this one, and then later ask why the numbers appear so high when what was acceptable was known earier.
Ignoring known influencing factors. This refers to ignoring known future factors, such as a significant holiday break occurring in the project period, or the unavailability of certain requirements or infrastructure, or any other resources that are certain to impact project effort and duration. A variation on this happens when the influence is taken into account, but then due to project initiation delays or other reasons, the factor is no more relevant, but continues to be included in the estimate anyway.
Trying to be too detailed. Estimation perfectionists often fall into this trap. In trying to get an estimate that is as close to reality as possible they include tasks and dependencies at the lowest possible level. This could be counterproductive to the objective of producing a good estimate because in reality, the actual project could deviate significantly from whatever was anticipated in the estimation model.
Unrealistic assumptions. In a perfect world, everything works smoothly, there is no shortage of funds or resources, no external delays, no unforeseen events, no technical brick walls, project and organizational processes work perfectly, and all dependencies smoothly are smoothly integrated on time and with no hiccups. Reality, of course, can be totally different. Beware of any estimate that is based on the assumption that everything works perfectly to completion.
Coerced underestimation. Possibly the biggest flaw in estimating software projects lies in coercing the effort and cost estimates down to unrealistic levels in order to meet budget expectations. This may be done to protect short term interests of various kinds, but is obviously detrimental in the long run when the project ends up underfunded.