The Toyota Product Development System Principles

There is much literature on the Toyota Production System, otherwise knows as Lean Manufacturing.  There is much less literature, however, on how Toyota develops products.  We know, for example, that the Agile Software Methodology and movement is mostly influenced by Toyota’s Product Development System (TPDS), but there is less information on TPDS, than there is for TPS.  The article below shows well what The Toyota Product Development System Principles is about.

For more on the Toyota Product Development System, you can check out this great book by Morgan and Liker:

The Toyota Product Development System: Integrating People, Process And Technology

The article below is from Automative Design and Production, February 2006:

The product development process is substantially different than a manufacturing process, in that the core “material” is not physical objects, but knowledge and information that are often difficult to see and touch. The cycle times in product development are measured in weeks and months, not seconds and minutes; the flows are non-linear and multi-directional; and the “workers” are a large group of diverse technical specialists rather than manufacturing workers. The opportunities for waste in the system are, however, quite similar to a manufacturing operation, and include: excessive transactions (hand-offsj; waiting (for data, decisions, inputs from other processes); rework (especially reinvention-the solving of the same problem multiple times because existing solutions are not utilized); set-up inefficiency (each time an engineer has to reorient himself or herself to a task because of “stop and go” processes); and lack of system discipline, including missed timelines (what Morgan refers to as “arrival variation.”)

TPDS creates a “community of scientists” among the engineering staff that is continuously experimenting with new ideas in a largely self-managed system that is driven by “pull” as opposed to “push” signals to control the flow of work.  Michael 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. Key feature of the TPDS include:

FUNCTIONAL MANAGERS AS TEACHERS

Functional engineering managers are primarily teachers in the Toyota system. The managers are the most technically competent engineers, with the highest levels of experience. The “biggest teacher” is the chief engineer, who has ultimate responsibility for all aspects of the product, and teaches and manages by continuously asking “why.”

A CLEAR EMPHASIS ON AND REWARD FOR TECHNICAL COMPETENCE

Authority derives from knowledge, especially technical knowledge. Engineers are judged on their knowledge and use of technical information, such as tradeoff curves. To guote James Morgan: “Toyota is run by an upper management group who were engineers and technical excellence is revered. It is comprised of a technical hierarchy created by rewarding technical excellence. At Toyota, your boss can almost always do your job better than you. This is what enables the teaching or mentoring as leadership principle.”

“PULL” SCHEDULING OF DISTRIBUTIVE PLANNING AND CONTROL

Instead of an elaborate set of detailed sub-schedules, the chief engineer is responsible for establishing a set of “key integrating events” (e.g. styling approval; tooling release; etc.) with very specific target dates. These dates are never missed. The chief engineer establishes exactly what needs to be done by those key dates. These requirements are the eguivalent of a “product development kanban card” that signals to the various parts of the system that a set of work needs to be completed by a specific date. It is the responsibility of the individuals involved to figure out their own schedules to meet those dates. Just as TP5 doesn’t need an MRP scheduling system, in TPDS there is no need for a top-down driven detailed timeline for program management. Instead, the requirements set by the chief engineer “pull” work along.

SET-BASED CONCURRENT ENGINEERING

At the sub-system 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, radically reducing risk. Instead of being designed from the top down, the actual system configuration “emerges” (you also might say “evolves”) from creative combinations of multiple solution sets.

KNOWLEDGE-CAPTURE AND REUSE

Knowledge about the various solutions (“sets”) that have been created, and their performance tradeoffs, is stored in a way that is easily accessible by all engineering team members. This knowledge management system dramatically reduces the waste of “reinvention.” It also encourages reuse of components on multiple platforms. The key technical data associated with each design variation in the set system is .. “tradeoff curves”-data that shows how the set variations perform against paired performance variables (e.g. weight vs. size|. All of the set solutions that were not used on one vehicle are now available for potential reuse on the next project.

STANDARDIZATION AROUND CHECKLISTS AND DESIGN STANDARDS

The equivalent of “standardized work” on the manufacturing floor (which is what creates the basis for experimentation and improvement) is the use of detailed engineering checklists and design standards at each sub-system and component level. Quality matrices (think of a “mini house ofquality” from a Quality Function Deployment matrix) are developed for each part, showing the detailed steps in the manufacturing process, and all of the quality or productivity issues that can be affected by that step. These and other standardization tools are used to retain a relentless focus on product performance, and to allow communication of learning easily across all players in the project team.

VISUAL MANAGEMENT OF THE DEVELOPMENT PROCESS

The same kind of emphasis on visual control boards that is placed on the manufacturing process is also emphasized in the development process. Team rooms with color-coded graphics make it easy to immediately grasp where a project is and is not meeting its goals.