Requirements Errors are a Leading Cause of Project Failure. In a previous blog, I explored why many projects continue to fail even though the causes of failure are widely known. This blog addresses Cause #1 – lack of user involvement, which is largely a result of insufficient requirements management. To understand how poor requirements cause projects to fail, let’s review the cost of errant requirements.
Requirements errors permeate development of a software system, negatively and exponentially impacting a project’s cost, schedule, and quality. Numerous studies document the expense of fixing a requirements error as development progresses. 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 eight 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. More recently, 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. All of these numerous studies conclude that the cost of fixing a requirements error grows exponentially as development progresses through design, coding, testing and deployment.
The impact on project costs of correcting requirements late is profound. 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 per cent to 42 per cent of a project’s development costs. Boehm & Pappacio (1988) found that fixing requirements errors consumes 30 per cent to 50 per cent 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 (over budget, behind schedule, or abandoned altogether).
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.
This is part of a blog series in which I explore key reasons why software projects fail and provide actionable remedies to root causes of failure. Hopefully, you may find the series informative, relevant and irresistible.
The previous blogs were “Why Do IT Projects Continue to Fail?” and “Select the Right Flavor of Agile to Succeed.” The next blog is “Mis-Using User Stories.”
