Set-Based Design

Quality is decided by the depth at which the work incorporates the alternatives within itself, and so masters them.
—Theodor Adorno

Assume variability; preserve options.
—SAFe Principle #3

Set-Based Design Abstract

Systems development can be described as a process of continuously reducing uncertainty to knowledge. No matter how well a system is initially defined and designed, real Customer needs and technological choices are both uncertain, and therefore the understanding of how a system needs to be implemented will have to adapt over time to reflect reality.

Point-based design—the process of committing to a specific, detailed requirements and system design early in the process—deprives the system developer of the potential benefit of later, more empirical data, which becomes available only as system development proceeds. The discovery that the chosen design doesn’t work occurs far too late in the process, making it impossible to recover with any grace.

Set-Based Design is a practice that maintains multiple requirements and design options for a longer period in the development cycle. Later, as the deadline approaches, it uses empirical data to collapse focus to the final design option. With such an approach, systems builders can assume variability and preserve options late into the game, providing for maximum flexibility of approach rather than binding early to a final option.


Point-based design commits to a set of requirements and a single design strategy early in the process. It often leads to late discoveries that require substantive rework as the deadline approaches, necessitating shortcuts, quality compromises, and, worse, missed program commitments and deadlines. This is one of the primary problems with system development when it follows a traditional, linear (waterfall) requirements > design > implementation > test approach, and it is one of the main reasons for the continual cost and schedule overruns of such processes.

Set-Based Design (SBD) maintains multiple design options through a longer period in the development cycle. Set-based design is an important practice for economic efficiency in Lean product development and is described further in [1] and [2]. Figure 1 shows the conceptual difference between set- and point-based design approaches.

Figure 1. Point-Based Design commits to a design up-front. Set-Based Design maintains multiple alternatives for a longer period.
Figure 1. Point-based design commits to a design up front. Set-based design maintains multiple alternatives for a longer period.

Set-Based Design and Fixed-Schedule Programs

Set-based design is particularly effective in programs that require a high degree of fixed schedule commitments. After all, since the schedule is unmovable, it makes sense to keep multiple design options present, even if some of the more reliable design options do not necessarily provide the degree of innovation or enhanced performance that the systems developers would otherwise prefer. But when the deadline is sacrosanct, teams must do what they can within the schedule.

Achieving Economic Efficiency with Set-Based Design

Of course, maintaining more than one design option also comes at a cost—the cost of developing and maintaining the options, even if they are mostly model or paper based. (Note: Reinertsen [3] points out that maintaining multiple design options is one form of U-curve optimization, and sometimes the optimum number on the curve is one!) But in the case of a high degree of innovation or variability, and in the case of immovable deadlines (“This crop combine must leave the factory in January”), a set-based design may be the best choice. In this case, design efficiency depends on a number of factors:

  • Flexibility – preserving a broad set of design options for as long as possible
  • Cost – minimizing the cost of multiple options through modeling, simulation, and prototyping
  • Speed – facilitating learning through early and frequent validation of design alternatives

In order to achieve this efficiency, some recommended practices are described below.

Specifying Interfaces and Requirements, Not Design

Complex systems are built out of subsystems and component elements, which collaborate to produce system results. While elements may have different levels of coupling, design flexibility can be increased by specifying the performance requirements and interfaces rather than how an element achieves its result. This abstraction to a higher level of concern provides a broader spectrum of design options, as different designs of an element may each potentially satisfy the predefined interfaces.

For example, perhaps a team is developing a new CNC lathe, one with substantially higher performance requirements than an existing model. Specifications for increased operating speeds will have specific implications on certain components. Designers might have a choice of analog servo control motors or stepping motors. Stepping motors would decrease manufacturing cost but might not be able to meet the performance requirements. Maintaining both options for some period during the design process could help with the right economic trade-offs.

In addition, specifying interfaces supports building incrementally with fast, integrated learning cycles. In the lathe example, having agreed upon certain interfaces, the team can test the prototype lathe on the fixture with each type of component, without changing other elements of the design.

Modeling, Simulation, and Prototyping

The process of modeling, simulating, and prototyping allows for empirical system validation early, and it provides early learning points that will help eliminate some design alternatives and validate others. Model-Based Systems Engineering is a disciplined, comprehensive, and rigorous approach to modeling. These techniques should be applied to the aspects of the system where the highest risk is likely to occur, thereby significantly reducing the cost of maintaining design alternatives for a longer period of time.

Frequent Integration Points

During development periods where new designs are in flight, uncertainty abounds and true knowledge is scarce. The only way to resolve the uncertainty is to test the design via early and frequent integration of the system components. In SAFe, these integration points are driven in part by System Demos, which occur on a fixed two-week cadence, and by Solution Demos, which typically occur on the longer Program Increment (PI) cadence. In fact, without this frequent integration, SBD practices may create a false sense of security and thereby even increase risk, as perhaps none of the design alternatives will really meet the necessary performance requirements. Frequent integration supports this empirical learning with new knowledge that is used to reduce options as the system evolves, as Figure 2 illustrates.

Figure 2. Frequent integration provides critical learning points that narrow design alternatives
Figure 2. Frequent integration provides critical learning points that narrow design alternatives

Frequent system integration is even more critical when system development initiatives involve Suppliers. Even when interfaces are carefully defined, if there is infrequent integration then unexpected findings will occur too late, often leaving no time or resources to respond to the impending deadline.

Adaptive Planning

Explicit and regular planning provides the opportunity for evaluating different design alternatives and directly supports set-based thinking. PI Planning defines the overall intent for the PI and fosters alignment on the constraints and requirements that will govern the design alternatives under consideration. Iteration Planning plays a more tactical role, allowing teams to adjust during PI execution as they learn more from frequently integrating and reviewing increments of value.

Economic Trade-offs in Set-Based Design

Different design options have different economic implications, so understanding set-based design requires an understanding of the macroeconomic goals and benefits of the system. One way to look at this is to place the alternatives on a spectrum, where a certain “weight” can be associated with each option.

Some of the economically significant indicators may include cost of development, cost of manufacturing, performance and reliability, cost of support, development time, and technical risks. These indicators help illustrate which design options provide the greater benefit. In the earlier lathe example, for instance, the trade-off between the accuracy of various types and brands of motors and the cost of manufacture can make a big difference, as Figure 3 demonstrates.

Figure 3. A trade-off curve between an economic indicator (Cost) and a performance requirement (Error Margin) provides guidance for choosing amongst set-based designs
Figure 3. A trade-off curve between an economic indicator (Cost) and a performance requirement (Error Margin) provides guidance for choosing among set-based designs

In summary, up-front commitment to a specific, detailed design can rarely survive contact with empirical evidence. With a proper understanding of the economic trade-offs, set-based design provides an adaptive approach with a wider systems perspective and provides for better economic choices and more adaptability to existing constraints.


Learn More

[1] Ward, Allen, and Durward Sobek. Lean Process and Product Development. Second edition. Lean Enterprise Institute, Inc., 2014.

[2] Oosterwal, Dantar. The Lean Machine. Amacom, 2010.

[3] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.



Last update: 31 March 2016