The Return on Investment from Better Requirements

Requirements & Requirements Management

The Return on Investment from Better Requirements

By |

Managers often ask me what return on investment (ROI) they can expect from the money they spend on training, process improvement, and tools for requirements engineering. I can’t give them a nice, tidy answer. As with so many questions in software, the correct answer is, “It depends.” In this article I discuss some of the factors that contribute to determining what ROI an organization can expect from better requirements.

The Investment

If you want to determine the ROI from any activity, you need to track both what you invested in the activity and the benefits—reduced costs, accelerated schedules, increased sales, whatever—you enjoyed as a result. Unfortunately, few software organizations collect this sort of data. It’s not hard to track the money and time your organization spends developing improved requirements. Measuring the payback is trickier.

Following are some of the actions you might take to improve your requirements processes and hence the product requirements themselves. Track what you spend on these activities to determine your investment.

Assessing current practices. All process improvement should begin with some kind of appraisal. You need to learn how your teams are dealing with their requirements issues today and how those current approaches do and do not yield the desired results. You might begin with the “Current Requirements Practice Self-Assessment” available at the Process Impact website.

Developing new processes and templates. Once you’ve identified specific requirements practices that are ripe for improvement, your teams need to devise processes that will work better for them. This might involve writing entirely new processes, modifying current processes, and selecting templates for your key requirements deliverables. You can start with the sample templates for a vision and scope document, use case document, and software requirements specification available from the Process Impact website. Adapt these to meet your project needs as appropriate.

Training the team. It’s not reasonable to expect your team members to work in new ways if they haven’t been taught how to perform the new practices. All business analysts and others who must deal with requirements should receive some basic training in requirements engineering concepts and practices. The team members also need guidance in the effective use of your own processes and templates.

Acquiring books and other resources. Requirements engineering is a complex domain with many concepts and practices. Your BAs will benefit from having reference books and articles at hand so they can refresh their knowledge and get ideas for handling new challenges they encounter. Books are a high-leverage investment, assuming that team members actually read them and apply what they learn.

Employing external consultants. Some software organizations pursue improved requirements approaches on their own. Others prefer to acquire assistance from experienced consultants who have worked with a variety of companies. Consultants aren’t cheap, but they can help your team members solve problems much faster than they might solve those problems on their own.

Written requirements documents have numerous limitations. As your requirements engineering activities become more sophisticated, you might elect to store requirements in a database rather than in traditional word processing documents. Nearly three dozen commercial requirements management tools are available. Descriptions and comparative information are available at http://www.incose.org/ProductsPubs/Products/rmsurvey.aspx and http://www.volere.co.uk/tools.htm.These tools make it far easier for you to store attributes that provide a rich understanding of each requirement, to track requirements status, to deal with changes, and to record requirements traceability information. Chapter 23 of my book More about Software Requirements (Microsoft Press, 2006) offers many tips on getting the most from your tool investment.

Of course, the greatest investment you make in developing superior requirements is the time your team members spend eliciting, analyzing, documenting, validating, and managing the requirements for their products. As we saw in the previous section, this is likely to accelerate your project, amply rewarding the additional investment in quality requirements.

The Return

I can’t predict what ROI you’re going to get from your investment in developing better requirements. There are too many variables, most of which depend on the performance of your own teams. However, I can help you think through what the payback might be for your organization. The return you can expect to receive depends on the price your projects are currently paying for shortcomings in your requirements. If your teams are forced to perform extensive rework to deal with overlooked or inaccurate requirements, you’ll obtain a better return than if requirements issues are just a minor nuisance. Before you dive into requirements process improvement, consider the following questions.

  • What fraction of your development effort is expended on rework? (Few software organizations can answer this question. Those that have measured it find that rework can consume 30 to 50 percent of all the effort expended on a software project. Some rework is unavoidable and adds value but much rework constitutes wasted effort.)
  • How much does a typical customer-reported defect cost your organization? A system-test defect? (Every organization should know this. To my knowledge, only one of my clients has measured it, though. They spent an average of $4,200 to deal with each customer-reported defect. Contrast this with their average cost of just $200 to discover a defect by inspection.)
  • What fraction of user-reported defects, and what fraction of defects discovered through system testing, originate in requirements errors? (Defect root cause analysis is an excellent technique for determining where your leverage lies for quality improvement.)
  • How much maintenance cost—defect correction, unplanned enhancements—can be attributed to missed requirements or other types of requirement defects?
  • How much do you think you could you shorten your delivery schedules if your project teams could reduce requirement defects by, say, fifty percent?

The goal of software process improvement is to improve the bottom line of your business by lowering the costs of building and maintaining software. Adopting practices that result in fewer requirement defects will reduce the amount of development rework your teams must perform. Performing less rework has a direct payback through reduced product development costs and quicker time to market. Techniques that get your BAs and customers working closer together lead to products that better meet customer needs. Superior requirements development also lowers your maintenance and support costs. Many products have to be modified immediately after release when the customers realize some critical functionality is missing or wrong.

Besides these obvious practical benefits, improving your requirements approaches leads to less tangible outcomes that are valuable but hard to measure. Experiencing fewer miscommunications on a software project reduces the overall level of chaos. Less chaos lowers unpaid overtime, increases team morale, boosts employee retention, and improves the team’s chances of delivering on time. And all of the benefits I’ve described here have the potential of leading to higher customer satisfaction. What is that worth to you? It might be hard to measure, but it’s real.

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.  Karl Wiegers is an independent consultant and not an employee of Jama.  He can be reached at http://www.processimpact.com.  Enjoy these free requirements management resources.

 

Karl Wiegers
Latest posts by Karl Wiegers (see all)