Front-loading activities (uploading) in Product Development
Everyone involved in the product development process is familiar, in one way or another, with the agony of late-stage change, known as loopbacks (rework). Whether it is an unexpected failure in prototype testing, a manufacturing problem that shows up during production launch, or a warranty issue, making late design or engineering changes produces a staggering amount of waste. Development teams work hard to avoid them, yet almost all practitioners consider loopbacks inevitable and, in fact, even plan on them. But from a lean perspective this is unfortunate, because a loopback is nothing more than rework by a different name. Developers design, analyze and test their product or process only to have to repeat those same activities later.
Just as on the shop floor, rework can be extremely expensive. It is widely recognized that the cost of making changes rises as you move along the timeline of a product development project. As shown in the figure above, for most manufactured products, making 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 people would agree that the cost curve is geometric. In fact, some have said that the cost of making a change at any stage is ten times higher than at the stage immediately before it! So we can see that late changes can indeed be expensive.
The common advice for eliminating the problem of loopbacks is to front-load some activities in the product development process. But what does front-loading mean?
Some have suggested that it is smart to start a product development project by accumulating what we already know. For example, manufacturing engineers can provide the team, at the start of the project, with information about the capability of their current manufacturing equipment. Product designers can then (we hope) design within those constraints to minimize problems on the shop floor while improving quality and efficiency. The challenge with this suggestion is, of course, accumulating knowledge. But it is also translating that knowledge from process terms into terms that product designers can understand. Lean companies devote a great deal of effort to cataloging their process capability on an ongoing basis so that the knowledge is ready to be deployed in any new product development project.
Others have recommended front-loading development projects by bringing cross-functional teams together from the start of the project. The teams consist of capable representatives of all the functions needed 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 points of view are considered from the earliest stages to avoid unexpected “discoveries” later. But one question often nags these teams: what should they be doing in these early phases?
Stefan Thomke recommends rapid experimentation in order to learn about the possibilities of the product and the production process. We can extend Thomke's idea with Allen Ward's notions of set-based design, which we now call set-based innovation.
In a set-based approach to development, teams engage with the development challenges they face in a very different way compared with conventional approaches. The main practices of set-based innovation are:
- Generate multiple alternative solutions for every identified design subproblem.
- Understand these solutions against the project requirements by generating data through analyses, models and low-cost prototypes. Pay attention to the granularity of the data needed – use low-fidelity models when quick, rough 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 picking a winner early – use a process of elimination.
- As you go, try to generate reusable knowledge in the form of design limits and trade-off 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 the project requirements so that you can use the knowledge gained to set the final requirements at a point where you more deeply understand the trade-offs at play.
What are you doing to avoid loopbacks? What other ways have you used to eliminate rework in development? Do you have examples of any of the approaches above? Share your thoughts and ideas so that we can all learn more.
