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
After further modifications that reflect the business priorities, forecasts, plans and constraints of the business leadership, the budget is passed, and then the project moves into the IT departmentâs program funnel. Once there, fresh estimates are usually drawn up based on a software engineering and delivery view, using either a formal software effort and cost estimation model or an approach based on expert opinion. These may be done in-house, or may be requested from an external vendor. Estimates are just that - estimates. They cannot be 100% precise. However there is always a very real pressure to get them very right, or to get them to conform to expectations. Whether they are done in-house or externally, the future can never be known and controlled to perfect precision, and with the impact of several other common occurrences, factors or influences, it is not uncommon to find at the end of the project that actual effort and cost vary significantly from the estimates, despite good project management.
Some of the most common flaws in the estimation process that managers should be aware of, so that they can try to control them, are the following.
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.
This blog is listed under Project & Service Management Community