Software Estimation – Is it really hard ?

Yes, it is hard.

Lot of folks do not understand why Software estimation is so hard. The problem is folks who don’t understand the difficulty in estimating software make it more harder. I would compare software estimation to using a camera. The objects are fuzzy to begin with and slowly they get into focus. it is a process which requires constant refinement.

The main issue around estimation is the inability of most customers to provide clear and concise requirements. Most times the requirements are too high level like “what does it cost to build a house ? “. Of course the characteristics of a house can vary dramatically even within a fixed budget.

It is difficult to know whether you can build the product that the
customer wants in the desired time frame until you have a detailed understanding
of what the customer wants.

Decision making is very important in software development. Every decision at every stage in a project has implications both on cost and time. Estimates become more precise towards the completion of the project but that does not help the customer a lot. The diagram below illustrates this concept.

Most customers want more than what they can afford. There are three ways to complete a project in this case :
1) Staff the project to accomplish the required features. This may not always work .
2) Compromise the feature-set . In the case of a house a third bathroom may not be required after all !.
3) Both customer and developers meet halfway. This is mostly the common scenario.

There is a thin line between software estimation and project control. It is always possible to deploy to a cost and budget as long as the customer is willing to be flexible , which means that the customer should be able to let go of some features to meet the deadline.

It is always a best practice to provide good feedback to your customer. I have felt that it is always better to tell the stakeholders that I will update the estimate at each stage of the project requirement specification , product design , software design etc.

The reality is , the shortest actual schedule results from the most accurate, planned schedule

If the estimate is too low,planning inefficiencies will drive up the actual cost of the project. If the estimate is too high, Parkinson’s law (that work expands to fill available time) will drive up the actual cost of the project.

The goal of estimation should be a convergence between your estimate and reality. The closer they are aligned the better it will be for the overall project. This also requires a lot of support from customers. They should be able to prevent scope creep so the developers are not held accountable to features they did not commit to delivering. The sad reality I am yet to see a customer who is able to prevent scope creep !

At the end of the day it will be fair to say that software estimation is a process of constant refinement and the budget will normally drive this process along with precise requirements. Allowing for improper ( high or low) estimates will only delay the project.

Reference :
Rapid Development
Steve Mcconnel