How to Justify Early Extra Investment to Reduce Late Budget Overruns

Software projects that result in late budget overruns are never welcome. As a result, most companies take steps to keep tight control on costs, particularly in the early stages of a project. Therefore, the last thing they want to see is a big invoice during the initial scoping and design stages, i.e. before coding even begins, let alone testing.

Providing extra investment in a project’s early stages, however, is the best way to reduce late budget overruns. Specifically, early investment in the requirements and design stages helps to identify potential defects and remove them from the system as early as possible.

This approach is exponentially cheaper than finding and fixing bugs at a later stage in the project.

The Cost of Software Defects

Well-known research backs up this approach, particularly research by Barry Boehm of the University of Southern California and Victor R. Basili of the University of Maryland. Their research confirms what we have seen at SL Controls in numerous projects.

In particular, the Boehm and Basili research describes how the cost of fixing a defect is up to 100 times more expensive at the end of a project (the maintenance phase) compared to fixing a defect at the start (the requirements phase). In addition, the cost of fixing a defect increases through each stage of the project. The cost increases considerably after the main coding stage.

Cost of Correcting Defects Boehm and Basili
Source: B. Boehm and V. Basili, Software Defect Reduction Top 10 List, IEEE Computer, IEEE Computer Society, Vol. 34, No. 1, January 2001, pp. 135-137

The general principles related to the cost of defects are as follows:

  • The longer a defect remains in a project, the more damage it does as it will have a broader impact than a defect introduced at a late stage
  • The longer a defect remains in a project, the costlier it is to fix
  • Spending more time and resources in the requirements and design stages of a project will identify defects early and, importantly, will help to prevent defects from entering the project further down the line
  • All defects identified late will be costlier to fix

In addition:

  • Software projects spend up to 50 percent of their resources on avoidable rework
  • 20 percent of defects account for 80 percent of avoidable rework

The solution is to find and address defects in the requirements and design stages. After all, it will always be cheaper and more efficient to avoid putting defects into the code in the first place than it is to find and remove them at a later date.

The SL Controls Experience

We have referenced below one example of a project we were involved in where several decisions were made in the early stages that led to significant difficulties at the latter stages of the project. At their core was a failure to take a controls and data-focused approach with clearly defined Critical to Quality (CTQ) parameters.

This led to a situation where several requirements of the project were not met. Crucially, these defects were not discovered until the Site Acceptance Testing (SAT) stage of the project. It should be noted there was no Functional Acceptance Testing (FAT) at the OEM site for scheduling reasons which resulted in the defects being uncovered later in the testing phase.

The late discovery of the defects resulted in the project going over budget and over schedule.

Of course, the situation could have been worse if production went live with critical software defects. The budget overruns were, however, significant.

We ran calculations showing this budget overrun could have been almost completely eliminated if the defects were found and corrected at the requirements and design stages of the project. It is likely the project would also have completed on schedule which would have saved the company even more.

Focus on the Early Stages

In summary, the best way to avoid budget overruns in software projects is to focus on identifying risks and defining CTQs in the requirements and design stages. This preventative approach is considerably less expensive than a corrective one that relies on the coding and testing stages to identify and remove defects.