Archive for the ‘Software Estimation’ Category

Accurate and precise estimate is important, when we are bidding for a project, if our estimate is greatly low, we may lose money and damage our company, at the same time if we overestimate, we may unnecessarily become less competent and lose a project to another bidder. The accuracy of initial project estimates statistically proven to fall in the range of rough order of magnitude -50% : 100%[1].

In general, if we are building similar systems to those we have previously built, with similar teams and technologies for the same type of customers then we may expect to become accurate with estimates.

This applies pretty well to for example mechanical or electrical engineering disciplines, however in software project there is a limitation to how far we can be accurate because software systems are rarely similar to each other even if we used the same technologies and same teams to build them.

But still, estimation is a valuable tool. This tool, if used properly, can educate project manager and project team on how risky a project is, and on how controlled a project should be.

In my practice, I found that usually estimation depends only on individual judgment leading to introducing subjectivity and bias into the estimates. I believe that estimate should not be done based on emotional decisions or personal opinions, rather it should be based on documented measurements of previous projects recorded in organized historical records.

And by using “Analogy” with these records we can be much more accurate while trying to predict the future performance of our projects.

So, in my opinion, answering the puzzling question of how much time/effort/cost this task/project would take should be done first and before all objectively and second systematically.

If I want to outline a simple estimation process, I would say it should be as the following:

1- Keep historical records of your projects.

2- From those historical records pick the closet match to new project you want to estimate.

3- Size your current project/task and compare it to the match from the historical records, then you can assume that the ratio of sizes new : historical = the ratio of efforts/times/costs new : historical 

4- Within a controlled project estimate implied error percentage should decrease, so based on where you are in the project you may assume an error percentage in your estimate.

This method is most suitable at initial stages of the project/task but once we start and we collect data from the project we can use the project data itself to predict project performance, also and as a rule of thump you need to apply more than one estimation method and compare the results, but you need to consider also how much time and effort you want to spend on estimation itself.


[1] Software Estimation: Demystifying the Black Art, bySteve McConnell, Microsoft Press 2006


Read Full Post »