The Number One Cause for Project Failure and How to Avoid It

Project Failure – The Cost of Requirements Errors

What makes requirement errors fatal to projects?

Is it the negative impact they have on a project’s cost, schedule, and quality? In a diluted answer, yes. But the real trouble that results from requirements errors can be seen from the shocking discoveries of the following studies.A NASA paper, “Error Cost Escalation Through the Project Life Cycle” (2004), reviewed seven studies and presented findings about NASA’s own software development projects.

As presented in the table below, NASA’s experience is similar to the studies it reviewed – a requirements error costs 8 times more to fix during design, 16 times more after it is coded, 21 times more after testing, and 29 times more after deployment.

In their book, “Managing Software Requirements: A Use Case Approach” (2003), Leffingwell & Widrig summarize the results of several studies, including Alan Davis’ own review of such studies (2003). Davis’ results presented above are very similar to those of the NASA study.

Reifer (2007) and Dabney & Barber (2003) also assessed the issue. IBM’s Systems Sciences Institute reports that the cost to fix an error found after product release was four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase.

‍

So what do these numerous studies say about the cost of errors?

That requirements errors can be fatal to projects because the cost of fixing them grows EXPONENTIALLY as development progresses through design, coding, testing, and deployment!

Let’s look at some actual numbers

The impact on project costs of correcting requirements late is profound. But don’t take my word for it…

The National Institute of Standards and Technology concluded in a 2003 study that software defects cost the US economy about $60 billion annually.

Hooks & Farry (2001) found that re-work of errant requirements consumes 28 percent to 42 percent of a project’s development costs.

Boehm & Pappacio (1988) found that fixing requirements errors consumes 30 percent to 50 percent of a project’s budget.

In 2002 the Standish Group reported that the average size of a project ranged from $434,000 (small company) to $1.33 million (medium-sized company) to $2.3 million (large company). Extrapolations of these data for the average project yield expenditures on requirements errors ranging from $108,000 to $920,000.‍

‍

Wow.

Given these figures, it is easy to see why insufficient requirements management remains the leading cause of project failure:

• It can lead to going over the budget
• It can cause the team to fall behind schedule
• Or it can cause the team to abandon the project all together

The math is compelling – project managers should not short-change requirements resources, nor lose focus on requirements objectives, tasks, techniques and tools.

Obviously, it is better to correct requirements errors during requirements elicitation than during design, code, test or post-deployment. Better still, a project team should minimize requirements errors as much as possible through the sound planning, elicitation, analysis, documentation, communication, verification and management of requirements.