Estimates are dangerous

We always hear of software projects being over budget and the reason is because how the budget of the project is determined. The issue is greater if the project is a fixed budget project where the budget is determined based on the initial estimate that is done for the project. Let me explain what is the fixed budget project.

Lets say you have to do task "T" which you know will take "H" hours. The per hour cost of a developer is "C" dollars. So you know the total cost of the developer to do task "T" is H*C dollars to this you add M which is the cost of the material needed such as software licences, machines, etc. So the total cost of doing task T is H*C + M. In a fixed budget project you agree to do the project for this amount. If there are any overruns it is over budget.

This looks like a logical deal for the customer as he has a budget before hand but it has inherent problems in it due to which in most cases the project will go over budget. What are the problems with this method

• The estimate is done very early in the project when many of the details of the project are not clear such as complete requirements, design of the task, level of testing and so on. It is like coming up with an estimate to build a house from a brief that is supplied to an architect for coming up with the drawings.
• The right people are not doing the estimate. Many a time management does the estimate based on prior experience in projects that are similar to this. But not all projects are the same and so it is bound to fail.
• If you ask developers to give an estimate they will not be able to give you one because they do not know the design of what needs to be developed and will ask you for time. But neither does the customer nor the management have the time as the budget needs to be approved.
• Usually estimates become more and more accurate as the software development proceeds. But in many projects one is not allowed to change the estimate after the initial estimate is approved. Many customers do not agree for a phase based estimate. They expect the entire estimate up front.

So one might ask what do you do in such a situation. There are a few techniques that I have developed that have helped my improve my estimates in the last few projects

• Develop a mock up on paper or using a tool such as Axure that will give a view of what you are going to build. Do not spend more than a day doing this.
• Give this mock up with the brief given to you for the estimate to a senior developer and ask them to do a high level architecture on paper. Do not spend more than a day doing this.
• At the same time the senior developer is doing the high level architecture give this mock up with the brief to a lead tester and ask them to come up with outline test cases - that is one line for each test case and what kind of testing will be performed. Do not spend more than a day doing this.
• At the end of 2 schedule days you along with the lead developer and tester should be having enough information to come up with an initial task list and an estimate with the unknowns of the project clearly listed down.
• Make a note in the initial estimate that as the unknowns gain clarity estimates may change and if there is a deviation of more than 10% then there has to be a discussion on the new estimate. This 10% is called the threshold value based on which renegotiation needs to take place. To learn more about when estimates might change read managing risk for better estimates.

Following this strategy along with a good design should negate most of the risks in the project when it comes to estimates.