Estimating Software Development

A recent software development project served as a prime example of what can go wrong. The project was late and over budget. So who is to blame when such a situation occurs?

I'll outline the scenario and let you decide:

The project was defined by the company to solve a specific problem. There is no commercially-available software product that could be acquired or even retrofitted as a solution, so the specialized software system had to be built from the ground up.

The contract programming firm met with the key users to get a feel for the project requirements and scope. After the meeting, a high-level overview of the project was prepared, with an estimate that included the approximate number of programs and high-level functionality that would be required.

Based on that document and subsequent meetings, a development estimate was prepared. The estimate was clear about the scope of the project, including the maximum number of programs to be included in the project.

When the estimate got to the customer's management team, a key approver decided it was too expensive. He called the vendor to try to get the cost lower. The vendor, of course, maintained that there were only two ways to lower the estimate: Cut back on scope or cut back on the hourly rate. And of course, the hourly rate was as low as the vendor was willing to go.

So partly because of the manager's insistence, and partly because the vendor didn't want to lose the business, certain assumptions were built in to reduce the scope of the project and bring the total estimated number down closer to the manager's liking.

The project got underway, and moved along through the analysis and design stages. Development began, and of course at some point it was realized that the scope would indeed be exceeded. In fact, the scope in terms of number of programs had gone up by nearly a factor of 2. The Project Manager was pretty certain the project scope was unrealistic as soon as the initial analysis was complete, but the Vendor manager asked him to hold off on raising it as an issue until he was certain the project would go over budget.

So when it became clear the project would exceed the allotted budget, an analysis was performed and a revised estimate prepared. Even so, due to the creativity, extra effort, and efficiencies realized from the key development team members, the revised estimate was not double, but was almost exactly the same as the original estimate.

The same manager's response was anger and outrage. How could the vendor have gotten it so wrong? When the vendor meekly pointed out that the reason for the increased estimate was that the assumptions made in response to his request to scale back the original cost turned out to be invalid, the manager suddenly developed amnesia.

So in the interest of keeping the customer happy, even though the project was cleary contracted as a Time & Materials agreement, the vendor made concessions to cut their profit margin to bring the project in at a total amount that basically split the difference between the revised estimate and the actual projected cost.

Coming back to the question leading into this story, who is to blame for this project going over budget?

Is it the client manager's fault for unfairly forcing concessions from the vendor when they clearly demonstrated that their original estimate was correct and was only reduced at his insistence?

Is it the vendor's fault for giving in to the manager and reducing the estimate, even though they knew the actual cost was likely to come in at the original estimate?

Is it the Project Manager's fault for failing to strongly protest the project budget immediately after initial planning indicated the budget was unrealistic?

What should the vendor learn from this experience?