Lean Product Development Gets Its Due16 Jul, 2008 By: Jeffrey Rowe
While lean production methods get more notoriety, lean product development is starting to receive the attention it deserves as well.
Most of our readers are probably familiar with the terms and concepts of "lean manufacturing" or "lean production." These terms have been around for many years and their principles have been universally applied, but their greatest level of adoption has been in the automotive industry. What we in the United States now know as lean manufacturing is actually a generic term applied to the Toyota Production System (TPS). The TPS combines management philosophy and practices to form an integrated social-technical system at Toyota. The TPS organizes manufacturing and logistics for the automobile manufacturer, including interaction with suppliers and customers.
The main goals of the TPS are to design out and eliminate waste. While eliminating waste seems simple and clear, waste is often conservatively identified and inadequately addressed. TPS targets seven kinds of waste for improving the production process:
- overproduction (production ahead of demand)
- motion (people or equipment moving or walking more than is required to perform the processing)
- waiting (waiting for the next production step)
- conveyance (movement of products that is not required to perform the processing)
- overprocessing (due to poor tool or product design)
- inventory (all components, work-in-progress, and finished product not being processed)
- correction (the effort involved in inspecting for and fixing defects with associated rework and scrap)
Although the TPS for manufacturing has received a lot of attention, just as important is how Toyota actually develops products, called Toyota's Product Development System (TPDS).
Functional engineering managers are the primarily teachers in TPDS. Authority is based on knowledge, especially technical knowledge. Engineers are judged on their knowledge and use of technical information, such as tradeoff curves. Instead of an elaborate set of detailed subschedules, a set of key integrating events, such as styling approval, tooling release, etc., are established with very specific target dates. At the subsystem level, engineers create multiple alternative solutions for each component, instead of designing one component variation to match a master solution. Over time, each alternative is evaluated against performance tradeoffs. Weak ones are eliminated and new ones are created, often from combining components in new ways. Redundancy is built into the system, thereby reducing risk.
The TPDS is described in great detail in an excellent book by James Morgan and Jeffrey Liker titled The Toyota Product Development System: Integrating People, Process and Technology. It is probably the most comprehensive book on the TPDS. In it, Morgan and Liker refer to the Lean Product Development System, but it is really Toyota's, not "lean" as practiced by other companies. The book is the result of research at the University of Michigan headed by the late Alan Ward and discusses 13 principles of lean product development. All the examples compare vehicle development between Toyota and North American car companies, but the principles can be applied to any type of product development.
The goal in lean production is to eliminate material waste through the entire supply chain. The analogy in product development is the waste-free flow of knowledge throughout the entire development supply chain all the way into production. Knowledge is the result of learning, and most learning is from what does not work rather than what does. This is the foundation of the TPDS and what lean product development is all about.
Knowledge-Based Product Development
While researching this article, I came across Targeted Convergence Corporation, a company that has championed the cause of learning and knowledge as the foundations of product development. I spoke with its founder and CEO, Michael Kennedy, about the significance of employing as much knowledge as possible during the product development process. He had several interesting insights as to what it is and how it is positively affecting companies that have adopted the philosophy.
Kennedy refers to Toyota's approach as knowledge-based product development (in which knowledge and technical expertise drive decision making), in contrast to "structure-based" development that is more typical at American manufacturers, where process structures, procedures, and controls drive decision making, with recommendations coming from nontechnical middle managers.
Automotive manufacturers are notoriously secretive about their design practices, so getting specifics is virtually impossible, but we know that in many automotive companies it's not uncommon to have a majority of the engineering workforce solving problems after a product is released to manufacturing. At Toyota, Kennedy estimates that this number is in the 5-10% range — a huge advantage.
According to Kennedy, Toyota doesn't believe it develops automobiles. Instead it continually develops knowledge about automobiles and applies it. He said, "Toyota's product development is all about consistent and planned knowledge from the subsystem level [brakes, interiors, etc.] up, not from the finished car down. If the knowledge part of the equation is addressed correctly, the cars will take care of themselves and emerge naturally from the interaction of gaining and applying knowledge."
Obviously, the product development process is quite a bit different from a manufacturing process, in that the core "material" is not physical objects, but knowledge and information that cannot be seen and touched. The opportunities for waste in the product development system are, however, quite similar to those found in manufacturing operations. Waste is possible with tangible things, such as physical materials, as well as intangible things, such as ideas and knowledge. Just as they are both possible, they are also both manageable, largely by technical and cultural changes within companies.
Test First, Then Design
Kennedy said that the typical product development paradigm is design and test. This paradigm involves first designing a product, testing to see if it works, then iterate until you get it right. This method is full of loop-backs and involves too many guesses for solving the design problem. Toyota finds this method fundamentally flawed and reverses the development paradigm with a sequence of test, then design. Testing first lets Toyota gain the knowledge it needs to eliminate design loop-backs, as well as understand where knowledge gaps are and resolve them.
According to Kennedy, Toyota developed the basic underpinnings of the TPDS from observing the Wright brothers and the "test before design" philosophy they employed while inventing the airplane. Before they ever built a physical airplane, they knew they had to eliminate knowledge gaps in the three fundamental areas for making an airplane fly: lift (wings), thrust (propeller), and control. They performed many tests and solved the problems in these three areas. Once solved, they felt their success was ensured, then they started building an airplane that eventually flew. This test before design philosophy is what Toyota basically still uses today, with great success.
In Kennedy's mind, the knowledge-based product development philosophy promoted innovation at the subsystem level that can be used across projects and a product portfolio and the knowledge it takes to create them. Knowledge-based product development is an interlocked system, not a collection of disconnected techniques. It does not concern itself with discrete projects, but rather, provides a continuum of knowledge that develops across projects.
With his past experience, Kennedy believes that knowledge-based product development works best at companies that continually make similar products, because they can create a continuous knowledge base that flows across all projects on an ongoing basis. And although knowledge-based product development can work at companies of all industries and scales, smaller companies seem to have an easier time adopting and adapting it. The reason is that smaller companies just don't have the administrative overhead (nontechnical middle management) of larger companies that can impede acceptance.
Knowledge Capture and Reuse
At Toyota, knowledge about various solutions sets that have been created, and their performance tradeoffs, is stored in a way that is accessible by all engineering team members. This knowledge management system dramatically reduces the waste of reinvention. It also encourages reuse of components on multiple Toyota automotive platforms. The key technical data associated with each design variation in the set system is tradeoff curves data that shows how variations perform against paired performance variables, such as weight versus size. All of the set solutions that were not used on one vehicle are now available for potential reuse on another vehicle project.
Kennedy said that Toyota has rejected the notion of designing a vehicle, then changing the entire design at once. The company tests and learns about a vehicle's subsystems first, then designs it to minimize and eliminate loop-backs.
In conclusion, Kennedy believes that if knowledge-based product development really catches on, as he truly expects it will, the companies that have adopted it will dominate those that have not. "Toyota is a good example of this domination, because they have gained and apply more knowledge than any other automotive manufacturer," he said. He also believes that in the next 10-15 years, knowledge-based product development will be the predominant means for developing products in an environment that will become increasingly competitive. Knowledge-based product development really is a different approach and one that we will continue to follow closely because of its significance and impact.
3 Ways Mid-Size Design Teams Are Driving Better Collaboration: White Paper - Now you can make it quick and simple for all practioners and stakeholders involved in design and engineering to share and find information, conduct collaborative design reviews, and manage contractural exchanges. Download your eBook here.