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.
Selecting a Contractor Proficient in the RUP
Suppose you are a manager in an outsourcing organization, and you have read enough about the RUP to believe that it is a better process for developing software. How do you select a contractor that is fluent in the RUP? How can you be sure the contractor really follows the best practices? Consider these points when evaluating contractors:
In addition, ask the contractor questions about previous projects on which it has applied the RUP. Some of the suggestions in the following list do not necessarily have right or wrong answers, but they can provide insight into the contractor's philosophy regarding the RUP: