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

System developers are inclined to try to reduce variability. That’s just human nature. It seems that the more you think you know and have already decided, the further along you think you are. But that’s often not the case.

While it’s true that variability can lead to bad outcomes, the opposite case can also be true.

Variability is inherently neither bad or good. Rather, the economics associated with the timing and type of variability is what determines the value of the outcomes. And a focus on eliminating variability too soon perpetuates a risk-avoidance culture, where people feel they can’t make mistakes and learn from experience what works and what doesn’t.

Other than a general understanding of system intent, Lean knowledge workers recognize that oftentimes very little is actually known at the beginning of a project. (If it were, they would have already built it!) Traditional design practices, however, tend to drive developers to quickly converge on a single option—an agreed point in the potential solution space—and then to modify the proposed design until it eventually meets the system intent.

This can be an effective approach—unless, of course, one picks the wrong starting point. Then subsequent iterations to refine that solution can waste time and lead to a suboptimal design [1]. And 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 1 [2].

Figure 1. Set-based Design

In this method, 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 learning points. Then, 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 design options open for as long as possible, converges when necessary, and produces more optimal technical and economic outcomes.


Learn More

[1] Iansiti, Marco. “Shooting the Rapids: Managing Product Development in Turbulent Environments.” California Management Review, 38. 1995.

[2] Ward, Allan C. and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute Inc., 2014.

Last update: 22 October, 2017