Book Review: Product Development for the Lean Enterprise

    By: PDMA Headquarters on Sep 26, 2013

    Book Review: Product Development for the Lean Enterprise: Why Toyota's System Is Four Times More Productive and How You Can Implement It 

    By: Michael N. Kennedy. Richmond, VA: Oaklea Press , 2003. 254 pages .
    Review by: Preston G. Smith

    Lean is in, even in product development. Product Development for the Lean Enterprise is a business novel targeted at executives on implementing the principles behind Toyota's outstanding product development system in Western companies.

    The timing of this book introduction and others like it (e.g., Fiore, 2003) is peculiar, as the application of manufacturing principles to product development was covered in seminal books by Reinertsen (1997) and Goldratt (1997a). The Toyota study, forming at least partially the basis for lean enterprise, was the subject of an article by Sobek, Liker, and Ward (1998) with a final report in 2000 (NCMS, 2000). Fully six years later, perhaps we still are digesting how to implement these principles.

    Japan's industry long has ceased to be viewed with fear and awe due mainly to the catastrophic economic downturn at the beginning of the nineties. Today, low-cost countries, such as India (Kripalani and Engardio, 2003) and China (Roberts, 2003), are seen as the larger long-term threat to as well as opportunity for American industry. However, Michael Kennedy reminds us that we are well advised to seek out and to learn about the gems of Japan's industry, such as Toyota (Bremner and Dawson, 2003), which have fared well due to their management practices. These superior practices, the author notes, extend beyond the manufacturing floor and into new product development.

    The book popularizes the outcome of a study by the National Center for Manufacturing Sciences (NCMS) (2000) and seeks to provide a path for implementing the practices uncovered there. Kennedy argues that business process reengineering has focused on redefining processes for maximum efficiency and value to the customer. However, business process reengineering requires an organizational structure to support ongoing change. It also provides a false sense of security for executives, who do not continue looking for solutions while initiatives are being rolled out.

    Kennedy identifies several problems with product development processes managed from a process reengineering viewpoint:

    • 1

    Project management has become too administrative.

    • 2

    Engineers only spend around 20 percent of their time on engineering.

    • 3

    Design reviews are largely ineffective.

    • 4

    Designs always are started from an engineering perspective and are not the result of real concurrent engineering (including suppliers).

    • 5

    There is minimal learning between projects.

    • 6

    Design engineers have very little design experience.

    • 7

    The scheduling system is inaccurate and unmaintainable.

    • 8

    Design-decision loop-backs are long.

    Toyota's product development system, however, was found not to exhibit these problems due to their use of a knowledge-based product development system (KBD) founded on set-based concurrent engineering, system designer entrepreneurial leadership, responsibility-based planning and control, and an expert engineering workforce.

    Set-based design introduces redundancy into the design process by allowing at least two different subsystem designs to be developed concurrently, one with little risk and additional ones with higher capabilities but also higher risk. To enable set-based design, Toyota uses tradeoff curves as a tool for managing subsystem performance as well as product modularity.

    Chief engineers are put in charge of end-to-end development of a product. They do not have direct authority over the resources needed but negotiate with the functional organizations for their support. Their authority is derived completely from their extensive experience and technical knowledge. In responsibility-based planning and control, the chief engineer sets a number of target times for key integrating events, such as styling approval or a major tooling release. Individual developers then are responsible for delivering their development projects. The integrating events are reviews, where technical decisions are being made. Note that these events seem to indicate “large-batch size” product development, which, according to Reinertsen (1997), could slow down the development process.

    Toyota develops an expert engineering workforce by organizing developers functionally. Developers join a product development effort only for as much time as is needed. They report to supervisors who have been chosen for their technical expertise rather than for their managerial prowess. The primary role of these supervisors in the functional organization is to enhance the expertise of their organization.

    To assist a Western company in arriving at a product development system based on these principles, Kennedy contrasts various approaches to organizational and process change management, including their advantages and disadvantages. He then proposes a change management philosophy and process for radical product development system changes. He draws a parallel between KBD and a change management environment. In participative change methodologies, the workforce develops implementation details in a succession of large integrative events. Within a 12-month window, the integrating events of a product development improvement initiative are launch, targets and concepts, process approved, organizational system approved, and system implemented. Because the participative change methodology has been shown to be consistently successful and because it is analogous to KBD, Kennedy argues for its application in developing the KBD environment. As Kennedy points out, the analogy has its problems, though, in the decision-making roles (an individual directing a change initiative is not desirable) and the sheer number of people involved in a change effort versus a product development project.

    To complete the description of the development system and its implementation, the author offers a short list of helpful tools: web repositories, responsibility-based planning systems, the project comparison matrix, and a continuous improvement process.

    In the context of Six Sigma, Kennedy mentions that design for Six Sigma focuses on designing products that exhibit Six Sigma levels of performance, which is complementary to his proposed changes. According to Kennedy, the application of lean principles (eliminating waste) or tools such as value stream mapping to product development never will result in a product development system with the characteristics of Toyota's. The gap between the state of product development in most companies today and what is possible is just too great. However, he does encourage the use of lean concepts in continuous improvement efforts of product development environments.

    The definition of waste in Fiore (2003) may serve as a good example. Among others, examples provided for waste in nonmanufacturing-based environments include “designing but never producing a product.” The large problem of design-in-process inventory (DIP) (Reinertsen, 1997) waste gets lost in the manufacturing-related nomenclature, because the definition of waste originates from an expense-based view of product development—not sufficiently recognizing the cost of being late to market.

    Kennedy does a good job in introducing the reader to the Toyota development philosophies and how to go about implementing these philosophies in Western companies. There are three comments worth noting. First, the implementation advice is not based on an actual implementation of the full product development system at an American company (p. 147 does list a few companies seeing some preliminary success). Second, too little is said about the circumstances under which this system is best. The car industry is a high-volume consumer capital goods business with a very complex supplier structure. This environment is very sensitive to variations in schedule and product unit costs but is far less sensitive to variations in development expense. Therefore, introducing redundancy into the development process through set-based design may make sense. Third, what new issues will this system exhibit? A recent article indicated problems at Toyota in developing the right products resulting perhaps from the technical leadership in product development (Bremner and Dawson, 2003).

    The style of a business novel is not conducive to delivering the key messages Kennedy attempts to deliver. Ever since The Goal (Goldratt, 1997b) became an international bestseller, business novels have emerged in an attempt to teach a new theory through a type of Socratic questioning in which a protagonist learns the theory as part of a story. This allows implementation problems to be highlighted from a variety of angles without the dryness of a textbook. What limits the book's effectiveness is that it does not develop the theory behind Toyota's product development system, which arrives at the character's company in the form of the NCMS report. Nor does the book's storyline fully cover the implementation of the Toyota system in Western companies. It begins with an executive call to action and ends with a successful executive presentation on how the change could be implemented. In other words, this book's storyline is about a few presentations rather than the gripping tale of a factory turnaround that made The Goal a success. The story's content forces the author to include roughly 60 graphs (some repetitious), a discussion section at the end of every chapter in which he provides an interpretation of the situation, and a final chapter wrapping everything up.

    In summary, the book is well worth the investment if one is interested in the advice of an experienced process implementer on how to implement the system described in Sobek, Liker, and Ward (1998) and NCMS (2000). Its strength is the careful deliberation of change implementation issues in an area not having obtained much attention in the past. Especially welcome is the treatment of change initiatives in product development with ambitious cycle time and efficiency goals as an antidote to so many failed top-down dictated-change attempts.


    Released: September 26, 2013, 10:36 am | Updated: October 30, 2013, 2:11 pm
    Keywords: PDMA Blog


    You must create an account or login with your existing account to provide comments or article ratings.

    About this Blog

    PDMA Blog

    Welcome to the PDMA Blog! This blog features industry insights for product developers and product managers from a variety of contributors.
    My Store Downloads

    No purchased files.

    Copyright © 2018 PDMA - Product Development and Management Association. All Rights Reserved

    PDMA 1000 Westgate Drive, #252 St. Paul, MN 55114 USA   |   Phone: 651-290-6280   |   Fax: 651-290-2266

    Contact PDMA   |   Legal Policies & Agreements