A large portion of IT projects fail or are challenged in some way. The cost of failed IT projects can be enormous. This article examines the impact of requirement quality on the project and business as a whole.

There are plenty of stories about failed projects. The 2004 CHAOS report from The Standish Group which researches the reasons for IT project failure in the USA, indicated that project success rates were only 34 percent, with the rest of projects being either “challenged” in some way or failing outright.

The losses can be very significant. For example, British food retailer Sainsbury had to write off its $526 million investment in an automated supply-chain management system. The U.S. Federal Aviation Administration spent $2.6 billion unsuccessfully trying to upgrade its air traffic control system in the 1990s. Ford Motor Company abandoned its purchasing system in 2004, after spending $400 million.

From the project management perspective, technology projects fail when they do not meet the following criteria for success:

  1. Project delivered on time.
  2. Project completed on or under budget.
  3. The delivered solution works as required by business stakeholders.

A number of factors are involved in any particular project failure. The most often quoted factors are listed below:

  1. Lack of stakeholder involvement
  2. Unrealistic time scales
  3. Poor requirements
  4. Scope creep
  5. Uncontrolled changes
  6. Insufficient testing

Poor requirements

The quality of requirements can have a lot of impact on the outcome of the project. One high profile project that was significantly affected by the requirements management process was the Chrysler Comprehensive Compensation System which was supposed to handle paychecks for Chrysler’s 87000 employees but was shut down after several years of development.

The impact is magnified as the BA moves from high-level requirements towards functional and non-functional requirements. The cost of rework of functional requirements is the highest because these requirements define the technical specification and design of the solution.

Here is the poster with the visual summary:

Download PDF

If business analysts provide subpar requirements, it causes a wide range of negative consequences not only for the current project but for the business as a whole.

1. Project

Projects are undertaken by the business to satisfy a strategic goal. Poor requirements impact the business through projects in the following ways:

  • Project scope (creep)
  • Project budget (money and time)
  • Resources (low utilisation, overheads)
  • Business process design (insufficient details about activities)
  • User Interface (poor design and ergonomics)
  • Software specification (unclear requirements for functionality)
  • Solution testing (poor specification amplifies the negative effect of poor requirements)
  • Code rework (time-consuming and costly task!)
  • Solution Integration (poor interface design and its specification).

2. Business

More generally, the business is affected in many different ways by poor requirements through the projects that the business undertakes. Here is the short list of negatively affected areas that I have witnessed:

  • Strategic goals (lost opportunities)
  • Competitive position (lost advantage)
  • Market compliance (breaches)
  • Stakeholder engagement (loss of trust)
  • Business process efficiency (poor solution design)
  • Positive user experience (cumbersome UI design)
  • Bottom line (waste of money)
  • Cohesive IT landscape (poor integration)

Ways to improve the situation

A prerequisite for success is aligning high-level requirements with the strategic goals. Business analysts need to work closely with stakeholders, engage them and build relationships based on mutual trust. They also need to ensure that the high level requirements are understood by stakeholders, accepted and fully agreed before moving towards the business requirements. The time spent on definition and agreement on the high level requirements will pay off manyfold by the end of the project.

I discuss more ways of preventing poor requirements in another post.

If you found this post useful, please share it with other people!