Traditional approaches to product development tend to be very sequential in nature. Systems designed based on “gates” tend to result in four to six major stages of product development. Very often there is a particular point at which a design is “frozen,” and other activities are triggered, such as sourcing of materials and tooling. However, development processes designed on these principles do not always provide the short lead times that an organization is looking for. As long lead times continue, other problems can also plague the process (Figure 6.1).
◾ Rapid product prototyping: Prototypes are quickly developed to improve the learning process. This technique can support the trys-torming effort described above.
◾ Concurrent or simultaneous engineering: This technique involves
“downstream” participants, such as manufacturing or the supplier, earlier in the learning process. As a result, more thoughtful ques-tions, representing broader perspectives, are asked during the learn-ing cycles. This, in turn, can reduce the number of cycles required to fully learn, thereby improving its effectiveness and effi ciency.
◾ System and parametric design: These concepts can provide a quick assessment of the impact of various design elements on other ele-ments and can reduce negative impacts. For example, a more robust design can be developed in such a way that unexpected variation in the design will not have a negative impact on its performance.
◾ Design of experiments (DOE): This involves the use of effi cient and effective test strategies. Less testing is usually necessary than is typi-cally required by traditional approaches in which one variable at a time is altered and the impact assessed through testing.
Background information on these and other tools are provided in the Appendix.
Figure 6.1 Sequential nature of traditional development processes.
48 ◾ Value Stream Mapping for Lean Development: A How-To Guide for Streamlining Time to Market
For example, the longer the lead time, the more likely it is that interruptions or program or project changes will occur. Therefore, the management of the program or project becomes more complicated. Further, the sequential nature of traditional development processes tends not to promote “concurrent” or “simulta-neous” design, in which suppliers, production, test, and other downstream par-ticipants are involved earlier in the process.
Lean Note
A “phased project planning” process has been practiced by some organiza-tions, in some form, for decades. General Electric adopted such approa-ches, commonly known as “stage-gates,” in the 1980s. Robert Cooper of McMaster University popularized this term and approach in the early 1990s in books and papers that describe a typical stage-gate process consisting of six stages and fi ve gates. Since this time, numerous organizations, and Cooper himself, have worked to streamline this approach by removing one or three stages altogether.
Such approaches are not necessarily incorrect. In fact, great benefi t can be realized by ensuring that specifi c information is available before moving on to the next stage or gate. These checkpoints can correct prob -lems before they move on. Gate approaches tend to be results or mile-stone oriented, as opposed to process oriented. They also tend to be sequ-ential in nature, which can slow the process, particularly at gates where there are inevitable delays in review and approval. Through experience, many organizations have developed ways to avoid some of these
pitfalls.
The Toyota Product Development System makes tremendous use of
“checklists” throughout their development process. The key is that they don’t wait for a gate before they use them. Rather, they are an integrated part of the design process, used and maintained by the functional engi-neering managers themselves.
The Lean product development process is more concurrent. There are really just two phases—a learning or studying phase and an execution phase.
During the study phase, multiple-designed product alternatives are assessed in parallel. The key is to learn as much as possible by exploring multiple alternatives before narrowing down solutions too quickly. This approach ensures involvement of suppliers, tool design, and production from the earli-est stage of the study phase, another form of concurrency. Although this typi-cally results in a longer study phase, the overall development lead time can be reduced signifi cantly. This, in turn, provides other benefi ts to an organiza-tion. For example, there will be fewer interruptions through the life of the program or project.
Lean Development Principles ◾ 49
Most organizations recognize the importance of involving other functions ear-lier in the design process, but few actually put this notion into practice. This can occur for several reasons:
Budgets, funding, etc.: For example, time for production personnel to be
◾
involved in the design process may never have been budgeted, nor fund-ing provided, for this activity. This can be particularly the case in programs where funding is released by a controlling organization, as in a defense contract.
Sourcing practices: Most companies take a frozen drawing and solicit bids
◾
from several potential suppliers, often choosing the low-cost supplier. Such practices require a frozen design that typically is not available until much later in the process. It also makes it problematic to involve suppliers earlier.
“We don’t know who the supplier will be until the bid process is complete.”
Historic behaviors: For example, production may be accustomed to fi xing
◾
design problems once the product is in manufacturing. Therefore, there may be a reluctance to get involved earlier.
As you can see, these are three very big obstacles that get to the heart of an organization’s supplier management, funding, and cultural issues. For example, a Lean development system can require a complete change in the relationship a company has with its suppliers. It requires true supplier partnering—committing to particular suppliers earlier in the development process in order to ensure their involvement sooner, and sticking by those commitments. Now, this may not represent as signifi cant a change as many organizations might think at fi rst. Most companies have a very good idea as to who they expect the supplier to be when they go out for bid. After all, there usually exists a substantial history with par-ticular suppliers. The key is to recognize this fact, and make this a standard part of the Lean development system (Figure 6.2).
Figure 6.2 Concurrent nature of Lean development system.
50 ◾ Value Stream Mapping for Lean Development: A How-To Guide for Streamlining Time to Market
Lean Note
James Morgan and Jeff Liker, in The Toyota Product Development System (2006), identifi ed the two phases of Toyota’s system. The kentou, or study phase, is meant to solve problems, resolve confl ict, and very basically to learn. Here is where the most variability occurs, and Toyota seeks to segre-gate it from the rest of the product development process. Therefore, other participants can work on the execution phase with fewer interruptions.
It is during the kentou phase that multiple design alternatives are pur-sued. In 1995, Ward et al. coined the term, “set-based” concurrent engi-neering, to describe this approach. Tools have been developed to assess alternatives (e.g. trade-off curves).
Equally important, simultaneous engineering is performed during the kentou phase. In Toyota, this is typically accomplished by cross-functional module development teams (MDTs) that are not usually dedicated solely to a single program or project.
Mapping Tip:
An icon that is often used in many development processes is the “narrowing icon.” It is used to show where decisions are made in the process with regard to alternate design solutions under consideration. In most development processes there are key points at which decisions are made to select which particular solutions will continue to be developed in subsequent stages, and which will be discarded. Guidelines to follow regarding the number of desired alternatives that should enter and exit this decision step, as well as the criteria for the narrowing, can be noted adjacent to the icon.
Test Alternatives Build Prototypes
5 : 2 (Cost, Performance
Trade-off curves) Narrowing icon with
guidelines noted