Business Case Requirements Management

Did you ever realized how many projects fail, and how this occurs?

Forrester reports on poor requirements (2006) a survey of the Standish Group's 1994 Chaos Report. Standish found, querying over 352 companies reporting on over 8,000 software projects, that the top three project impairment factors were:

  • Lack of user input (12.8% of respondents);
  • Incomplete requirements and specifications (12.3%);
  • Changing requirements and specifications (11.8).

Other research has shown almost 50% of defects identified during testing to be due to defects in business requirements.

Specifically, according to the Standish Group:

  • 31% of all software projects are canceled before completed ($81 billion waste).
  • 53% of projects will cost 189% of estimates.
  • 9% on time and on budget (large companies).
  • 16% on time and on budget (small companies).

It seems that our inability to work more effectively with users to better understand their requirements, coupled with weak engineering discipline in managing requirements, is the leading cause of software failures.

See the source document: Calculating your return on investment (ROI) from more effective requirements management.

The calculation

When we transform this information into round figures, it says that 37% of the project cost will be wasted on bad specifications.

Let us for the sake of argument assume that a project costs 1 million euros (MEUR 1.0). Suppose we were able to manage the process of requirements analysis and requirements management better, and let us assume that we could improve the project specifications with 50%.

In money this would immediately give us room for an investment of MEUR 1 * 37% * 50% = 185,000 euro. And this is only one moderately small project, not taking all quantitative (and qualitative!) benefits into account. If we would extend this to a larger project, or a project portfolio the benefits are clear. And also, the value is much more, as we did not try to quantify the intangible benefits.

This investment must of course be used for improvement of the requirements processes. This means:

back to top