Project Estimation

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 software industry as a whole is still very immature compared to other industries. Each company typically has its own development process and personnel competency level. There are wide variations from company to company and project to project. There is no consistency of methods from one company to another. If an outsourcing organization receives many bids for the same project, this does not necessarily mean that the lowest bidder is better at building software systems and can build them successfully for a lower cost. It could mean that the low bidder does not have a complete understanding of what is involved in building the project, or perhaps it cut corners to produce a lower bid. Likewise, a company that bids high is not necessarily less competent at building software. It could mean that it has a more complete understanding of the tasks and risks and adheres to a more disciplined process that produces a more predictable result, so therefore it costs more. In other words, software is not a commodity.

  • Software projects that are put out for competitive bid receive estimates that do not reflect reality. The estimates are produced in an artificial environment where the emphasis is on producing a winning bid. This means that there is significant pressure for contractors to produce estimates that are on the low side.

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.

Project Management with the IBM Rational Unified Process(c) Lessons from the Trenches
Project Management with the IBM Rational Unified Process: Lessons From The Trenches
ISBN: 0321336399
EAN: 2147483647
Year: 2007
Pages: 166
Similar book on Amazon © 2008-2017.
If you may any questions please contact us: