“Generate alternative system-level designs and subsystem concepts. Rather than try to pick an early winner, aggressively eliminate alternatives. The designs that survive are your most robust alternatives.” —Allen C. Ward
In the realm of solution development, uncertainty is an ever-present companion. Variability, be it technical or market-related, permeates the entire development process. It is the nature of innovation itself, for if a guaranteed path to success existed, it would cease to be innovation. Embracing this inherent uncertainty is precisely what makes this business so exciting.
Developers naturally strive to minimize variability as swiftly as possible. The comfort of definitiveness instills a sense of progress. Yet, even in the face of such certainty, variability still lurks.
Variability itself is neither inherently good nor bad; it simply exists. The impact it has on outcomes is determined by the economics of its timing and nature. The goal, therefore, is to manage variability, preserving options and providing teams with the controls and flexibility they need to create outstanding solutions.
This article explores the concept of managing variability and preserving options through set-based design. For a deeper dive into managing variability, check out Principle #7—Apply cadence; synchronize with cross-domain planning.
Table of Contents
Development Occurs in an Uncertain World
Acknowledging the persistent presence of variability in development prompts us to reconsider our approach. Traditional, sequential, and stage-gated development practices push developers to quickly converge on a single, “point-based” option—an agreed-upon point within the requirements and design solution space. It is then modified until it aligns with the system intent. For a while, everyone feels confident in the chosen requirements and design.
However, the likelihood of selecting the optimal starting point is low. Subsequent efforts to force that solution to work result in wasted time and significant delivery problems. This situation is illustrated in Figure 1.
Time for recovery is scarce because we operate early in the “cone of uncertainty” and attempt to create certainty by freezing requirements and design. The larger and more technologically innovative the system, the higher the chances that the agreed starting point was not the best one. Unfortunately, the response to this risk often involves even stricter specifications, even earlier in the discovery process. The problem is not solved; it is compounded.
Preserve Options with Set-Based Design
A better approach, known as Set-Based Design (SBD) or Set-Based Concurrent Engineering (SBCE), is depicted in Figure 2.
With this approach, developers begin by casting a wider design net, considering various design choices from the start. They continuously evaluate economic and technical trade-offs, typically using the objective evidence presented at integration-based learning points. Over time, weaker options are eliminated, leading to convergence on a final design based on the knowledge gained.
This process keeps design options open for as long as possible, only converging when necessary, ultimately resulting in more optimal technical and economic outcomes.
(Note: Due to the scope and economic impact of large systems, set-based design is a fundamental construct of Large Solution SAFe. For more detailed information, including guidance on applying set-based design to fixed schedule commitments, planning impact, and economic trade-offs, read the Set-Based Design article and the Enterprise Solution Delivery competency articles.)
Learn More
- [1] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas, 2009.
- [2] Iansiti, Marco. Shooting the Rapids: Managing Product Development in Turbulent Environments. California Management Review, 38. 1995.
- [3] McConnell, Steve. Software Project Survival Guide. Microsoft Press, 1997.
- [4] Ward, Allan C., and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute Inc., 2014.
