The proper estimation of effort required on a project is a controversial topic that has received much attention in the industry. Many useful and innovative methods have been developed and described by my colleagues. Each method has unique advantages, so I find it difficult to recommend one method over another. This discussion is beyond the scope of this book. A number of useful estimation tools are available. I encourage any organization bidding on software projects to invest in acquiring one of these tools and in training on estimation methodologies as well. Despite these methods and tools, one of the major impediments to estimation is human behavior.
Only rarely does any estimate turn out to be exactly correct. The actual experience usually ends up producing higher or lower numbers than the estimated number. For many software projects, the sad fact is that actual experience ends up producing far higher numbers than estimates, for both schedule and budget. I believe that the primary causes are as follows:
The procurement models described in this chapter help alleviate the problems created by estimates produced under competitive pressure. The estimates can be produced collaboratively in a better environment where the contractor knows it has the work, provided it continues to perform well.
To judge an estimate's viability, I often use the "50% rule." A proper estimate has a 50% likelihood of being too high and a 50% likelihood of being too low. If the organization can honestly make this statement about an estimate, it's probably a good estimate. For example, if someone estimates that it will take 10 months to complete a project, I often ask under what conditions they can finish in less than 10 months. If the response is "None," I know the estimate is not viable. Many estimates produced under competitive pressure suffer from this problem. No wonder software projects are so frequently late. The estimates assume a perfect world.