Project Estimation

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.

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:

  • Look for contractors that have established a partnership with IBM Rational. One way to do this is to attend the annual IBM Rational Software Development Conferences. Many partners of IBM Rational present papers regularly at these conferences on a variety of topics. Some also have booths at the exhibit hall where you can speak to representatives of the company.

  • Find out if the contractor certifies its engineers. IBM Rational partners can obtain many certifications for their engineers. Certainly, certification in the RUP is valuable, and also for the supporting tools.

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:

  • How do you tailor the RUP for individual projects? What factors do you consider when tailoring the RUP for a given project?

  • Give examples of projects in which major problems were averted as a result of uncovering risk early through iterative development.

  • How long are typical iterations on a project?

  • How do you identify the appropriate architecture for a project? What factors do you consider, and how do you prove that the architecture is viable?

  • What process do you use to elicit and manage requirements? How are changes to the requirements managed? How do you manage changes in scope to the project requirements?