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

Principle #3 – Assume variability; preserve options

Solution development is an inherently uncertain process. Technical variability and market variability are present throughout the development process. Innovative new systems have, by definition, never been developed before, so there is no guaranteed path to success. If there were, it wouldn’t be innovation. That’s why we love this business.

To assure forward progress, system developers are inclined to reduce variability as quickly as possible. The more deterministic things are, the better we feel. That’s just human nature. It seems that the more we think we know and have already decided, the further along we think we are. And that’s true up to a point, but even then variability is a constant presence.

Variability is inherently neither bad or good—it just is what it is. But it’s the economics associated with the timing and type of variability that determines outcomes. The goal is to manage variability, and to preserve options, providing the controls and flexibility teams need to build great solutions.

This article describes how to manage variability and preserve options with set-based design. For more on managing variability, see Principle #7—Apply cadence; synchronize with cross-domain planning.

Preserve Options with Set-Based Design

Acknowledging the continued presence of variability in development causes us to reexamine our approach. Traditional, sequential, stage-gated development practices drive developers to quickly converge on a single option—an agreed to point in the requirements and design solution space—and then modify the design until it eventually meets the full system intent. Everyone feels good that they have the right requirements and the right design. At least for a while.

Indeed, this can be an effective approach—unless, of course, one picks the wrong starting point. Then subsequent iterations that are done to refine that solution can waste time and lead to significant delivery problems, as illustrated in Figure 1 [2].

There just isn’t enough time to recover. This is because, knowingly or not, we are operating early in the ‘cone of uncertainty’ [3] and attempting to force certainty by freezing requirements and design.  The bigger and more technically innovative the system is, the higher the odds are that the agreed starting point was not the best one.

A better approach, referred to as Set-Based Design (SBD) or Set-Based Concurrent Engineering (SBCE), is illustrated in Figure 2 [4].

In this approach, developers cast a wider design net initially, considering multiple design choices at the start. After that, they continuously evaluate economic and technical trade-offs—typically as exhibited by the objective evidence presented at integration-based learning points. Then, as Figure 3 illustrates, they eliminate the weaker options over time and ultimately converge on a final design, based on the knowledge gained to that point.

This process leaves the design options open for as long as possible, converges when necessary, and produces more optimal technical and economic outcomes.

(Note: Due to the scope and economic impact of big systems, set-based design is a fundamental construct of Large Solution SAFe. For more information, including guidance on applying set-based design to fixed schedule commitments, planning impact, and economic tradeoffs, read the Set-Based Design article and the guidance in the Enterprise Solution Delivery competency article.)

Learn More

Last update: 10 February 2021