Do you Know Your ROI on Your Requirements Work?
Success with requirements pays off – quickly – by allowing you to
Shorten your product development cycle
Deliver the right product on time
Boost your team’s productivity
Reduce rework and conflicts arising from unclear requirements
Cost savings
Getting requirements right, early in your project, can save you one-third or more of your overall project budget (Hooks and Farry, 2001)
By investing only 10% more effort in requirements before freezing them, large, complex projects experienced significantly lower cost overruns — 30% to 130% overruns fell to 10% to 20% overruns (NASA Comptroller Office, reported in Hooks and Farry, 2001).
The costs of requirements errors are extremely high. For example, the cost to correct errors injected early (during requirements development) multiplies as your project proceeds—costing you 50, 100, or even 400 times more as the project proceeds (Reifer, 2007; Dabney and Barber, 2003; Boehm and Basili, 2001; Nelson et al., 1999; McConnell, 1996; Boehm and Papaccio, 1988).
You save money by getting requirements right to begin with. Why? Because fixing requirements errors accounts for 70% to 80% of your rework costs (Leffingwell, 1997).
Well-defined and well-managed requirements reduce your application’s total cost of ownership (Light, 2005).
You will save precious money and time by correctly defining your product needs.
Why collaboration works
Trust. Shared vision. Common goals. These are ingredients for a healthy project community and a successful project. It is essential for technology projects to start with a shared vision and a common understanding of product needs. This makes for a smart start. Early on, business and technical stakeholders collaborate around these goals and product needs.
Project success factors include user involvement, clear business objectives, minimized scope, and agile requirements processes (Standish Group, 2003).
Collaboration between business and technical stakeholders can give you a 10-to-1 return on investment (Jones, 1996a).
Well-designed and well-run requirements workshops (sometimes referred to as “JAD” - Joint Application Design) deliver spectacular outcomes. More Details.
Reduce the risk of scope creep from 80% to 10% or less when combined with prototyping (Jones, 1996a).
Cut requirements creep in half (Jones, 2000).
Provide a 5% to 15% savings in time and effort for the project as a whole (Jones, 1996a).
Reduce defects delivered in software by 20% (Jones, 1996a).
Reduce project failure and cancellation rates by about 50% (Jones, 1996a).
Increase productivity by 10% to 50% (Vosburgh et al., 1984).
Provide a 10-to-1 return on investment ($10 for every $1 invested (Jones, 1996a).
Cut elapsed time of requirements specification by 20% to 60%, and reduce total project effort by 20% to 60% (August, 1991)
Note: citations are at the bottom of this page
Ellen Gottesdiener, EBG’s principal consultant and founder, literally wrote the book on how to do collaborative workshops. Our training is widely recognized as the best-in-class way to learn how to use this vital technique. Our direct project help for requirements workshops and agile requirements workshops get your project off to a smart start. You will obtain high-quality product requirements quickly—while building a healthy project community.
Shorter delivery cycles
Deficient requirements are among the top five causes of poor project estimation (Davis, 1995).
Requirements rework is not only costly but it also slows down your project (Jones, 2000).
Incremental delivery is smart—when it's based on customer priorities and architectural dependencies. It lets you reduce the myriad of risks associated with requirements errors. Adapting agile requirements practices—such as using iterations, creating analysis models, developing low-fidelity prototypes, and co-locating your teams—can reduce development time by 20% to 40% (Lindquist, 2005).
Successful projects use requirements iterations (three or four) and spend more time on analysis modeling and elicitation than less successful teams (Hofmann and Lehner, 2001).
Business agility is enabled by your business analysts’ ability to clearly define and manage requirements (Henschen et al., 2007).
You’ll learn how to define requirements iteratively and incrementally to deliver what you need, when you need it
The right product
Early and continual customer involvement in developing your product requirements is essential. If you don't obtain customer requirements through efficient means, you won't deliver the right product.
You are spending precious time and money defining requirements you won’t even use.
(Standish Group International, 2002b).
Getting the right product means eliminating the many risks associated with requirements. You do that by using sound requirements processes, actively involving users, appropriately documenting requirements, validating and verifying requirements, and managing requirements changes. (Leishman and Cook, 2002).
Defects originating in requirements contribute to about one-third of the total delivered defects in your product. Missing requirements make up the largest portion of these defects. (Firesmith, 2003; Lauesen and Vinter, 2001).
Customers won't buy or use a defective product. A defect is not just a bug in software. A defective product fails to do what the user needs. Your product may be missing functionality, or it may not conform to expected quality attributes.
To get the right product, you need to articulate your requirements early on, before the cost of fixing requirements errors kills your development budget, causes ill will with customers, and jeopardizes your business.
You can learn how to develop your product requirements efficiently and effectively.
For a list of cited research materials, click here.
