Everyone who participates in the product development process in some way is familiar with the agony of late-stage changes, sometime called loopbacks. Whether it’s an unexpected failure in prototype testing or a manufacturability issue that appears during production ramp-up or a warranty issue in the field, making design or engineering changes late in the game produces a tremendous amount of waste. Development teams strive hard to avoid them, yet almost all practitioners consider loopbacks as inevitable, and indeed even plan for them. But from a lean perspective, this is regrettable because a loopback is just rework under a different name. Developers design, analyze and test their product or process, only to have to repeat those same activities at a later date.
Just like on the production floor, loopbacks (or rework) can be tremendously costly. It is widely recognized that the cost of making changes increases over product development project timeline. As shown in the figure at the right, for most manufactured products, the cost to make a change during the design phase is cheaper than during the prototype phase, which is cheaper than when the product is in production. And most would agree that the cost curve is geometric. In fact, some have said that the cost to make a change in any given stage is ten times more expensive that the immediately preceding stage! So we can see that late-stage changes can be costly indeed.
The common advice to head off the problem of loopbacks is to “frontload” the product development process. But what does frontload mean?
Some have suggested that it is wise to start a product development project by accumulating what we already know. For example, manufacturing engineers can supply the team with information on the process capability of their current manufacturing equipment at the start of the project. Then the product designers can (hopefully) design within those constraints to minimize problems on the plant floor while improving quality and efficiency. The challenge with this suggestion is, of course, in the accumulating of the knowledge. But it is also in the translation of that knowledge from process terms into terms that product designers can understand. Lean companies devote significant effort to catalog their process capability on a continual basis so that the knowledge is ready to deploy with any new product development projection.
Others have recommended to front-load development projects by putting together cross-functional teams from the very start of the project. Teams consist of capable representatives from all functions necessary to bring a product to market: sales/marketing, product engineering, industrial design, manufacturing engineering, purchasing, and finance, for example. The idea is to ensure that all viewpoints are considered from the early stages to avoid unexpected “discoveries” late in the process. But one question often nags these teams: what should they do in those early phases?
Stefan Thomke recommends rapid experimentation in order to learn about product and manufacturing process possibilities. We can extend Thomke’s idea with Allen Ward’s notions of set-based design, what we now term set-based innovation.
In a set-based approach to development, teams engage in very different way with the development challenges they face versus conventional approaches. The core practices of set-based innovation are:
- Generate multiple alternative solutions for every design sub-problem identified.
- Understand those solutions against design requirements by generating data through analysis, modeling, and low-cost prototyping. Pay attention to the granularity of data needed – use low fidelity models when quick-and-dirty answers are needed, for example.
- Eliminate an alternative when the data show that it either cannot meet the requirements, or is clearly inferior to another alternative. Avoid selecting an early winner—use an elimination process instead.
- As you go, try to generate reusable knowledge in the form of design limits and tradeoff curves. If you understand the physical limits of a design concept, and those limits fall outside the requirements, you can safely eliminate that alternative.
- Allow some flexibility in design requirements so that you can use the knowledge gained to set the final requirements at a point where you more fully understand the trade-offs being made.
What are you doing to avoid loopbacks? What are other ways you have used to eliminate rework in development? Do you have examples of any of the above approaches? Share your thoughts and ideas so we can all learn more.
