The Return on Investment from Better Requirements

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’d love to give them a nice, tidy answer—but I can’t. As with so many questions in software, the correct answer is, “It depends.” This article explores some of the factors that influence what ROI an organization can expect from better requirements.

If you want to determine the ROI from any activity, you need to know both what you invested 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 activities should begin with some kind of appraisal. You need to learn how your teams are dealing with their requirements issues today and whether those current approaches yield the desired results. You might begin with the “Current Requirements Practice Self-Assessment” available at http://www.processimpact.com/goodies.shtml.

Developing new processes and templates. Once you’ve identified specific areas 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 or modifying templates for your key requirements deliverables. You can start with the sample templates for a vision and scope document, use cases, and software requirements specification available from http://www.processimpact.com/goodies.shtml. 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. Give your BAs the reference books and articles they need to refresh their knowledge and get ideas for handling new challenges. 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 seek 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.

Buying requirements tools. Written requirements documents have numerous limitations. As your requirements activities become more sophisticated, you might elect to store requirements in a database rather than in traditional word processing documents. Dozens of 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 easy to store attributes that provide a rich understanding of each requirement, to track requirements status, to deal with changes, and to record requirements trace information. Other tools can help with requirements elicitation, modeling, simulation, analysis, and prototyping. Make sure your tools don’t become expensive shelfware, though. Chapter 30 of my book co-authored with Joy Beatty, Software Requirements, Third Edition (Microsoft Press, 2013), offers many tips on getting the most from your requirements management tool investment.

Of course, the greatest investment is the time your project team members spend eliciting, analyzing, documenting, validating, and managing the requirements for their products. Though not trivial, this effort will almost certainly accelerate your project, amply rewarding the additional investment you’re making in high-quality requirements.

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 requirements problems. If your teams must 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. 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 consulting clients has measured it, though. This organization 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 using the software inspection technique.)
• 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 way to discover where your leverage lies for quality and productivity improvement.)
• How much maintenance cost—defect correction, unplanned enhancements, customer support—can you attribute 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 your business bottom line by reducing the costs of building and maintaining software. Practices that result in fewer requirement defects will reduce the amount of 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, wrong, or badly implemented.

Besides these obvious practical benefits, improving your requirements 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 then 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’s that worth to you? It might be hard to measure, but it’s real.

Author: Karl Wiegers, Process Impact