At every stage, companies risk stumbling into pitfalls that can cause development and product costs to soar, resulting in offerings that do not meet customers' needs. To avoid these pitfalls, companies must establish a disciplined approach to managing requirements at each stage in the product development process. Although effective requirements management is a complicated process with many moving parts, we find that best-in-class companies tend to excel at three specific aspects (Exhibit 1):
- Matching requirements to actual customer needs during concept definition
- Ensuring that requirements are met during development
- Efficiently managing the inevitable change requests that crop up throughout the product development process.
Companies that adroitly manage all three have the best chances of not only satisfying their customers (and keeping them satisfied) but also minimizing their operating costs. And that can translate into the healthier profit margins that come with rising revenues and decreasing costs. In fact, we have seen up to a 10 percent material-cost reduction for companies that invest in optimizing requirements—rather than just procedurally defining and managing them. We expect an increase in customer satisfaction as well, since the requirements are better targeted at customers' true needs. With these advantages in mind, let us take a closer look at each of the dimensions.
Matching requirements to actual customer needs during concept definition
In the early phases of product development—including concept definition—companies typically conceptualize the overall design of the new or refined offering. They also set baseline requirements reflecting customer needs (such as product features and performance) and define cost targets.
Managers often arrive at these initial requirements simply by copying them from a predecessor product, adding some requirements that reflect new features planned for the next-generation product, and perhaps deleting a few requirements for an out-dated feature. They seldom validate whether the existing and the new requirements truly matter to the intended customer. This can lead to a bloated set of legacy requirements, and, consequently, a product concept that moves ahead in the product development process even though it does not precisely accommodate customers' needs or demands cost overruns to meet unnecessary specifications.
To excel at this dimension of requirements management, companies must take a decidedly different approach: defining product features rather than concepts, and basing requirements on an accurate understanding of customers' needs and their willingness to pay (Exhibit 2). To do so, managers can assess the best functional concepts in the market, drawing on advanced data-analytics tools and methodologies. Several tools are readily available to help managers get this first set of requirements right:
- Internal and competitor product review. A company makes an initial comparison of its own products and its competitors', which provides a good starting point to understand how customer needs are translated into requirements. It also helps to identify the most concrete definition of requirements.
- Best of benchmark. During a best-of-benchmark effort, a company asks for quotes on its own and competitors' concepts. Using feedback from suppliers, the company then identifies the most cost-efficient concept to meet a customer need. The benchmarking also gives the company an opportunity to grasp innovative ideas from several suppliers.
- Requirements database. Companies that build a database with all relevant existing requirements and best-of-benchmark results have a rich pool of information to choose from to define the best starting point for concept requirements.
- Rapid customer testing. Depending on the types of products being developed, new technologies may help to run rapid-prototyping and customer-testing efforts to sharpen requirements in an early phase of the process (see sidebar "Spotlight on new technologies and big data").
Ensuring that requirements are met during development
After setting the right initial requirements in the concept definition stage, managers shift focus to the development stage for the product in question. Here, the product concept is chosen and a detailed design is completed, down to the level of concrete components.
Many products are complex—comprising multiple systems, subsystems, and components. In such cases, the original product-level requirements must be cascaded down to inform the design of lower-level elements. Poorly managed handoffs at each of these intersections can lead to mistakes. The most common among them is that designs for lower-level elements are over- or underspecified compared with the initial product-level requirements. Those mistakes must be fixed later, at additional cost in the form of both time and money.
The so-called V-model of product development, though it has its detractors, is still a widely used process framework in engineering-centric industries. It can thus be a good device for managing these requirements and design handoffs during the development phase (Exhibit 3).
World-class companies ensure that the handoff from product-level requirements to system-, subsystem-, and component-level requirements happens through structured interfaces. During each handoff, they analyze the derived requirements on the next level and the defined architectural design to see how well they support the requirements on the level immediately above. Companies can use a couple of different tools to address that challenge:
- They can install a handover process, in which providers of both system and subsystem requirements align on whether the breakdown was done effectively along a process checklist.
- Companies can also install a challenge board at defined points in the development process. Here, a cross-functional team reviews a set of the most important requirements—for example, with information from a requirements database, other current products, or competitor products—and challenges requirements for cost efficiency and fit with customer needs.
In addition to ensuring an effective "vertical" handover of requirements, it is important to align requirements along the "horizontal" axis as well. Often, testing and validation procedures do not fit the set of initial requirements, and they may deliver results that lead to unnecessary changes in the product design or to sign-off on products that do not meet customer needs and call for costly, late changes. Test procedures often overspecify testing, thereby holding the product to implicit, unnecessary requirements. Or test procedures neglect to test important requirements, resulting in late changes to accommodate what was missed in the design.
Companies therefore need to implement a system where testing procedures and targets are frequently questioned and aligned with the respective product requirements, using similar tools to ensure consistency in the vertical requirements.
Efficiently managing the inevitable change requests that crop up throughout the product development process
Reducing deviations from the initial product level requirements helps minimize costly errors and delays. At the same time, it is an unavoidable fact that new and unexpected realities emerge during the development process—especially for projects whose development unfolds over multiple years. Technologies advance. New rivals muscle into the competitive arena. Customers want something different. And these are just the external forces that can throw a wrench into the development process. Internal forces, such as unexpected test results, can have the same impact.
Such changes can trigger those all-too-familiar fast-track change requests that can crop up during any stage of the development process. However, requests that come in very late in the process pose the risk that managers will disregard initial requirements so as to speed up the implementation of a change.
Regardless of the nature or cause of changes, many of them are time critical, and it is all too easy for managers to execute the changes without fully considering the impact on the product's requirements. This can cause the resulting product incarnations to morph away from the original concept and all its associated requirements with the respective customer value and cost implications.
For these reasons, companies need to build flexibility—but in a disciplined way—into their requirements management approach. Ideas for doing this include the following:
- Make a check on requirements impact a required step in the engineering change process.
- Create an accessible, easy-to-use database containing key requirements, which managers can easily check during change request processing.
- Use the database to foster transparency of data, so managers can readily compare requirements across similar projects.
A case in point: Matching requirements to actual customer needs during concept definition
An automotive OEM we worked with set up a requirements review process as part of a larger program aimed at reducing material costs. The company identified classical cost reduction levers first, such as changing materials as part of design-to-cost reviews. But after optimizing the existing requirements for a new vehicle model, executives wanted to find ways to unlock additional value (for customers and for the company) through more effective requirements management. The initial focus was on improving how requirements mapped to actual customer needs; the company aimed to unlock further material-cost savings by understanding which requirements, disconnected from actual customer needs, were driving additional costs that customers did not value.
First, the company reviewed the new requirements and compared them with those of the predecessor. We worked with it to identify differences and consider them alongside internal and external products in cross-functional workshops. Here, we intensely questioned how well each requirement matched customers' needs. To assess the implications of these analyses, reduce the number of requirements, and unlock cost-saving opportunities, the company assembled a cross-functional board comprising representatives from R&D, as well as core owners of requirements such as sales, quality control, and design.
By challenging each requirement's validity, the board discovered that many of the requirements had little relevance to customers. For instance, one called for a specific color of black for the engine compartment plastics—a color difficult to distinguish from the standard black used by most competitors. The discrepancy was hardly noticeable in a laboratory environment, and customers were even less likely to see any difference. Changing the requirements back to the standard plastic unlocked significant savings potential.
In addition, we benchmarked select features to find out how well other concepts developed at competing companies delivered against customers' needs and what their requirements looked like. We used a supplier-based best-of-benchmark method to carry out this analysis.
All of these efforts paid big dividends. Specifically, the company identified opportunities to lower material costs by as much as 10 percent for the component areas reviewed by removing features based on requirements with little appeal for customers.
* * *
The notion of taking a more rigorous approach to requirements management—by matching requirements to real customer needs, ensuring that requirements are met during development, and managing change requests during the process—may seem simple. But many companies have difficulty establishing the discipline, systems, and structures needed to adopt this approach. Technological advances have made the process easier, and we believe now is the time for companies to explore it. Even more important, in this era of accelerating change and stiffening competition, no company can afford to ignore an opportunity to enhance its bottom line by boosting efficiency and effectiveness in core business processes such as product development. The requirements management approach we describe here is a powerful ally in this race.
About the authors: Carlos Felip is a consultant in McKinsey’s Madrid office, Eric Hannon is a partner in the Frankfurt office, and Marius Weigand is an alumnus of the Berlin office.