A while back, Ellen Gottesdiener from EBG Consultants assembled a list of citations about ROI and requirements titled Do You Know Your ROI on Your Requirements Work. Ellen did an excellent job researching this topic and presents a comprehensive list of citations in her article.
Also, Ellen and her business partner Mary Gorman have recently published a new book with the title Discover to Deliver: Agile Product Planning and Analysis. Ellen and Mary did a great job on this book and I would recommend it to all business analysts, and especially the ones involved in product management.
Below is a brief extract from Ellen’s article.
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 up to 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’s 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., 999; McConnell, 1996; Boehm and Papaccio, 1988).
- You save money by getting requirements right the first time. 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. (Ellen Gottesdiener)
Collaboration and User Input:
- 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. (Ellen Gottesdiener).
- 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, 1996).
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 etal, 2007).
Deliver 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. (Ellen Gottesdiener)
- You are spending precious time and money defining requirements you won’t even use. (Ellen Gottesdiener)
- 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. (Ellen Gottesdiener)
- 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, or jeopardizes your business. (Ellen Gottesdiener)
[cta id=”7434″]