Morgan Liker front 3/2/06 11:11 AM Page i

The Toyota Product

Development System
Morgan Liker front 3/2/06 11:11 AM Page ii
Morgan Liker front 3/2/06 11:11 AM Page iii

The Toyota Product

Development System
Integrating People, Process, and Technology

James M. Morgan
and
Jeffrey K. Liker

New York
Morgan Liker front 3/2/06 11:11 AM Page iv

© 2006 by Productivity Press, a division of The Kraus Organization

Limited

All rights reserved. No part of this book may be reproduced or utilized in

any form or by any means, electronic or mechanical, including photo-
copying, recording, or by any information storage and retrieval system,
without permission in writing from the publisher.

Most Productivity Press books are available at quantity discounts when

purchased in bulk. For more information, contact our Customer Service
Department (888-319-5852). Address all other inquires to:

Productivity Press
444 Park Avenue South, 7th floor
New York, NY 10016
United States of America
Telephone: 212-686-5900
Fax: 212-686-5411
E-mail: [email protected]
ProductivityPress.com

Library of Congress Cataloging-in-Publication Data

Morgan, James M.
The Toyota product development system : integrating people, process,
and technology / James M. Morgan and Jeffrey K. Liker
p. cm.
ISBN 1-56327-282-2(alk. paper)
1. Automobile—Design and contstruction. 2. Project management. 3.
Concurrent engineering. 4. Toyota Jidosha Kogyo Kabushniki Kaisha.
I. Liker, Jeffrey K. II. Title.
TL278.M6787 2006
629.2’3068—dc22
2006004343

10 09 08 07 06 5 4 3 2 1
Morgan Liker front 3/2/06 11:11 AM Page v

Dedication

To my wife Mary and son Greg.

Without whom this work would not be possible.
JIM MORGAN

To my wife Deb, son Jesse, and daughter Emma

You give me a loving place to come home to.
JEFF LIKER

To our colleague and friend Dr. Allen Ward

Your light still guides.
JIM MORGAN AND JEFF LIKER
Morgan Liker front 3/2/06 11:11 AM Page vi
Morgan Liker front 3/2/06 11:11 AM Page vii

CONTENTS

Foreword xv
Acknowledgments xvii
Preface xix

Section One: Introduction

Chapter 1: The New Product Development Revolution 3
The Next Competitive Frontier: The Product Development System 5
Excellence in Product Development: The Next Dominant
Core Competency 9
Lean Product Development System: Linking Disciplines,
Departments, and Suppliers 10
Why Focus on Toyota? 11
Learning from Toyota 12

Chapter 2: The Lean Product Development System Model 15

A Sociotechnical System (STS) 15
The Process Subsystem: LPDS Principles 1 to 4 17
The People Subsystem: LPDS Principles 5 to 10 21
The Tools and Technology Subsystem: LPDS Principles 11 to 13 23

Section Two: Process Subsystem

Chapter 3: Establish Customer-Defined Value to
Separate Value-Added from Waste 27
Customer-Defined Value Process at North American Car Company 28
Customer-Defined Value Process at Toyota 29
Program Leadership: The Chief Engineer Role 29
Steps for Delivering Value to the Customer 30
Case Example: Lexus Body Team Reduces the Margin for
Error in Half 32
Why This Is the First Principle 36

Chapter 4: Front-Load the PD Process to Explore Alternatives

Thoroughly 39
Front-Loading for the Design Factory: Creating the Context for
Individual Program Development by Managing Product Platforms 41
Derivative Vehicles Built on Existing Product Platforms 42
Advanced Technology Planning 44

vii
Morgan Liker front 3/2/06 11:11 AM Page viii

Contents

Front-Loading Within an Individual Program: Styling and

Engineering Feasibility 46
Set-Based Concurrent Engineering 47
Toyota Body and Structures Engineering—Kentou 51
Standardizing Lower-Level Activities Enables
Quick Problem Solving—An Example 53
Application of Common Architecture and Principle of Re-use 54
Evaluating and Deciding on Vehicle-Level Goals 55
Toyota Production Engineering: The Simultaneous Engineer’s
Responsibilities 56
SEs Must Hit Investment and Variable Cost Targets 57
Mizen Boushi and Going to Production Plants 58
Communicating with Functional Specialists 59
The SE Submits the Plan 59
Leveraging Digital Tools 59
Early Problem Solving in Kentou: A Case Example 60
Kozokeikaku (K4) Pulling the Pieces Together 64
Right Person, Right Work, Right Time 64

Chapter 5: Create a Leveled Product Development Process Flow 67

The Power of Flow 67
Viewing Product Development as a Process 68
Value Stream Mapping 69
Seven Wastes in the Product Development Process 70
There Are Really Three Ms 74
Barriers and Facilitators of Flow: Insights from Queuing Theory 76
Leveled Flow Starts in the “Fuzzy” Front End: Kentou and Flow 82
The Role of Process Logic 82
Workload Leveling, Cycle Planning, and Allocating Resources 83
Staggering Vehicle Launches Using Common Platforms 84
The Execution Phase of Product Development 85
Cross-Functional and Within Functional Synchronization 86
Examples of Cross-Function Synchronization 87
Creating Flexible Capacity 88
Detailed (Fundoshi) Scheduling to Head Off Unevenness 90
Detailed (Fundoshi) Scheduling at the Functional-
Organization Level 91
Using Staggered Releases to Flow Across Functions 91

viii
Morgan Liker front 3/2/06 11:11 AM Page ix

Contents

Creating Process Flow in Nontraditional Manufacturing 92

Establishing an Engineering Cadence and Cutting Management
Cycle Time 93
Using Jidoka and Poka-Yoke to Support Product
Development Flow 94
Pulling Knowledge Through the PD System 95
Putting It All Together to Flow 97

Chapter 6: Utilize Rigorous Standardization to Reduce Variation

and Create Flexibility and Predictable Outcomes 99
Three Categories of Standardization 100
Category One: Design Standardization and Engineering Checklists 101
Category Two: Process Standardization 104
Toyota’s Standardized Process for Production Engineering 106
Toyota’s Die Engineering 106
Process and Binder Development 107
Toyota Lean Tool and Die Manufacturing 108
Typical Time Frames for Lean Tool and Die Manufacutring 108
Toyota Die Machining 109
Toyota Die Construction 109
Toyota Vehicle Assembly Engineering 111
Category Three: Standardized Skill Sets/Competence 112
Conclusion 113

Section Three: People Subsystem

Chapter 7: Create a Chief Engineer System to Lead Development
from Start to Finish 117
The Cultural Icon Behind the CE System 118
A Tale of Two Chief Engineers: Lexus and Prius 120
Lexus: A Chief Engineer Who Refused to Compromise 121
Prius: A New Chief Engineer and New Engineering Process
for a Twenty-first Century Car 125
The CE Leadership Model 131
NAC Product Development Manager: From Chief Engineer to
Bureaucrat 134
Group Facilitation at Chrysler 135
Toyota CE System: Avoiding Compromises that Lead to Bureaucracy 137

ix
Morgan Liker front 3/2/06 11:11 AM Page x

Contents

Chapter 8: Organize to Balance Functional Expertise and

Cross-Functional Integration 139
One Best Organizational Structure? 139
Shortcomings of a Product Organization 140
Strengths and Weaknesses of the Matrix Organization to
Manage the PD Process 142
Toyota’s Original Matrix Organization: A Long Tradition of
Combining Two Structures 143
A Fundamental Change to Toyota’s Matrix Organization 145
Chrysler’s Platform Team Structure: A Contrast to Vehicle
Development Centers 147
Simultaneous Engineering: The Obeya Room 152
Simultaneous Engineering: The Module Development Teams and
Chief Production Engineers 154
Example of Module Development Teams for Body and
Production Engineering 156
Organization as an Evolving Process 160

Chapter 9: Develop Towering Technical Competence in

All Engineers 163
A Philosophy for Hiring, Developing, and Retaining People 164
Recruiting/Hiring Process at NAC 165
Recruiting/Hiring at NAC Product Engineering 166
Hiring at NAC Manufacturing Engineering 166
Training and Development at NAC 167
Developing People at Toyota 168
Hiring at Toyota 169
Training and Development at Toyota 170
Training and Development at Toyota Body and
Structures Engineering 170
Training and Development at Production Engineering 172
Genchi Genbutsu Engineering 173
Competitor Teardowns 174
Prototype Builds 174
Daily Build Wrap-up Meetings 175
Your Lean PD System Must Develop People 175

x
Morgan Liker front 3/2/06 11:11 AM Page xi

Contents

Chapter 10: Fully Integrate Suppliers into the Product

Development System 179
A Part Is Not a Part, and a Supplier Is Not a Supplier 180
The Power of the Keiretsu 182
Are All Suppliers Created Equal? 183
Selecting and Developing Toyota Suppliers to Partner:
U.S. Supplier Tire Example 186
Partnering with Suppliers: Who Gets What? 190
Suppliers Work Closely with Company: Mutually
Beneficial Long-term Relationships 190
Price Is Not Everything 191
Losing a Bid 192
Relationship Development 193
The Guest Engineer System 193
The Supplier Stable 194
The Crux of Outsourcing Strategy 195
Mastering Core Technology 195
Developing new capability: the hybrid electric motor and
computer controls 196
Outsourcing the battery while maintaining capability 196
Changing Policy to Maintain Internal Capability 197
Using Keiretsu to maintain internal capability 197
Using Keiretsu megasuppliers to build modules 198
Treating Suppliers Respectfully and Reasonably 199

Chapter 11: Build in Learning and Continuous Improvement 203

Defining Knowledge and Organizational Learning 203
Explicit Versus Tacit Knowledge Transfer 204
Toyota’s Product Development Learning Network 205
Learning from Experience 207
Hansei at Toyota 208
Ijiwara Testing at Toyota 210
The Power of Problems 210
Problem Solving at the Source 211
Cross-checking 212
Daily wrap-up meetings 213
Ignorance: The Ultimate Expense 213
Rapid Learning Cycles 214

xi
Morgan Liker front 3/2/06 11:11 AM Page xii

Contents

Chapter 12: Build a Culture to Support Excellence and

Relentless Improvement 217
How Culture Can Stand Between You and Lean 217
A Tool Is Not a Solution 220
Contributing to Customers, Society, and Community 221
Technical and Engineering Excellence Are Intertwined in the Culture 222
Discipline and Work Ethic 224
Everyday Kaizen 226
Customer First Spirit 228
Learning DNA 229
Accountability and Responsibility 230
Team Integrity 230
Managing Upward, Downward, and Sideways:
Hourensu Management 232
The Right Process Will Yield the Right Results 233
The Culture Supports the Process 234
Leaders Renew the Culture 237

Section Four: Tools and Technology Subsystem

Chapter 13: Adapt Technology to Fit Your People and Process 241
Five Primary Principles for Choosing Tools and Technology 241
Technology in Lean Product Development 243
Digital Engineering at Toyota 244
Design Technology at Toyota 244
Virtual Manufacturing and Digital Visualization at NAC 245
Digital Assembly at Toyota 246
Finite Element Analysis at NAC and Toyota 248
Tools for Manufacturing Engineering and Tool Making 249
Checklists and Standardization Tools at Toyota and NAC 249
Solids Die Design: NAC Versus Toyota 250
Pattern Making at NAC Versus High-speed Pattern Making
at Toyota 251
Die Machining: NAC Versus Toyota 252
Tryout Presses: NAC Versus Toyota 253
No Adjust Build at NAC Versus Functional Build at Toyota 254
Three-dimensional noncontact measuring 255
Adopting Technology to Enable Process 257

xii
Morgan Liker front 3/2/06 11:11 AM Page xiii

Contents

Chapter 14: Align Your Organization Through Simple,

Visual Communication 259
Chief Engineer’s Concept Paper: An Aligning Document 260
The Cross-Functional Obeya 262
Alignment Tools 263
Nemawashi at Toyota 264
The Ringi System at Toyota 265
Hoshin Management at Toyota 266
Toyota’s A3 Problem-Solving Tool 269
Communication and Alignment at Toyota 276

Chapter 15: Use Powerful Tools for Standardization and

Organizational Learning 279
How Does Your Organization Learn? 279
Knowledge Database at NAC: The Body Development Value Stream 280
The Know-how Database at Toyota 281
Competitor Benchmarking Reports at NAC 286
Trade-Off Curves 284
Decision Matrices 285
Toyota Competitor Teardown and Analysis Sheets 287
Standardization Tools at Toyota: Engineering Checklists, Quality
Matrices, Senzu, Standardized Process Sheets 289
The Role of Standardization and Learning Tools 292

Section Five: Creating a Coherent Lean PD System

Chapter 16: A Coherent System: Putting the Pieces Together 297
Subsystem Integration: People, Process, Tools and Technology 299
Identifying Value: Delivering Customer-Defined Value 299
Enabling the Value Stream: Eliminating Waste and Variation 300
Eliminate or Isolate Variation 302
Flexible Capacity 303
Creating Pull and Flow 304
Enable Efficient Manufacturing 305
Perfection: Building in Learning and Continuous Improvement 306
Cross-Functional Integration 307

xiii
Morgan Liker front 3/2/06 11:11 AM Page xiv

Contents

Chapter 17: Eliminating Waste in the Product Development

Value Stream 311
Product Development Value Stream Mapping (PDVSM) 312
Addressing Some Differences Between PD and
Manufacturing VSM 314
Specific Challenges and Countermeasures for Mapping
the PD Process 315
Virtual data 316
Longer timeframes 317
Knowledge work 319
Complex information flow 322
Large, diverse group of specialists 325
PDVSM Workshops 325
Learning to See Product Development as a Process 330

Chapter 18: Getting to Culture Change: The Heart of Lean PD 333

Develop an Internal Change Agent 335
Get the Knowledge You Need 335
Identify Manageable Work Streams to Understand PD as a Process 336
Integration Mechanisms (Obeya/Design reviews) 337
Enrollment of the Line Organization 338
Start with Your Customer 339
Grasp the Current State of Your Lean Product Development Process 340
Driving to Real Culture Change 343
People: The Heart of the Lean Product Development System 346
A Roadmap for Lean Transformation 347
Leadership and Building in Learning and Continuous Improvement 351

Appendix: Applying Value Stream Mapping to a Product

Development Process: The PeopleFlo Manufacturing Inc.
Case by Dr. John Drogosz 353

Bibliography 359
Index 365
About the Authors 377

xiv
Morgan Liker front 3/2/06 11:11 AM Page xv

FOREWORD

FIFTEEN YEARS AGO, Dan Jones, Dan Roos, and I reported in The Machine
That Changed the World that Toyota had pioneered a new product devel-
opment system. (This work was done in parallel with research by Kim
Clark at the Harvard Business School and Taka Fujimoto at the Univer-
sity of Tokyo.) The quantitative evidence we presented was very clear:
The Toyota system developed products in much less time with many
fewer hours of engineering, products that cost much less to manufacture
and that had many fewer defects as reported by customers. (Not surpris-
ingly, these products also sold at considerably higher prices within a
given segment of the auto market.) This product development system
consistently created more value with less time and effort, the very defi-
nition of lean.
While we tried to give a broad-brush outline of how the system
worked—heavy-weight program management with strong team leaders,
intensive horizontal communication across departments, and simultaneous
engineering—our knowledge of its details was actually very limited. After
all, we were academics, not hands-on product development engineers, and
our access to Toyota was limited. The best we could do was to clearly meas-
ure the difference in performance while speculating on the causes.
Surprisingly, this continued to be the situation until very recently.
Everyone has understood that the Toyota system is superior, but no one
has been able to describe in a comprehensive way how it actually works.
And without this knowledge, efforts to copy it or even improve on it have
been frustrating or impossible.
Fortunately, the volume you hold in your hand finally explains how
Toyota does it and how your organization can as well. The whole gamut of
Toyota methods—the chief engineer, set-based concurrent engineering (a
critical concept working in parallel with simultaneous engineering), the
front-loaded development process, leveled process flow, rigorous stan-
dardization of design, process, and engineering skills, etc.—is clearly
explained along with the philosophy behind the use of each technique. In
short, readers working in product development organizations will no longer
have any excuse for failing to copy or even to improve on the Toyota system.
How has this breakthrough been possible? Because Jim Morgan is an
actual practicing engineer—with two decades of experience in auto-
motive product development. And he is also a scholar, having recently
taken several years to do a Ph.D. at the University of Michigan. There
he collaborated with Professor Jeff Liker, author of the widely praised The
Toyota Way. Fortunately, they were able to gain extensive access to

xv
Morgan Liker front 3/2/06 11:11 AM Page xvi

Foreword

Toyota’s product development organization in the United States and Japan

as part of their research.
By combining Jeff ’s comprehensive insights into the whole Toyota sys-
tem with Jim’s experience in product development, plus his fine-grained
investigation of the Toyota development system, they have finally put the
whole puzzle together.
All that remains is for you to study this volume carefully—and it does
demand careful study because it presents a complete system integrating
people, process, tools, and technology—and then to transform your own
development system.

By James P. Womack

xvi
Morgan Liker front 3/2/06 11:11 AM Page xvii

ACKNOWLEDGMENTS

WE WOULD LIKE TO EXPRESS our deep and sincere appreciation to the many
people who have contributed to this research. We are profoundly indebted
to them.
We can never possibly repay the profound debt we owe to Mr. Mike
Massaki, Mr. Uchi Okamoto, and Mr. Hiro Sugiura of Toyota. Massaki-san
provided us with access and opportunity and Okamoto-san and Sugiura-
san spent countless hours explaining the intricacies of Toyota vehicle
development, while Mr. Miyadera answered many additional questions.
We also gained many insights into Toyota’s systems from American Toyota
executives who have worked so hard to understand the true philosophy at
the Toyota Technical Center, including Jim Griffith, Ed Mantey, Bruce
Brownlee, and David Baxter.
We also owe a considerable debt to the many others at Toyota such as
Mr. Uchiyamada, Mr. M. Terasaka, Mr. S. Yamaguchi, Mr. S. Nakao, Mr.
K. Miyadera Mr. T. Yamashina, Mr. E. Gay, Mr. C. Royal, Mr. T. Buffeta,
Dr. C. Couch, and Mr. B. Krinock and the many others who spent their
time helping us in this research.
We are of course very grateful for the work that came before this
and in a sense made this book possible. The now classic work of Dr. Jim
Womack and Dr. Dan Jones, as well as the value stream mapping book and
class by Mr. Mike Rother and Mr. John Shook inspired and informed this
application to product development. The long stream of product develop-
ment research at the University of Michigan provided a firm foundation,
including the excellent work by Professor Durward Sobek, Dr. Pat Ham-
mett, Dr. John Cristiano, Dr. Jay Baron, Professor Jack Hu, and especially
for the path-breaking research of Dr. Allen Ward.
We are also very grateful to those who have provided ongoing assis-
tance and feedback in this process such as Mr. John Shook and Mr.
Stephen Hung, especially with value stream mapping.
Finally, and most especially we are grateful to our families. Jim thanks
his wife Mary for her editorial input, continuing moral support, and
patience and son Greg for patience beyond his years, support, and for the
good luck charm that he loaned. Jeff thanks his wife Deb, son Jesse, and
daughter Emma who provide a loving home to return to and put up with
much time away traveling to spread the word of the Toyota Way.

xvii
Morgan Liker front 3/2/06 11:11 AM Page xviii
Morgan Liker front 3/2/06 11:11 AM Page xix

PREFACE

RESEARCH FOR THIS BOOK began in the fall of 1982 when Jeff Liker was
invited to join a major comparative study of the U.S.-Japan auto industry
led by David Cole and Robert Cole at the University of Michigan. The
study involved most of the automakers and many suppliers in the United
States and Japan and faculty across the university’s departments. The
study focused on the different approaches used by U.S. automakers and
Japanese automakers in working with suppliers on product development.
It quickly became obvious that Toyota’s approach, which was distinctly
different from that of U.S. automakers and only partially similar to that of
Japanese automakers, was in most respects unique and exceptional, par-
ticularly with respect to its product development practices.
At that time, there was much interest in the Toyota Production System
(TPS) (later referred to as “lean manufacturing”) but relatively little inter-
est in Toyota’s product development system. In fact, TPS and product
development had evolved quite distinctively and in separate organiza-
tional units. Most Toyota product development managers claimed they
had very limited knowledge of TPS, and Toyota engineers did not see TPS
as the launching point for lean processes in product development.
The research program that subsequently evolved at the University of
Michigan included Al Ward, a mechanical engineering professor at the
time, and a number of gifted Ph.D. students. One major theme of the study
was set-based, concurrent engineering, and specifically, Al Ward’s research
on how Toyota engineers thought broadly about sets of solutions before
zooming in on one particular solution. The study also included research
conducted by Durward Sobek, whose work entailed a comparative review
of Toyota’s system and Chrysler’s early platform team structure, detailed the
chief engineer system and the mechanisms for coordination across func-
tional specialists, and provided an applied understanding of set-based con-
current engineering. Articles based on Sobek’s work were subsequently
published in Harvard Business Review and Sloan Management Review.
While this research gave study participants a broad view of how Toyota
engineered its vehicles and a deeper understanding of other issues, there
was something missing. In some ways, we had really only skimmed the sur-
face. What was missing was research by someone with the technical under-
standing to see clearly and deeply the specific and fine-grained differences
between Toyota’s system and that of conventional automakers and translate
that understanding into actionable principles for lean implementation. The
person who filled this gap was James Morgan who, over the course of
two decades, had accumulated a wealth of experience in various roles in

xix
Morgan Liker front 3/2/06 11:11 AM Page xx

Preface

automotive product development and had served as vice president of a

tier-one automotive supplier of tools, parts, and engineering services.
Over the next three years, Morgan spent many hours learning, in detail,
about Toyota’s body development system and about the body development
system of a large North American auto company. His experience allowed
him to penetrate deeply into the actual engineering processes, tools and
technology employed, and people systems at Toyota and to understand the
differences between Toyota and its North American foil at a detailed level. To
communicate these differences Morgan utilized a sociotechnical model to
compare and contrast elements of each company’s people systems,
processes, and technology. He also developed a value stream mapping
methodology, specifically adapted to product development. This methodol-
ogy later became a key tool for lean product development implementation.
In some ways, this book is the product of a dual process. To an extent,
it is a product of the accumulation of over 20 years of study by the Uni-
versity of Michigan research group. But it is also a work heavily built on
James Morgan’s more recent research. In writing the book, the authors
chose to present the materials that comprise the sum total of the research
as a set of principles of a Lean Product Development System (LPDS). Case
examples are interwoven with theory and theory is interwoven with sug-
gestions and methodology for practical implementation of these princi-
ples. The objective is to provide companies that wish to become leaner in
product development a foundation for their own LPDS.
One of the things the authors discovered while researching Toyota is
how deeply Toyota’s systems are rooted in the company’s unique history
and evolution—the Toyoda family, Japanese culture, the specific social and
economic environment from which Toyota emerged and matured, and the
decades of effective company-wide learning. But because every company
has its own history and its own environmental circumstances, it is neither
possible nor desirable for a company to adopt Toyota tools and strategies
and transform itself into Toyota. It is also not possible to single out an
individual tool or technique or process, change it to reflect lean principles,
and expect it to operate in exactly the same way as it does elsewhere. While
it is true that all companies must evolve their own systems, we hope that
your journey will benefit from this research and the principles of LPDS.

James Morgan
Jeffrey Liker
Ann Arbor, Michigan

xx
Morgan Liker sec 1 3/2/06 11:28 AM Page 1

SECTION ONE

Introduction
Morgan Liker sec 1 3/2/06 11:28 AM Page 2
Morgan Liker sec 1 3/2/06 11:28 AM Page 3

CHAPTER 1

The New Product

Development Revolution
“There is nothing wrong with a company that
great product cannot solve.”
CARLOS GHOSN, CEO, Nissan

IN 1990, THE MACHINE THAT CHANGED THE WORLD took the automobile
industry by storm, providing irrefutable proof that Japanese automakers
were simply better than their European or U.S. counterparts. In fact, they
were not a little better, but a lot better—two to ten times across a range of
performance metrics. For many English speakers, The Machine was an
introduction to the tremendous performance capability of the Toyota Pro-
duction System. It was also an introduction to Toyota, a company destined
to become an automotive juggernaut. In The Machine, Jim Womack, Dan
Jones, and Dan Roos (1991) introduced the term lean manufacturing—
doing more of everything with less of everything. It described a produc-
tion system that was better, faster, and cheaper; required less space, less
inventory, and fewer labor hours; and avoided wasteful practices. Along
with subsequent works on the Toyota Production System (TPS), The
Machine sparked a revolution in manufacturing that crossed both national
and industry boundaries, spawning a multimillion dollar consulting phe-
nomenon that has made lean manufacturing the most important develop-
ment in manufacturing of the past two decades.
As the authors of The Machine are quick to point out, only one chap-
ter of the path-breaking book focused on manufacturing. The book is
really about the lean enterprise, which includes marketing, distribution,
accounting, and product development. Yet most company transformation
efforts have focused almost exclusively on the manufacturing shopfloor, a
logical first step that more than a decade of experience implementing lean
supports. But we also have learned from this experience that the shop floor
is only the starting point. The transformation into a lean enterprise
requires a second step: moving upstream to the development of products
and processes. As many companies have discovered, there is only so much

3
Morgan Liker sec 1 3/2/06 11:28 AM Page 4

Section One: Introduction

waste that you can squeeze out of production before the engineering of the
products and processes becomes a critical constraint. Indeed, product and
process development can have an even bigger impact on lean enterprise
than lean manufacturing. Fortunately, Toyota provides as good a model
for product-process development as it does for product manufacturing.
Toyota’s product development system, though not as well known as the
Toyota Production System, is every bit as refined and powerful.
This book presents a model of a Lean Product Development System
(LPDS) and is the culmination of research, experience, and insights the
authors have gained over the course of many years. It is work that incor-
porates and integrates knowledge acquired from more than 15 years of
research at the University of Michigan, more than 20 years of product
development experience, privileged access to Toyota, and the patient guid-
ance of our Toyota Sensei. It is the first research-based book to assemble
together Toyota’s product development practices, policies, and philoso-
phies into one system. The research base for this book began with studies
by Liker, Ward, and their students, leading to the creation of the set-based
concurrent engineering model (Ward et al, 1995). Durward Sobek (1997)
took this research a step forward in his dissertation through a broad com-
parison of Toyota’s PD system to Chrysler’s then emerging platform
organization of product development.
Building on this research stream, Jim Morgan, while at the University
of Michigan, drew on his decades of direct experience and conducted a
two-and-a-half year, in-depth study of how Toyota’s automotive body
development compared to body development at an American “big 3
automaker.” By examining one vehicle subsystem (the longest lead time
and Toyotas most common type of product development), Morgan was
able to penetrate deeply into Toyota’s practices, which he then extrapo-
lated into a broader model of lean product development. The scope of the
study included design engineering, body engineering, manufacturing
engineering, prototype development, die manufacture, body assembly
development, and die and stamping approval. Data and information were
gathered through interviews with Toyota and supplier representatives and
during site visits. Over 1,000 hours of interviews were held with 40 people
at 12 different sites in the United States and Japan. Company representa-
tives from executive management, body engineering, manufacturing or
production engineering, tool manufacture, as well as several chief engi-
neers, participated in the interviews. Furthermore, Morgan built his study
on a sociotechnical framework (people, process, technology) for analysis

4
Morgan Liker sec 1 3/2/06 11:28 AM Page 5

The New Product Development Revolution

based on a long tradition of established research (Taylor and Felton, 1993;

Nadler and Tushman, 1997).
In many ways, this book, which brings together insights from this
collective research base, was inspired by a single question: What are the
underlying principles of product development that have made Toyota so
successful? To answer this question, the authors identified 13 principles
that were subsequently grouped into three broad categories: Process,
People, and Technology, and these became the framework for the Lean
Product Development System (LPDS) model. The purpose of this work
is to present the LPDS model in a way that demonstrates why a lean
productive development system is an asset and how such a system can
be created, implemented, or improved in any company. Though the dis-
cussions in this work are auto centric, the authors’ experiences helping
other companies implement these practices have demonstrated that the
principles and processes apply to any product development system.
One of the challenges of creating the LPDS model is that the Toyota
PD System is constantly evolving to meet new challenges and technologies.
In fact, for the authors, the learning process has been very much the
proverbial peeling away the layers of the onion, each layer revealing new
and critical insights. You can describe lean manufacturing as a set of tools
(e.g., kanban, andon, poka yoke) that eliminates waste and creates flow
of materials through a transformation process. You can describe lean
product development the same way. But peel away another layer, and you
discover the basis of both lean product development and lean manu-
facturing is the importance of appropriately integrating people, processes,
tools, and technology to add value to the customer and society.

The Next Competitive Frontier: The Product

Development System
Today, lean manufacturing is no longer the exclusive competitive advan-
tage of Toyota. Former disciples of Taiichi Ohno, the father of the Toyota
Production System, have circumnavigated the globe, teaching and imple-
menting lean manufacturing principles in many industries. In the auto-
motive industry, lean manufacturing has become so effective that every
automobile company has developed a lean manufacturing strategy, and
many have been quite successful. Likewise, many companies in other
industries have developed or are developing lean strategies. While most
automobile companies still lack Toyota’s manufacturing prowess, they

5
Morgan Liker sec 1 3/2/06 11:28 AM Page 6

Section One: Introduction

have made impressive progress in closing the productivity gap; in North

America, some have even surpassed Toyota in specific manufacturing cate-
gories. According to the 2005 Harbour Top Ten North American Assem-
bly Plants hours per vehicle rating (see Figure 1-1), GM Oshawa was
number one with just 15.9 hours per vehicle. In second place was Nissan’s
Smyrna, Tennessee plant (16.1 hours per vehicle), followed by Ford’s
Atlanta plant (16.6 hours); Toyota’s Georgetown plant (18.4 hours); and
DCX (18.7 hours). This is indeed an impressive change from the 40 hours
per vehicle reported in The Machine for the GM plant in Framingham,
Massachusetts, in the 1980s.
22.0
21.0

20.81
20.0
19.0
19.50

18.71
18.0
18.43
18.40
2003
HPV

2004

17.0
16.0
16.58
16.40

16.10
15.85

15.0
15.33

14.0
13.0
12.0
Oshawa #1 Smyrna Atlanta Georgetown #2 Belvidere
Impala, Altima Sable, Camry, Solara, Neon
Monte Carlo Taurus Solara Conv.

Figure 1-1. Harbour Top N.A. Assembly Plants by OEM—Hours per Vehicle

For some time, industries in the Western Hemisphere have been

focusing on pushing manufacturing and routine IT activities overseas to
Asia, specifically to China and India. However, the core of product-process
development thinking remains the domain of the parent company, and the
demands of integrating the design of complex products and processes
requires even more precise coordination mechanisms when outsourcing.
With the tremendous cost leverage to be gained in the design stage, it is
becoming clear that the new frontier is product-process development.
In the automobile industry, the number of vehicle models available to
North American consumers has increased dramatically. Conversely, the

6
Morgan Liker sec 1 3/2/06 11:28 AM Page 7

The New Product Development Revolution

number of unique vehicle platforms has decreased substantially. Conse-

quently, to be successful and remain competitive, automakers must now
offer a much wider variety of vehicles, while using fewer platforms. This
product-intensive environment has resulted in vehicle classes such as
car/truck “crossovers,” which did not exist in the late 80s but accounted for
more than 16 percent of total vehicle sales in North America by 2006.
Automakers are also introducing new vehicles more often. According to a
Merrill Lynch analysis, new model introductions over the past five years
have grown at a tremendous pace, with more than 60 new vehicles being
introduced each year in the United States alone between 2003 and 2005.
In connection with this trend, many industries have been moving to
platform engineering. For example, Intel recently made this a strategic
priority, moving to platforms of integrated chip sets to cater to different
customer segments. This strategy reflects the industry’s move toward
mass customization. The great success of the Centrino chip was the first
model for this.
Today, customers are selecting vehicles not only on the basis of cost
and quality but also on style and features. As a result, most consumer-
driven companies must work to meet consumer demands by accelerating
product development and bringing to market the products that customers
want when they want them. Companies that miss these key market trends
are being left in the dust, regardless of how efficiently they can produce
yesterday’s products.
Shorter technology development cycles, coupled with an explosion of
new and innovative vehicle features, have put tremendous pressure on
vehicle-development lead times. According to Merrill Lynch, there is a
direct correlation between model age and market share. “Clearly, the older
the model the lower the market share—newness wins every time.”
In the late 1980s, vehicle development time from styling freeze to start
of production (SOP) was typically 36 to 40 months. Today, the time
required to develop a new vehicle is significantly shorter, averaging
approximately 24 months. Toyota has exceeded this average by cutting
development times to as low as just 15 months regularly and an incredi-
ble 10 months in a single instance.
In many companies, product-development resource growth has not
kept pace with the growth of the broad range of vehicle models. In fact, the
availability of an ever-increasing variety of vehicles has led to market
microsegmentation that has critical implications for product develop-
ment. Wider model variety, combined with relatively stable total sales,

7
Morgan Liker sec 1 3/2/06 11:28 AM Page 8

Section One: Introduction

means that individual models are destined to have smaller total sales vol-
umes for lower individual model sales volumes. Amortizing develop-
ment costs means that development costs must be much lower than costs
for traditional models destined for much higher sales volumes. For the
program business equation to make sense, development costs must be
much lower than in the past. Best-in-class companies have recognized
and adapted themselves to this concept and it has propelled many
innovations in design and tool development. In these companies, prod-
uct development efficiency has already become a powerful product
pricing advantage.
Because auto companies are introducing more vehicles more often,
and are simultaneously facing higher quality expectations and increasing
pricing pressure, they have less time to improve quality and manufactur-
ing productivity. There is also a smaller margin of error: New vehicle
introductions cannot result in a drop in vehicle quality. With shortened
model life spans, companies can no longer afford a spike in defects and or
a leisurely hours per vehicle pace. Instead, they must work to achieve
leanproduct development and lean manufacturing that work synergisti-
cally to create flawless launches and unprecedented manufacturing quality
and efficiency.

Excellence in Product Development: The Next Dominant

Core Competency
Given the dramatic changes in the automotive product development envi-
ronment, it is obvious that a strong product development system is a
crucial core competence and fundamental to the success of any consumer-
driven company. The growing complexity of the modern automobile,
along with the changes discussed above, make new product development
extremely challenging. In today’s hyper-competitive market, excellence in
product development is rapidly becoming more of a strategic differentia-
tor than manufacturing capability. In fact, it can be argued that product
development will become the dominant industry competence within the
next decade.
The reason for this prediction is simple: There is much more oppor-
tunity for competitive advantage in product development than anywhere
else. Two underlying factors support this premise. First, whereas the per-
formance gap in manufacturing is closing, the gap between best-in-class
and the rest of the automobile industry in product development is

8
Morgan Liker sec 1 3/2/06 11:28 AM Page 9

The New Product Development Revolution

increasing. Furthermore, although most companies have made signifi-

cant improvements in manufacturing since the late 1980s through the
introduction of lean manufacturing methodologies, current levels of
manufacturing efficiency portend that a focus on manufacturing will
have diminishing returns in the future. Secondly, manufacturing’s abil-
ity to impact vehicle sales performance is inherently limited. While a
strong manufacturing system can affect quality and productivity, the
ability to impact customer-defined value as well as vehicle investment
and variable cost is clearly much greater early in the product’s develop-
ment process and decreases as the development program proceeds
toward launch. And manufacturing can do little to reduce development
costs or the timing of vehicle introduction relative to competitors, fea-
tures, technology, or styling. Furthermore, manufacturing has little role
in the initial selection of component suppliers. Given that most vehicles
have greater than 60 percent supplier content (a common trend in other
industries as well), supplier contribution to engineering and manufac-
turing, and, consequently, supplier selection, has a huge impact on over-
all vehicle cost and quality. Finally, as Toyota and others have clearly
demonstrated, though manufacturing capability is paramount, it is only
one functional discipline. Success requires that complementary disci-
plines be equally effective.

Lean Product Development System: Linking Disciplines,

Departments, and Suppliers
Many progressive companies, including Toyota, are exploring opportuni-
ties to create a truly lean enterprise, not only in the manufacturing process
but in design, purchasing, engineering, finance, and human resources.
However, many companies continue to struggle with executing a lean
enterprise strategy, partly because they have overlooked the leverage
gained by linking these functions. Lean product development requires an
integrated effort among sales and marketing design, purchasing, engineer-
ing, manufacturing, and suppliers. As Figure 1-2 illustrates, integrating
the efforts of these disciplines in product design is fundamental to lean
product development.
As previously noted, lean product development offers by far the great-
est potential for a competitive advantage for any consumer-driven com-
pany and is a critical component in dealing with the many environmental
challenges that all companies must now take into consideration. Many in

9
Morgan Liker sec 1 3/2/06 11:28 AM Page 10

Section One: Introduction

All of these disciplines must collaborate

and execute with excellence

Purchasing Sales and Marketing

Product Planning Manufacturing

Design Studio Engineering

Finance Human Resources

Figure 1-2. The Lean Enterprise Model

the automobile world concur with this opinion. The CEOs of GM, Ford,
Nissan, and DCX have all identified product development capability as the
centerpiece of their respective competitive strategies. In connection with
this, these companies have taken steps to bolster product development in
diverse ways, under the direction of astute individuals with the foresight
and ability to implement wide-ranging changes. In the 1990s, for example,
GM brought vaunted product guru Bob Lutz out of retirement and
opened a giant state-of-the-art engineering campus. Ford named a new
product chief and completely reorganized both its product development
group and its process. DCX also named a new vice president of product
development in an effort to shake up its product development system.
Efforts by GM, Ford, and DCX to adopt features of Toyota’s product devel-
opment system have been ongoing.

Why Focus on Toyota?

It is easy to get the impression that the authors of this work and others look
to Toyota for guidance in product development simply because Toyota is so
good at manufacturing. But while Toyota’s stunning success at consistently
bringing to market excellent products, build market share globally, and
make profits year in and year out is impressive, it cannot be attributed

10
Morgan Liker sec 1 3/2/06 11:28 AM Page 11

The New Product Development Revolution

solely to lean manufacturing. The underlying philosophy of The Toyota

Way led to parallel evolutionary paths in three core competencies—manu-
facturing, sales, and product development (Liker, 2004). Although not as
broadly understood as Toyota’s production system, Toyota’s product devel-
opment system is just as profound and powerful. The company consistently
develops higher quality vehicles faster, for less cost, and at a greater profit
than its competitors. It also launches more new vehicles annually than most
of its competitors, creating a steady flow of high quality new products to
meet consumer demand. This has fueled industry leading profits (reaching
a Japanese record $10.9 billion by 2005 and continuing upward), a market
capitalization greater than that of GM, Ford, and DCX combined, and a
continuing growth in market share (on track for a world-leading 15 percent
of the global market). Toyota’s market value ($177 billion in 2005) exceeds
the combined value of General Motors, Chrysler, and Ford and in 2005 was
13 times that of General Motors alone.
One reason for these successes is the quality of Toyota products.
Objective data, showing that Toyota excels in new product quality,
includes the J.D. Powers survey for initial quality from a survey of new
car customers within the first 90 days of ownership. The survey is a par-
ticularly well known indicator of vehicle development quality, which
Toyota has dominated during this decade with 39 first-place vehicles
since 2001, including a phenomenal 10 first-place vehicles out of 16 cate-
gories rated in 2005 (see Figure 1-3).

North
Measure Europe Japan America Toyota
2001 JD Powers IQS* 1 0 1 7
2002 JD Powers IQS* 0 1 2 9
2003 JD Powers IQS* 1 1 3 6
2004 JD Powers IQS* 1 0 2 7
2005 JD Powers IQS* 0 0 2 10
Freeze to SOP (mos.) 27 20 26 15
R&D $ to Sales 5.5 5.1 4.8 3.6
*number of first place vehicles.

Figure 1-3. Product Development Performance—

Latest Trends for Freeze to SOP and Research

11
Morgan Liker sec 1 3/2/06 11:28 AM Page 12

Section One: Introduction

With respect to speed to market and product freshness, Toyota can

consistently bring a new body with carryover chassis and powertrain (the
most common type of automotive product development) from styling
freeze to start of production in just 15 months. More basic categories of
vehicles, such as the Corolla, require only 12 months. Most of the com-
pany’s competitors require 24 to 30 months to accomplish the same task.
This consistent performance advantage has enabled Toyota to more than
double the number of unique models the company has marketed in
North America since 1990. Toyota’s average vehicle age is only 1.2 years
(compared to an average age of almost three years for competing
automakers), and its North American product offerings have steadily
increased since 1990. And this speed to market does not come at a high
price. Toyota is lowest in the ratio of R&D to sales. By combining its lean
production capabilities with common architecture strategies, standard
processes, and component sharing, Toyota achieves an incredible overall
cost advantage. It achieves speed and quality by minimizing variation and
increasing the potential for predictable outcomes in an unpredictable
environment.

Learning from Toyota

Our research, as well as direct experience applying the model in a number
of large consumer products companies, has shown that tweaking human
resource policies alone will have little sustained impact. Borrowing a tool
from Toyota’s lean system is equally futile as is buying the latest and great-
est collaborative engineering IT system. The only way a company can
make significant breakthrough improvements in product development
performance is to build its own product development system with the
patience and philosophical underpinnings that has led to the success of
Toyota and other great companies.
One of Toyota’s strengths has been the ability to learn from others,
such as Ford Motor Company, quality gurus and industrial engineers from
the United States, Japan, and Europe, and then carefully adapt this knowl-
edge to its own internal systems. In doing so, Toyota has thoroughly con-
sidered the implications, piloted the new approach, studied the costs and
benefits, and adapted the new approach to improve a current process.
Chapter 2 of this work breaks down the result of Toyota’s efforts to inte-
grate its product development system and lays out 13 principles that make
up the LPDS model.

12
Morgan Liker sec 1 3/2/06 11:28 AM Page 13

The New Product Development Revolution

Copious research examples have been included to assist the reader in

understanding the LPDS model. In addition to examples from Toyota, we
include counter-examples from one of the big three car companies,
referred to as North American Car Company (NAC), which was studied
intensively for comparative purposes. The comparison should help the
reader understand how Toyota’s product development practices differ
from a more typical automotive company.
One core premise emphasized in this work is that learning by doing
and institutionalizing that knowledge is the only way an organization can
begin to attain the standards of excellence set by Toyota. Although each
company must ultimately build a product development system that is dif-
ferent from Toyota’s, such a system, without the underlying philosophy
and management principles created and implemented by Toyota, may very
well be short-lived. It is hoped that the collected wisdom and researched
examples in these pages will assist you in creating and sustaining your own
product development core competency, the next competitive frontier.

13
Morgan Liker sec 1 3/2/06 11:28 AM Page 14
Morgan Liker sec 1 3/2/06 11:28 AM Page 15

CHAPTER 2

The Lean Product Development

System Model
“Everything should be made as simple as possible,
but not one bit simpler.”
ALBERT EINSTEIN

IT IS INTERESTING TO SPECULATE about the secret behind Toyota’s unparalleled

success in the automotive industry. Did Sakichi Toyoda pilfer some ancient
Samurai secret when he started the original automatic loom company? Is
there a hidden army of engineers equipped with six sigma statistical pack-
ages, expert systems, and the latest cross-networked supercomputers who
are really churning out Toyota’s designs? The truth is actually much more
straightforward. In fact, some of the American product development exec-
utives at Toyota reduce it to three words: “common sense engineering.”
Unfortunately, what seems like common sense to Toyota often does not
seem so common outside of Toyota.
One of the reasons for the elusiveness of Toyota’s secret for success is
that there is no single secret pulling it all together. Toyota’s success comes
from hard work, excellent engineers, a culture of teamwork, an optimized
process, simple but powerful tools that work, and kaizen that improves,
improves, and improves on all of these. In short, it is a truly lean system
that continually evolves.

A Sociotechnical System (STS)

Sociotechnical systems theory (STS) became popular in the 1970s and
1980s. Part of it was driven by European experiments with workplace
democracy. Part was driven by American academics with engineering and
social science backgrounds. When reduced to the simplest terms, STS says
that to be successful an organization must find the appropriate fit between
the social and technical system that fits the organizational purpose and the
external environment. Broadly speaking, the technical system includes not
only machines but also the policies and standard operating procedures of

15
Morgan Liker sec 1 3/2/06 11:28 AM Page 16

Section One: Introduction

an organization. All of the operational policies that an industrial engineer

might put in place are part of the technical system. The social system is
viewed as anything having to do with the selection, development, and
characteristics of an organization’s people and the culture that emerges
through the interaction of those people.
The term system suggests multiple interdependent parts that interact
to create a complex whole. And we cannot fully understand a system sim-
ply by looking at its individual parts. Only by studying people and equip-
ment working together can we see the way the whole functions. In
addition, a system has a dynamic element—it changes over time in
response to changes in the environment. The term “open-system” refers to
this interaction between what is inside the organization and the outside
environment.
Toyota’s product development has been evolving as a living system to
fit its unique environment for many years. The sociotechnical systems
model used here to describe Toyota’s PD System has three primary sub-
systems: 1) process, 2) people, and 3) tools and technology. In a lean PD
system model, these three subsystems are interrelated and interdependent
and affect an organization’s ability to achieve its external purpose (see
Figure 2-1).
To
o
le

ls
p

&
eo

Lean
Te
dP

Product
hn
ille

olo

Development
Sk

System
gy

Process

Mutually Supportive Aligned System Elements

Figure 2-1. Coherent Systems Approach to Product Development

STS thinking begins with three questions: 1) What is the purpose of

the organization? 2) Why does it exist? and 3) What is the relevant envi-
ronment of the organization? An organization can continue to exist only
if it imports sufficient information and resources from the environment to

16
Morgan Liker sec 1 3/2/06 11:28 AM Page 17

The Lean Product Development System Model

sustain the system. In other words, there must be an intimate connection

between the organization and its environment.
One purpose of this work is to further define the three subsystems in
the STS with 13 principles that comprise the Lean Product Development
System (LPDS) model. These 13 principles correspond to each of the three
subsystems of the STS model as presented in Figure 2-2.
Before reviewing these 13 principles, it is important to interject a
word of caution. Although it is useful for the purposes of analysis, com-
munication, and even implementation, to decompose the Toyota Lean
PD System into a LPDS model, the model does not explain the way
lean product development works in reality. While a specific tool or
human resource method covered in the principles may be individually
valuable, what makes lean product development truly powerful is the
whole system of mutually supportive tools, processes, and human
systems working in harmony. Therefore, to benefit fully from this sys-
tem, implementation requires a holistic systems approach that engages
the entire organization. A discussion on how this works and how
to maintain a systems approach to implementation is provided in
the final chapters of this book. This chapter provides a brief summary
of the three sociotechnical subsystems and their corresponding prin-
ciples, in a structure that serves as an outline of the content of subse-
quent chapters.

The Process Subsystem: LPDS Principles 1 to 4

The first subsystem is processes, which comprises all the tasks and the
sequence of tasks required to bring a product from concept to start of pro-
duction. In STS terms, this is part of the technical system. In lean terms,
this is what you look at when you “map the value stream” from raw mate-
rial to finished goods. In an engineering process, that raw material consists
of information—customer needs, past product characteristics, competi-
tive product data, engineering principles, and other inputs that are trans-
formed through the product development process into the complete
engineering of a product that will be built by manufacturing. Virtually all
companies have some type of documented process for developing prod-
ucts. LPDS, however, is less interested in the documented process and
more interested in the actual process, the day-by-day activities by which
information flows, designs evolve, tests are completed, prototypes built,
and finally a finished product emerges.

17
 5. Develop a Chief Engineer System to
Integrate Development from Start to
Finish.
11. Adapt Technology to Fit your People
6. Organize to Balance Functional Expertise

To
and Process.
Morgan Liker sec 1

le
and Cross-functional Integration.

ols
12. Align your Organization through

op
&
7. Develop Towering Technical Competence

e
Simple, Visual Communication.

P
Lean

Te
in all Engineers.

ch
Product 13. Use Powerful Tools for Standardization

led
8. Fully Integrate Suppliers into the Product

l
3/2/06

i
and Organizational Learning.

no
Development System. Development

Sk
lo
System

gy
9. Build in Learning and Continuous
Improvement.
10. Build a Culture to Support Excellence and
11:28 AM

Process
Relentless Improvement.

1. Establish Customer-Defined Value to

Separate Value-Added from Waste.

18
Page 18

2. Front-Load the Product Development

Process to Explore Thoroughly
Alternative Solutions while there is
Maximum Design Space.
3. Create a Leveled Product Development
Section One: Introduction

Process Flow.
4. Utilize Rigorous Standardization to
Reduce Variation, and Create
Flexibility and Predictable Outcomes.

Source: Reprinted with changes from Jeffrey K. Liker, The Toyota Way (New York: McGraw-Hill, 2004), 176, by permission of McGraw-Hill

Figure 2-2. Lean PPD Model and 13 Principles

Morgan Liker sec 1 3/2/06 11:28 AM Page 19

The Lean Product Development System Model

Principle 1: Establish Customer-Defined Value to Separate

Value-Added Activity from Waste
The customer is always the starting point in a lean system, so defining
waste starts with defining what a customer values. Further, you must effec-
tively communicate and operationalize customer-defined value through-
out the product development organization to align all objectives, focus
energy on the customer, and eliminate waste from the system. Simply put,
any activity that takes time and money but does not add value from the
customer’s perspective is waste. In product development (PD), there are
two broad categories of waste.
1. Waste created by poor engineering that results in low levels of prod-
uct or process performance. This is the most destructive waste. The
best antidote to this category of waste is a deep and concrete
knowledge of how to create customer-defined value at each level
of the organization, a hierarchy of value. Toyota employs tools
and methods to achieve this understanding and create value and
objective alignment throughout the program team.
2. Waste in the product development process itself. Insights from queu-
ing theory and Product Development Value Stream Mapping
(PDVSM) can help to combat these wastes.

Principle 2: Front-Load the Product Development Process While

There Is Maximum Design Space to Explore Alternative Solutions
Thoroughly
By far the greatest opportunity to explore alternatives is clearly early in the
product development program (PD program). Toyota has developed a
number of methods and techniques for effectively front-loading its prod-
uct development process (PD process) with integrated cross-functional
engineering resources that focus on resolving major engineering chal-
lenges while the maximum possible options are still available. Problem
solving while designs are at maximum fluidity allows the company to
explore potential solutions in design, engineering, and manufacturing.
Furthermore, by employing this “set-based” approach (i.e., examining
multiple alternatives simultaneously as opposed to single-point iteration)
to engineering across functions, Toyota dramatically increases its chances
of arriving at an optimal solution. This minimizes expensive engineering
changes downstream. Through the discipline of Kentou and Mizen Boushi
Toyota brings clarity and purpose to the front end of the PD process that

19
Morgan Liker sec 1 3/2/06 11:28 AM Page 20

Section One: Introduction

drives much of the fuzziness out of the “fuzzy front end.” In addition, it is
able to isolate inherent PD process variation and also drives system com-
patibility before completing individual component designs.
Principle 3: Create a Leveled Product Development Process Flow
Once you define value and have resolved the majority of engineering and
design challenges (i.e., achieved basic stability), lean product development
requires a waste-free process to speed the product to market. You can man-
age and improve the PD process much like any other process. Although you
may have many specific and unique design challenges, the tasks to be per-
formed and their sequences are generally similar across programs. In this
sense, a lean PD system is a knowledge work job shop, which a company can
continuously improve by using adapted tools used in repetitive manufac-
turing processes to eliminate waste and synchronize cross-functional activ-
ities. Toyota utilizes the powerful perspective of the knowledge work job
shop to level workload, create and shorten management event cadence to
create a takt time, minimize queues, synchronize processes across func-
tional departments, and reduce rework to a minimum.
Principle 4: Utilize Rigorous Standardization to Reduce Variation,
and Create Flexibility and Predictable Outcomes
The challenge in product development is to reduce variation while preserv-
ing creativity. Toyota creates higher-level system flexibility by standardiz-
ing lower-level tasks. There are three broad categories of standardization
at Toyota.
1. Design standardization. Toyota achieves this through common
architecture, modularity, and reusable or shared components.
2. Process standardization. Toyota accomplishes this by designing
products and building footprinted manufacturing facilities based
on standard manufacturing processes.
3. Engineering skill set standardization. At Toyota, this provides flexi-
bility in staffing and program planning.
Standardization provides the foundation for Toyota to develop effec-
tive solutions to traditionally highly cyclic resource demands inherent in
most PD systems. It also allows the company to create highly stable and
predictable outcomes (with both quality and timing) in an unpredictable
environment.

20
Morgan Liker sec 1 3/2/06 11:28 AM Page 21

The Lean Product Development System Model

The People Subsystem: LPDS Principles 5 to 10

The people subsystem covers recruiting, selecting, and training engineers,

leadership style, and organizational structure and learning patterns. This
subsystem and its principles cover the elusive thing called culture, which
can be quite encompassing as it entails the organization’s shared lan-
guage, symbols, beliefs, and values. A measure of the strength of the cul-
ture, and an important tenet of lean thinking, is the degree to which an
organization truly shares these things across its membership and with
partners.

Principle 5: Develop a Chief Engineer System to Integrate

Development from Start to Finish
In many companies, there are so many functional departments responsi-
ble for different pieces of PD that nobody is responsible. Try to identify
exactly what the status of the project is or where decisions are made, and
you get lost in the morass of endless departments. At Toyota, the antidote
to this problem is a chief engineer who is responsible for and can tell you
the exact status of any given project. The chief engineer is not just a proj-
ect manager but a leader and technical systems integrator; it is to this indi-
vidual that difficult decisions are brought for resolution. Although many
companies have someone with the title of chief engineer or program man-
ager, these individuals are often relegated to the role of project manager,
managing people and timing but not serving as chief technical architect.
The unique role of Toyota’s chief engineer is to be the glue that holds the
whole PD system together.

Principle 6: Organize to Balance Functional Expertise and

Cross-Functional Integration
One of the more difficult tasks in developing a high-performance PD sys-
tem is striking a balance between functional excellence within specific dis-
ciplines while achieving the seamless integration of those experts across
departments; this synergy is required for the success of any individual pro-
gram. While Toyota is fundamentally a functionally-organized company
with emphasis on strong functional skills and a skill-based hierarchy, it has
integrated the traditional silos through the chief engineer, module devel-
opment teams, and an obeya (“big room”) system that enhances cross-
functional integration and provides a PD program focus.

21
Morgan Liker sec 1 3/2/06 11:28 AM Page 22

Section One: Introduction

Principle 7: Develop Towering Technical Competence in

All Engineers
Technical excellence in engineering and design resources is fundamental to
lean product development. The modern automobile is a complex system
of highly technical, interdependent components that demands knowledge
of computer technology, aero and fluid dynamics, mechanics, and elec-
tronics, among other specialized disciplines. In light of this, it is surpris-
ing that many automakers pay little more than lip service to developing
technical superstars, preferring that their engineers broaden rather than
deepen their experience and seek MBAs rather than developing their tech-
nical expertise. In fact, much of the “training” encouraged or available in
many organizations is often so general as to be of questionable value at all.
At Toyota, technical excellence is revered, and Toyota engineers spend a
great deal of their time on core engineering. Toyota begins with a rigorous
hiring process and then designs a career path that emphasizes deep tech-
nical skill acquisition within a specific discipline, focusing on mentoring
of critical tactical skills that are required for engineering excellence. The
principle of genchi genbutsu (actual part, actual place) at Toyota pushes
engineers to get their hands dirty and go directly to see for themselves how
the work is getting done and what the problems are.
Principle 8: Fully Integrate Suppliers into the Product
Development System
Suppliers provide more than 50 percent of vehicle content for most
automakers (over 75 percent in the case of Toyota) and should clearly be a
fundamental part of a lean product development system. Companies
should manage and nurture their suppliers in much the same way they
manage and nurture internal manufacturing and engineering resources.
At Toyota, suppliers are valued for their technical expertise in addition to
their parts-making capability. Presourcing arrangements get them on
board from the start so that they are involved from the earliest stages in
concept development of a product. Using methods like having guest engi-
neers from suppliers work full-time in Toyota’s engineering offices cement
the intimate relationship between Toyota and its suppliers.
Principle 9: Build in Learning and Continuous Improvement
An ability to learn and improve may well be the most sustainable com-
petitive advantage a company has in its arsenal. At Toyota, learning and
continuous improvement are a basic part of day-to-day operations.

22
Morgan Liker sec 1 3/2/06 11:28 AM Page 23

The Lean Product Development System Model

Toyota, a leader in gathering, diffusing, and applying performance-

enhancing information, recognizes the benefits of learning and maximizes
its impact company-wide.
Principle 10: Build a Culture to Support Excellence and Relentless
Improvement
The DNA of Toyota is a composite of very strongly held beliefs and values
that are shared with successive generations of managers and working level
engineers. These core beliefs compel the organization to work harmo-
niously toward common goals. Toyota’s culture supports excellence with
explicitly defined values and an unwavering adherence to core beliefs by
leaders and team members alike. All of the other principles work because
the culture itself makes the principles a living part of how Toyota gets
things done.

The Tools and Technology Subsystem: LPDS Principles 11 to 13

The third subsystem consists of the tools and technologies employed in
order to bring a vehicle into being. This subsystem not only includes CAD
systems, machine technology, and digital manufacturing and testing tech-
nologies, but all the “soft” tools that support the effort of the people
involved in the development project, whether it be for problem solving,
learning, or standardizing best practices.
Principle 11: Adapt Technology to Fit Your People and Processes
Many companies err when they attempt to use some silver-bullet tech-
nology to achieve high levels of performance in product development,
especially when they do this without considering how this technology will
impact current processes or people. Adding technology to a fundamen-
tally flawed product development system will do little to help and may
even retard performance—especially for the short term. Toyota recog-
nizes that technology in and of itself seldom represents a meaningful
competitive advantage, partly because technology can be so easily repli-
cated elsewhere. It is much more important to take the time and effort to
make sure that the technology fits and enhances already optimized and
disciplined processes and highly skilled and organized people. That is why
Toyota works hard to adapt design software and other digital simulation
tools specifically to the Toyota Way before implementing them. In an
effective product development system, effective process and people

23
Morgan Liker sec 1 3/2/06 11:28 AM Page 24

Section One: Introduction

subsystems come first; technological accelerators that leverage specific

opportunities follow.
Principle 12: Align your Organization through Simple, Visual
Communication
While culture and customer focus is the glue that holds the Toyota organ-
ization together, there are some simple tools that help align the many
designers and engineers focusing on their technical specialties. One well-
known Japanese management tool is hoshin kanri, also known as policy
deployment. This is a method to break high-level corporate goals down to
meaningful objectives at the working level of the organization. This
method is also used by Toyota to break vehicle objectives down to specific
system objectives for performance, weight, cost, safety, etc. To support this
process and to solve problems that naturally occur when things do not go
exactly to plan, Toyota uses very simple, visual methods for communicat-
ing information, often limiting it to one side of one sheet of paper. This A3
report (named after the A3 paper size) has four minor variations for pro-
posals, problem solving, status up dates, and competitive analysis.
Principle 13: Use Powerful Tools for Standardization and
Organizational Learning
A well-known principle of kaizen is that you cannot have continuous
improvement without standardization. A corollary of this is that learning
should extend from program to program. Toyota has created (through an
evolutionary process) some powerful tools that standardize learning from
program to program. This occurs at a macro-level of learning from how a
design process is shared among program managers to individual lessons at
the detailed technical component level captured in engineering checklists.
These then are the 13 principles that comprise our not so simple
model of a Lean Product Development System. The next three sections of
this book cover individual subsystems, with a chapter dedicated to each
principle. At the end of the each chapter is a brief summary of LPDS basics
for the principle discussed. Section V discusses how Toyota integrates
these principals into a coherent system of product development and, in
Chapter 17, addresses a question that transforms theory into action: How
can you learn from Toyota’s PD system, and develop and implement your
own coherent lean product development system?

24
Morgan Liker sec 2 3/2/06 11:16 AM Page 25

SECTION TWO

Process Subsystem
Morgan Liker sec 2 3/2/06 11:16 AM Page 26
Morgan Liker sec 2 3/2/06 11:16 AM Page 27

CHAPTER 3

Establish Customer-Defined
Value to Separate Value-Added
from Waste
“What is our business is not determined by the producer but the
consumer. It is not defined by the company’s name, statutes, or
articles of incorporation but by the want the customer satisfies when
he buys a product or service. The question can therefore only be
answered by looking at the business from the outside, from the point
of view of the customer.”
PETER F. DRUCKER

THE PRIMARY DIRECTIVE OF ANY TRUE LEAN SYSTEM is establishing and deliv-
ering customer-defined value. However, this can be particularly difficult to
do in product development. Developing the next generation of a product
concept requires an accurate understanding of value from the perspective
of the targeted customer. In the automobile industry, vehicle characteris-
tics that represent value for a RAV Four customer and a Lexus LS 430 sedan
customer are likely to be quite different. Compounding the problem are
buyer demographics (age, location, or income) and the personal prefer-
ences of individuals looking at the same type of car. Getting this right can
be a very challenging task, but getting it wrong may jeopardize the success
of product development efforts.
The late Al Ward believed the primary role of effective product devel-
opment is the creation of new and profitable value streams for the organi-
zation. With respect to product development, this presents a twofold
objective: gauging customer-defined value as accurately as possible and,
based on this assessment, eliminating or reducing waste that interferes
with product development that matches that value.
Waste in product development generally occurs in one of two broad
areas: 1) engineering and 2) product development process. This chapter
addresses the former; Chapter 5 deals with the latter. In each case, the

27
Morgan Liker sec 2 3/2/06 11:16 AM Page 28

Section Two: Process Subsystem

underlying premise is that no effort or resources should be expended with-

out a deep understanding of customer-defined value.
Understanding customer preference is a basic part of any product devel-
opment system. Traditional product development uses many tools to achieve
this, such as market data, focus groups, and surveys. Each of these traditional
tools can gather important information about market trends and customer
sentiment, but they do not provide the deep knowledge that establishes a
concrete understanding of customer-defined value. Because a lean PD system
relies on this deep knowledge, these traditional tools fall short of the intended
mark because they fail to reflect data that allows you to differentiate between
value-added and non-value-added activities. Without this knowledge, it is
not possible to define a customer’s value characteristics accurately. This will
adversely affect effective allocation and management of product develop-
ment resources. The North American Car Company (NAC) case study below
should provide a better understanding of the relationship between a tradi-
tional approach to product development and detrimental engineering waste.

Customer-Defined Value Process at North American

Car Company
Every company spends a great deal of time trying to identify product attrib-
utes that will be important to customers. The North American Car Company
(NAC) spends significant resources gathering and studying demographic
data, reviewing the results of focus groups, benchmarking competitors, and
reviewing field quality data on the current model vehicle. Once compiled,
this data produce a long and detailed document describing the target cus-
tomer and feasible cost model, as well as outlining vehicle-level performance
objectives for new models. NAC utilizes sophisticated analytical tools and
scores of business case reviews to evaluate objective data that determines pro-
gram direction and feasibility. But something is elementally lacking. First of
all, at least part of the problem is that this analytic approach may be too
objective. The primary focus of the product development team is on deliver-
ing the numbers—especially the financial requirements. In fact, the teams
with which we met obsessed over little else as they prepared to navigate their
way through senior management reviews. Obviously this does little to estab-
lish an emotional customer connection or a shared sense of excitement about
the vehicle program. The targeted customer is not central to the process—the
numbers are. In fact, beyond the conceptual stage the customer is rarely even
mentioned. So although the key program leadership at NAC is clearly mind-

28
Morgan Liker sec 2 3/2/06 11:16 AM Page 29

Establish Customer-Defined Value to Separate Value-Added from Waste

ful of Return on Investments (ROI), program leaders seem to be out of touch

with the customer, do not focus on the customer’s true value characteristics,
and are unaware of the engineering waste created as a result of this.
Like other traditional companies, NAC also struggles to communicate
what it knows about the program in meaningful or measurable ways to the
program team, causing the team to be uncertain about the program objec-
tives, functional objectives, and team goals. In fact, many key program par-
ticipants have only a vague knowledge of their own function-specific
objectives and an even vaguer understanding of general program objectives.
This lack of understanding is even more evident downstream, where
groups are likely to have their own set of objectives for the vehicle program
based on issues that relate to day-to-day manufacturing operations. The
reason for this is simple. NAC does not involve functional groups, such as
manufacturing, in the value-definition process. As a result, the NAC pro-
gram objectives do not gain the full enrollment or ownership by functional
groups downstream, so these groups do not have an opportunity to put
into operation vehicle-level objectives or deliver on specific goals in a way
that is meaningful to them. The result of failing to involve and align all pro-
gram participants means each functional group develops its own goals,
causing confusion or conflict across development teams. This not only
inhibits NAC’s ability to deliver customer-defined value but also creates
program delays, significant cost penalties, and a generally inferior product.

Customer-Defined Value Process at Toyota

Like NAC, Toyota evaluates field quality data, market research, and com-
petitor’s products to understand its customer. But the similarities end
here. A critical first step in Toyota’s value discovery process is selecting
key program leadership. Toyota selects program leaders with the back-
ground and experience to establish an emotional connection with the
target customer. As Kousuke Shiramizu, Lexus quality guru and executive
vice president explains, “Engineers who have never set foot in Beverly Hills
have no business designing a Lexus. Nor has anybody who has never expe-
rienced driving on the Autobahn firsthand.”

Program Leadership: The Chief Engineer Role

The top program leadership at Toyota is the chief engineer (CE). In addi-
tion to being a super engineer, he or she must understand what customers

29
Morgan Liker sec 2 3/2/06 11:16 AM Page 30

Section Two: Process Subsystem

value and how these value characteristics mesh with the program’s vehicle
performance characteristics. Toyota’s chief engineers and their staffs (CE
team) go to great lengths to achieve this understanding. One anecdotal
example of how far a Toyota CE will go to make this happen illustrates this
diligence. The story concerns a chief engineer who moved in with a young
target family in southern California to enhance his understanding of the
generation X lifestyle associated with RAV Four customers. While devel-
oping Toyota’s successful 2003 Sienna, the Sienna CE drove his team in
Toyota’s previous minivan model more than 50,000 miles across North
America through every part of Canada, the United States, and Mexico. The
CE experienced a visceral lesson in what is important to the North Amer-
ican minivan driver and discovered in every locale new opportunities for
improving the current product. As a result, the Sienna was made big
enough to hold full sheets of plywood while the turning radius was tight-
ened, more cupholders were added, and cross-wind stability was enhanced,
among many other improvements that resulted from this experience.
The CE’s actions confirm that Toyota’s value targeting process and vehi-
cle drive analysis are important tools in the company’s search for customer
value. To assure that the driving experience achieves maximum benefit, CE
team members receive advanced driving training as well as vehicle evalua-
tion-skill training to identify problems and recognize improvement
opportunities.
Once defined, the value characteristics must be: 1) communicated
across the program to all product teams and 2) aligned and put into oper-
ation with meaningful, measurable objectives that entail specific tasks that
each person on the product team can execute.

Steps for Delivering Value to the Customer

At Toyota, the chief engineer’s ultimate responsibility is delivering value
to the customer, though the process entails many steps and people. First,
the CE communicates customer-defined value, vehicle-level perform-
ance objectives, and aligns the vehicle-level performance goals of the
entire program team. This step begins with the Chief Engineer’s Concept
Paper, which outlines the CE’s vision for the new vehicle. The concept
paper, a document that rarely exceeds 25 pages, usually takes several
months to complete. It includes both quantitative and qualitative objec-
tives for vehicle characteristics, performance, cost, and quality. Many
people provide input for the concept paper but it is written and issued

30
Morgan Liker sec 2 3/2/06 11:16 AM Page 31

Establish Customer-Defined Value to Separate Value-Added from Waste

by the CE and finally presented in a large auditorium as the marching

orders for all participants.
The Japanese term for the concept paper (and other documents issued
by the CE) is shijisho, literally translated as “direct order document.”1 The
CE’s concept paper can thus be compared to a direct order in the military.
The concept is the result of many months of discussion, information gath-
ering, and consensus building, and has been approved by the managing
directors of the company, but, when it is issued, it is the law of the program.
Once the concept is approved, the next step in the customer-defined
value process is to develop specific objectives that support the chief engi-
neer’s vision for all functional program teams. The vehicle-level performance
goals set by the CE must be translated into specific, measurable objectives
for the stylists, packaging engineers, body engineers, stamping engineers,
etc. that make up the program team. Putting into operation customer-
defined value at a vehicle level that supports aligned goals that cascade
throughout the program teams creates a value hierarchy. As the CE team
moves down this value hierarchy, it decomposes the high-level vehicle-
level performance targets and aligns them at each level into a set of specific
actions. This process gives Toyota an internal customer perspective for
each functional team. (A simple example of the value decomposition
process, which is a semistructured, reductionist approach to achieving
value alignment in the product development process is provided later in
the chapter.)
Next, module development teams (MDT), responsible for each vehicle
subsystem, meet to develop specific, measurable goals for each subsystem
and communicate it to the CE team. Using a customer-first attitude and
the CE as the primary voice of the customer, the various MDTs go through
fairly intense negotiations and ultimately commit to specific objectives
designed to support the vehicle-level performance characteristics. This
process is very similar to the catch-ball process utilized in Hoshin Kanri,
which is a process designed to achieve enrollment and alignment among
all participants and to encourage a candid exchange of views that set
achievable stretch goals. This process drives everyone to focus all efforts
and energy toward delivering value to the customer and guards against the

1. There are two types of shijisho. A-Types are broad and set general goals and objectives,
identify trends, and include targets for weight, performance, and cost like the concept
paper. B-Types are at the smaller component level, e.g., deciding the number of
prototypes or, for engines, deciding on a certain type of mount.

31
Morgan Liker sec 2 3/2/06 11:16 AM Page 32

Section Two: Process Subsystem

very real potential for team members to champion their respective indi-
vidual systems at the expense of optimizing the whole system. The final
version of these objectives is posted and tracked throughout the program.
Team members’ performance is judged, in part, by their ability to hit these
targets. This results in each member of the program contributing directly
to delivering customer-defined value.
The next step in the process requires intensive cross-functional partic-
ipation among the MDT to develop specific strategies and value targets to
deliver the value-driven commitments each team made. Equipped with
predetermined value targets, the various MDTs work together by studying
field quality data, tearing down competitor products, and visiting dealer-
ships to document direct customer feedback. They also visit their own and
competitor’s manufacturing plants to study production as well as talk with
operators about manufacturing quality and efficiency. This is an example
of an important concept described in The Toyota Way, Genchi Genbutsu
(go to the source), which is a critical underpinning of the lean product
development system.
It is important to understand that as the cross-functional MDTs go to
the source, they are going with a common set of objectives and goals based
on vehicle-level performance objectives set by the chief engineer. Because
the MDTs begin their quest for delivering value early in the process, while
the vehicle concept is most fluid, they are able to communicate and
integrate their value-driven commitments with the design, engineering,
processing, and manufacturing departments, which presents many oppor-
tunities to discover potential improvements to their development ideas.
(This topic is revisited in the next chapter.)

Case Example: Lexus Body Team Reduces the Margin for

Error in Half
A look at the early days of Lexus provides a simple illustration of value
alignment and the value decomposition process. The driving principle
behind the Lexus brand was the relentless pursuit of perfection. At the time,
however, Toyota’s customer feedback clearly indicated customer prefer-
ence for the precision and craftsmanship offered by German engineered
BMWs and Mercedes, two of the primary luxury car competitor targets
established by the Lexus team. To achieve breakthrough quality to fit the
level of quality customers would expect of a Lexus, the team established
the high-level objective of reducing its margin of error by half. One spe-

32
Morgan Liker sec 2 3/2/06 11:16 AM Page 33

Establish Customer-Defined Value to Separate Value-Added from Waste

cific action resulting from this objective was that the body team reduced
the margins or small spaces between body panels from the current stan-
dard gap and also reduced the amount of acceptable variation in those
gaps to half of the then accepted level, consequently achieving a level of
precision not only never before seen in a vehicle body, but one considered
by many at that time to be unobtainable.
The Lexus team realized that reducing these gaps would contribute to
vehicle aerodynamics and a significant reduction in wind noise. In addi-
tion, the modifications would dramatically improve vehicle appearance
and craftsmanship, something that customers had identified as being criti-
cal to selecting a luxury brand. The module development team that was
responsible for vehicle closure subassemblies (e.g., hood, doors and deck
lid) had a particularly difficult challenge. In addition to the already chal-
lenging goal of reducing gaps and variation tolerance, they had to consider
the swing gap required for closing and opening these subassemblies. The
cross-functional team began by executing a detailed teardown and analy-
sis of two best-in-class competitors’ doors. They identified very specific
areas of concern, plotted on the radar graph in Figure 3-1.
The areas identified on the radar graph correspond to the specific
areas on the doors shown in Figure 3-2. Since these areas showed the
greatest difference between the products, the team began its investigation
by analyzing these specific areas.
As Figure 3-2 illustrates, the top and bottom sections of the doors have
comparable variation in gap. The greatest differences between the two
doors are in area A, at the front edge of the door, and area E, at the rear
edge of the door. During the manufacturing process, the door edge is
created by hemming or folding the edge flange of the outer door over the
periphery trim flange of the inner door as shown in Figure 3-3 on page 35.
Although the general appearance or design effects of the doors’ front
edges appear similar, closer examination by the team identified several
important differences. The sharp break created by a drastic change of
direction at point A of the Lexus model may create material compression
and distortion in this area of the hem and subsequent variation in the
panel gap. The competitor’s door edge gently sweeps upward, creating a
smooth gradual effect that minimizes material distortion. In the same
area, they also saw that the character or style line that crosses the door
interrupts the edge, creating potential for even more distortion. The style
line in the competitor’s door blends upward and washes out in the mirror
attach area, never interrupting the hem edge.

33
Morgan Liker sec 2 3/2/06 11:16 AM Page 34

Section Two: Process Subsystem

Front Door Margin Comparison

Region A
0.8
0.7
0.6
Region G 0.5 Region B
0.4
0.3
0.2
0.1
0

Region F Region C

Vehicle A
Vehicle B

Region E Region D

Detail Region Vehicle A Vehicle B

Region A 0.5 0.3
Region B 0.6 0.6
Region C 0.1 0.2
Region D 0.2 0.3
Region E 0.8 0.5
Region F 0.1 0.2
Region G 0.4 0.3

Figure 3-1. Radar Graph Comparison for Front Doors

On the rear edge of the door, the MDT discovered similar conditions:
two style lines that interrupt the hem edges and another sharp break at
the top of the door. With the information gleaned from this analysis, the
team was able to design changes to help achieve their panel gap objectives.
The team also noticed a 1mm offset in the edge of the inner door flange
that follows the entire periphery (area E). Team members concluded that
this offset would provide more stability than a flat edge, contributing to
both gap and flushness consistency and a generally more precise panel fit

34
Morgan Liker sec 2 3/2/06 11:16 AM Page 35

Establish Customer-Defined Value to Separate Value-Added from Waste

A. Front edge of door blended into mirror detail

B. Styling line integrated into mirror detail to avoid violating hem line
C. Cleaner periphery line/arc on rear edge of door
D. Sharp break-lines through hem on Vehicle A
E. Product details on inner door closely follows periphery of hem
flange on Vehicle B. This constant offset provides superior dimen-
sional stability for a better fit.

Figure 3-2. Comparison Based on Radar Graph Results

Figure 3-3. Hemming Operation

35
Morgan Liker sec 2 3/2/06 11:16 AM Page 36

Section Two: Process Subsystem

condition. This design change was also easily incorporated at this point in
the program.
The MDT next visited the manufacturing facility responsible for hem-
ming current door subassemblies. Firsthand observation and operator inter-
views identified another potential improvement opportunity. By changing
the preclinch condition and shortening the flange lengths on the outer pan-
els, they could achieve much greater control in the hemming process, result-
ing in less variation and the ability to make the gaps between panels (margin
for error) smaller. Subsequent trials, in the manufacturing environment gave
the team the opportunity to identify the optimum flange length and pre-
clinch condition for both maximum clinching power (holding the assemblies
together) and minimum, most constant gap.
Hem variation and panel gap and flushness were monitored through-
out the program and checked closely at all design reviews; results were
tracked. The team also developed specific metrics for both the end condi-
tion (4mm gap and variation) and the means (design changes, flange
length, and preclinch requirements) and tracked both the means and the
results throughout the program, posting simple graphs in the program
team room. By tracking both the results and the means, the team was able
to identify quickly whether the methods/means were resulting in subopti-
mal results or whether the methods/means were not being followed. By
working collaboratively on the details of delivering customer value, the
team was able to deliver a luxury product that exceeded standards of the
time. Many readers may recall the resulting Lexus commercial where a ball
bearing is rolled down one of the panel gaps to demonstrate a new level of
vehicle precision achieved by the Lexus team.
Excellent product development requires that the program leadership
has a process for clearly communicating specific, detailed goals that are
aligned throughout the program and that leadership engages all functional
groups (development teams) to participate in delivering customer-defined
value. Committing to and delivering on goals early will ensure meaningful
participation. It will also eliminate engineering waste, enabling manufac-
turers to deliver value consistently.

Why This Is the First Principle

This LPDS principle emphasizes how essential it is to a lean PD system to
establish a deep understanding of customer-defined value, diffuse it
throughout the program team, and decompose it into meaningful objec-

36
Morgan Liker sec 2 3/2/06 11:16 AM Page 37

Establish Customer-Defined Value to Separate Value-Added from Waste

tives throughout the program. Establishing and decomposing customer-

defined value is your critical first step in creating a lean PD process. Further-
more, to bring this high-level knowledge about and have customer-defined
value bear directly on the product development system, you need a chief
engineer, or equivalent, to define and align program objectives and goals
among cross-functional teams early in the program. For Toyota, giving the
module development team time to analyze, track, and consider options is
crucial for delivering on the performance objectives and performance goals
set by the CE team.
Furthermore, when you work to establish customer-defined value, you
are also separating your value-added activities from wasteful activities. It is
here, at the front end of the PD process, that companies have the greatest
opportunities to have a positive impact on end product. Like lean manu-
facturing, lean product process needs to drive the principle of eliminating
nonvalue-added activities, in this case, engineering waste.
Chapter 5, which addresses LPDS Principle 3, includes a discussion of
how Toyota minimizes the second PD waste, product development process
waste, and creates flow by maximizing the potential of the early stages of
product development. Toyota accomplishes this by front-loading the lean
PD process with experienced, cross-functional engineering resources
focused on resolving key engineering challenges and problem solving, the
subject of the second LPDS principle.

LPDS Basics for Principle One

Establish customer-defined value to separate value-added activity
from waste in product development. A lean product development
system starts with the customer. There must be a process for iden-
tifying product-specific, customer-defined value, effectively com-
municating that value, and developing and executing specific,
aligned objectives throughout the organization from the start of
the program. Toyota starts with direct, visceral product and cus-
tomer experiences for program leadership and then adds rigorous
internal and competitor data analysis and broad technology
reviews. The CE then communicates his vision for the vehicle
through the CE paper and aligned, executable objectives are devel-
oped by each of the subsystem teams and confirmed by the CE.
These objectives are tracked throughout the program.

37
Morgan Liker sec 2 3/2/06 11:16 AM Page 38
Morgan Liker sec 2 3/2/06 11:16 AM Page 39

CHAPTER 4

Front-Load the PD Process to

Explore Alternatives Thoroughly
“The manager’s job is to prevent decisions from
being made too quickly . . . but once a decision is made,
we change it only if absolutely necessary.”
TOYOTA GENERAL MANAGER OF BODY ENGINEERING

THE ABILITY TO INFLUENCE THE SUCCESS of a PD program is never greater

than at the start of a project. The further into the process, the greater the
constraints on decision making. As the program progresses, the design
space fills, investments are made, and changing course becomes increas-
ingly more expensive, time consuming, and detrimental to product
integrity.
Empirical evidence shows that poor decisions early in the process have
a negative impact on cost and timing, which increases exponentially as
time passes and the project matures. Although this is generally recognized,
very few companies understand how to take advantage of this golden
front-end opportunity by making wise front-end investments. Toyota is
one of the few.
The LPDS model’s second principle, Front-Loading the Product Devel-
opment Process to Explore Alternatives Thoroughly, is the foundation for
flawless execution throughout the program and is analogous to the
shopfloor maxim of measure twice—cut once. It emphasizes the value of
good preparation and concentrates the PD team’s effort on the beginning
of the program. Moreover, although initial plans are often subject to
change, the process of detailed, rigorous planning is absolutely crucial to the
success of the lean PD program. It is working though the planning process;
bringing together your brightest, most experienced engineers from all
functional disciplines to work collaboratively, thoroughly thinking though
all of the critical project details, anticipating problems, applying lessons
learned, creating precise plans, and designing countermeasures from a
total systems perspective that is crucial to the success of the program and
the evolution of the lean product development system.

39
Morgan Liker sec 2 3/2/06 11:16 AM Page 40

Section Two: Process Subsystem

Toyota’s maxim for product development planning is “plan carefully

and execute exactly,” and it is through rigorous planning that Toyota
brings a unique precision to the product development process. It is at that
stage of the PD program that a company must use its best resources for a
disciplined front-loading strategy.
Because front-loading solves problems at a root cause level early in the
process, it nearly eliminates the traditional PD problem of late design
changes, which are expensive, suboptimal and always degrade both prod-
uct and process performance. Late engineering changes are “quick fixes,”
or patches, not continuous improvement; in fact, they are waste of the very
worst kind. In lean thinking, effective continuous improvement activity
begins at the beginning of a program. Front-loading also provides a way
to control much of the variation inherent in the product development
process. Since early variation has the greatest impact on queues and other
systems delays during the execution phase of product development, Toyota
tries to isolate and minimize variation early in the process in two ways:
1. By standardizing architecture, processes, very specific activities
and by setting very specific performance goals.
2. By creating an early phase of the PD process (kentou) to solve
problems, resolve conflict, address the roots of variation, and seg-
regate it from the rest of the PD process. This allows participants
to focus on the execution of their specific tasks.
The ensuing discussion of front-loading has been subdivided into two
broad categories, the first of which addresses cross-program front-loading.
This section explains how Toyota “front-loads” the multiprogram “design
factory” and creates an operating environment in which each individual pro-
gram has the greatest potential for success. This section also discusses how
Toyota leverages platforms and shared architectures, re-uses components,
allocates shared resources, and assesses new technologies to minimize varia-
tion and uncertainty in product development. The second section illustrates
how front-loading affects individual programs and examines what Toyota
calls the kentou or study phase of a program as well as critical concepts like
Mizen Boushi or designed-in quality. This chapter also covers set-based con-
current engineering, which considers sets of design and manufacturing solu-
tions concurrently and then gradually narrows the sets, helping to ensure that
designs are compatible with their environment and feasible. Set-based con-
current engineering dramatically reduces the need for engineering changes.
This set-based philosophy also helps to identify and resolve problems as early

40
Morgan Liker sec 2 3/2/06 11:16 AM Page 41

Front-Load the PD Process to Explore Alternatives Thoroughly

as possible and ensures that product attributes, including crucial trade-offs,

which are a fundamental part of product development, are clearly under-
stood. The chapter concludes with a discussion of the principle of right per-
son, right work, and right time as an antidote to the tendency of some
companies to do too much too soon thereby creating tremendous waste. This
is the waste of overproduction and creates massive rework downstream in the
process because of work performed too early in a process.

Front-Loading for the Design Factory: Creating the

Context for Individual Program Development by
Managing Product Platforms
Any individual PD project represents only a fraction of a company’s prod-
uct portfolio and a single element in its total product development
strategy. To be successful, an enterprise must effectively master what
Cusumano and Nobeoka (1998) refer to as multiproject management, a
strategy that optimizes the sharing of resources across multiple, concur-
rent projects. It is an effective way to manage technological complexities
when developing diverse and sophisticated products.
A product development project can range from programs related to
breakthrough inventions the world has never before seen to routine
upgrades of existing products. There are four broad categories of new
product development:

1. Revolutionary new products that represent radically different prod-

ucts or technology. This is a complete, white sheet product, and is
the least common type of product development project in the
automotive industry or any other mature industry.
2. Product platform-development projects that require fundamentally
new systems and components. In the automotive industry, this
would include such things as a new engine, transmission, chassis,
underbody, HVAC, and electrical systems, resulting in a com-
pletely new vehicle that utilizes improved versions of existing
technology, possibly combined in innovative ways. This is also
fairly rare, particularly at Toyota, which has worked hard to
maintain common “platforms” for vehicle derivatives.
3. Derivative products built on existing product platforms. In the auto
industry, derivative vehicles can require entirely new exterior body
shells, interiors, secondary technology synthesis, and trim and

41
Morgan Liker sec 2 3/2/06 11:16 AM Page 42

Section Two: Process Subsystem

ornamentation. This type of product, increasingly more common

to the industry, is the primary focus of this book.
4. Incremental product improvements. In the auto industry, this
would include such things as new trim, cladding, replacing
selected outer and/or interior panels, or updating selected tech-
nologies. This “facelift”-type product development was once ade-
quate for between-model updates, but increased competition,
faster technological development cycles, and better-informed con-
sumers are making it a less viable option, both in the automobile
world and in many platform-based industries.

This section and the chapters to follow will focus on the third type of
product development and Toyota’s adherence to the front-load the PD
process and thoroughly explore alternatives principle.

Derivative Vehicles Built on Existing Product Platforms

In this category of product development, standard manufacturing
processes, robust common platforms, and shared vehicle architecture are
crucial PD system enablers for individual programs. They contribute
directly to development speed, lower development costs, and significantly
higher vehicle quality. Although definitions vary, it is generally accepted
that a vehicle platform contains at least the following components: power
pack (engine and transmission); front, center pan, and rear end structures,
front and rear axles and suspensions; frames and subframes; brake and
electrical systems; bumper beams; and fuel tank. These components make
up the mechanical system or “guts” of the vehicle. Much of the expensive
high technology, as well as the basic functionality of the car, truck, or SUV
is driven by these components. To a great extent, these components also
determine vehicle driving performance characteristics and basic vehicle
reliability. Common front-end structures also contribute to similar crash
paths and minimize iterative testing requirements. In terms of lean enter-
prise, then, it makes sense to engineer standard vehicle platforms that have
a great impact on vehicle quality and reliability and can accommodate a
wide variety of body shells and interiors. While such platforms and the
philosophy that supports them are invisible to consumers, they are the pri-
mary source of vehicle quality and reliability and an important source of
differentiation that appeals to customers, a connection that Toyota has
fully understood and used to refine its PD.

42
Morgan Liker sec 2 3/2/06 11:16 AM Page 43

Front-Load the PD Process to Explore Alternatives Thoroughly

One example of this is the way Toyota addresses the issue of noise and
vibration, a critical point among “customer value” elements. The way the
engine is mounted to the steel sheet metal cradle affects the amount of
noise and vibration the customer experiences, so this in particular defines
a platform from Toyota’s perspective. Once Toyota tests and proves a plat-
form, the platform can be stretched and widened with a great degree of
flexibility to accommodate model derivatives. For example, the Toyota
Camry, Sienna Minivan, and Avalon, even though they are different sizes
and appear to be very different vehicles, are all assembled on the same
platform. On this platform, however, everything from the underbody and
power pack up to sheet metal and interior is customized for each vehicle.
In fact, they do not share a single common piece of sheet metal.
One reason Toyota stands out in the industry in terms of the number
of vehicles derived from a single platform is that it develops vehicle plat-
forms that are meant to be reused for up to 15 years. On average, Toyota
produces seven different vehicles on each platform with a high degree of
mechanical reliability across vehicle type. To enable “off the shelf ” plat-
form selection by individual programs, Toyota focuses on engineering reli-
able, robust vehicle platforms with maximum flexibility, in advance of
specific vehicle programs. This front-loading practice is a key to Toyota’s
reputation for vehicle safety and reliability. It also dramatically reduces
product development time and cost, in some cases even eliminating the
need for prototype tools.
In addition to sharing mechanical platforms, Toyota focuses on com-
monizing certain critical aspects of vehicle geometry. More specifically,
certain shapes, forms, and holes in exterior-stamped sheet metal and sub-
assemblies necessary for efficient manufacturing (or successful vehicle
crash performance) are identified and standardized across certain specific
vehicle models or generations of the same vehicle. Examples of this
include crash-critical geometry in inner hoods and doors, specific flats
and holes for locating detail parts at assembly for flexible body shops,
maximum hits per part, and depth-to-width ratios for parts.
Furthermore, Toyota defines standards that minimize impact on
creativity by focusing on unseen part characteristics and utilizing ratios
and trade-off curves wherever possible, allowing its designers to maintain
maximum flexibility in decision making. These standards are the subject
of numerous documents that will be discussed in some detail in Chapters
6 and 15. Here, it is important to emphasize that the information in these
documents is available to all program participants and is an essential tool

43
Morgan Liker sec 2 3/2/06 11:16 AM Page 44

Section Two: Process Subsystem

for sharing the experience and knowledge gained from other programs,
thus drastically shortening technical learning curves for individual pro-
grams. It also frees up time and resources, allowing PD teams to perform
other tasks and thoroughly explore alternatives during front-loading.

Advanced Technology Planning

While platforms and shared architecture provide an important foundation,
the essence of new product development is delivering fresh, innovative
products that excite and motivate customers to spend their hard-earned
cash. As previously noted, too much commonality can lead to poor product
differentiation and an uninspired portfolio of products that age on show-
room floors. A lean product development system must balance quality,
speed, and cost advantages of commonality with attractiveness and excite-
ment. By combining and balancing these elements, a lean enterprise keeps
a steady stream of innovative products flowing to a steady stream of cus-
tomers. This requires advanced technological planning, one of the key
factors that make innovation feasible.
Toyota draws from many sources for new technology and innovation:
internal research and development, suppliers, Business Revolution Teams,
and even competitors. All vehicle lines review R&D proposals on a regular
basis, and specific R&D projects are generated from specific vehicle line
input based on customer feedback and environmental changes. All primary
suppliers participate in routine technology reviews; indeed, participation is
understood as a prerequisite for any supplier that wants to remain a pri-
mary supplier. Business revolution teams are small, fast-moving units,
which focus on technological innovation to address specific existing or
anticipated challenges and feedback. One example of the efficacy of such
units is the Toyota Prius, which started as a business revolution team proj-
ect tasked with coming up with a new vehicle concept and new product
development process for the twenty-first century (see Chapter 7). Finally,
Toyota regularly analyzes competitor innovations for potential fit with
Toyota vehicle line strategies. Teams review and subject the ideas from all
these sources to a rigorous funneling process to evaluate and select concepts
based on fit with strategic objectives and vehicle line requirements (i.e.,
ability to share across individual vehicle models).
Toyota has developed a time-based process for evaluating input,
selecting ideas, developing concepts, and launching advanced projects on
an annual cadence, thus assuring a steady and focused supply of innova-

44
Morgan Liker sec 2 3/2/06 11:16 AM Page 45

Front-Load the PD Process to Explore Alternatives Thoroughly

tion to each of its vehicle lines. During this process, which supplements
the actual development process for specific vehicles, Toyota evaluates ideas
and technologies for implementation readiness and fit with corporate
requirements, including design, manufacturing, marketing, and product
planning. Each new technology must pass rigorous tests before it is
deemed suitable for inclusion in a specific vehicle program. Toyota is
somewhat technically conservative and insists that all technologies and
concepts be fully vetted before they are adopted. The company does not
normally develop new technology on individual development program
critical paths and is extremely demanding of suppliers who promote new
technologies, requiring that all such promotions be backed by data from
the start. In this way, Toyota creates a set of proven technologies that are
put “on the shelf ” until they are needed for specific vehicle programs. The
Chief Engineers decide when and whether to pull these technologies off
the shelf because it is the chief engineers who thoroughly understand what
customers want and how the total vehicle fits together.
The platform planning approach, standardization, and the speed of
Toyota’s process enable regular insertion of technology into vehicles. If a
particular technology is not thoroughly tested and reviewed by the time a
chief engineer develops the concept for a vehicle, it may be incorporated
into the next program or the one following it. The short cycles between
vehicles ensures that the next available program will not be far behind.
Toyota’s chief engineers have also developed an intuitive “feel” for how
much change in a particular vehicle is just enough. The primary intent is
to carry over most of the parts of the vehicle and consider the best utiliza-
tion of existing tooling; only then will a chief engineer consider where and
how to introduce new technologies. This is a stark contrast to the “clean
sheet” approach historically employed by NAC and other companies.
It is also important to comment briefly on Toyota from an organiza-
tional perspective beyond the role of the chief engineers who decide
when and for what purpose new technology is pulled from the shelf.
Toyota also has a contingent of Advanced Engineers, a group that func-
tions as an autonomous entity but is tightly linked with specific Vehicle
Centers. Advanced Engineers are not pulled in to day-to-day activities.
Instead, they are given the independence to create the brand identifica-
tion that is so important to and necessary for a full understanding of
technological fit.
One may get the impression that the high hurdles for new technol-
ogy make Toyota inflexible and behind the times. Quite the contrary,

45
Morgan Liker sec 2 3/2/06 11:16 AM Page 46

Section Two: Process Subsystem

technological innovation is strategically focused, often in response to a

request from a chief engineer. Also, certain car models have been selected
as the leaders in new technology, in particular the Crown model in Japan
and Lexus. These product lines must be at the forefront of new technology
in at least several areas and there is a close interaction between the research
group and the CE. These technologies will, over time, migrate to less
expensive models. This interaction between those developing the tech-
nologies and those leading the programs and the rigorous evaluation
process before putting the technology on the shelf ensures that there is lit-
tle delay between when a technology is ready and when a chief engineer
determines that a program wants the technology.

Front-Loading Within an Individual Program: Styling

and Engineering Feasibility
Vehicle styling, the activity that defines the exterior appearance of a vehi-
cle, is arguably the most creative or artistic set of activities in the PD
process. It is crucial to customer appeal and vehicle sales. Vehicle style also
has an important impact on downstream engineering and manufacturing
activities and must strive to balance its own activities with these. Styling,
in any PD system, represents the joining of art and science.
At Toyota, styling studios in Europe, Asia, and North America com-
pete with each other to capture the essence of a new car’s style while incor-
porating sound engineering principles and guidelines set by the Toyota
Production System. The styling process begins with a series of sketches,
and progresses to multiple scaled-down clay models. The goal of each of
these activities is to capture and refine the chief engineer’s vision for the
new vehicle. Styling for an existing vehicle line (by far the most common
PD projects in the automotive industry), usually requires some combina-
tion of creating fresh styling queues and maintaining a given vehicle’s
brand DNA—retaining those styling features and vehicle characteristics
that clearly identify that specific vehicle over time. Eventually the PD team
creates between two to four full-scale clay models of the vehicle. During
this process, the CE Team continues the practice of genchi gembutsu, fre-
quently visiting the studios and sharing relevant data and analysis as it
becomes available. At the same time, the CE is soliciting and receiving
broad input, mostly from internal employees to guard confidentiality. The
input requested and received is related to the strengths and weaknesses of
alternative models.

46
Morgan Liker sec 2 3/2/06 11:16 AM Page 47

Front-Load the PD Process to Explore Alternatives Thoroughly

Set-Based Concurrent Engineering

Examining multiple alternatives during the styling activity is an example

of set-based concurrent engineering (Ward, Liker, Sobek, Cristiano, 1995).
The term was coined by the authors cited here (an academic team from
the University of Michigan) who studied Toyota’s process and noted the
unusual degree to which Toyota considers a broad range of alternatives
and systematically narrows the sets to a final, often superior, choice. Mor-
gan (2002) subsequently confirmed the set-based approach to body engi-
neering was employed by Toyota during the Kentou period when hundreds
of kentouzu (study drawings) are generated and broadly considered and
matured until converging on a single design solution.
A simple graphic can help illustrate set-based concurrent engineering
(SBCE) (see Figure 4-1). While conducting the early studies, the team
from the University of Michigan interviewed many engineers working for
U.S. and Japanese automakers, including engineers from Toyota. During
these interviews, a common theme among these engineers (with the
exception of Toyota engineers) was some version of “iterative point-based
design.” As a rule, this meant that styling would initially consider many
alternatives. After these alternatives were narrowed down, executives
would select a clay model and then authorize engineering to turn it into

Synthesize Analyze

Modify

Iterative Point-Based Model

Set-Based Concurrent
Engineering

Figure 4-1. Two Models of Design

47
Morgan Liker sec 2 3/2/06 11:16 AM Page 48

Section Two: Process Subsystem

digital data and a tooled factory. Of course, engineering would find many
problems with the style from the perspective of functionality (e.g., aero-
dynamics) and request changes—iteration. This iteration would go on
until time in the PD process ran out. Sometimes engineering would sim-
ply modify some aspect of the styling just to “make it work.” Then, process
engineering would start the work of tooling and discover further problems
with the design, leading to more iterative discussion that sometimes
resulted in heated conflict. It is easy to see how this iterative cycling con-
sumes a company’s time and resources and leads to a suboptimal design.
From Toyota engineers and subsequent studies of Toyota’s PD systems,
the team ascertained that the company was not constrained by the “iterative
point-based design” process or impacted by its wasteful consequences. An
example of Toyota’s lean PD process is the Prius hybrid. At the time this
model was being developed, there was intense pressure to meet aggressive
time lines set by the company president, Mr. Okuda. The timeline was short-
ened and shortened despite the fact that the vehicle was to have an entirely
new power train (type 2 in the framework laid out earlier with some type 1
characteristics of brand new technology). The simplest solution for the
chief engineer, Mr. Uchiyamada, was to short-circuit the process. But Mr.
Uchiyamada was a true Toyota man, a chief engineer whose father was also
a chief engineer. He refused to compromise, insisting on adherence to the
established Toyota process of considering broad alternatives and gradually
narrowing the alternatives until a superior engine, body style, and trans-
mission could be selected.
For the body, four design studios (California, Paris, Tokyo, and Toyota
City) participated in an open competition, submitting 20 sketches. Of
these, five sketches were selected for further consideration and four were
eventually turned into life-sized clay models. After broad input from
employees, two of these clay models were chosen—one from California
and one from Japan. The California design, not surprisingly, was more
radical and posed potential manufacturing problems; the design from the
Japanese studio was conservative but would be easier to produce. Chief
Engineer Uchiyamada asked each studio to try one more time to come up
with a truly exceptional design that was also practical. The resulting two
models were subjected to extensive feedback from Toyota employees from
diverse backgrounds and departments, and their responses were almost
equally split between the two alternatives. Reviewing the responses again,
Uchiyamada discovered that younger employees and female employees
preferred the California design. Based on this distinction, he selected the

48
Morgan Liker sec 2 3/2/06 11:16 AM Page 49

Front-Load the PD Process to Explore Alternatives Thoroughly

California design, which dovetailed with a major Toyota goal: increase sales
among the young and female buyers.
In a separate, parallel process, the body engineering organization was
already working intensely, studying the body and developing solutions.
Uchiyamada had told these engineers to assume the design from Japan
would win, an assumption probably based on past experience, so they
began working on some preliminary structural engineering. After Uchiya-
mada’s decision to go with the California design, they discovered that there
were enough similarities between the Japan and California designs that the
engineering work they had started was a useful foundation on which to
build. The sketches and the intense discussions between engineering and
styling in the kentou stage had already led to important modifications,
joint solutions that satisfied styling, product engineering, and manufac-
turing. This turn of events attests to the inherent strength of set-based
concurrent engineering in the PD process.
Set-based concurrent engineering considers the different design per-
spectives proposed by different parties, a phenomenon that can best be
graphically illustrated by Venn diagrams (see Figure 4-2). Each party has
some acceptable range of alternatives—a solution space that will work
from its own perspective. Front-loading finds where the sets overlap and,
in the process, identifies the winning design solution.

Body Structural Suspension

Capability Alternatives
Acceptable

Styling
Alternatives

Figure 4-2. Set-Based Perspective—Looking for Intersections between

Feasible Regions of Functional Groups

A comparison of Toyota’s convergent approach and NAC’s iterative

approach clearly illustrates the advantages to be gained by the former:
Toyota’s approach has essentially eliminated a great deal of waste while

49
Morgan Liker sec 2 3/2/06 11:16 AM Page 50

Section Two: Process Subsystem

achieving a superior solution (see Figure 4-3). Where Toyota’s deliberate

examination of sets of alternatives and systematic convergence is very
smooth, NAC’s iterative approach has resulted in jerky rework caused by
forcing premature decisions based on relatively narrow solution sets.

<PA> Program Approval

Sourcing

<ST> Surface Transfer

Design Complete

Toyota Convergence
NAC Convergence
Rework

Figure 4-3. Slower Decision Making Leads to Steady Convergence,

Forced Premature Decisions Drive Rework

Our discussion of set-based concurrent engineering would not be com-

plete without noting an important underlying premise of the set-based engi-
neering process. Toyota engineers have a strong sense of the vehicle as a
system and consequently focus a great deal of skill and energy at the design
interfaces. This includes not only the interdependencies of the various indi-
vidual components that make up the vehicle, but also the downstream man-
ufacturing processes. Consequently, Toyota’s process does not focus on the
speedy completion of individual component designs in isolation, but
instead looks at how individual designs will interact within a system before
the design is complete. In other words, they focus on system compatibility
before individual design completion. The principle of compatibility before
completion is fundamental to the set-based approach and is a major con-

50
Morgan Liker sec 2 3/2/06 11:16 AM Page 51

Front-Load the PD Process to Explore Alternatives Thoroughly

tributor (along with standard architecture and processes) to Toyota’s

extremely low number of engineering changes. System compatibility
(including design compatibility with lean manufacturing) is a key determi-
nant for attribute selection during the set-based convergence process.
The practice of developing and presenting multiple alternatives is fun-
damental to both the Toyota PD and lean manufacturing systems and is
the basis for decision matrices and other tools discussed later in this book.
This chapter provides examples of how each contributor to the develop-
ment process naturally presents multiple alternatives or solutions to any
problem. To get at the root of “set-based thinking,” however, requires an
understanding that it is more than a specific set of tools or methods. It is,
in fact, a cultural characteristic that is woven into “the way things are
done.” Fortunately, companies can adapt structural aspects of this culture
to their own PD by using the following:
• Intentionally identifying multiple solutions to design problems
before selecting just one.
• Encouraging engineers (both upstream and downstream) to dis-
cuss alternatives early before a fixed decision has been reached on
a single design from one perspective.
• Using set-based tools (discussed later in the book) such as trade-
off curves to identify the trade-offs of various solutions from dif-
ferent perspectives.
• Capturing past knowledge in checklists (described later) in the
form of graphs and equations that show the effects of different
alternatives.
• Using system methods like parametric design that quickly show
system impacts when parameters are changed.
• Having structured time early in this front-end period for partici-
pants with diverse perspectives to work out solutions when the
broadest set of alternatives is still available.

Toyota Body and Structures Engineering—Kentou

Pre-clay freeze activities mark the beginning of a crucial period during the
product development process at Toyota. Referred to as kentou or study,
this is a time of intense engineering activity throughout the PD program,
during which engineers generate hundreds of kentouzu or study drawings.
At this time, cross-functional Module Development Teams (MDT) meet

51
Morgan Liker sec 2 3/2/06 11:16 AM Page 52

Section Two: Process Subsystem

with each participant to study his or her unique technical perspective of

the clay models and design proposals. As noted in Chapter 3, MDTs are
cross-functional teams typically organized around the various vehicle sub-
systems. They consist of representatives of the functional organizations
responsible for some aspect of subsystem development, such as the clo-
sures or the instrument panel. A typical MDT might comprise one to three
senior engineers from the body engineering organization, someone from
styling, one or more members from the production engineering group,
and, if necessary, an electronics engineer. Pilot team leaders from the
assembly plant might also participate if there are important implications
for final assembly in a particular subsystem.
This discussion of MDTs requires a brief examination of styling at
Toyota, which has intentionally created two different roles for this func-
tion. The first is purely artistic, a designer who develops the sketches that
may, if selected, become clay models. This designer is relatively protected
from discussions of manufacturability and the usual consensus building
that characterizes Toyota. The second role is a combination of art and
pragmatism, the production designer responsible for modifying a clay
model to make it more production ready. This second role is part of the
MDT; in fact, some production designers are stationed in the engineering
offices and work side by side with body engineers. They represent styling
from a dual perspective: one that deeply understands what the customer
values and one that deeply understands the permissible degree of freedom
to modify a style in order to make it more producible. In organizational
terms, a production designer’s function fulfills a liaison role.
The entire MDT’s function is to identify and resolve technical prob-
lems and map strategies to achieve component/subsystem-level goals that
are aligned with and support overall vehicle objectives. A major part of this
task requires studying the design interfaces. As most experienced engineers
know, most problems occur at component intersections. It is relatively
straightforward to design an outer door. The true challenge lies in design-
ing the door system (inner, outer, reinforcements, electronics, etc.) and
ensuring that the door fits the body shell, matches the fender, and the cen-
ter pillar and to design this system in a manner that supports lean manu-
facturing. This means making sure that designs are compatible and feasible
before they are complete. By completing individual designs too quickly, you
run a great risk of having to change them later in the program when choices
are more limited and expensive, that is, after you have matched them up
with related components or assessed them for manufacturability.

52
Morgan Liker sec 2 3/2/06 11:16 AM Page 53

Front-Load the PD Process to Explore Alternatives Thoroughly

The importance of using early cross-functional teams for component-

level goal setting and problem solving to resolve such challenges cannot be
overemphasized. MDT participants are also Toyota’s best and seasoned
engineers. Using Toyota’s standards and fundamental engineering tools
and practices, they help identify and reduce variability. An MDT may
spend hundreds, even thousands, of engineering hours working toward
this goal, so downstream activities can focus on execution.

Standardizing Lower-Level Activities Enables Quick

Problem Solving: An Example
Toyota’s tradition of standardizing lower level activities enables a problem-
solving methodology for finding multiple alternative solutions to engi-
neering challenges. For example, in the design and development of an
outer hood panel, manufacturing standards require that the hood be
stretched (not drawn because feeding material will reduce required stretch
for class-one surface appearance) and that the hood be fully manufactured
in three operations (draw, trim, and flange). Body engineering must engi-
neer a hood that matches the required body sweeps at the fenders, wind-
screen, and grill, while maintaining the vehicle trademark power dome at
the center of the hood. The body engineer will create (in section form)
several versions of the hood that meet the outlined criteria but will look
substantially different from each other. In the meantime, the production
engineer assigned to the program (the Simultaneous Engineer) will evalu-
ate these drawings against his:
• Common architecture-standard construction sections
• senzu (a manufacturing intent drawing of the previous hood for
this vehicle)
• component quality matrix (individual part quality plans discussed
in Chapter 15)
• the specific goals resulting from competitor tear downs
Using this standardized material and the component quality matrix,
the production engineer (PE) then provides written feedback to the body
engineer on each proposal. If necessary, the PE may even surface the sec-
tions and run them through simulation software, although this does not
often occur because Toyota’s component-specific process histories are usu-
ally sufficient. In any case, the PE can provide quick feedback on the vari-
ous alternative designs because of standardization and experience.

53
Morgan Liker sec 2 3/2/06 11:16 AM Page 54

Section Two: Process Subsystem

The PE, based on his significant experience, knows that as long as the
periphery depth of the hood is kept below a specific level and is constant,
the depth and shape of the power dome and the sweep of the fender lines
are of little concern to production engineering. However, these factors do
become important near the windscreen surface blends. Here the PE con-
sults previous senzu for creating a temporary “manufacturing surface” that
is designed to maintain surface tension for good appearance. The PE con-
tinues to address specific difficulties and challenges in a systematic, ongo-
ing process, eliminating some alternative designs and combining specific
characteristics of others to produce a final design.
This collaborative, simultaneous engineering process has important
implications for the PD process and the sense of ownership of key partic-
ipants. For instance, requiring that team participants closely interact to
evaluate multiple solutions against specific criteria is a driving force for
generating a breadth of options. And the kentouzu, or study drawings,
generated from this process are the first step to creating K4 drawings (to
be described later). This process is markedly different from processes prac-
ticed by many of Toyota’s competitors where, as was noted in the descrip-
tion of NAC, “early feasibility assessment” often means a manufacturing
engineer looking at the clay model and providing a list of what seems
infeasible. Styling then responds to this “point-based” input with some
iteration, which satisfies some concerns and ignores others.
At Toyota, such an approach would be untenable. Instead of styling
doing most of their work and then asking for a reaction, the team jointly
develops the body with intensive interaction and many data sources at its
disposal. The team utilizes competitor teardowns and preprogram plant
visits to act on specific objectives defined in the CE’s concept paper. The
primary tasks of the team during this period are to work together to trans-
late the CE’s customer-defined value into meaningful engineering require-
ments and to resolve subsequent design/manufacturing challenges while
staying true to the stylist’s artistic rendering of what is a visually appealing
design from a customer perspective.

Application of Common Architecture and Principle

of Re-use
Another critical aspect of the kentou phase is the application of common
architecture through detailed design standards and specifications, which
the body engineer can draw from a database of best-body sections for each

54
Morgan Liker sec 2 3/2/06 11:16 AM Page 55

Front-Load the PD Process to Explore Alternatives Thoroughly

vehicle type. Body engineers can expand, shrink, or otherwise modify

these structural best practices while the database simultaneously main-
tains critical geometric relationships to preserve product performance and
manufacturability. Wherever possible, the body engineer identifies carry-
over or cross-platform parts for possible use. The principle of re-use is cru-
cial to efficiency and quality because qualified and established components
substantially reduce performance variability in product development,
tooling development, and final production. The downstream impact of re-
use on quality and efficiency is dramatic. There are typically two or three
body engineering supervisors participating in this stage of the process and
holding key meetings with the CE Team and upper management to begin
the vehicle-vision cascade.
As the CE narrows the alternative clay models to two or three, digital
scans are sent to the body engineering group for more detailed evaluation.
This stage of kentou is referred to as the idea proposal stage and as many
as ten core body engineers may be involved. This is also the beginning of
kentouzu or study drawing generation. Given that the engineers are work-
ing from scan data, the majority of study drawings, originally created by
hand, are re-created in CAD.

Evaluating and Deciding on Vehicle-Level Goals

The MDT evaluates the impact of vehicle-level goals on the body, identi-
fying and resolving potential problems. For example, the CE Team may
have decided to incorporate a new lighting system that was demonstrated
by one of Toyota’s suppliers, and this may have a significant effect on the
design of the front fascia and fender and, in turn, on the manufacture of
those components. The body engineer generates several solutions to this
design challenge for the production engineer to evaluate quality and man-
ufacturability. It may be that the shape of the new lighting system, when
combined with the fender-to-hood line sweep, will cause the “nose” of the
fender to be too sharp and thereby create a poor quality manufacturing
condition. Or perhaps a new safety regulation in the United States requires
increased bumper impact absorption, which, in turn, will require greater
bumper overhang that affects vehicle styling. These kinds of challenges
will also initiate multiple alternatives for the MDT to review. A great deal
of negotiation takes place in these teams, and participant passion can lead
to conflict. However, Toyota’s “customer first” mentality or customer-
defined value, is the final arbiter for decisions.

55
Morgan Liker sec 2 3/2/06 11:16 AM Page 56

Section Two: Process Subsystem

During this time, there is also a great deal of component or subsystem

testing. Wherever a nonstandard condition exists, the body engineers
carry out virtual or physical testing of rapid prototypes and mockups.
Although testing is often straightforward, it is always scientific.
Body engineering holds regular (often weekly) meetings with several
module teams (or the “cross-module team”) to address detailed technical
problems and decide schedules, budgets, and design interfaces. These
meetings are typically short because the engineers use a variety of commu-
nication tools (described in Chapter 14) and hold small pre-meetings
(often consisting of two engineers) to provide all relevant problem descrip-
tions, Toyota standard references, and proposed solution alternatives to the
appropriate meeting participants before the meeting. Participants are
expected to be informed and prepared for the meeting and to have achieved
consensus. At the meeting, team members engage in a detailed and pro-
ductive discussion. This type of lean cultural behavior is another illustra-
tion of integrating process, people, and tools and technology.
As the vehicle design matures and the clay models are reduced from
two to one, body engineers begin to transform their study drawings into
simultaneous engineering drawings to initiate several specific production
engineering activities, such as processing, fixture layout, or binder devel-
opment. The design intent of these drawings is close to the final layered
drawings that will be available at final data release. Given the standardized
processes and the size and general shape of parts, the product engineers
can begin their simultaneous activities in earnest.

Toyota Production Engineering: The Simultaneous

Engineer’s Responsibilities
In the 1990s, Toyota continued to push manufacturing considerations
further up in the development process. Body engineers had always been
very cognizant of manufacturing issues and had spent time working in
the plant as well as regularly visiting the plant, but Toyota wanted more.
Under its current, more aggressive simultaneous engineering process (in
the early stages of kentou), key production engineers are assigned to
vehicle program MDTs as simultaneous engineers (SEs) who function as
full-time representatives of their manufacturing discipline. For example,
the body closures MDT might have an SE lead and several SE members
who are each responsible for 12 or more individual parts throughout the
entire program.

56
Morgan Liker sec 2 3/2/06 11:16 AM Page 57

Front-Load the PD Process to Explore Alternatives Thoroughly

At the beginning of the kentou phase, the SE team studies electroni-

cally transmitted design information before attending the biweekly MDT
meetings. Body engineering hosts these meetings and with production
data and updated senzu (manufacturing drawings) and checklists in hand,
the engineers discuss the analysis of current design proposals and partici-
pate in the often arduous negotiations. They will spend hundreds of hours
analyzing, discussing, and codeveloping multiple-design alternatives to
achieve process and product goals.
This is an intense period for each simultaneous engineer, during
which single MDT sessions may run for several 12-hour days at a stretch.
Since the SE is responsible for his or her parts from this time until start of
production (SOP), there is strong motivation to evaluate the quality and
productivity implications for manufacturing of the proposed designs
thoroughly. The SE will serve as “Lead Manufacturing Engineer” and will
be fully responsible for a specific set of parts as he or she shepherds them
through the entire development process. This process eliminates many of
the handoffs and associated wastes in a typical product development
process. The SE is also aware that the decisions reached now will affect the
success of every other step in the development process to SOP.
As noted above, Toyota uses the CE’s concept paper, field QA data,
competitor teardown sheets, and current production process data to
establish specific goals for both the vehicle system and individual compo-
nents. Toyota accomplishes this by translating specific product quality and
performance goals, based on customer-defined value, into specific part
design characteristics. This, in turn, requires a robust manufacturing
process capable of consistently delivering parts within an acceptable toler-
ance range at a reasonable total cost. Each body engineer and simultane-
ous engineer understands that this process will require saying no and
eliminating non-critical part requirements or unreasonable tolerance
bands. The process also identifies critical customer-defined quality char-
acteristics, and eliminates nonessential elements in the pursuit of those
specific goals.

SEs Must Hit Investment and Variable Cost Targets

The SEs are also responsible for hitting both investment and variable cost
targets for their parts—both the tooling cost and the parts produced by
these tools. This is the beginning of enabling lean manufacturing. It is
the CE who sets goals for performance and quality for both the part and

57
Morgan Liker sec 2 3/2/06 11:16 AM Page 58

Section Two: Process Subsystem

the efficient manufacture of the part. It is also the CE who establishes the
cost targets with a continuous improvement concept in mind. It is the role
of the SEs to work early and hard in the PD process to meet and design (in
process) capabilities and efficiencies for both the product and process. This
is a far cry from teams that try to “thrift” or improve a process after the fact.
Lean manufacturing processes are standardized by part, continuously
improved, and adhered to by all participants. The key to SEs successfully
managing such broad responsibilities and achieving cost, quality, and per-
formance targets is to front-load problem solving and adhere to disciplined
standardization. This makes the body engineer and the simultaneous engi-
neer equally responsible for adhering to standardized manufacturing
processes. The early design process consists of the following:
• defining a “design space” or system requirements
• creating multiple design and process alternatives (or solutions)
based on standards (including common construction sections)
• quick testing and program objectives, analyzing each alternative’s
impact on cost, quality, and performance
• rigorously honing in on the essential characteristics of each
alternative
• combining characteristics across alternatives
• focusing energy and effort toward a single design and process solution
In this sense, product and process are “codeveloped” and solutions are
“designed in” instead of becoming expensive add-ons later in the process.

Mizen Boushi and Going to Production Plants

In preparation for the kentou process, the SE spends a good amount of
time in the production plants gathering data and talking to team leaders
and operators in order to understand fully current manufacturing issues
and solicit potential countermeasures. If necessary, the SE invites produc-
tion team members to visit with the MDT. This is an important part of the
mizen boushi or designed-in quality process during which engineers focus
on “designing in” countermeasures. Roughly translated, mizen boushi
means “to prevent mistake” or “preventive measure” and refers to a disci-
plined process that focuses on the early design stage to engineer products
and processes that support lean manufacturing and produce robust qual-
ity. Standardized design and process checklists (discussed in Chapter 6)
are crucial to this very rigorous process.

58
Morgan Liker sec 2 3/2/06 11:16 AM Page 59

Front-Load the PD Process to Explore Alternatives Thoroughly

Communicating with Functional Specialists

During the kentou process the SE continually communicates with different
functional specialists within the production engineering department, such
as process engineers, die designers, fixture and assembly engineers, and
even with assembly teams in the plant. Although he or she is an experi-
enced production engineer, the SE is not typically as knowledgeable as the
specialists and utilizes their specific knowledge to deal with highly techni-
cal or unusual situations. In this way, the SE acts as the link between
styling, body engineering, production engineering, and the production
plant. As such, the SE communicates on both technical and logistical
issues, helping to keep the activities of both groups synchronized. From
the beginning, the SE communicates specific performance, cost, and qual-
ity objectives with the functional specialists and uses their input to fashion
his or her counterproposals for the MDT. In addition to obtaining valu-
able technical input, this activity also creates early familiarity and a sense
of ownership among the functional specialists on whom the SE will rely
for much of the core manufacturing engineering tasks. This is crucial to
achieving both PD and manufacturing process efficiency goals. The SE
also works with specific suppliers if these provide manufacturing engi-
neering services. This activity in and of itself can enhance the PD process.

The SE Submits the Plan

The SE eventually emerges from the communication part of the process
with a deep understanding of the product goals and a process plan. The SE
prepares, on an 8.5 3 11 sheet of paper, a process plan for each of his or
her components and subsystem, which is reviewed with the appropriate
functional specialist within the production engineering organization. This
plan, along with the part-specific senzu and quality matrices, is used to
begin preparation for such activities as “prepare for die/fixture design”
and “preliminary binder developments” in the core production engineer-
ing groups.

Leveraging Digital Tools

Much of Toyota’s ability to front-load its PD programs has been enhanced
by significant advances in digital technology (discussed further in Chapter
13). PD teams can begin very early in the process with advanced design

59
Morgan Liker sec 2 3/2/06 11:16 AM Page 60

Section Two: Process Subsystem

tools such as the CATIA CAD system, enabling design fit-up analysis or
“digital mockups” that identify design crashes (interferences) and ratholes
(voids). Often, the process includes parametric design models to make
certain that any change in part design is matched by updating all related
parts and tools. Sophisticated CAE crash and manufacturing simulation
tools enable short problem-solving cycles and allow more iterations to run
earlier, in less time, and at a lower cost. In fact, in many cases, these tools
have eliminated the need for elaborate, expensive, time-consuming physi-
cal prototypes. These technological innovations continue to shorten lead-
time, reduce cost, and improve product quality.

Early Problem Solving in Kentou: A Case Example

The lean PD process consists of an interrelated series of problems that must
be solved: technical, logistical, and financial. Obviously, organizations with
excellent problem-solving skills will achieve higher quality solutions faster
and have a significant competitive advantage in product development. In
addition, companies that are superior at problem solving will learn from
their experiences and have a greater knowledge base from which to draw.
This means they will spend less time “re-solving” problems.
Kentou results in far fewer engineering changes and creates process
flow by allowing companies to focus on downstream task execution. Ken-
tou also provides a formal structure for cross-functional teams to “design
in” solutions. This, of course, is far less expensive than solving problems
or “fixing” designs later in the process.
One fairly straightforward example of this problem-solving characteris-
tics of Kentou occurred during a Camry development program. The new style
called for a wrap-around headlight design that would have design, engineer-
ing, and manufacturing implications for the fender, hood, and front fascia.
As the MDT worked its way through these challenges during the kentou
phase, a critical problem surfaced. The new headlight clearance requirements
were driving a fender design with a long, narrow nose (see Figure 4-4).
The production engineering group suspected that this condition
would be problematic both in terms of dimensional stability of secondary
forming operations (twisting caused by material springback) as well as for
material handling (the narrow condition on the nose would be easily dam-
aged). Sketches and digital simulation tools confirmed these suspicions
and allowed the MDT to design and confirm a solution (see Figure 4-5).
By making a minor modification to the hood cut line (edge) the team was

60
Morgan Liker sec 2 3/2/06 11:16 AM Page 61

Front-Load the PD Process to Explore Alternatives Thoroughly

Design Issue
New wrap-around type headlight system required on vehicle,
which will necessitate a larger clearance area on the fender.

Figure 4-4. Kentou Early Problem Solving—Design Issue

Analysis
Early sketches showed a clearance opening that required a long
narrow nose condition on the fender.

Narrow Nose
Condition

Product eng. suggests modifying hood line and grill cut line to compensate

Figure 4-5. Kentou Early Problem Solving—Analysis

61
Morgan Liker sec 2 3/2/06 11:16 AM Page 62

Section Two: Process Subsystem

able to shorten the nose of the fender and arrive at a condition that satis-
fied all participants (see Figure 4-6).

Proposed Resolution
Make a minor modification to the hood cut line (edge) to
shorten the nose of the fender.

Product Design Revision

Figure 4-6. Kentou Early Problem Solving Example—Proposed Resolution

Had the team discovered this problem later in the process, there might
not have been sufficient design flexibility to allow for a designed-in solu-
tion. This would have led to a compromise based on cost of the engineer-
ing change—an inferior solution.
An example of “early problem solving” at the North America Car
Company (NAC) illustrates the stark contrast between a traditional and
lean PD approach. NAC recognizes the value of solving problems earlier in
the process, but has not developed any mechanisms such as MDTs or a
kentou period for this purpose. During the prototype phase of a recent
program, a supplier noted that the design condition of the inner lift gate
was very similar to the design of the inner lift gate from a recent program,
which resulted in material compression and wrinkles on the seal surface
(see Figure 4-7).
Unfortunately, the design solution required to rectify this condition
would change other adjacent parts that were also in the prototype stage
(see Figure 4-8).
Since these designs were “mature” and tooling for these parts had already
started, the only possible fix was to change the tools for manufacturing

62
Morgan Liker sec 2 3/2/06 11:16 AM Page 63

Front-Load the PD Process to Explore Alternatives Thoroughly

Current Program Previous Program

Figure 4-7. Seal Surface Compression and Wrinkle Condition

Alternative Design Suggestion

Figure 4-8. Alternative Design Solutions to Seal Surface Condition

63
Morgan Liker sec 2 3/2/06 11:16 AM Page 64

Section Two: Process Subsystem

the inner lift gate itself, which would help to minimize, but would not
eliminate, the wrinkling condition. Changing the massive stamping tools
was not only expensive, but also required considerable time.

Kozokeikaku (K4) Pulling the Pieces Together

The kozokeikaku or K4 is a high-level body structures document that pulls
together the final set of individual kentouzu into a body system plan. The
K4 term has evolved among Toyota’s North American Engineers because of
the difficulty of pronouncing kozokeikaku and the four k’s contained in the
word. The K4 plan includes critical vehicle cross-sections, locators, clear-
ances, and design intersections. It will also call out specific assembly
requirements, critical tolerances, and any other important manufacturing
direction as well as any potential standard process deviations. The K4 is the
body system execution plan. It defines all vehicle system requirements for
individual designs, provides crucial guidance to the detail design process
and is an invaluable aid in the real world execution of compatibility before
completion. It pulls together the results of the many study drawings devel-
oped in the kentou period. The K4 is circulated to all concerned functional
groups in both PD and Manufacturing for signatory approval. The K4 is
developed toward the later part of Kentou and is typically released about a
month after styling completion and provides the basis for early system
analysis, manufacturing planning, and all subsequent detailed drawings.

Right Person, Right Work, Right Time

Unfortunately, the early stages of product development at many compa-
nies are poorly understood and unstructured. As a result, they get few
resources and little attention. In these companies, management is
unwilling to commit its most capable human resources to the early stages
of a program, choosing instead to assign its best people to fire fighting in
the final stages. This is a waste of both corporate resources and the
potential and morale of high-performance individuals. Product develop-
ment is talent driven, and talented people generally prefer creating
something great rather than patching up a sinking program. Companies
that run ineffective PD programs often suffer from brain drain and con-
stantly produce mediocrity.
Getting the most out of talent is about using process, people, and
tools and technology effectively. Companies that do not get serious about

64
Morgan Liker sec 2 3/2/06 11:16 AM Page 65

Front-Load the PD Process to Explore Alternatives Thoroughly

product development until they begin to review completed designs, or

worse, physical prototypes, continually struggle with massive cost over-
runs and delay-riddled product introductions. Part of the problem is that
they subscribe to the notion of a “fuzzy front-end” and a “fix things” later
philosophy. When the front-end of concept development is “fuzzy,” it
suggests that serious, disciplined processes are impossible in this early
stage. Lean thinking sees this undisciplined approach as a slow, expensive,
and unpredictable process that can seriously disrupt product develop-
ment and other activities.
The concepts of concurrent engineering and front-loading have been
around for a while. As a result, some companies, in their eagerness to
speed up their PD process, have attempted to push more work up front
without a detailed understanding of the implications of this decision. This
is “front-load by brute force” and invariably leads to mistakes (such as
insisting on final pricing from suppliers before designs are complete or
doing too much process work with immature designs or rushing to com-
plete individual designs earlier in the process). These, and similar mistakes
lead to greater and greater levels of rework and a slower overall process.
Toyota, in contrast, focuses on doing the right work at the right time
executed by the right person. This in part explains the findings of Ward,
Liker, Sobek, and Cristiano (1995) that delaying decisions at Toyota gener-
ally leads to faster overall product development.
In the next chapter, the discussion returns to minimizing the second
PD waste, product development process waste. The chapter also looks at
useful tools for combating this waste.

LPDS Basics for Principle Two

Front-load the process to explore alternatives thoroughly

The LPDS is front-loaded because the start of the program is where

you can have the greatest impact on the success of the product for
the lowest cost. Preprogram, multiprogram management activities
include product portfolio management, technology and platform
planning, PD system resource management, and the management
of shared program content to create an environment where individ-
ual programs have the best chance of being successful. In individual

65
Morgan Liker sec 2 3/2/06 11:16 AM Page 66

Section Two: Process Subsystem

programs, cross-functional teams made up of the most experienced

people come together at the start of the project to look at a broad
range of solution sets that anticipate and solve problems, to design
in countermeasures for quality and manufacturability, and to iso-
late the inherent variability in product development in order to
facilitate flawless execution in the next phase of the program. At
Toyota, this takes place during an intense, initial program phase
referred to as Kentou, during which hundreds of kentouzu are gen-
erated and Toyota’s most experienced engineers resolve approxi-
mately 80 percent of a program’s technical problems and
dramatically reduce late engineering changes.

66
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 67

CHAPTER 5

Create a Leveled Product

Development Process Flow
At Toyota we try to make every process like a tightly linked chain—
where the processes are connected by information and by physical
flow. There’s nowhere for a problem to hide. The chain never works
perfectly. But if we know where our breaks are and our people are
trained to fix the breaks, we get stronger every day in the company. It
keeps us on our toes, it self-identifies muda and, five whys is our
method to eliminate muda.
GLENN UMINGER, Toyota Manufacturing Corporation, North America

The Power of Flow

In 1913, Henry Ford and his team revolutionized the world of manufac-
turing by developing a continuous assembly line for the Model T Ford and
introducing the world to the power of flow. Ford’s dramatic results were
not lost on Toyota, which was quick to learn from Ford and has subse-
quently become the leader in adapting the concept of flow to a variety of
environments. For Ford, however, flow stopped once a process moved
away from the assembly line. Outside the assembly line, large batches of
parts made by machining operations, stamping operations, and injection
molding operations were pushed, rather than pulled, to the assembly line.
Using cellular manufacturing, Toyota extended the concept of “one-
piece flow,” or leveled flow, throughout its operations—even into supplier
operations. When it was not possible to flow one piece at a time, Toyota
built small stores of parts, sometimes called “supermarkets.” This super-
market concept reflects what actually occurs in real supermarkets: Cus-
tomers “pull” what they need from store shelves and the owner or
manager replenishes the shelves as needed, restocking what customers
have purchased. In manufacturing industries, activity provides a direct
link between the customer and the supplier of materials in a pull system.
The smaller the batch size the producer makes, the closer the operation is
to the ideal “one-piece flow.” To maintain leveled flow, producers must be

67
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 68

Section Two: Process Subsystem

wary of waste. Toyota has long been aware of this and conducts its “war on
waste” on processes companywide.
So what does this have to do with product development? This chapter
posits that Toyota’s success in product development starts with viewing PD
as a process. Like any process, PD has a cadence and repeated cycles of
activity. Toyota has done an exceptional job of standardizing the PD
process to bring to the surface the repeated cadence that allows continu-
ous improvement through repeated cycles of waste reduction. The chapter
focuses on the notorious seven wastes of lean manufacturing and identi-
fies some of the solutions Toyota has discovered to remove these wastes
from the product-development value stream. In addition, this chapter
shows that Toyota has managed to “level the flow,” not only by eliminating
waste (muda) but also by eliminating “unevenness” (mura) and “overbur-
den” (muri). In this way, Toyota has steadily moved ahead of its competi-
tion in bringing products to market more quickly and with higher quality.

Viewing Product Development as a Process

As discussed in Chapter 4, the majority of Toyota’s product development
is derivative product vehicles built on existing product platforms, focusing on
modifications of existing products or variations on a theme. This type of
PD system typically has a great deal in common with other process-based
systems, such as manufacturing operations. For instance, modern PD sys-
tems must deal with multiple projects simultaneously and face similar
shared resource management challenges. Moreover, even though many of
the specific design challenges might be different, the basic work, the tasks,
and the sequence of tasks, are the same across programs. From this per-
spective, companies can view the PD system as a knowledge work job shop
that must deal with multiple work centers, constraints, and an integrated
network of queues. This PD process perspective enhances a company’s
ability to apply adapted process management tools and methods to reduce
variation and create leveled process flow without destroying the creativity
necessary for great products.
This view of product development begs the question of just how
“lean” applies to a process in which information flows is more important
than material flows and in which variability from project to project is a
given. In other words, can PD value streams be made to flow as smoothly
as the manufacturing of physical goods? There are two answers to this
question: yes and no. Yes, you can view product development as a repeat-

68
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 69

Create a Leveled Product Development Process Flow

able process of steps that are interrupted by waste. Stabilizing the PD

process and improving it through waste reduction is quite possible and
effective. But no, it is clearly not identical to repetitive manufacturing
processes. The tasks are more complex with relatively long cycle times and
far too much variability to pull out seconds. Thus, even though many of
the concepts and methods discussed in this chapter have common roots in
manufacturing—as discussed in the The Toyota Way (Liker 2002)—it is
critical to keep in mind that product development has its own complex
environment and fundamentally unique challenges. One of the first of
these is seeing the process.

Value Stream Mapping

The key tool for understanding the flow of material and information and
seeing the manufacturing processes is value stream mapping (Rother and
Shook, 1998). This methodology looks at the transformation of material
as a series of process steps interrupted by waste. What governs the flow is
information that tells individual processes what to make, how much, and
when. By mapping the current state and identifying the waste that inter-
rupts flow, value stream mapping then moves to a leaner future state
vision that is translated to an action plan. This powerful tool seems to be
fine for repetitive manufacturing processes but is, at least in its original
form, difficult to apply to product development.
With modifications, however, value stream mapping can become a
powerful tool for improving product development value streams. Morgan
(2000) has successfully adapted value stream mapping to the complex PD
environment. (This modification, called PDVSM, is reviewed in Chapter
17 and illustrated in the appendix to this book.) The starting point for
representing the PD value stream is recognizing it as a process. One key
attribute of this unique process is that it involves many parallel, interde-
pendent activities rather than the neat serial value streams typical of
manufacturing.
In any given product development project, there is a lot going on. The
primary activities are value-adding activities and waste is hidden. The key
to superior product development is to disentangle this complex web of
activity into definable “work streams” that perform a distinctive function:
converting inputs into outputs. Doing this reveals a number of parallel
work streams that are, to some extent, independent but are also inter-
dependent. It also reveals waste within each of the work streams.

69
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 70

Section Two: Process Subsystem

Figure 5-1 illustrates a PD value stream as a series of parallel “work

streams.” Each work stream (or “swim lane”) has a set of serial processes
interrupted by waste. The figure shows the work streams on a common
timeline; viewing a single slice or section of this reveals what is happening
across work streams. As Chapter 17 of this work will show, the PDVSM
tool can also be used to reveal connections across work streams, different
types of waste, and even feedback loops.
One thing that will be apparent to any one experienced with product
development is that the timing suggested by a chart like this is rough at
best. For example, not every project will have a concept stage that starts or
ends as neatly as this diagram suggests. It is not always clear exactly when
a concept stage begins or ends. For this reason, it is important to note that
this diagram illustrates only concepts. Actual current-state value stream
mapping should reflect the activities and timing of a real product devel-
opment project—not an abstract “typical project.” All projects are some-
what unique. At this level, the task at hand is to understand the wastes and
sources of waste in a product development value stream, not to measure
precise and invariable activity sequences and timing.
With this caveat, it is important to reemphasize that the starting point
for improving a process is to understand it as a process. And the starting
point for eliminating waste is to recognize waste. Figure 5-1 suggests that
(from the perspective of the information being transformed into a design)
most of the time spent in a product development process is, in fact, waste.
But what most companies typically do in the name of reducing PD lead
times is to focus on reducing time in value-adding processes. For example,
they implement a new CAD feature that reduces the time for entering data
into the computer and creating the 3-D graphic. Or they buy faster com-
puters to make the engineering analysis algorithm converge more quickly.
Lean, on the other hand, begins with looking at the total value stream
because waste between process steps is likely to be far greater than waste
within a single process step (like entering the CAD data). A full apprecia-
tion of the concept of waste requires characterizing waste in PD value
streams and understanding its causes.

Seven Wastes in the Product Development Process

Most product development processes are not lean. They are, in fact,
fraught with waste. Waste or muda is any activity in a process that con-
sumes resources without adding value for the customer. In this work, the

70
 Marketing Business Model

Clay Model Theme Selection

Concept
Engineering Change Support
CAD
Morgan Liker sec 2_ch 5&6

Styling Launch Support

CAD Design
3/2/06

Supplier Development Product Quality

Prototype

Mfg. Eng.
1:05 PM

Tooling
Process Development

71
Launch
Page 71

Tooling Construction

Design Time Start of

Concept Production

• Value Added Time is only a very small percentage of the Lead-Time.

= Non-Value Added Time (Waste)
• Traditional Cost Savings focused on only Value Added Items.
Create a Leveled Product Development Process Flow

= Value-Added Time
• BETTER: List All Steps and Target the Non-Value-Adding Ones!

Figure 5-1. Product Development Lead Time

Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 72

Section Two: Process Subsystem

starting point for identifying product development wastes is Taiichi Ohno’s

seven categories of waste: Overproduction, Waiting, Conveyance, Process-
ing, Inventory, Motion, and Correction. Although causes for these notori-
ous seven are different for manufacturing, these same categories can be
quite useful in revealing non-value-adding activities in product develop-
ment (see Figure 5-2).

Seven Wastes What is it? PD Examples

Overproducing Producing more or Batching, unsynchro-
earlier than the next nized concurrent tasks
process needs
Waiting Waiting for materials, Waiting for decisions,
information, or information
decisions distribution
Conveyance Moving material or Hand-offs/excessive
information from information
place to place distribution
Processing Doing unnecessary Stop-and-go tasks,
processing on a task redundant tasks,
or an unnecessary task reinvention, process
variation—lack of
standardization
Inventory A build up of material Batching, system
or information that is overutilization,
not being used arrival variation
Motion Excess motion or Long travel distances/
activity during task redundant meetings/
execution superficial reviews
Correction Inspection to catch External quality
quality problems or enforcement,
fixing an error correction and
already made rework

Figure 5-2. Applying the Seven Wastes to Product Development

1. Overproduction: In manufacturing, this is producing ahead of

what is actually needed by the next process or customer. In prod-

72
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 73

Create a Leveled Product Development Process Flow

uct development, this waste is common where processes are not

well synchronized across functional organizations. Examples of
this include any task that is completed before the next operation
is ready to process it or conversely, downstream operations work-
ing on upstream designs prematurely in an effort to do concur-
rent engineering. Another example of overproduction is working
on the wrong activities instead of on activities the next process
really needs. Often, overproduction is the result of completing
design work before checking for its system compatibility or man-
ufacturability.
2. Waiting: In manufacturing, operators stand idle waiting for mate-
rial or do nothing while their automatic machines are processing.
In product development, engineers seem to be in a state of perpet-
ual motion, always rushing from meeting to meeting or engrossed
in something on a computer screen. From the perspective of a
workstream, however, there is often some key activity that engi-
neers should be working but cannot because they do not have
what they need to proceed with the given task. Before they can
proceed, engineers routinely wait for reviews, decisions, permis-
sion, information, purchase orders, or some other wasteful trans-
action activity. Our experience has repeatedly demonstrated that
waiting is one of the most pervasive wastes in the PD process.
3. Conveyance: In manufacturing, this means moving parts and
products unnecessarily. In product development, it means unnec-
essary handoffs from one overly specialized activity to another,
and more specifically, information changing hands, whether by
word, picture, or data exchange. This waste leads to the loss of
momentum, information, and accountability in the process. It is
also a commonly accepted dysfunction in traditional PD systems.
4. Processing: In manufacturing, this waste is manifested by unneces-
sary or incorrect processing. In product development, it includes
engineering errors or system flaws. Proper training and development
can eliminate or greatly reduce the former. It can also result from
designing new components instead of using carry-over, designing
from scratch instead of morphing standard design architecture, or
creating new manufacturing processes for each program instead of
working to a standard manufacturing process. Another example of
processing waste is unnecessary transactions and negotiations that
transpire while selecting and managing suppliers.

73
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 74

Section Two: Process Subsystem

5. Inventory : In both manufacturing and PD, inventory waste is the

direct result of overproduction. For manufacturing, this is simply
having more than the minimum stock required for a precisely con-
trolled pull system. In product development, it is excess information,
such as designs that wait for the next available resource. Information
waiting in queues to be processed represents the most insidious
waste in product development. Often, there are problems in this
information (e.g., it is not what the next process needs) or informa-
tion gets lost and is late in getting to where it is needed. These prob-
lems often remain hidden; by the time anyone discovers them, they
have already resulted in extensive rework and long lead times.
6. Motion: In manufacturing, operators move in ways that are
unnecessary or cause strain. In product development, engineers
attend unnecessary meetings, create redundant status reports,
and prepare for and participate in unnecessary project reviews.
Motion waste also includes nonsubstantive, “wide aisle” type
plant and facility tours that do not lead to the direct data needed
to make real design decisions.
7. Correction: In manufacturing, this is inspection, rework, and scrap.
In product development, it takes the form of program audits,
reviews, testing new components instead of reusing proven ones,
late engineering changes, excess tool tryout, and all forms of
rework. Most product development processes are so inflated with
the correction waste that at least a third of total allocated
resources are engaged in rework at any given time.

There Are Really Three Ms

People often define the goal of lean as waste elimination. But battling
muda does not accurately represent all that “lean” is about. True lean
thinking does not focus on one-dimensional muda elimination; it works
to eliminate three types of interrelated waste: muda, mura, and muri—col-
lectively known as the three Ms.

1.Muda (non-value-added). The best known “M,” it includes the

seven wastes of the Toyota Production System and their lean prod-
uct development counterparts discussed in Chapter 3. Any activi-
ties that lengthen lead times and add an extra cost to the product,
for which the customer is unwilling to pay, are considered muda.

74
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 75

Create a Leveled Product Development Process Flow

2. Muri (overburden). In some respects, muri is the opposite of muda.

Muri is pushing a machine, process, or person beyond natural limits.
Overburdening people can lead to sloppy work resulting in quality
problems and potential safety risks. Overburdening equipment
causes breakdowns and defects. Overburdening a process means
long queues that increase PD lead-time or short-circuiting the
process, which leads to downstream errors and rework.
3. Mura (unevenness). In normal production systems, the workflow
is uneven. Sometimes, there is more work than people or
machines can handle; at other times, there is not enough work.
Engineers are all too familiar with the frenetic pace of work
immediately preceding a deadline (for example, prototype review
or new product launch), which is generally followed by calm with
relatively little work pressure. Unevenness results from an irregu-
lar production schedule or fluctuating production volumes caused
by internal problems such as computer downtime or missing
information. Muda will be a result of mura. With uneven produc-
tion levels, it will always be necessary to have the equipment,
materials, and people on hand for the highest level of produc-
tion—even if the average requirements are much lower.

When they begin to apply lean methods, most companies look at any
process where the work schedule swings wildly and begin engaging in a
“war on waste” to eliminate muda. Almost invariably, they start by pulling
out inventory and linking operations. They also look at the work balance
and take people out of a system; they also reorganize the workplace to
eliminate wasted motion. Then they step back and let the system run. To
their dismay, the “improved” system often runs itself into the ground!
People become overburdened, sick leave soars, equipment break downs
more often, and before long, management is convinced that lean doesn’t
work. What these companies fail to realize in “implementing lean” is that
they have done nothing to stabilize the system and create the “evenness”
that allows lean tools to work properly.
Lean thinking has made it is easy to identify waste and pull it out of a
system, but it takes much more effort to create an evenly balanced lean
flow of work. What many companies are fixating on is blindly pulling out
muda because this can lead to short-term cost reductions. An extreme
example of this is downsizing the engineering work size by 10 or 15 per-
cent. Costs go down and the company has eliminated “waste.” But has it

75
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 76

Section Two: Process Subsystem

really? In lean thinking, the real and more difficult challenge is the long-
term task of continuously driving out muri and mura—managing and cor-
recting an overburdened and uneven system. Downsizing engineering work
does neither. In fact, it inevitably results in overburdening and uneven-
ness, albeit somewhere else in the process.
Most people assume that continuous flow means leveled continuous
flow. But the result of this assumption is flawed decisions that eliminate
“waste” in one activity while ignoring waste elsewhere in the process. For
example, having material flow one piece at a time across work centers
without inventory does not correct a jerky and unstable pace and mix of
production. This is not and will never be a continuous flow. It is simply an
erratic, one-piece flow, with starts and stops, overutilization and under-
utilization that is inherently failure prone and will almost always fail to
create quality, productivity, or continuous improvement. Continuous flow
is eliminating all non-value-adding activities of a product’s progression
along its value stream so that it flows unimpeded continuously—from con-
cept to delivery.

Barriers and Facilitators of Flow: Insights from

Queuing Theory
It is important at this juncture to examine why the seven wastes discussed
above are so prevalent because no company can truly understand how to
eliminate these wastes until it understands their true root cause. Viewing
the PD process as a knowledge work job shop and considering the well-
known body of knowledge on queuing theory will provide some impor-
tant insights about the root cause of waste in product development.
Queueing theory can help us to see how traditional approaches to product
development actually exacerbate the inherent variability in the process
andcause incredible amounts of waste. Traditional PD practices that are
particularly problematic include:

• PD work centers working in large batches created by the stage-gate

or milestone based product development processes.
• PD work centers with differing levels of capacity at any point in
time creating capacity mismatches and a general ignorance of work
center capacity and subsequent constant system overburdening.
• Unpredictable PD workloads expanding to take up all the time of
all engineers assigned to projects.

76
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 77

Create a Leveled Product Development Process Flow

• Highly cyclic PD workloads characterized by lulls in workload fol-

lowed by tremendous system congestion, expanding lead times
beyond planned deadlines.
• Low levels of task execution and scheduling discipline, leading to
high levels of both task and interarrival variability.
To gain insight into the reasons wastes are generated by this approach
consider the PD process as a system—where arrivals (requests for work)
place demands upon a finite capacity resource—and apply queuing the-
ory—the phenomena of standing, waiting, and serving. Then consider
traditional product development practices in the light of the following
basic tenants of queuing theory which are well understood in manufac-
turing and well documented in Factory Physics (Spears and Hopp, 1996):
• Law of Batches: “Cycle times over a routing are roughly propor-
tional to the (move) batch size used in the routing.”
• Law of Variability Placement: “Variability early in the routing has a
greater impact on WIP and cycle times than equivalent variability
later in the routing.”
• Law of Utilization: “If a system increases utilization without mak-
ing any other changes, average cycle time will increase in a highly
nonlinear fashion.”
• Law of Variability: “In steady state, increasing variability always
increases average cycle times and WIP (work in process) levels.”
These principles can teach us a great deal about the root cause of
much of the fundamental waste in the product development system. The
“law of batches” suggests that if we manage the product development
process as a series of gateways at which the process must pause and then
organize the product development system into a lot of separated work cen-
ters (sometimes called functions or chimneys), each processing and releas-
ing work in large batches of information we begin to understand why we
experience tremendous levels of WIP and incredibly long lead-times in
product development. Consider, for example, a centralized engineering
analysis department getting many requests for analysis over time and then
working on these requests and issuing results in batch mode. The natural
result is that this will extend lead times. Substitute for engineering analy-
sis executive reviews, the design studio, body engineering, the prototype
shop, testing, CAD designers, tooling designers, etc. and you will get the
same results that the law of batches predicts for a job shop.

77
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 78

Section Two: Process Subsystem

Capacity over-utilization has well understood consequences for sys-

tem performance yet system capacity is seldom even a consideration in
product development planning. The queuing curve illustrates the
increases in lead time based on changes in system capacity utilization (see
Figure 5-3). It begins to increase in a nearly exponential manner at about
80 percent of capacity utilization, meaning that there is a nonlinear rela-
tionship between additional system loading and lead-time increases when
80 percent of system capacity has been reached. Product development sys-
tems often operate at levels significantly above this level.

After about 80 percent capacity, a

small change in system loading has
Development a large impact on throughput time.
Lead Time

0 Capacity Utilization 100%

Nonlinear relationship between capacity utilization and

lead time causes systems to bog down before full
utilization (Factory Physics, 1996)

Figure 5-3. Effect of Overburdening Capacity on Development Lead Time

To make matters worse, the high level of variability naturally associ-

ated with the PD process further exacerbates these system-loading effects
as illustrated in Figure 5-4
Variability is a primary determinant of poor system performance.
Unfortunately, most traditional PD systems are ripe with variability. There
are two types of variability to be concerned with:

1. Task Variability: This refers to differences in the methods

and duration of specific tasks rampant in most product
development.
2. Interarrival Variation: This refers to the time difference between
when work is scheduled to arrive at a workstation and when it

78
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 79

Create a Leveled Product Development Process Flow

actually arrives. This is often caused by the first type of variation

as well as by capacity constraints.

When these types of variations combine within a system, we get a

rapid propagation of variation that is incredibly destructive to system per-
formance. Moreover, if the variability is present early in the process, it will
have a magnified effect throughout the process. Thus, any efforts to elim-
inate this variability on the front end (the concept stage as covered in
LPDS Principle 2) will pay huge dividends. Consequently, managing vari-
ation and controlling system capacity is crucial to high levels of product
development system performance.
It may be easiest to understand these phenomena through a com-
monly cited analogy. At one time or another, we have all been in a traffic
jam. Traffic comes to a complete stop and then moves at a snail’s pace for
miles. Finally, we discover the cause of the delay. Two cars, involved in a
minor accident, are on the side of the road with a police car partially
blocking traffic in one lane of a three-lane highway (see Figure 5-5). But
why would this cause traffic to stop. The fact of the matter is that if the
conditions were different (e.g., fewer cars on the road or low highway sys-
tem utilization), then the partially blocked single lane would not create a
jam. Excess highway system capacity would be available to absorb the vari-
ability. However, if the highway is 80 percent utilized (or more), losing one

20
19
18 Queuing Theory
17
16
15
14
13
Average CT

12
11
10 High
9 Variability
8
7
6
5
4 Low
3 Variability
2
1
0
0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0

Utilization

Figure 5-4. High Levels of Variability Further Exacerbates the Effects of

Capacity Utilization (Factory Physics, 1996)
Capacity Utilization and Variability

Variability
79
Capacity Utilization

CTq =
( Ca2 + Ce2
2 )( )
u
1-u
te
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 80

Section Two: Process Subsystem

lane causes a major backup. In this case, the variability in the system (the
cars unexpectedly getting into an accident and heavy traffic at that partic-
ular time) will lead to total system congestion and long lead times (i.e.,
traffic moving at a snail’s pace).

Low Resource Utilization Above 80 Percent Capacity

Figure 5-5. Queuing Theory and Traffic Jams

Striking evidence for the effectiveness of applying the principles of

queuing theory in product development is provided by Paul Adler. Adler
et al. (1996) studied several PD projects and verified a common finding:
that the projects progressed fairly smoothly during periods of moderate
workloads when people were not very highly utilized. However, when the
workload increased and reached about 70 to 80 percent of system capac-
ity, any additional workload began to cause the lead time to increase dra-
matically. Any variability in the process (e.g., missing information,
wrong information, late arrival of key data) interacted with any increases
in workload, causing the system to blow up. In fact, overutilization of PD
resources, along with high levels of process variability is the primary rea-
son for long lead times, program delays, and even quality issues. By man-
aging system utilization and employing basic tools to reduce both task
and interarrival variability these companies experienced both decreases

80
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 81

Create a Leveled Product Development Process Flow

in lead time and increases in overall system productivity over time

(Adler et al, 1996).
Queuing theory principles nearly always reveal the root causes under-
lying the seven wastes of lean product development. Figure 5-6 shows the
relationships between these causes and the seven wastes. The figure by no
means presents a comprehensive list of all causes; nor does it identify all of
the relationships between causes and waste. It does, however, provide a
graphic illustration that provides a general insight into the system causes
that must be changed by fundamental changes in the PD system.

Batching Overproducing

Process and arrival variation

Inventory
Unsynchronized concurrent tasks
Waiting
System overutilization

Handoffs Conveyance

Redundant tasks
Processing
Reinvention
Motion
Stop and go tasks

Rework Correction

External quality enforcement

Figure 5-6. System Causes of Seven Product Development Wastes

Companies that continue to view the PD process in the traditional

way; as an uncontrollable series of discrete events that just pop up, will
always be on the defensive and be forced to deal with variability and
capacity issues in a fire drill mode. Toyota never accepts variability prob-
lems as necessary or uncontrollable. The following discussion of Toyota’s
PD process presents the powerful antidotes developed by Toyota to
attack waste at the root and create PD process flow. Detailed examina-
tion will show that many of Toyota’s practices align extremely well with
queuing theory fundamentals and that they start from the beginning of
the process.

81
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 82

Section Two: Process Subsystem

Leveled Flow Starts in the “Fuzzy” Front End: Kentou

and Flow

Toyota’s lean PD process attacks waste from the very beginning. A previ-
ous chapter emphasized how important front-loading is to leveling the
workload with LPDS Principle 3: Front-load the product development
process to thoroughly explore alternatives. Portfolio management, cycle
planning, and rigorous shared resource scheduling at the front end of a
process are prerequisites to leveling work in a multiproduct lean develop-
ment system. Crucial to Toyota’s ability to create flow during the execution
phase is the ability to use cross-functional activities to front-load failure-
mode resolution and core-engineering strategies, and align CE objectives
during kentou. As previously noted, the kentou phase isolates, manages,
and minimizes much of the variation in product development, which
allows Toyota to focus on execution.
By aligning objectives across functions and developing designed-in
countermeasures, Toyota enables synchronized, cross-functional process
flow and eliminates one of the mortal enemies of flow in product devel-
opment—unscheduled and late engineering changes. These engineering
changes disrupt the process, drive excessive cost, and negatively impact
quality. Although Toyota strives for no engineering changes after final
design release, some engineering changes in a product as complex as an
automobile are unavoidable. To mitigate the negative impact of these
unavoidable changes, Toyota coordinates and controls engineering
changes in its process logic.

The Role of Process Logic

At a high level, process logic defines the tasks and the sequence of tasks
required to create a new product and the step-by-step process description
that generates the schedules. Process logic determines who will do what
and when, and which decisions PD teams must make at each milestone in
the product development process at a macro level. It makes no attempt to
provide all the details of how the work is done, but it does provide the
framework that coordinates all the various participants. The functional
organization that best understands the process, creates, maintains, and
owns the detailed work instructions. Centralized control is limited to a
critical, manageable few. In fact, fewer than 200 one-page process sheets
define macrolevel product development process requirements. These are

82
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 83

Create a Leveled Product Development Process Flow

fashioned in such a way that they reveal the health of the program and
serve as an early warning signal for any possible issues. All participants are
aware of these requirements and align activities accordingly. Process logic
by itself cannot create flow, but when it is flawed, it drives rework loops,
waste, and prevents flow from taking place.
Simple but common examples of flawed process logic include concur-
rent engineering sequences that are poorly synchronized. For instance,
when manufacturing engineering engages in detailed work on unstable
design data, inevitable design changes upstream will undo all manufac-
turing engineering efforts. Another example is engineering and test
sequences that do not factor in enough time for test analysis and counter-
measure development. Finally, process logic is flawed when it tries to force
teams to make decisions or commitments before sufficient, specific infor-
mation is available (Ward et al., 1995). Engineers, frustrated by the broken
process logic, often develop work-arounds that add and drive variation in
the PD system, which further inhibits flow.
In the Toyota PD process, scheduling starts with using process logic and
milestone requirements to balance the needs of each PD program. First,
Toyota staggers programs to keep resource demands level. Next, Toyota
decouples high-level schedules for vehicle subsystems with different con-
tent and time requirements. The company also separates and designs
schedules for power train, chassis systems (underbody), and top hat
(upper body) that will converge later in the process. Toyota ranks or scales
each new product, as well as the manufacturing requirements, according
to the amount of content for each of these subsystems. The amount of
content determines specific milestone-timing requirements for each sub-
system, and changes within each subsystem then determine the high-level
schedule the program will follow.
Toyota’s approach to macro process logic is the essence of elegant sim-
plicity. It provides centralized control without the waste associated with
monstrously large traditional PD central schedules (which are usually too
complex to follow accurately) and places ownership and accountability
where it belongs.

Workload Leveling, Cycle Planning, and Allocating

Resources
In most companies, product development is a cyclic environment, and
trying to level workload can be a maddening experience. However, it is a

83
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 84

Section Two: Process Subsystem

critical component of effective utilization of resources and speed to mar-

ket. Leveling workload must actually begin prior to the execution phase; in
a lean PD process, it begins before the surface transfer. In fact, it begins
with product portfolio planning and resource scheduling, which occur
prior to execution.
Product planning is the process of reviewing the performance of a
company’s current product portfolio to determine where potential gaps
and opportunities may exist and then determine which products the organ-
ization will develop. A cycle plan is a time-based output of which products
the organization will develop and when. Since the purpose of a cycle plan
is to determine PD system resource requirements, it is important to make
the plan relatively stable. However, given the economic and competitive
forces in which most companies operate, maintaining stability can be a
major challenge. Fundamental market forces change rapidly, and to sur-
vive, companies must have the ability to react quickly. Cyclical periods of
intense resource demand or little or no resource demand whipsaws a com-
pany’s PD system. Scale only further exacerbates the challenge. The larger
and broader a company’s product portfolio is, the more challenging this
problem becomes. Toyota has handled this challenge in several ways.

Using Common Platforms

In 1992, Toyota reorganized its platform strategy into vehicle centers. Each
vehicle center maintains its own planning division consisting of 170 to 200
people (Cusumano & Nobeoka, 1998). This planning division is responsi-
ble for the following tasks:
• advanced concept studies
• product portfolio planning
• cost planning (including component commonality)
• resource allocation
By creating a planning group within each vehicle center and develop-
ing the plan around common vehicle platforms, Toyota was able to
decrease the number of products and therefore the scope and complexity
of the PD plan. In addition, combining these products into vehicle centers
and the platform strategy has improved predictive accuracy and commu-
nication, resulting in fewer changes to the cycle plan once it has been final-
ized. (The specific organizational characteristics of the vehicle centers is
discussed in Chapter 8.)

84
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 85

Create a Leveled Product Development Process Flow

Staggering Vehicle Launches

Toyota then schedules engineering redesigns in its product portfolio to
level the workload over time. For example, Toyota would not schedule all
the vehicles in a vehicle center for a complete redesign in the same year. A
simple matrix would have rows representing vehicles within a vehicle cen-
ter and years as columns. Toyota typically schedules its major redesigns of
one vehicle with minor facelifts of other vehicles so as to have a similar
workload in any given year.
Ideally, Toyota engineers would like to stagger annual vehicle launches
so that an equal number of vehicles are launched in each quarter. How-
ever, the laws of the marketplace often preclude this. Sales and marketing
determine the ideal time to launch a vehicle, and engineering has little
influence on this. Thus, engineering must deal with the fact that late sum-
mer and early fall are going to be crunch times with major demands to
support vehicle launches in various plants. Kunihiko Masaki, former pres-
ident of the Toyota Technical Center, explains:

Launchings of existing models are fixed, in general, in a product

plan. But Sales channels have strong power to determine when
they want the vehicles launched. But a few months delay or
advance of launching is sometimes possible. Staggering of vehicle
development projects is done in the technical center based upon
the Kousu Yamazumi forecast of workload vs. workforce. General
Managers submit their own division’s staggering idea to the Tech-
nical Administration department. Workforces of Toyota Auto
Body, Kanto Auto Body, ARACO, Central, Hino and Daihatsu can
also be brought in if the workload gets too high.

The Execution Phase of Product Development

The execution phase of product development is quite different from the ken-
tou or study phase. In the front-loading phase, the PD teams anticipate,
study, and resolve problems, completing such tasks as fundamental design
decisions, identifying failure modes, designing in countermeasures, and set-
ting cross-functional objectives. Once kentou is complete, detailed engineer-
ing, prototyping, and production tooling can begin. By the time it reaches
this point, Toyota has made a full commitment to the product and has
begun to invest significant sums of money in tooling and in its suppliers.

85
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 86

Section Two: Process Subsystem

Because of this investment, it is financially critical to have a high-velocity

PD process with radically shortened lead times focused on precise execu-
tion and smooth product-to-market delivery. Toyota’s goal, from this point
forward, is to optimize capital investment, match quick cycle-supporting or
embedded technology lead times, make decisions closer to the customer,
and react quickly to changes in the competitive environment. Creating flow
by synchronizing product development activities is one of the most power-
ful ways to increase speed.

Cross-Functional and Within-Function Synchronization

The PD value stream consists of all work and functional expertise required
to bring a product from the planning stage to launch. Creating process
flow within individual engineering activities is necessary, but insufficient
for creating flow. To avoid interrupting the flow as a new product moves
from one organization or resource to another, the cross-functional mod-
ule-development teams must coordinate and synchronize individual func-
tional organizational activities. Cross-functional synchronization is even
more important for the successful execution of concurrent engineering,
where simultaneous activities can result in a lot of rework if not fully inte-
grated. Effective cross-functional synchronization in a lean PD system
requires a thorough understanding of:
• the details of how the work actually gets done.
• each participant’s specific roles and responsibilities.
• key inputs, outputs and interdependencies for each activity.
• sequences of activities in all functions.
When the participants in an upstream process understand these
requirements, they know what to deliver so downstream participants can
accomplish their tasks. Conversely, downstream participants can adjust
their process to maximize the utility of the information available from the
prior upstream process as it matures. A review of a number of ways that
Toyota synchronizes activities, both within and across functions through-
out the development process to maintain flow, follows.
The role of the simultaneous engineers (SE) is a powerful mechanism
for both cross-functional and within-function synchronization. As dis-
cussed in Chapter 4, SEs are responsible for specific parts early in the pro-
gram until launch; in this capacity, they serve as lead manufacturing
engineers. This role of shepherding parts through the entire development

86
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 87

Create a Leveled Product Development Process Flow

process removes the momentum draining hand-off of knowledge and parts

that occurs in a traditional PD process. Simultaneous engineers mitigate
the extra setup time that engineers would otherwise have to expend when
moving from task to task to support continuous flow. The SEs are respon-
sible for making timely decisions, communicating regularly with functional
resources, and working to keep things progressing, particularly on the criti-
cal handoff between product development and manufacturing process
development. They are adept at decision making, transferring knowledge,
and coordinating the activities of people inside and outside of their home
organization as they work on their respective set of parts. Utilizing the SE
on the MDTs also builds accountability in the lean PD system.

Examples of Cross-Functional Synchronization

One of the best ways to synchronize cross-functional activities is to align
and integrate them. This is what Toyota does early in the design process
where simultaneous engineers, representing various manufacturing dis-
ciplines, work with designers and product engineers to codevelop feasi-
ble designs. By working together in teams organized around specific
vehicle subsystems (Module Development Teams), such as closures or
underbody, they are able to execute true simultaneous engineering or
develop processes and product. This differs greatly from the practice of
checking feasibility of an existing design after the fact, which of course
creates mountains of rework.
Another example of cross-functional synchronization occurs in the
die design process. Toyota designs dies from the outside of the part in. This
process, combined with standardized manufacturing processes, allows
Toyota to maximize the utility of early data because part type and size are
known much earlier in the process than details on flanges and holes, etc.
When combined with standard die components, such as nitrogen springs
and die wear pads, a great deal of die design work can be accomplished
before finished part geometry is available.
The Toyota PD process also uses specific product development process
events, such as design reviews, prototype builds, and part coordination
builds that are organized to synchronize cross-functional activities in real
time. For the design reviews and prototype build events, engineers and
suppliers must bring the designs, prototype parts, and test results to be
reviewed. This provides opportunities to coordinate activities in real time.
Part-coordination build events, in which part-by-part evaluation takes

87
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 88

Section Two: Process Subsystem

place during a slow vehicle body build, are timed to support die try-out
activities. In all three of these events, key team members gather to
exchange information and adjust activities as needed. If required, the engi-
neers make on the spot, real-time decisions, and engineering changes are
coordinated across the group simultaneously to maintain flow.

Creating Flexible Capacity

By using all the lean PD methods described in this book, Toyota has managed
to create a relatively predictable and repeatable product development process.
In fact, through methods like standardization and adherence to detailed
schedules, Toyota can anticipate the peaks and valleys over the life of a vehi-
cle program. A predictable and repeatable PD process allows the company to
plan resource allocation. This does not mean Toyota can control workload
and level resources over the life of the program—natural ebbs and flows
make this impossible. However, because Toyota can anticipate these ebbs and
flows, it can plan for extra resources at very specific times by using its flexible
capacity system to add extra engineering resources when they are needed.
Toyota creates flexible capacity in two fundamental but strategic ways:
1) satellite companies and 2) flexible staffing. Satellite companies, such as
Toyota Auto Body or Toyota Auto Loom (now called Toyota Industries),
provide a capacity relief valve. These are wholly-owned subsidiaries that
are fully versed in Toyota operating methods and standards and can take
up all or the most critical portions of programs as required by cycle plan
demands. Because they are as competent as Toyota’s internal resources,
these companies can step in and execute with none of the ramp-up time
or transaction costs associated with traditional supplier arrangements.
The practice of using satellite companies is consistent with the single
queue, multiple-server condition, which is an efficient processing strategy
(Hopp and Spearman, 1996), as well as with the flexible capacity strategies
recommended by Loch and Terwiesch (1999) in other industries.
To achieve the strategy of flexible staffing, Toyota pools and shares var-
ious skilled technical staff. Although each PD program team has a group
of dedicated, highly experienced engineers, these are augmented with
technicians and tracers (those who now detail designs in CAD systems)
from pools that are shared by multiple programs. In addition, Toyota uses
specially qualified suppliers as a final tool for staffing flexibility (see Figure
5.7). In this way, teams add additional capacity only when and where it is
required, creating a kind of just-in-time approach to resource allocation.

88
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 89

Create a Leveled Product Development Process Flow

35
Clay Freeze Final Release
# Associates Assigned to Project

30

25 Suppliers
Body Styling
(Multiple Clay Models) Tracers
20
Technicians
15

10
Core Engineers
5

0
1 2 3 4 5 6
Months

Figure 5-7. Toyota Flexible Staffing Distribution to Address

an Unleveled Flow

While facilitating Toyota’s phenomenal speed and product quality,

standardization is also a crucial underpinning for flexible capacity in a
lean PD system. Without rigorous standardization of skills, design, and
process (or standardization cubed), you cannot achieve this level of flexi-
bility because the learning curve of the flexible resources would be too
steep. This standardization-flexibility paradox is discussed in Chapter 6.
Not to be overlooked is how standardization contributes to increased
planning capability and subsequent system stability. When system vari-
ability is reduced, the time required to complete standardized tasks is
more consistent and predictable over time. This reduces task-time varia-
tion. Tasks performed in a standardized process are completed on time,
advancing the process according to schedule. This, in turn, reduces inter-
arrival variation. As a result, PD programs are completed according to
schedule, eliminating the need to expedite or otherwise change individ-
ual program schedules, which makes capacity planning far more accurate
and stable.
Finally, Toyota’s incredible speed to market is itself an advantage in
stabilizing its cycle plan. The company’s ability to execute to market
demand quickly means it can target opportunities before they disappear
and avoid the constant starting and canceling of programs inherent in
slower organizations.

89
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 90

Section Two: Process Subsystem

Detailed (Fundoshi ) Scheduling to Head Off Unevenness

Accurate and disciplined scheduling is fundamental to managing multipro-

ject workload leveling. As noted in Chapter 4, multiproject management is
the ability to manage technological complexities and interrelationships
while developing diverse and sophisticated products. Multiproject manage-
ment optimizes the sharing of resources across multiple, concurrent proj-
ects. In a lean PD system, each individual PD program draws from the same
set of designers and engineers; in addition, each utilizes the same tooling
and prototype facilities. Obviously, if multiple programs vied for the same
resources at the same time or did not proceed according to a planned
cadence (missed intermediate schedule dates), a progress-blocking logjam
would occur.
Designing and developing an automobile takes hundreds of engi-
neers, thousands of components and tools, and high-tech equipment to
manufacture each of those components. It also takes many specialized
testing facilities to ensure quality, performance, and safety. Multiply this
across all the PD programs running simultaneously, and you see the
enormity of any automotive PD scheduling task. A completely central-
ized approach would quickly become too cumbersome and inaccurate,
due to the many specialized tasks. A strictly functional approach would
not provide the necessary cross-project functional synchronization and
would drive PD teams to focus on optimizing their local objectives at the
expense of the program as a whole. The challenge in scheduling within a
complex environment is to schedule in only the details that accomplish
the objectives—avoiding the waste of excess information and false sense
of control.
At Toyota, schedule discipline means recognizing that intermediate
dates are crucial to managing limited resources across multiple programs
and approaching these dates with rigor and precision. Toyota’s suppliers
are also aware of this tenacious attentiveness to intermediate target dates
and would not consider letting a date slip. Toyota executes to schedule at
a level of precision that is unknown in traditional product development
systems. All participants in Toyota’s individual PD programs understand
that these intermediate milestone dates are critical in order to manage
the shared resources required by all programs. If they do not complete
their requirements on time, they will not be given an extension and
will have to “move to the back of the line.” One example of just how
strictly this is observed is that Toyota engineers are often prepared to

90
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 91

Create a Leveled Product Development Process Flow

sleep on tatami mats at test equipment facilities if it will help complete

test cycles on time.

Detailed (Fundoshi) Scheduling at the Functional-

Organization Level
Synchronized process logic and standardized milestone requirements
allow the PD teams to concentrate on meticulous detail at the functional-
organization level (e.g., prototyping, testing, or tool and die facilities).
Toyota often refers to this detailed scheduling as fundoshi scheduling. Fun-
doshi is an ancient, traditional, male undergarment that is long and nar-
row and wraps around the body. When applied to scheduling, the term
conveys something quite similar because fundoshi scheduling specifically
refers to the length and the comprehensiveness of detailed schedules. At the
functional level, teams have the necessary technical knowledge to create
and execute these schedules in support of the high-level program require-
ments. The teams track all details of every part or tool. Specific machines
and test equipment are scheduled and tracked by the hour. Tool and die
components arrive JIT at the required work cells, and specialty cutters and
machine programs arrive at the milling machines at the same time as the
die components to be machined. Daily morning “walk arounds” at the
facilities and large hour-by-hour schedule boards spell out specifc hourly
task requirements, which provide the basis for visual “at the source” com-
munication and identify issues early, addressing them on the spot.

Using Staggered Releases to Flow Across Functions

In manufacturing, it is easy to see the waste associated with working in
batches—expensive inventory piles up, taking up needed space, wasting
resources, and hiding potential quality problems. In product develop-
ment, this is not as obvious—you do not see inventory piled up in the
engineering cubes, but it is there just the same. For example, in a batch-
design release system, manufacturing engineers wait for design informa-
tion in order to begin their tasks. When a large batch of part designs is
released that exceeds available manufacturing engineering resources, it
sits in data collectors, waiting for someone to act upon, decide, or execute
the next step.
In the lean PD process, program teams agree on a design-release stag-
ger, which facilitates downstream operations. The release order facilitates

91
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 92

Section Two: Process Subsystem

work content so that parts requiring more time and tool-up in manufac-
turing engineering are released first and smaller components are released
later. This practice also facilitates the design process. Because the larger
and more complex parts are already designed, smaller components, such
as brackets or reinforcements, can be designed in context.

Creating Process Flow in Nontraditional Manufacturing

Integral to the product development system is the nontraditional manu-
facturing required in prototype build and in tool manufacture. To make
the entire PD value stream flow, these types of manufacturing tasks must
move from unpredictable, craft-based activities to a nontraditional, lean
manufacturing model. There are a number of examples of the applica-
tion of lean principles within the die manufacturing activity. At the
machining department of the die shop, for example, die components,
cutter paths, and cutting tools are all required to complete the task of
machining a die. Toyota’s dies arrive at the machine just hours before
they are required, as do machine tools that have been specially selected,
sharpened, and kitted in rolling carts. The cutter path is pulled from a
shared drive directly at the machine as required. Once die pieces are
machined, they must be assembled, so the die pieces arrive JIT at stan-
dardized work cells, organized by construction task and die family. The
same holds true for purchased components, which are assembled
according to standardized and detail-specified work instructions. This
creates a flow through the construction department that results in die
construction times that are a small fraction of the time expended on
similar tasks by Toyota’s competitors.
During the tool-up portion of the lean PD execution, physical parts
make inventory more visible. In a craft-based environment, however,
inventory is often not recognized. Toyota staggers the release of die
designs, foundry patterns, and castings as they are completed to create a
flow through both their suppliers and their own tool shop. In the Toyota
PD process, individual die designs are reviewed for function virtually and
shipped to pattern suppliers as completed. Because of the accurate virtual
quality, confirmation patterns are shipped as completed and individual
castings arrive at the tool shop no more than two days before they are
scheduled to begin machining. By staggering die by die releases instead of
traditional batches, Toyota’s tool process results in almost zero inventory
and the fastest lead times in the industry.

92
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 93

Create a Leveled Product Development Process Flow

Establishing an Engineering Cadence and Cutting

Management Cycle Time

In lean manufacturing, takt time, based on available production time

divided by customer demand, establishes the cadence and mix that drive
manufacturing operations. Although the lean PD process does not have
an exact corollary to takt time, establishing an engineering cadence to
orchestrate activities and keep the program moving forward at a regular
pace is crucial. Once you have eliminated waste and created leveled flow
in the PD process, you need a mechanism to keep the entire system mov-
ing forward at a common, regulated pace. Toyota accomplishes pace set-
ting by using a number of engineering cadence mechanisms. First, the
company aligns and tiers engineering cadence with lower-level events
designed to support higher-level program events. This keeps the program
moving forward at a uniform pace and is achieved through rigorous
design reviews, scheduled at regular intervals. Engineers and suppliers
come to these reviews with prototypes, test results, open issues, etc., so
that the CE can determine (at the source) whether the program is where
it is supposed to be. The CE does not pull any punches and asks techni-
cal questions that reveal any potential concerns. Anyone who has
attended one of these events knows that it is nearly impossible to fake
your way through this process. You are either ready or you are not, and
this becomes clear very quickly. Engineers work hard to prepare for these
important design reviews, in itself a hard and fast deadline that creates
subsequent deadlines for the team to meet. When issues or concerns arise,
response is immediate.
Later in the PD process, the CE uses physical prototype build and part
coordination events to the same effect. CEs schedule these events into the
process to provide critical input into the design and tool manufacturing
process at the moment it is needed to support the PD teams subprocesses.
This again keeps the product development process moving forward. As
with the design reviews, participants work hard to support these rigorous,
system-focused events. The part coordination events, for example, focus
on how stamped sheet metal panels fit together to create the car body and
make individual die decisions based on this data.
At a lower level, the engineering leads meet with the CE in the Obeya
about every other day to review program status, open issues, and per-
formance to metrics, which are posted on the wall. These reviews are
short and to the point; they focus primarily on any abnormal conditions,

93
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 94

Section Two: Process Subsystem

much like jidoka in manufacturing. In the Tool shop, the management

team takes a daily morning walk around to check the status of parts to
hourly schedules and develop countermeasures on the spot so that major
events like prototype reviews are fully supported.
This integrated system of using cadence mechanisms has the added
benefit of providing shorter management cycle times, which allow for
quicker course corrections as needed and shorter time horizons for
teams to focus on and work toward. Management cycle time can be
defined as the time between checks on progress of the work by manage-
ment and the amount of time to deadline for engineers. In a lean PD sys-
tem the management cycle time is almost daily. In some companies,
however, these management cycle times are so unstructured and vague
that months may go by before someone sees the work results and notices
problems. One automotive supplier’s management cycle time was a clas-
sic example of this. After working with the authors, the supplier estab-
lished a strict schedule for management cycle time and began holding
weekly reviews, using visual boards to track progress. This decreased
lead time significantly.

Using Jidoka and Poka-Yoke to Support Product

Development Flow
In lean manufacturing jidoka, or autonomation, is the practice of recog-
nizing an abnormal condition and responding quickly. Visual manage-
ment, such as andon (light goes on when a worker pulls a chord on the line),
is often employed to aid in this effort, which is also associated with the
separation of human work from machine work and is critical in support-
ing and maintaining flow. In the product development process, it is even
more important to have the ability to recognize and remedy abnormal
conditions quickly. The Toyota PD System uses a number of tools, such as
checklists, for this purpose. Having program teams post specific objectives
(visual management) in the Obeya and track program progress toward
those objectives is an example of jidoka and visual management in the
Toyota PD system.
Toyota’s parametric CAD system is an example of utilizing technology
to recognize abnormal conditions. In this system, as engineers update
individual designs, all associated designs, including parts and most tool
designs, are also changed to match. When an error state occurs in the sys-
tem, such as part crashes, all appropriate designers are notified. In addi-

94
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 95

Create a Leveled Product Development Process Flow

tion, Toyota creates all engineering designs within the context of the entire
vehicle. This means all designers and engineers have access to all part
designs simultaneously and can see if their planned change(s) will impact
other parts.
Poka Yoke (error proofing) is another concept that supports continu-
ous flow in Toyota’s manufacturing process. Poka Yoke prevents errors
from occurring, which reduces inspection time and frees up time to build
in quality. A related concept is inspection at the source, which does not
rely on outside inspection to catch errors downstream but makes the manu-
facturing operation responsible for checking quality as it produces. In
product development, Poka Yoke takes the shape of:
• checklists
• standard, detailed test plans
• part quality matrices
• standard architecture
• shared components across vehicles
• standardized manufacturing processes
The checklists guide engineers through the PD process and eliminate
design errors. Test plans, standardized part by part, prescribe test require-
ments and test timing for each part being designed. In addition, each part
has a detailed quality matrix that identifies the standard manufacturing
process and matches individual part design characteristics impacted by
specific steps in the manufacturing process. The quality matrix (see Chap-
ter 15) provides design engineers with process-driven design guidelines
and builds in lean manufacturing. Adapting standard architecture to new
products enables Toyota to maintain consistent vehicle performance levels
relative to crash, handling, and noise. The same is true for sharing com-
ponents across vehicle lines. Finally, by designing new parts to use stan-
dard manufacturing processes, Toyota can be certain of quality and
productivity levels. A lean PD system prevents error states before they
occur, which helps to create predictable results.

Pulling Knowledge Through the PD System

In lean manufacturing, pull production eliminates overproduction by hav-
ing downstream activities signal their needs (demand) to upstream activi-
ties. Kanban cards usually signal (control) production in a pull system. In
product development, knowledge and information are the materials that

95
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 96

Section Two: Process Subsystem

are required by the downstream activity The speed at which technology

delivers information in automotive product development is overwhelm-
ing. However, not all information is equal to all people. The lean PD Sys-
tem uses “pull” to sort through this mass of data to get the right
information to the right engineer at the right time. Knowledge is the fun-
damental element (material) in product development.
Toyota does very little “information broadcasting” to the masses.
Instead, it is up to the individual engineer to know what he or she is
responsible for, to pull what is needed, and to know where to get it. Indi-
vidual engineers are expected to locate and extract needed information,
whether this be design data residing in the data collector, a product per-
formance experience, or a perspective from a senior executive. This policy
holds true for everyone, from the most junior design and release engineer
to the chief engineer. The key underlying principle that makes this work is
that everyone has access to both the design data and the CE.
For an example from the opposite end of the program hierarchy, all engi-
neers are responsible for creating benchmarks for their respective compo-
nents. They are expected to gather relevant information and understand the
latest technological developments, industry trends, and supplier and com-
petitor products that affect their designs. Once the execution phase begins,
manufacturing engineers pull design data from data collectors as they need
itto start working on die or fixture designs. All engineers pull requirements
from checklists, which are updated at the end of each program.
The supplier mentioned earlier (a company that had an unacceptable
management cycle time) illustrates how the PD system links processes.
This seat maker through value steam mapping identified that they were
batch dumping information onto the next process (design sent hundreds
of drawings to purchasing and ordered hundreds of parts prototyping, to
build the hundreds of different variations of prototype seats, etc.) After
moving to a staggered release system where a subset of seat designs were
released on a preplanned schedule, weekly reviews of progress were set up
and the supplier set up status boards at each functional area within the
value chain. A key purpose of the status boards (referred to as “pull
boards”) was to signal the need for information from other functions.
Once the status board was in place, it was easy to spot when key informa-
tion was needed. When key information was delayed, it was identified
within a week rather than months later. The example clearly shows that in
a lean PD process, a key enabler for pull knowledge systems is reducing
management cycle time.

96
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 97

Create a Leveled Product Development Process Flow

Putting It All Together to Flow

Within manufacturing, the common solution to creating flow and thus

linking together operations is the cell. Cells are created by taking equip-
ment from different departments and arranging them in a product’s
natural flow. This will quickly move products one piece at a time through
the cell. Where cells are not feasible, small inventory buffers are estab-
lished with pull systems between processes. The general lean principle is
to schedule in one specific place (the pacemaker process) and then pull
material to that point. The pacemaker process is not scheduled exactly as
orders come in from the customer, as customers demands are rarely level.
Instead, production control levels the customer demand into a schedule
in the pacemaker, which then creates a leveled pull on upstream processes
and ultimately on suppliers. The speed of production at the pacemaker is
set at the takt time—the average pace of customer demand over the
period leveled.
The equivalent of a one-piece flow cell in the lean PD process would
be a cross-functional team dedicated to a product design that works just as
needed in the sequence needed. In a sense, this is what the simultaneous
engineer and cross-functional MDT is doing. Outside information and
materials can then be pulled as needed by this “virtual cell.” Unfortunately,
the level of precision of the routine processes in manufacturing is not pos-
sible within product development. However, as discussed throughout this
chapter, Toyota has used analogous principles to drive out process vari-
ability and largely eliminate rework through rigorous task and schedule
discipline, manage capacity and level workload through detailed planning
and utilizing flexible resources in peak periods, create flow through stag-
gered releases and cross-functional synchronization and orchestrate the
entire system through cadence mechanisms.
As valuable as these mechanisms may be, a lean process strategy is
insufficient. As should be obvious to the reader at this point, the execution
of a lean process requires discipline and standardization. A concept that is
covered in the next LPDS principle.

97
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 98

Section Two: Process Subsystem

LPDS Basics for Principle Three

Create a leveled product development process flow
Utilizing a process perspective to improve product development
performance is potentially very powerful. There are several critical
characteristics of a lean product development process:
• Use the kentou or study period during concept development
to anticipate and resolve as many downstream technical issues
as possible, thus reducing variation early in the value stream.
• Develop a clear process logic with a manageable number of
milestones and activities.
• Synchronize activities across functions.
• Level the workload through a well-designed product cycle
plan which is adhered to in order to manage system capacity.
• Use a flexible capacity strategy to fill in the gaps in high
workload periods.
• Use scheduling across functions, and even more detailed
scheduling within functions, to synchronize activities and
drive out variation.
• Stagger the release of data from one function to the next,
prioritizing what needs to be worked on early versus late.
• Establish an engineering cadence and short management
cycle time to orchestrate the system and create manageable
deadlines.
• Execute the process plan with precision and demand sched-
ule adherence to drive out inter-arrival variation.
• Use checklists and part-by-part standardized development
plans to drive out task variation.
• Build in quality at each step of the process and do not pass
along problems.
• Set up a system and culture in which engineers pull knowl-
edge as they need it instead of inundating large numbers
of engineers with information as it is produced.
• Build learning and continuous improvement into the basic
process.
This is a long list, but the combination of all these methods will
begin to develop a level flow and create a controllable process that
companies can improve through kaizen.

98
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 99

CHAPTER 6

Utilizing Rigorous Standardization

to Reduce Variation and
Create Flexibility and
Predictable Outcomes
“Today’s standardization is the necessary foundation on which
tomorrow’s improvement will be based. If you think of ‘standardiza-
tion’ as the best you know today, but which is to be improved tomor-
row—you get somewhere. But if you think of standards as confining,
then progress stops.”
HENRY FORD

STANDARDIZED WORK IS ONE OF THE CORE DISCIPLINES of the Toyota Produc-

tion System in which jobs are specified down to the second to match takt
time—the rate of customer demand. The question here is whether this
discipline can be applied to engineering work. Takt time standardization
may lend itself to some routine tasks, such as the simplest CAD work, but
engineers who move from big task to big task facing multiple uncertain-
ties cannot standardize work in a way that specifies exactly what they will
be doing every five minutes.
Indeed, when the authors have suggested to engineers that they need
to standardize their jobs, the responses were predictable: “We are creative
engineers,” “We do not do repetitive manual work,” “We need the freedom
to schedule our work day and to be creative.” To a certain degree, it is easy
to understand why product development engineers are unable to perceive
how standardization and creativity can work in tandem. On the other
hand, Toyota’s PD process shows that variations of standardization actu-
ally give program teams a great degree of flexibility and enables speed, pre-
cise execution, improved quality through robust reliability as well as
system predictability, and waste elimination that reduces cost.
Standardization, coupled with a culture of discipline are the most
powerful weapons a product development organization can bring to bear

99
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 100

Section Two: Process Subsystem

against the destructive power of variation identified in our previous dis-

cussion of queuing theory. In fact, standardization underpins and enables
much of Toyota’s success in product development. It is its very backbone.
Rigorous design standardization supports the power of platform reusabil-
ity, allows Toyota to share critical components, subsystems, and technolo-
gies across vehicle platforms, building in lower cost and higher quality.
Standard architecture enables consistent body system performance, mini-
mizes test requirements, and underlies consistent lean manufacturing
processes. Standard development processes build trust, enable develop-
ment speed through precise synchronization and are key to successfully
managing the very complex process of developing new vehicles. Standard
manufacturing and testing processes enable consistent quality and excel-
lence in execution of lean manufacturing as well as make clear the upfront
constraints on product development. Finally, standard engineering com-
petencies ensure Toyota’s ability to consistently develop outstanding engi-
neers, produce consistently high levels of product development process
performance, and are the basis for professional trust and collaboration. Far
from diminishing the autonomy and creativity of engineers, when coupled
with Toyota’s pursuit of perfection, standardization is the very basis for a
level of professionalism, pride, and an invigorating environment of tech-
nical collegiality and mutual respect unmatched in their industry.

Three Categories of Standardization

As noted in Chapter 4, there are three broad categories of standardization
in the lean PD systems: design standardization, process standardization,
and engineering skill-set standardization. Each category is briefly defined
below and then analyzed in the context of Toyota’s PD process.

1. Design standardization. This is standardization of product/compo-

nent design and architecture. It includes the use of proven, stan-
dard components shared across vehicle models, building new
model variations on common platforms, modularity, and design
for (lean) manufacturing standards that creates robust, reusable
design architecture.
2. Process standardization. This involves standardizing tasks, work
instructions, and the sequences of tasks in the development
process itself. This category of standardization also includes the
downstream processes that test and manufacture the product.

100
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 101

Utilizing Rigorous Standardization to Reduce Variation and

Create Flexibility and Predictable Outcomes

3. Engineering skill-set standardization. This is standardization of

skills and capabilities across engineering and technical teams. It is
based on a deep commitment to people development and growth
through demonstrated competencies. It is quite powerful and
often overlooked.

Category One: Design Standardization and

Engineering Checklists
Interestingly, many of Toyota’s design standards are not given as specific
parameter requirements or “thou shalt or shall not” directives. More typ-
ically, these standards are concerned with ratios and physics driven. Sort of
“if, then” statements based on proven physical realities that give Toyota
engineers a great degree of latitude and creative freedom while simultane-
ously maintaining lean manufacturing requirements. Engineers are not
constrained by “point-based” parameters; instead, design standards pro-
vide a reliable guide as they work to identify optimal sets of solutions.
Design standards are embodied in specific, detailed part and process
checklists, reusable components and standard subsystem, and vehicle level
architecture that defines sets of best cross sections (often referred to as
common architecture) for each part. The power of common architecture
strategy was discussed in Chapter 4. The discussion below addresses the
use of engineering checklists as a key tool for design standardization.
Chapter 15 elaborates on this concept through specific examples and a dis-
cussion of trade-off curves that provide a graphic representation of how
they are used by engineers to achieve desirable solution sets.
Engineering checklists are certainly not unique to Toyota. In all prob-
ability, such checklists came to Toyota with the aerospace industry chief
engineers the company recruited as Japan’s aerospace industry was
declining. (See Chapter 7.) Checklists are simple reminders of things that
should not be left out. They can be powerful or worthless, depending on
how they are used. If updated regularly and referred to diligently, they are
powerful. If stagnant and unused, they are worthless. Unfortunately,
many companies have not developed the discipline to maintain or utilize
them effectively.
Ideally, engineering checklists are an accumulated knowledge base
reflecting what a company has learned over time about good and bad design
practices, performance requirements, critical design interfaces, critical to
quality characteristics, manufacturing requirements as well as standards

101
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 102

Section Two: Process Subsystem

that commonize design. Checklists at Toyota are highly visual, part spe-
cific, incredibly meticulous and comprehensive and may, in fact, seem
impossibly detailed to those unfamiliar with the level of precision Toyota
expects from its engineers. Checklists for complex parts may include hun-
dreds or more parameters. Interestingly, as detailed and technical as the
checklists are, most engineers we interviewed knew not only their own
part checklists, but those of related parts and the checklists for the associ-
ated manufacturing processes by rote. This was clear evidence of consis-
tent, long term use and a sense of ownership.
Though based on science, the real world practice of engineering is an
art form that relies on tacit knowledge gained through experience and
judgment in considering multiple variables that interact in complex ways.
As a result, a best solution cannot necessarily be predicted in advance. It is
learned over time through experience and is guided by the spirit of kaizen,
which postulates that there is always an opportunity to learn more and
that learning is an ongoing process. This spirit of engineering kaizen is
driven by the never-ending pursuit of technical excellence that underlies
consistent checklists utilization, validation, and improvement.
A company that cannot standardize will struggle to learn from experi-
ence and is not truly engaged in lean thinking. Indeed, any company that
simply tries new things without standardizing along the way is “randomly
wandering through a maze,” repeating the same errors, relying on little
more than undocumented hearsay and a wide range of opinions among its
employees only to eventually discover that “it has been here before.” Toyota
uses a systematic and scientific approach to product development. It tests,
evaluates, standardizes, improves, and retests, scrupulously following the
Plan-Do-Check-Act cycle that was introduced to the company decades ago
by Deming. It then standardizes “today’s” best practice. As it accumulates
new information and new experiences, these are used to modify current
shared standards and reborn as a future “today’s” best practice.
Toyota utilizes standards-embedded checklists from the very start of
the program during the styling process through to launch at the assembly
plant and everywhere in between. In the studio, designers and senior
engineers from Body Engineering and Production Engineering work col-
laboratively through part-by-part solution sets, utilizing design and
process checklists as their guide until a fully feasible design emerges from
the process. In this way Toyota is able to design a feasible product the first
time unlike NAC where engineers typically reviewed nearly completed
designs on an ad hoc basis, virtually guaranteeing downstream engineer-

102
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 103

Utilizing Rigorous Standardization to Reduce Variation and

Create Flexibility and Predictable Outcomes

ing changes. In the launch readiness phase checklists are utilized to assure
die and tool accuracy and to be certain that tools, dies, and manufactur-
ing equipment are capable of maintaining critical part and assembly
characteristics.
What this means is that Toyota has a plethora of checklists that, indi-
vidually and collectively, reflect every part, every rule, every standard way
of processing a given part, and every graph that illustrates acceptable and
unacceptable ranges. In connection to PD, each Toyota engineer has books
of standards that are checked off as each item for each design is consid-
ered. When explaining this structured and systematic checklist process
during seminars or classes, the authors have heard a number of interesting
and disturbing comments. In a classroom setting, hands instantly go up
and invariably, someone will pose a variation of the following question:

In this day and age wouldn’t it be better to computerize the check-

lists? We heard about the Toyota approach, and we are planning on
doing them one better and developing an online knowledge man-
agement database of all the standards cross-referenced on a secure
corporate intranet. We have a department set up to develop a state-
of-the-art knowledge database. Is Toyota moving in that direction?

This is all rather moot. To begin with, Toyota has already moved in
that direction and has computerized most of its checklists and standards.
Secondly, creating a computerized knowledge database is not a guaran-
tee of success, and in fact, misses the point: you still might find the data-
base is worthless.
In essence, the question of how checklists are constructed and main-
tained, whether in books or in a computerized database, is secondary. The
primary questions should consider the issue of roles and responsibilities.
Who will feed the checklist? Who will use it? What are the specific respon-
sibilities and accountabilities for updating the checklist and using it? At
Toyota, this is intimately connected to an organizational structure
(described in Chapter 8) that operates on the basic principle that “team
work is the key to getting high quality work done but some individual
always needs to be responsible.” Responsibility for checklists is vested in
functional groups that are organized down to the subsystem level.
For example, the door engineering supervisor is responsible for main-
taining the door engineering checklist and ensuring that it is used by all
door engineers. Body engineering and production engineering share

103
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 104

Section Two: Process Subsystem

responsibility for door checklists. A production engineering supervisor is

responsible for checklists on how the door will be processed and the design
features that make it producible. At the beginning of a new program, the
door engineer will ask for the latest checklist from production engineering
and considers it in tandem with the checklist from body engineering.
Incorporating the production-engineering checklist into the design is now
the door engineer’s responsibility.
In short, the people doing the work are responsible for maintaining and
using the checklists and, in lean thinking, it is never a corporate IT function.
The checklist is not the amorphous responsibility of “engineers.” It is the
responsibility of a specific engineer responsible for each part of the vehicle,
who must coordinate the efforts of all engineers working on that part of
the vehicle and incorporate that knowledge, information, data, learning—
or whatever you may want to call it—into the checklist.
As discussed in Chapter 5, Toyota’s flexible capacity strategy relies on
wholly-owned subsidiaries and skilled technicians who work out of pools
arriving JIT to the product program. Rigorous process and design stan-
dards allow both subsidiary engineers and technicians to ramp up quickly
and become almost instantly productive on the program. Because these
technicians specialize by part, they are very familiar with relevant stan-
dards. They are able to apply the checklists, master cross sections, and
standard locators to the design space, which is provided by the surface
scans from the clay, and K4 body structures drawings, to produce final
designs that reflect the new styling and performance intent of the new pro-
gram. At the same time, they are able to retain proven part geometry that
will maintain performance levels for such things as crash, NVH, and, of
course, manufacturability. This reduces the number of physical prototypes
that need to be tested. It also leads to far fewer late and expensive engi-
neering changes, driving a lot of waste from the PD process. Having highly
experienced engineers and technicians working with rigorous standardiza-
tion tools is fundamental to Toyota’s ability to deliver high quality designs
rapidly and manage its flexible capacity strategy. A number of checklist
examples are provided later in this book.

Category Two: Process Standardization

Using this second category of standardization enables true concurrent
engineering and provides a structure for synchronizing cross-functional
processes that enables unmatched vehicle development speed. A standard-

104
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 105

Utilizing Rigorous Standardization to Reduce Variation and

Create Flexibility and Predictable Outcomes

ized development process means standardizing common tasks, sequence

of tasks and task durations, and utilizing this as the basis for continuous
product development process improvement. Process standardization is a
potent antidote to both task and inter-arrival variation discussed in the
previous chapter. Process standardization is the only way to know reliably
what other functional organizations are doing and when they do it. It is
how interdependent processes/organizations know specifically what
inputs are required from each other and when they are needed. Finally,
strict process discipline coupled with standard development processes are
the only conceivable way to run a multiproject “development factory” and
is absolutely fundamental in gauging the performance and progress of any
individual program
As mentioned in the discussion in Chapter 5 on process logic, the
lean PD process centrally controls high-level standard process require-
ments to guarantee synchronization. For Toyota (see Chapter 4), this
means that macrolevel milestones and timing are utilized across different
programs and that each individual functional-organization level controls
the detailed, working-level processes. By leveraging both of these stan-
dardized structures, detailed, program-specific schedules at the working
level are developed.
By contrast, NAC uses a corporate staff group to standardize mile-
stones at a relatively high level with a great deal of detail about all func-
tional organizations results that must occur by these milestones (e.g.,
“stage-gate model”). It is the responsibility of the program and functional
teams to figure out how to accomplish this. Whereas Toyota’s various engi-
neering organizations each standardizes the means to engineer the prod-
uct based on the requirements of a central framework, NAC corporate
staff attempts to standardize only the ends for the entire product develop-
ment enterprise.
Without rigorous standardization and common architecture, NAC
lacks an effective flexible capacity strategy, resulting in constant bottle-
necks at critical resources throughout the PD process. NAC does use sup-
plier engineers or outsource engineering work, but because it does not
standardize skills, design, and process, it often experiences poor results
and extremely high transactions costs which it blames on their suppliers.
Having standardized processes guiding detailed work at the functional
level is key in enabling flexible capacity and leveling workload. Without it,
LPDS Principle 3 of creating leveled flow would not be possible in prod-
uct development. It is well known in lean manufacturing that stability is a

105
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 106

Section Two: Process Subsystem

requirement for flow and this is also true in product development. Stan-
dardization provides the stability, consistent expectations and level of pre-
dictable outcomes as the necessary foundation for flow.
One perhaps overlooked benefit of a standard development process is
that it contributes to more precise communication and greater under-
standing across engineering organizations by providing a common frame-
work for discussion.

Toyota’s Standardized Process for Production Engineering

Because of a reliable standard process, at the same time Toyota body engi-
neers begin to work with digitized surface data from the clay model, pro-
duction engineering is able to start its work on detailed process design. Die
design, fixture design, and processing/binder development groups also
begin preliminary activity at this time. The various Production Engineer-
ing organizations synchronize their activities with the evolution of the
part design to maximize the utility of sketchy and partial design informa-
tion to create a synchronous evolution. By utilizing a standardized process
that works only with stable aspects of the part design as they become avail-
able, the Production Engineering Department creates efficient process
flow through concurrent engineering and simultaneously eliminates
wasteful downstream rework. This highly synchronized approach to con-
current engineering is vital to protect against the all too common practice
of trying to accomplish too much too early with partial or premature
design information, which is likely to change and cause rework and waste.
In addition to the ubiquitous checklists discussed earlier, Production engi-
neers also employ senzu. Senzu are very detailed manufacturing drawings
that have been created for each part. Senzu are updated at the end of each
program, shared across functional specialties, and contain all manufactur-
ing information, best practices including manufacturing geometry
changes, locators, weld locations etc., accumulated for a specific part.

Toyota’s Die Engineering

During this intense period, the die engineering group practices a flexible
capacity strategy, which includes the use of trainees. Because the lean PD
process has broken down the complex die engineering challenge into many
standardized subroutines, and because solids databases provide standard-
ized components and simultaneous access to the designs, using computer-

106
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 107

Utilizing Rigorous Standardization to Reduce Variation and

Create Flexibility and Predictable Outcomes

aided die design, designers with varying degrees of expertise can work on
the same design at once. As a result, designs are completed more quickly
and flexible human resources can then be transferred to work on other
parts as they become available. Parts availability is especially important
because in order for body engineering to achieve final data release require-
ments, some parts will be completed before others. Furthermore, because
these parts are available to production engineering through a shared data-
base, they can be pulled as the engineers are ready to work on them.
As noted above, cross-functionally synchronized standard processes
enable die designers to start on parts with incomplete data. As each part
design is completed, die designers can pull and complete it. At this point,
die design trainees can carry out the die designing tasks that require less
skill. These trainees then move on to assist another die designer. This
process is possible only because standardization mutually supports all
three lean PD subsystems—process, tools and technology, and people.
One of the key enablers in establishing this kind of standardization is the
senzu. In the case of dies, the senzu details such things as binder shape,
overcrown, overdraw, and radii requirements. Collectively, senzu are part
and vehicle specific references that are critical to stamping engineering
performance in the entire PD process.

Process and Binder Development

Early in the process, in conjunction with the final phases of vehicle
styling, standard manufacturing processes and common part architecture
enable preliminary binder development to be accomplished in the pro-
cessing/binder development area. The binder is the part of the first form-
ing die that holds the sheet material in place while forming the part. It is
crucial to a quality stamping process and can be quite challenging for
complex geometries. This process often involves formability assessment,
utilizing formability simulation and Finite Element Analysis (FEA). In
fact, because there is not process or design standardization, NAC is forced
to perform FEA on all stamped parts, creating a huge bottleneck in the
process at this limited resource. However, in the Toyota PD process, char-
acterized by standardized part geometry and manufacturing processes,
less than one-third of the stampings require FEA of any type. Eliminating
the need for FEA for two-thirds of all parts removes the potential for
bottlenecks and associated queues and variability from the PD process. It
also improves average throughput times and significantly reduces costs.

107
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 108

Section Two: Process Subsystem

This also strengthens competitive advantage in the lean PD process of the

next product development phase.

Toyota’s Lean Tool and Die Manufacturing

In this phase, in which tools are cast, machined, assembled, tried out, and
approved, Toyota’s lean manufacturing principles are truly brought to bear
on the product development process because building tools and dies is a form
of manufacturing. Extremely accurate and detailed standard die designs
allow Toyota to employ an adapted form of lean manufacturing principles at
this point in the PD process that is a powerful competitive advantage in a lean
PD system. On average, a large set of dies, such as those required for body
sides, will require less than four months for casting, machining, construction,
and preliminary tryout at the die shop. Because they are still utilizing a craft-
based process for die making, most of Toyota’s competitors require 10 to 12
months for the same set of tasks. The die shop will then ship them to the
stamping plant for home-line tryout, which includes not only final die tryout
but also tryout time for all the check fixtures and automation required for
final production stampings. This takes up to an additional one to two
months, in increments of six to eight hours once or twice per week. Toyota’s
high velocity die development capability combined with part design stan-
dards and effective use of sophisticated virtual tools has also allowed them to
eliminate the need for most prototype tooling—a huge cost and time saver.
Although Toyota has significantly faster times on special projects, the discus-
sion below focuses on the typical time frame it takes for designing dies and
completing tooling in a standard process.

Typical Time Frames for Lean Tool and Die Manufacturing

Designers classify all dies in categories ranging from A0 to D. Assigned to
each category is a specific line of milling machines, construction bays, and
spotting presses. Those who have studied TPS will recognize this as the
identification of product families with dedicated flow lines. A0 are large dies
with class one (outer) surfaces, A dies are large dies with unexposed sur-
faces, and so on to D class dies, which are smaller parts produced on pro-
gressive dies. Dies are assigned to the smallest possible line of equipment
(right sizing). These die categories allow for standard procedures and stan-
dardized times that make scheduling more accurate and outcomes more
predictable. To assist in visual management and to make all participants

108
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 109

Utilizing Rigorous Standardization to Reduce Variation and

Create Flexibility and Predictable Outcomes

aware of scheduling requirements, the plant keeps and maintains large

schedule boards that are both task and department-specific. These boards
track progress in hourly increments and are checked by the plant manage-
ment team daily. Once again, the lean standardization in the PD process
works to reduce process variability and thus improve throughput times.
Designers perform virtual checks on the die designs against standards and
then uplink the design to a virtual simulation system (digital 3-D simulation
of the complete die set), to ensure clearances, functionality, and production
efficiencies. These designs are then utilized to drive standardized work
instructions in the die construction phase and are the models used by manu-
facturing to machine die patterns. This step eliminates the need for physical
reviews. Toyota pattern timing is one week or less and die castings require only
an additional ten days. In contrast, Toyota’s North American competitors
require three weeks for patterns and four weeks or more for castings.

Toyota Die Machining

Toyota’s accurate and highly detailed die designs and standardized die
manufacturing process allows the company to do the vast majority of die
manufacture on precision milling machines, which substantially reduces
time spent on handfitting and reworking die details, and in lengthy die
tryout, advantages Toyota’s North American competitors do not have.
Toyota has also patented a number of specialized cutters to maximize the
efficiency of its machining operations, adding an even greater element of
precision, speed, and predictability to its lean die manufacturing. By
focusing on precision machining, Toyota has completely eliminated sev-
eral secondary operations, such as the hand polishing and die fitting
required in traditional die manufacturing. This lean die manufacturing
approach allows Toyota to apply additional lean methodologies such as
SMED (single minute exchange of dies) to its machine setup operations
and JIT cutter kit arrival to maximize machine value-added time. Detailed
schedules in hourly increments are posted next to the machines and main-
tained by the operators. As in pattern construction, during morning plant
walk arounds, the plant manager and the team review these schedules.

Toyota Die Construction

After machining, each die detail or component is shipped to the appropri-
ate construction cell in the construction bay corresponding to its category

109
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 110

Section Two: Process Subsystem

classification. There are five separate construction bays, each containing

several phased “lines” made up of multiple stations or cells, each of which
is responsible for a portion of the construction process. Die details and
purchased components arrive at the right cell at the right time to keep the
construction process flowing forward. Just as in an assembly line, each cell
completes a portion of the construction work, with the die moving on to
the next cell for the next step in the process. Work procedures are thor-
oughly standardized in detail and each cell’s task times is equalized (as
measured in days) so that there is synchronized movement or flow
through the construction department. This reduces variation, makes out-
comes much more predictable, and enables people to see die construction
status at a glance. Schedule boards are posted throughout the construction
bays and all participants are aware of scheduling requirements and work
to meet them.
Each cell is self-contained with all the assembly tools and perishable
supplies (such as screws and dowels) that are needed in a particular opera-
tion organized and located near the point of use. Die locations are painted
out on the floor, all hand tools and machines are in place, and benches with
labeled racks and drawers are set around the working area. Air tools are
suspended by retractable lift assist equipment; they are within easy reach
when needed and recoil out of the way when not in use. Even purchased
components arrive just before they are needed, so die makers do not have
to leave their cells to search for anything. Die construction personnel
resemble race car pit crews each busily executing predetermined tasks
simultaneously with incredible precision. Kaizen is ongoing. For example,
one kaizen focused on a construction innovation that eliminated flipping
over the die during assembly—normally a time-consuming operation that
requires a crane.
Die makers are cross-trained in construction tasks and also in tryout.
Individual die maker skill levels are posted on boards in the department. Pay
is linked to skill level, and all die makers are on salary but paid for overtime.
Die makers use customized checklists for each cell in each bay, both as a pro-
cedural reference and a quality assurance tool. These checklists serve as the
primary guide for the cell leader’s sign-off of each die before it moves to the
next station. These “sign-offs” by construction personnel are the primary
form of quality control during die construction. As with pattern construc-
tion, no paper drawings of die designs are required: All die makers are
trained to use the CAD system, and all die design data is available on the
CAD computer located near the cell. Die designers and simultaneous engi-

110
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 111

Utilizing Rigorous Standardization to Reduce Variation and

Create Flexibility and Predictable Outcomes

neers visit construction bays regularly to work with die construction per-
sonnel to identify problems or ways to improve designs and methods.

Toyota Vehicle Assembly Engineering

Vehicle assembly engineering is a part of the production engineering
organization and is fully integrated with the die engineering group at
Toyota. Their challenge is to design tools and processes to assemble the
stampings into a vehicle body or body in white. This is a complex process,
requiring large stampings to be precisely located, held in place, and usu-
ally spot welded together. Closure subassemblies such as doors, hood, and
lift gates have an additional step of hemming in which a flange from the
outer panel is hemmed or crimped around the flange of the inner panel in
order to secure them together before being mounted on the vehicle. This
requires the design and manufacture of complex and extremely expensive
fixtures, subassembly cells and body assembly lines.
By standardizing locators, checking points, weld standards etc., Toyota
was the first to be able to design stampings and assemblies to standards
that support flexible assembly operations that allowed Toyota to build
multiple body styles on the same line. In a more recent development to
that process Toyota introduced Global Body Lines through their Blue Sky
project that took flexible body assembly to a new level. This project
required intense collaboration between both Production Engineering and
Body Engineering to update design and process standards to support this
revolutionary innovation. According to Atsushi Niimi, former President
and CEO of Toyota Manufacturing North America, the new system
replaces the fifty pallets required for each body style in the old system with
only one master pallet tool each. This new pallet tool looks something like
a ski-lift and locates the body from the inside on programmable locators.
This system improves over-all body quality, reduces the number of weld
stations required, and dramatically increases manufacturing flexibility.
Now eight different bodies can be assembled on the same line by changing
only a single master pallet. Niimi-san claims that new body shop installa-
tion costs for new programs have been reduced by 50 percent, space
required is reduced by 50 percent, and the cost of adding another body to
an existing line or a new top hat program is down by 70 percent. This is
the power of innovation. But it would not be possible without engineering
organizations working together collaboratively to create effective process
and design standards and a culture of discipline to maintain the gains.

111
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 112

Section Two: Process Subsystem

Toyota has installed the GBL worldwide. Consequently all vehicles are now
designed to support this standard assembly process.

Category Three: Standardized Skill Sets/Competence

Most companies considering standardization seldom think of standard-
ized skill sets. Yet this is an essential principle for creating a lean PD sys-
tem. It builds team integrity, enables incredible development speed, and
drives task variation out of the development process. Managers have much
greater flexibility in assignments and both managers and team members
alike can have more confidence in performance expectations. Toyota’s
culture of demonstrated technical excellence is fundamental to creating
professional trust and high-performing teams in any environment. This
section of the chapter highlights some of the practices that lead to consis-
tent or standardized skill sets at Toyota, beginning with the hiring process.
A more detailed discussion of the benefits of the people development
process is presented in Chapter 9, which deals with the seventh LPDS prin-
ciple: developing towering technical competence.
After a lengthy and rigorous review process, Toyota hires only about 1.1
percent of professional candidates applying for engineering positions
(Kramp, 2001). Once hired, engineers follow a standard, skills-acquisition-
based personnel development process from day one. The process focuses
on demonstrated competencies and intensive technical mentoring for
advancement: A rookie engineer can expect to undergo an intensive two-
year on-the-job training period before moving up to first-level engineer-
ing rank. Toyota invests three to four years in each new engineer before
he or she becomes a serious team contributor. Within the industry, this is
a significant investment. After this initial period, a body engineer can
expect to spend five or six more years within this same technical specialty
before being considered a first-rate engineer. During the approximately
eight-year development period, engineers are “interviewed” four times
per year, and technical areas of improvement are assessed using standard-
ized skills inventories. Training is mostly on the job and special care is
given to the assignments that an engineer receives to be certain he or she
will have the opportunity for continued technical growth. An action plan
is developed through Hansei (reflection) to address shortcomings.
Among the criteria used to evaluate Toyota engineers is successful adher-
ence to process and standard methodology, which further develops each
engineer’s standardized skill sets.

112
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 113

Utilizing Rigorous Standardization to Reduce Variation and

Create Flexibility and Predictable Outcomes

A new engineer’s career path consists of experiences that develop deep

technical competence, while slowly climbing the technical hierarchy
within each functional department, and is a direct result of engineers
being rewarded for technical achievement. The engineer’s boss usually
knows how to do the job better than the engineer; he or she also knows the
standardized process for doing it, which enables the leadership principle of
teaching and mentoring. The lean PD system depends on mentoring for
developing talent. To support mentoring, Toyota creates an engineering
apprenticeship environment in which highly technical, tacit skills are
handed down from one generation to the next, thus basing professional
growth on demonstrated competence in the real world.

Conclusion
This chapter concludes the discussion of the first LPDS subsystem process
and its four principles within the broad framework of the product devel-
opment system, which was outlined in Chapter 2 as a sociotechnical sys-
tem (STS) with three primary subsystems: 1) process, 2) people, and 3)
tools and technology. In STS terms, body engineering was used to show
the technical system of processes—all the tasks and sequences needed to
bring a body design from concept to start of production. In developing
this section of the work, we emphasized how raw material consists of
information, customer demands, past product characteristics, competitive
product data, and engineering principles that are transformed through the
lean PD process into the complete engineering of a product. Similar, if not
stronger, emphasis was placed on the connection between lean develop-
ment and lean manufacturing. In addition, the authors have endeavored
to show how the first LPDS subsystem and its principles define a com-
pany’s value stream map as how information flows, stops, gets rerouted,
and sits in queues. The next chapter examines the second lean PD sub-
system, People, and LPDS principles five through ten.

113
Morgan Liker sec 2_ch 5&6 3/2/06 1:05 PM Page 114

Section Two: Process Subsystem

LPDS Basics for Principle Four

Utilize rigorous standardization to reduce variation
and create flexibility and predictable outcomes

In a lean PD system, you need to standardize products, processes,

and competence to create a foundation for flexibility and speed.
Standardization is critical to the LPDS because it underpins many
of the other LPDS principles by reducing variation, subsequently
creating greater flexibility and more predictable outcomes. In LPDS,
there are three types of standardization: design standardization,
process standardization, and skill-set standardization, all of which
are necessary to drive out waste and achieve a truly lean system.
Design standardization is manifested in engineering checklists,
standard architecture, and shared/common components and plat-
forms. Process standardization refers to both the development and
manufacturing processes and is housed in individual component
development plans (senzu) and detailed manufacturing process
plans. Standardized skill sets are developed through careful
mentoring, strategic assignments, and periodic assessments of
demonstrated competencies. The functional organizations own,
maintain, continuously improve, and execute standardized designs,
processes, and skill sets.

114
Morgan Liker sec 3 3/2/06 11:27 AM Page 115

SECTION THREE

People Subsystem
Morgan Liker sec 3 3/2/06 11:27 AM Page 116
Morgan Liker sec 3 3/2/06 11:27 AM Page 117

CHAPTER 7

Create a Chief Engineer System

to Lead Development from
Start to Finish
We can be successful at Toyota only when we do something better
than our competitors or when we surpass the average for the
industry. If we are designing a new product, and know there is no
room for failure, our attitude certainly must not be just to aim for the
average. If we do that, we will surely fail. We must do our all-out best
at such times, and allow ourselves no thought of failure.
KENYA NAKAMURA, first chief engineer of Toyota Crown

THIS CHAPTER BEGINS A DISCUSSION of the second STS subsystem for the
Lean Product Development System, People, which cover Principles 5
through 10. People are the essence and energy of the LPD system, and you
cannot compete in product development without a capable, energized,
aligned organization that executes as a high performance team. Lean PD
people systems are constructed on a foundation of teamwork, continuous
learning, and kaizen, which drive and evolve lean within the other subsys-
tems. The people subsystem encompasses shared language, symbols,
beliefs, and values that determine such things as how an organization is
structured, its leadership style and learning style, and how it recruits,
trains, and develops employees.
Consider what it would take to align your company with the LPDS
model’s people system. Would you need to overhaul your business and
managerial philosophy? Can you really change the “soft” thing known as
“culture?” The answer is complex and entails changing some fundamental
approaches to how people get work done. For the lean PD system, the first
important change is deciding who “runs the program”—you have already
been introduced to the person who does this at Toyota: the chief engineer
(CE). Determining this piece of your lean PD system is one of your most
important decisions because it dictates how you develop the structure of
your PD organizational system.

117
Morgan Liker sec 3 3/2/06 11:27 AM Page 118

Section Three: People Subsystem

Most organizations use some form of the matrix system to determine

who is reporting to whom and what respective roles and responsibilities
will be. (Toyota’s Matrix System is discussed in detail in Chapter 8.)
Within this matrix, each engineer has multiple bosses—typically a func-
tional boss who is a technical specialist (e.g., Body Engineering) and a
program boss who runs the product development program. In most
organizations, the matrix is a communication nightmare that spawns
mixed allegiance and conflict between and among different parts of the
organization. Toyota also uses a matrix, but the program boss is the chief
engineer. The CE as program boss system is unique and avoids many of
the problems within a traditional matrix structure, mainly because the
CE clearly runs the show. Thus, it is appropriate to begin the discussion
of the people subsystem with the central figure of Toyota’s product devel-
opment organization.

The Cultural Icon Behind the CE System

Toyota’s chief engineer, sometimes characterized as the “Heavyweight Pro-
ject Manager,” is likely the most publicized and imitated aspect of Toyota’s
PD system. But while it is true that most organizations have some type of
program manager who, like the CE, is responsible for overseeing design
projects and making sure they are on time and on budget, the similarities
end there. Like the program manager in many other companies, the CE
does not have formal authority over the engineers working on the pro-
gram; however, the CE is ultimately the one person charged with the suc-
cess of the design, development, and sale of a car. Consider the range of
responsibilities for the CE and his or her small staff:

• voice of the customer

• customer-defined value
• product concept
• program objectives
• vehicle-level architecture
• vehicle-level performance
• vehicle-level characteristics
• vehicle-level objectives
• vision for all functional program teams
• value targets
• product planning

118
Morgan Liker sec 3 3/2/06 11:27 AM Page 119

Create a Chief Engineer System to Lead Development

from Start to Finish

• performance targets
• project timing
The CE’s ultimate responsibility is delivering value to the customer.
While Toyota always emphasizes teamwork, there is always one person
who is accountable for the success of the team. For product development,
this person is the CE.
The defense industry in Japan originally used the CE system, and like
many other process innovations, this system was adopted and adapted by
Toyota. The geniuses given credit for building the CE system at Toyota
include early chief engineers like Tatsuo Hasegawa, chief engineer for the
first Corolla, and Kenya Nakamura, chief engineer for the first 1955 Crown
(Ikari, 1985). Since that time, there has been a continuous stream of CEs.
But while the tradition has grown, the responsibilities and characteristics
of the chief engineers remained fundamentally unchanged. Below are
some of the characteristics that Toyota has come to value in its CEs, many
of which underscore the importance of balancing engineering skills with a
broad and rounded approach to leadership:
• A visceral feel for what customers want
• Exceptional engineering skills
• Intuitive yet grounded in facts
• Innovative yet skeptical of unproven technology
• Visionary yet practical
• A hard-driving teacher, motivator, and disciplinarian, yet a
patient listener
• A no-compromise attitude to achieving breakthrough targets
• An exceptional communicator
• Always ready to get his or her hands dirty
While working with companies on lean product development and
introducing the CE system, the authors often hear, “We already have a
chief engineer” or “We can tweak the organizational chart in this way to
create this role.” The response to such comments is that although it is easy
to imitate the organizational form of Toyota’s CE system, it takes years to
develop the roles and responsibilities within that system. Furthermore, the
lean PD model requires careful selection and grooming of CE candidates
over many years (at Toyota, this grooming period takes at least 12 years
and usually more). This grooming entails an incremental blending of
characteristics that are the hallmarks of a super engineer and leader.

119
Morgan Liker sec 3 3/2/06 11:27 AM Page 120

Section Three: People Subsystem

First, management needs to identify exceptional people who have han-

dled challenge after challenge, have matured and grown, and have the
hands-on experience required to lead the development of a highly complex
product. Second, management needs a CE to fit into a broader system of
roles, responsibilities, and commitment. The CE role is high profile; it is a
role the entire organization must recognize and respond to. In a sense, this
person functions outside the company bureaucracy and standard operating
procedures and has the latitude to do what is necessary to get the job done.
The position is valued and is often more admired than the organizational
senior positions of director or vice president. It is by far the coveted posi-
tion among engineers within the Toyota PD community. For all of these
reasons, the chief engineer at Toyota is revered as a cultural icon, one whose
special status lies in the freedom to rise to many challenges.
In a typical PD system, once the top executives make a strategic deci-
sion to develop a new product line, the program is immediately assigned
to a high-level planning group, possibly with a marketing background,
which develops the marketing concept. Industrial designers are then
assigned to develop sketches. Somewhere down the road, engineers enter
the picture to work out the technical details. A lean PD system does not
take such a soft, non-technical route. When top management makes such
a momentous decision around a new program, it immediately selects a
chief engineer to head it up. As project manager, the CE does not simply
coordinate schedules or fine tune technical details—the CE owns the car,
from concept to styling, to prototype, to launch. Often, a CE will stay with
the same product over multiple generations.

A Tale of Two Chief Engineers: Lexus and Prius

To appreciate the unique role of the chief engineer in the Toyota system it
helps to consider two of the most visible cases of product development at
Toyota over the last 20 years; two vehicle programs that Toyota views as the
epitome of the Toyota Way.1 For Lexus, the breakthrough approach meant
developing not only a car but also a brand name with its own dealer net-
work. Prius, on the other hand, was the first fuel-electric hybrid vehicle
ever to be mass produced. Many people know that Toyota excels at rapid

1. In this section, we summarize the Lexus and Prius story line from The Toyota Way (2004)
for the purposes of highlighting the PD process. For a more in-depth story and dis-
cussion around the personalities of the two CEs, the reader can refer to The Toyota Way.

120
Morgan Liker sec 3 3/2/06 11:27 AM Page 121

Create a Chief Engineer System to Lead Development

from Start to Finish

vehicle modification or top hat programs rather than innovative sweeping

change to meet changes in the market. However, fewer people know that
Toyota began with a strong spirit of innovation when engineers had no
choice but to be innovative. This goes back to the days of former Toyota
president Shoichiro Toyoda and his “3 Cs”—creativity, challenge, and
courage—and it was this spirit that permeated the development process of
both the Lexus and the Prius, with the chief engineers leading the way. By
featuring these exceptional programs we hope to demonstrate more clearly
the critical role of the CE.
In the lean PD process, the CE is tasked in the earliest stages to lead in
developing the concept of a new vehicle, while the top executive’s role is to
tap the right person for the program. Toyota’s Prius and Lexus were special
cases. Neither vehicle had any preliminary styling nor was there a well-
thought-out vision. With the Prius, top executives had a concept of devel-
oping a high fuel efficiency car for the twenty-first century. With the Lexus,
top executives had a concept of building a luxury car for the U.S. market
that would be in the class of such luxury carmakers as BMW and Mer-
cedes. In both cases, it was the responsibility of the CE to shape an amor-
phous vision and make it a clear and definite product concept.
The genesis for the Lexus started with Yukiyasu Togo, head of Toyota
Motor Sales in Southern California, who strongly promoted the idea for
developing a luxury brand, eventually convincing management that Toyota
needed a new car, a new brand, and a new dealer network. Once top man-
agement approved the Lexus concept, they quickly appointed Ichiro Suzuki
as the chief engineer, one of the best and most revered chief engineers in
Toyota’s history. For the Prius, Toyota took a very different tack, appointing
the neophyte Takeshi Uchiyamada to run with management’s general
vision of a twenty-first century car and rethink the development process
itself. Uchiyamada, a former test engineer, who had not previously served
the company as a CE, was also tasked with defining and engineering the
product concept, as well as with launching the vehicle under an aggressive
timetable. The two engineers came from very different backgrounds and
had very different styles, but top management chose the right leader for
each project, for reasons that went far beyond developing a new car.

Lexus: A Chief Engineer Who Refused to Compromise

In August 1983, the board of directors, in a top-secret meeting presided
over by Toyota Chairman Eiji Toyoda, officially blessed the Lexus program.

121
Morgan Liker sec 3 3/2/06 11:27 AM Page 122

Section Three: People Subsystem

when appointed as CE, Ichiro Suzuki immediately sought out the voice of
the customer by conducting focus group interviews in various locations,
creating a sampling of two groups across the main European luxury
brands. Group A had four Audi 5000 owners, one BMW 528e owner, two
Benz 190E owners, and three Volvo 740/760 owners. Group B almost
directly paralleled this makeup. Suzuki collected the comments from the
customers and classified them. Starting with the broad current concept of
a luxury car, Suzuki looked into the customer’s reasons for purchasing or
rejecting other vehicles in the same class, according to the image the cus-
tomer had of each car. He then defined the most common and simple
qualitative descriptors and created a one-page summary (see Figure 7-1).

Voice of the Customer—Customer Value Characteristics

Reason Rejected in favor

Reason for Purchase of Competitor
Benz Quality, investment Too small; weaker style
value, sturdy appeal (vs. BMW)
BMW Style, handling, functional Too many on road
Audi Style, space, affordability Poor quality, poor service
Volvo Safety, reliability, Boxy styling
quality, sturdy
Jaguar Most attractive styling Poor quality, small interior
Source: Reprinted with changes, from Jeffrey K. Liker, The Toyota Way (New York:
McGraw Hill, 2004), 44, by permission of McGraw Hill.

Figure 7-1. Reasons for Purchase and Rejection of Competitive Luxury

Vehicles (1980s)

What may surprise many engineers is that the Toyota sales and mar-
keting organization was not driving this process. Where were the pages of
marketing surveys? Where were all the scientifically valid samples? How
did a single CE think that reviewing information from a couple of focus
groups was enough? Nonetheless, this is exactly what happened, and this
early work of studying and classifying the voice of the customer into descrip-
tors like quality, investment value, and affordability, helped define cus-
tomer-value characteristics that went into building the luxury concept for
the biggest Toyota investment of the 1980s. Though this luxury concept

122
Morgan Liker sec 3 3/2/06 11:27 AM Page 123

Create a Chief Engineer System to Lead Development

from Start to Finish

was highly qualitative and intuitive, Suzuki had correctly read the current
environment in which Lexus was going to be competing. In a traditional
PD system, management would have had another group do this research
and then this group would have tossed it to engineering to design-in these
qualities. The shortcoming with this traditional approach is that as a pro-
gram proceeds, this early work easily gets lost or ignored because there is
no authority behind it to continue championing and refining it. In the case
of the Lexus, the main thing Suzuki had learned was that a Japanese car
was not associated with luxury or status. Armed with this information,
Suzuki now knew what had to be done, and it was clear that this would not
be business as usual. If it was to be successful, the Lexus would have to
break out of Toyota’s existing product development mold.
Suzuki’s next challenge was to define the Lexus concept by what would
appeal to customers in the future, not simply reflect what current cus-
tomers or marketing told him about current trends. For example, he had
asked customers to rank customer value characteristics in their decision to
buy a Mercedes in the current market, but then outright rejected the data.
Below is the customer’s ranking Suzuki compiled, ranked from most
important to least important:
1. Status and prestige of image
2. High quality
3. Resale value
4. Performance (e.g., handling, ride, power)
5. Safety
Because he was an engineer, this ranking was at odds with Suzuki’s
common sense. Being intuitive yet grounded in facts, he did not believe that
these customer value characteristics defined the future luxury car. Suzuki
stepped back to define some basic principles for determining the vehicle-
level architecture that would lift the Lexus above other luxury cars and
dominate the market. He asked the follow questions:
• What does it mean to own a high-quality luxury vehicle?
• What characteristics does a car need to make people who own it
feel like they’re wealthy—financially and emotionally?
• What characteristics would a car have that, as the years go on, would
make people become more attached to it and possessive of it?
After extensive discussions with the CE team and other associates,
Suzuki concluded that the two most important design criteria driving the

123
Morgan Liker sec 3 3/2/06 11:27 AM Page 124

Section Three: People Subsystem

vehicle-level architecture and meeting the customer-defined value for the

Lexus and the future luxury car was, in order of importance:
1. Exceptional functional performance (power, feel, noise level,
aerodynamics)
2. Elegant appearance (not traditionally a Toyota strength)
Suzuki decided that if Toyota could make a car with exceptional
functional performance, which was considerably better than what Benz
cars offered and, at the same time, combine this with an elegant appear-
ance, the company could break free of its stodgy image and compete in
the luxury market. With the vehicle vision now clearly defined and the
vehicle-level performance goals set, Suzuki had the beginnings of his CE
concept paper.
This upfront definition of the concept of the vehicles may have been
Suzuki’s biggest contribution to the company and the Lexus. Once the con-
cept was defined, he proceeded to develop a set of “no-compromise goals.”
These were competing design criteria that, at first glance, appear mutually
exclusive. If engineers focused on exceptional functional performance,
then most likely, they would sacrifice elegant appearance. Likewise, if the
engineers focused on appearance, they might sacrifice performance. If the
engineers attempted to design-in these two criteria at the same time, they
would probably be making trade-off choices. This is where the Toyota
engineer in Suzuki kicked in. His overarching goal for the Lexus was to
fuse these two criteria together, so the vehicle characteristics needed for
one would benefit the other. The challenge he put to the engineers was to
solve each problem resulting from the clash of these competing engineer-
ing criteria and synthesize it into the Lexus brand.
To accomplish this Suzuki had to find the right people in the company
to do the right thing. This was to be extraordinarily innovative engineer-
ing and would have to accomplish some extraordinary feats, for example:
• Breakthroughs in vehicle styling that also achieved aggressive vehi-
cle aerodynamics goals.
• Breakthroughs in engine design and machining of engine parts to
achieve the world’s quietest engine, with the least vibration facili-
tating low noise yet high performance.
Making these breakthroughs was not simply a matter of making a
request and sitting back waiting. Even finding the right people entailed
much effort. Such people would have to be persuaded and motivated and

124
Morgan Liker sec 3 3/2/06 11:27 AM Page 125

Create a Chief Engineer System to Lead Development

from Start to Finish

led through the process of innovation. Suzuki had the vision and the pas-
sion, and only he could make it all come together.
In the end, Suzuki was able to meet or exceed all of his no-compro-
mise objectives, and the rest is history. At the time of the Lexus launch in
1989, Mercedes Benz’s three models (300E, 420SE, 560SEL) had no rival in
the U.S. market. But Lexus, with only a single model was able to sell 2.7
times the number of all three of those well-established Mercedes com-
bined—in a single year. In addition to creating a new luxury division for
Toyota, the Lexus project injected a new spirit of innovation into Toyota’s
engineering. It broke the behavioral mold of a global powerhouse with
clearly delineated product families, and engineers who had only known
the risk-averse Toyota, were suddenly engaged in a bold new challenging
project. This renewed spirit would carry over into an entirely new project
with new objectives and challenges and would permanently reinvent
Toyota’s PD process. That project was the Prius.

Prius: A New Chief Engineer and New Engineering

Process for a Twenty-first Century Car
Like the Lexus, the Prius was the brainchild of the highest-level executives
at Toyota. In the early 1990s, at the peak of the Japanese bubble economy,
Toyota’s business was booming. Toyota Chairman, Eiji Toyoda, knew this
could not last forever. At a Toyota board meeting he asked his colleagues,
“Should we continue building cars as we have been doing? Can we survive
in the twenty-first century with the type of R&D that we are doing?” In
September 1993, Yoshiro Kimbara, then executive VP of R&D, following
Eiji Toyoda’s lead, founded a project called Global 21 (G21). The project
committee was tasked with researching a new car for the twenty-first cen-
tury—a fuel-efficient, small-sized car with a spacious cabin. The fuel
economy target was set at 1.5 times the efficiency of existing small cars like
Corolla. The vision represented a major design challenge, and no one at
the time was thinking hybrid.
Once the G21 had broadly defined the concept for the twenty-first
century car, it was ready to name the chief engineer to head up the PD pro-
gram. In July 1994, Toyota did something that was atypical; they appointed
a chief engineer who was not on a career track to become one: Takeshi
Uchiyamada. Mr. Uchiyamada had been attending some of the early G21
meetings mainly because he had been the chief architect of Toyota’s reor-
ganization of product development into vehicle centers (see Chapter 8).

125
Morgan Liker sec 3 3/2/06 11:27 AM Page 126

Section Three: People Subsystem

His task was to figure out where the G21 would eventually fit into the
structure. He was surprised and nervous at being named CE. He had no
experience in visiting suppliers or checking the production line to solve
problems. One of the personifications of a CE is that they “know” every-
thing—from the smallest part, like a bolt, to knowing what the customer
wants. Uchiyamada did not and felt unqualified to accept this position.
Hindsight reveals, however, that he had three characteristics that made
him ideal for this project:
1. Research Background: Uchiyamada’s background was in test engi-
neering. He was from the research side of the house, which gave
him access to an extensive research network to develop the new
technology for the twenty-first century car.
2. Organizational Skills: He knew Toyota’s organization and how to
get the resources needed for this unusual project. He also had a
talent for creating new forms of organization to move programs
forward aggressively. This meant innovatively changing the old
method of developing cars, a skill that made him one of the key
architects of the largest reorganization of product development in
Toyota history (see Chapter 8).
5 Outside the Box CE: As a neophyte who had not been “groomed”
for the typical CE position, Uchiyamada brought a fresh perspec-
tive to product and process.
By intentionally selecting a nonexpert chief engineer, the Toyota exec-
utives chose a CE that had to “invent” a new method for developing cars—
one of the challenges put forth by the G21.
The first thing Uchiyamada did was to surround himself with a cross-
functional team of experts on whom he was to rely to a far greater extent
than the traditional CE. This team and leader reliance dynamic brought
about a new organizational design perspective, the obeya (big room) sys-
tem of development, which is now a Toyota standard method for develop-
ing vehicles. Unlike previous CEs who traveled about meeting with people
as needed to coordinate the program, Uchiyamada collocated with a group
of experts in the obeya, outside the fray of normal day-to-day affairs, to
review the progress of the program and discuss key decisions.
As for guiding the development of the Prius, Uchiyamada turned out
to be a disciplined leader who kept the project on track with respect to
timing and cost and with a no-compromise attitude to achieving break-
through targets and desired features. He constantly questioned the pur-

126
Morgan Liker sec 3 3/2/06 11:27 AM Page 127

Create a Chief Engineer System to Lead Development

from Start to Finish

pose of the project and the design concept that would give customers
something special. For example, in the early stages of concept develop-
ment, the team became bogged down in discussing technical details of
powertrain technology. Mr. Uchiyamada called the team together and said:

Let’s stop focusing on hardware. We engineers tend to focus on

hardware. However, what we need to do with this car is to focus
on the “soft” aspects, not the hardware. Let’s forget everything
about hardware and review from the beginning the concept of the
car that we are trying to build from the ground up (Itazaki, p. 46).

Uchiyamada then got his hands dirty, leading a brainstorming session

of key concepts describing vehicle characteristics of the twenty-first cen-
tury car. Several days later, the team identified two ideas they believed
would define and drive all subsequent development of a “small, fuel-effi-
cient car”: 1) natural resources and 2) environment. The phrase “small,
fuel-efficient car” became the G21 goal.
Uchiyamada took another unconventional approach to achieve the
G21 goal of a spacious interior. Unlike traditional CEs, Uchiyamada was
unfamiliar with the standard dimensions of vehicles, so he turned to his
team and asked them to study 30 existing Toyota models. In each case, the
team noted differences from the dimensions that the CE team had
designed for the G21 project and then asked designers of the 30 existing
models why they had come up with their dimensions. The answer was
“they had always done it that way.” It was only then that the team realized
that the reasoning behind its G21 dimensions was sound.
Uchiyamada’s approach of having deep discussions and considering
many alternative designs early on illustrates the set-based approach (dis-
cussed in Chapter 4) that characterized all phases of Prius development.
The use of the set-based approach by Uchiyamada is even more striking
given the intense time pressures the program was under throughout the
development process. Figure 7-2 summarizes the time line for the pro-
gram. As the figure shows, management continually challenged Uchiya-
mada to do more and more in less and less time. Despite this pressure,
Uchiyamada continued to follow the lean PD process of thoroughly con-
sidering alternatives before moving on.
As the G21 program progressed, executives escalated pressure on the
CE to make a hybrid rather than a conventional fuel-efficient car while, at
the same time, pushing for a quick launch. As previously noted, the Toyota

127
 Date Technical Organizational Issues
Morgan Liker sec 3

1990 Toyota PD becoming routine, stagnant Japanese bubble economy peak: Eiji Toyoda
preaches crisis mentality
Sep-93 Phase I: Develop car for 21st century G21 founded by Uoshiro Kimbara (Exec. VP
3/2/06

of R&D) with Eiji Toyoda endorsement

Dec-93 G21 concept presented to board G21 study group disbands
(1.5x fuel economy)
11:27 AM

Jan-94 Phase II: Create G21 blueprint “Permanent project team” for G21 formed
(detailed concept)
Jul-94 Final report of detailed concept Team disbands; members return to develop

128
components for G21 in functional homes
Page 128

Jul-94 Phase III: Actual development for G21 begins Form development team led by Uchiyamada
as chief engineer
Sep-94 Request to present G21 as concept for Team must speed development; named Prius
Section Three: People Subsystem

Tokyo Auto Show (plan on conventional (“prior” to 21st century)

powertrain)
Nov-94 Mr. Wada (senior technical officer) requests Secret intention is to push team toward
showcase hybrid (double fuel economy) hybrid technology

Figure 7-2. Prius Development History

 Morgan Liker sec 3

Date Technical Organizational Issues

May-95 Present selected hybrid engine type to BR-VF does exhaustive search of 80 hybrid
3/2/06

G21 team engine types and settles on one as “de-facto

standard.”
Jun-95 G21 becomes official development project All board member meeting; decide on
11:27 AM

people, dollars, timing

Aug-95 Plan developed (1st prototype in year; Okuda makes “impossible” request—
thorough research year 2; production Launch by 12/97
model year 3; SOP end of 1998 at earliest)
Page 129

129
Oct-95 First public presentation of Prius at Tokyo By show have decided to pursue
Auto Show (showcase product for Toyota) hybrid for Prius
Feb-96 First round of sketches for vehicle style Used competition among design centers
from Start to Finish

(>20 to 5 designs selected)

Jul-96 Final styling review—select innovative By board, General Managers, and broad panel;
Calty design Line off (first vehicle) set for 12/97 (17 months
out) and official board review set for 9/96
Dec-97 Launch Prius
Create a Chief Engineer System to Lead Development

Figure 7-2. continued

Morgan Liker sec 3 3/2/06 11:27 AM Page 130

Section Three: People Subsystem

chief engineer is fiercely independent and intentionally given a great deal

of autonomy to run an entire program. While this is true of the day-to-
day operation of the program, higher-level executives certainly have a
hand in influencing the overall targets for the program, including per-
formance features, timing, and cost targets. In September 1994, the CE
team met with Executive VP Wada and Managing Director Shiomi. Dur-
ing this meeting, hybrid technology was discussed but no conclusions for
pursuing it were reached. In connection with continuing the develop-
ment of the G21 project, the G21 group and CE team were asked to pres-
ent Toyota’s small, fuel-efficient car concept for the Tokyo Auto Show
scheduled for October 1995. This meant they had a year to develop what
would become the showcase product of the auto show. However, this
turned out to be the least of their challenges. In November 1994, Mr.
Wada casually told the CE team: “By the way, your group is also working
on the new concept car for the Motor Show, right? We recently have
decided to develop that concept as a hybrid vehicle. That way, it would be
easy to explain its fuel economy.” (Itazaki, p. 69)
At another meeting with Wada and Shiomi around the same time, it
was concluded that the team needed to double the current fuel economy;
a 50 percent improvement was deemed far too little for a twenty-first cen-
tury car. Current engine technology could not achieve this, and Uchiya-
mada protested as such, but the reply was subtly definite: “Since you are
already developing a hybrid vehicle for the Motor Show, there is no reason
not to use a hybrid for the production model.” (Itazaki, p. 72)
As is often the approach at Toyota, these two executives were not issu-
ing explicit orders to create a hybrid. They were perhaps not so subtly sug-
gesting to the team that this was a natural conclusion. A genuine
twenty-first century car had to have breakthrough fuel economy, and a
hybrid was the only practical alternative. Uchiyamada took up the chal-
lenge and got one important concession—the right to select the finest
Toyota engineers available to work on the hybrid engine system.
In less than a year, the new hybrid team developed a new working
hybrid system and concept vehicle for the auto show. Work continued on
the G21 and in June 1995, the G21 became an official development project
with a budget and schedule. Uchiyamada and the team decided to really
stretch themselves on timing and committed themselves to a launch date
of December 1998 with a slight cushion that would allow the launch to be
rescheduled for early 1999. This gave them a year to develop the first com-
plete prototype, a second year to refine the prototype, and a third year to

130
Morgan Liker sec 3 3/2/06 11:27 AM Page 131

Create a Chief Engineer System to Lead Development

from Start to Finish

finalize the production version and prepare for manufacturing. Consider-

ing that this was new technology with a new production line, this time
frame was extremely tight.
The timing pressure intensified even more in August 1995, when the
new president of Toyota, Hiroshi Okuda, saw the importance of the G21
project and told Wada the stretch goal had to be earlier because this was
the car that could change the course of Toyota’s future (Itazaki, p. 115)
Uchiyamada was shocked. He was working on a car that could change the
course of Toyota’s future, but his launch date had been moved up to
December 1997. An entire year of the projected time frame had vanished.
The Prius was launched in October 1997, two months ahead of the new
target date, and potential customers immediately bombarded Toyota with
inquiries. At the end of March 1999, sales had reached 22,000 units. By
early 2003, this number had risen to 120,000. Worldwide sales since then
have continued to grow and the Prius continues to be a Toyota success
story but for reasons that are not limited to its hybrid engine.
Certainly, the hybrid engine had caused a great stir in the marketplace.
But perhaps, more importantly, and for the future of the company, the CE
team working on the Prius had also made some important and funda-
mental innovations in the product development process; innovations that
are now used in all vehicle development programs at Toyota and are help-
ing to achieve the next target of regular 12-month programs. Gauged by
this measure, the returns on the Prius project are astronomical and the
investment almost trivial.

The CE Leadership Model

In the lean PD system, the standard operating procedure is to give man-
agers more responsibility than they have the authority to carry out. Toyota’s
CE system epitomizes this. At any one point, there are thousands of Toyota
associates working on a program, but the CE has a team of only six to ten
people who formally report to him. John Shook, the first American to
become a Toyota manager in Japan, was surprised to experience this system
and came to describe it as “responsibility without authority.” As discussed
later in this work (see Chapter 8), Toyota has adapted a matrix organization
structure to its CE system. The functional groups, like body engineering
and chassis engineering, are technical specialty groups with their own gen-
eral managers. The general managers supervise the engineers and decide
which projects they are assigned to, conduct their performance evaluations,

131
Morgan Liker sec 3 3/2/06 11:27 AM Page 132

Section Three: People Subsystem

and determine promotions. The chief engineer controls the vehicle pro-
gram and is responsible for the results but depends on all of the functional
groups to supply the people and get the work done. The Toyota Way cul-
ture binds the entire enterprise, promoting the common objectives of sat-
isfying customers and making the company successful.
All engineering managers have the responsibility of coordinating a
group of people so that their activities align to complete a project. But as
Figure 7-3 illustrates, there is a marked difference between how a tradi-
tional chief engineer leadership role and a lean, CE type of leadership role
handles this responsibility.

CE Footprint

Group Facilitator System Integrator

Bottom-Up
(Flexibility) “You’re Empowered” “Here is the concept,
I will lead the integration”

Top-Down
Bureaucratic Manager System Designer
(Rigid “Follow the Rules” “Here is the design
Directives)
specification, detail it”

Social Technical
Coordination Integration

Figure 7-3. Leadership Model: Types of CE Leaders

Source: Reprinted with changes from Jeffrey K. Liker, The Toyota Way
(New York: McGraw Hill, 2004), 176, by permission of McGraw Hill
In the figure, combinations of leadership skills show two dimensions
of engineering leadership. In one dimension, an engineering leader
focuses primarily on social coordination or technical integration of
people and their activities. The second dimension distinguishes top-
down leaders who dictate to others what to do versus bottom-up leaders
who draw out the expertise of others. When you put these together, you
see four types of leaders.

1. Bureaucratic manager: This manager coordinates people top down

and does not draw on his or her own engineering expertise, rely-
ing instead on standards and target schedules and task delegation.

132
Morgan Liker sec 3 3/2/06 11:27 AM Page 133

Create a Chief Engineer System to Lead Development

from Start to Finish

This type of leader follows the engineering standards and rules,

meets deadlines and rules by Gantt chart and budget, and compels
projects efficiently. There is little flexibility in adapting the time-
line or the technical vision beyond routine work, and the bureau-
cratic manager cannot make creative leaps that will move the
project beyond the initial vision and the capabilities of individual
engineers. Undoubtedly, to rise to the leadership position, this
individual must have had strong engineering skills at some point;
in the managerial position; however, he or she employs these skills
only minimally. The person can bring in a project on time and on
budget but is unlikely to be a great engineer. He has become a
project manager, not an engineer or leader.
2. System designer: This engineering manager has exceptional techni-
cal skills and is passionate about making the product fit a vision of
technical excellence, with parts of the system working together to
achieve the design objectives. This type of leader is a creative
thinker and excellent systems engineer, however, he or she is not
terribly skilled at managing people or having the patience to coor-
dinate, teach, or listen to them. This manager has a top-down
style for making key technical decisions and uses subordinates to
do the detailed, routine work. Henry Ford, in his early days, fits
this model. There are limits to the flexibility of the project because
many people are doing the detailed work, all orchestrated from
the top, and this works only if everyone is following clearly speci-
fied instructions. Changes will reverberate through the organiza-
tion, and the teams are incapable of thinking for themselves
without direction from the top.
3. Group facilitator: This engineering manager is a people person
who has developed leadership skills and is able to take a group of
individuals and facilitate their working together as a team. This
type of leader is not necessarily a great engineer and may even
find detailed technical work boring. Instead, he or she likes to
communicate, facilitate, and be a catalyst that moves a talented
group of technical professionals toward a common goal. This
manager is a flexible thinker and the group can work autono-
mously to organize and reorganize itself. Terms like “rugby-style
management” capture this leadership style, which is characterized
by spontaneous adjustment as the game progresses. The weakness
in this approach is the lack of a strong technical vision from the

133
Morgan Liker sec 3 3/2/06 11:27 AM Page 134

Section Three: People Subsystem

top. This can lead to engineering details falling through the cracks,
which can cause time lines to extend outward and weaken techni-
cal integration.
4. System Integrator: A system integrator is strong technically and
uses a bottom-up process to bring out the best ideas from team
members. This type of leader has a strong vision for the product
and orchestrates the technical integration of the project; he or she
also facilitates a dynamic team process with a great deal of flexibil-
ity. Toyota CEs best fit this model.

The CE system is designed to give the CE a small number of people to

manage administratively, freeing the CE to lead the project by focusing on
technical vision and horizontal cross-functional group facilitation. Both
Uchiyamada and Suzuki exemplify this leadership style. Each developed
strong visions for the product and sought out the right people and
resources at the right time. They also excelled at “top-down” management,
adhering to strict targets for timing, cost, weight, and fuel efficiency, while
at the same time motivating their teams to accomplish remarkable things
technically. Note that Figure 7-3 shows that the footprint of the CE cuts
across all four types of leaders; residing primarily in the “system integra-
tor” quadrant, he or she also at times puts on the hat of the other three.

NAC Product Development Manager: From Chief

Engineer to Bureaucrat
North American Car Company started as a small entrepreneurial venture
and, in fact, its early engineers had a lot in common with the chief engi-
neers of Toyota. Leaders of the company loved cars, grew up tinkering
with machines, and were more inventors than technicians or managers.
They provided a creative genius needed to push the envelope of technol-
ogy to higher and higher levels. Under their leadership, automobiles
became more sophisticated and costs were dramatically reduced. Because
NAC was a small company, these “chief engineers” of old were unen-
cumbered by a lot of bureaucracy. In fact, they worked closely with the
company’s chief owner, who shared their excitement about cars and tech-
nology. This gave them a great deal of authority, but their power also
came from having strong technical expertise. At that time, the company
was quite autocratic; engineering leaders made technical decisions and
expected their orders to be followed. They were the architects of the

134
Morgan Liker sec 3 3/2/06 11:27 AM Page 135

Create a Chief Engineer System to Lead Development

from Start to Finish

system, and others in specialized functional groups assisted them in han-

dling the detailed tests and design work.
As NAC grew into a global powerhouse, the vehicles became far more
varied and complex, and the organizational structure mirrored this.
Departments proliferated. Functional “chimneys” were formed to lead
every detail of every vehicle—chassis, powertrain, car bodies, electrical
systems, electronics, die engineering, engineering analysis, window regu-
lators, emissions control, and on and on. Each functional group had sev-
eral layers of managers who ultimately reported to the vice president of
Engineering. This person was so high up on the organizational chart, there
was no bandwidth to keep track of the myriad of work details throughout
the company. The overall coordination of the program belonged to spe-
cialized program management groups; the technical integration was the
responsibility of specialized systems engineering groups.
Lost in this complex bureaucratic organization were the customers. Of
course, the company could point to specialized sales and marketing
departments responsible for identifying what customers wanted, but by
the time that information found its way to disparate technical groups,
these customer preferences were distorted beyond recognition. In the sec-
ond half of the 1990s, NAC moved to a matrix organization in an attempt
to compensate for the heavy emphasis on functional departments making
separate decisions with weak coordination with other departments. The
result was another bureaucratic organization of program managers
attempting to exert influence over recalcitrant functional departments.
Clearly, the functional departments were winning the power struggle.
Thus, at NAC, bureaucratic managers who learned how to play the
game led product development, replacing the powerful and creative chief
engineers of old. These managers were administrators rather than system
designers. Instead of leading a technical process, they issued orders, set
policies, defined objectives for programs (e.g., timing, cost, features), and
used rewards and coercive power to whip the organization into shape. At
the same time, individual functional departments suboptimized and
attempted to grow their functions and power base from the perspective of
their own objectives.

Group Facilitation at Chrysler

Durward Sobek’s (1997) research comparing Toyota’s product development
approach to Chrysler’s is an interesting case in which Chrysler’s original

135
Morgan Liker sec 3 3/2/06 11:27 AM Page 136

Section Three: People Subsystem

platform team structure was presented as an example of “group facilita-

tion.” Like NAC, Chrysler favored the bureaucratic management system
up through the early 1990s, and this nearly drove the company out of busi-
ness. Chrysler was unable to develop new vehicles rapidly enough to get
the market share needed to sustain the company. In a bold move, Lee
Iacocca and his vice president of engineering, Robert Lutz, reengineered
the entire product development organization around platform teams and
even built a multibillion dollar R&D center in Auburn Hills, Michigan, to
collocate cross-functional platform teams. Chrysler eliminated much of
the functional organization that was the backbone of companies like NAC
and that continues to be a major strength of Toyota. Once this change was
implemented, the functional experts—body engineers, chassis engineers,
electrical engineers, component engineers, and even some manufacturing
engineers—all reported directly to the head of the platform team. In fact,
Glenn Gardner, the first platform team general manager insisted that he
either owned these people 100 percent or not at all. This product focus led
to great coordination across engineers toward a common goal. Gardner
and later platform general managers facilitated groups toward consensus,
and product development lead times shrank significantly from 48 months
or more to 33 months on the first program and were reduced even more
on later programs like Neon and the minivan.
In retrospect, it seems that this new approach led to breakthrough
projects like completely new, large cars (Concorde, LHS, Intrepid), the
Neon, very new and different minivans, the new Jeep Grand Cherokee, and
the P.T. Cruiser. These fresh new products were launched in record time
for Chrysler and saved the company. Moreover, Chrysler boasted the low-
est cost per vehicle in the industry and the largest profit per vehicle, mak-
ing even Toyota look carefully at Chrysler as a potential competitive threat.
But within this apparently successful model, Chrysler engineers spent
morning until night in meetings and seemed to focus more on developing
group consensus than on engaging in detailed engineering work. Product
quality and durability never achieved Toyota levels, and the lead time for
developing products never caught up with Toyota lead time. There was also
some difficulty in maintaining the deep technical expertise of engineers
(who did not work with other specialists in the other platforms), and
design standards across platforms did not develop or improve. This, ulti-
mately, led to a creeping increase in product cost. It seems that there were
limits to a pure group facilitation approach and to eliminating the strengths
of the functional model. In contrast, Toyota’s system based on the “system

136
Morgan Liker sec 3 3/2/06 11:27 AM Page 137

Create a Chief Engineer System to Lead Development

from Start to Finish

integrator” role has gone farther than Chrysler’s and has stood the test of
time. It is not surprising that in recent years, the Chrysler group of Daimler-
Chrysler has been working to adopt a version of the CE system of Toyota.

Toyota CE System: Avoiding Compromises that Lead

to Bureaucracy
Toyota seems to be able to break time-honored organizational principles
and avoid compromises. Through the CE system, the company has reaped
benefits that derive from its cross-functional product-focused organiza-
tion, which is peopled by functional experts. It also benefits from top-
down management that meets strict timelines and targets and from the
flexibility and creativity of bottom-up style management. The Toyota CE
shares the technical excellence and passion of the early system designers of
NAC. Like those early system designers, Toyota’s chief engineers have the
ear of top management and are relatively unencumbered by bureaucracy
or onerous administrative responsibility. By design, the engineering
organization is housed in functional groups, and chief engineers do not
have to concern themselves with a great deal of administrative work to
manage those engineers and worry about human resource issues.
But Toyota’s chief engineer differs from the early system designers in
important ways. Toyota is a huge, multinational bureaucracy that cannot
function exactly like early small car companies functioned. Toyota’s cul-
ture is based on consensus management (to a degree) and not blatant
autocracy. The size and complexity of the organization and the vehicles it
produces prohibits the chief engineer from making all key decisions alone
and barking orders. Furthermore, engineers do not formally report to the
chief engineer. Thus, the CE must combine his or her recognized techni-
cal superiority with strong leadership skills to mobilize the organization
and must guide a process of developing consensus across functions. One
thing that enables the CE to accomplish this is the concept paper; another
is the CE’s role as system designer and overall architect of the vehicle. In
addition, the chief engineer has the final word on technical decisions (sub-
ject to executive approval on major issues). The system works because
Toyota has a culture focused on the customer, and functional engineering
groups recognize that they exist to support Toyota’s customers and that the
CE is the voice of the customer.
Key decisions, mentoring, lobbying for resources, building a shared
vision, pushing the product to higher levels, and achieving quality, safety,

137
Morgan Liker sec 3 3/2/06 11:27 AM Page 138

Section Three: People Subsystem

cost, and timing targets all start with the chief engineer. This makes the CE
system stand out as a pivotal part of Toyota’s PD system. As the analysis of
Toyota’s people systems continues, it will become clear that the CE system
works because of the broad expertise and organizational alignment that
has evolved at Toyota. In connection with this, the following chapter
examines LPDS Principle 6 and Toyota’s Matrix System.

LPDS Basics for Principle Five

Develop a chief engineer system to lead the development
from start to finish

The LPDS is led by an exceptional chief engineer (CE) with the skills
to lead system integration, both in the product and integrating the
people working on the program. The CE is different from the tra-
ditional project manager in several respects. First, the CE does not
manage the engineers working on the project, with the exception
of a small group of assistants. The CE leads through personal influ-
ence, technical know how, and authority over product decisions.
Second, the CE represents the voice of the customer and is respon-
sible for the success of the vehicle program from concept to sales.
Third, the CE focuses more attention on decisions about systems
integration than on personnel decisions and project administration.
If a CE is acting only as a project manager, then your company does
not really have a CE role.

138
Morgan Liker sec 3 3/2/06 11:27 AM Page 139

CHAPTER 8

Organize to Balance
Functional Expertise and
Cross-Functional Integration
One result of the Prius development project is something called
obeya—big room—where the chief engineer gathers the team of
people responsible for that project. That is where simultaneous
engineering can be even more effectively implemented by all the key
people coming together in this area.
TAKESHI UCHIYAMADA, first chief engineer of the Prius hybrid

One Best Organizational Structure?

The problem of attaining the “best” organization structure for product
development is finding a balance between trade-offs. Various structures
promoting product-focused organizations have replaced the traditional
functional organization structures that were most common at the turn of
the twentieth century. Now companies see the functional organization as
bad and the product-focused organization as good. This seems clear-cut,
but the lean PD system uses neither . . . or both.
A functional organization groups like specialties and like-minded pro-
fessionals into departments. It segregates all of the mechanical engineers
into a set of cubicles where they share war stories and practices. All of the
electrical engineers occupy a different set of cubicles and gossip about the
boring work mechanical engineers do. The manufacturing engineers go to
offices on or near the shopfloor where “real” work is being done and criti-
cize the head-in-the-clouds theoretical work of the electrical and mechani-
cal engineers. And so on. At one time, however, the functional organization
had certain advantages. These existed because functional specialists:
• could talk to each other efficiently in a specialized language.
• shared the latest technologies and methods with each other,
increasing their technical depth.
• attended the same professional conferences, read the same jour-
nals, and continued to learn long after leaving school.

139
Morgan Liker sec 3 3/2/06 11:27 AM Page 140

Section Three: People Subsystem

• could standardize their approaches and the actual technologies

they used in the product, saving cost and sharing solutions
to problems.
• could be efficiently deployed as needed to projects (whoever was
available at the time could go work on the project)—thus fully uti-
lizing all of the engineering resources.
But there was one big problem with this organizational approach—
functional specialists tended to bond and become more wedded to their func-
tion and profession than to the company and its products and customers.
Their measure of success was how well the functional department per-
formed and how big a budget it garnered. They believed their profession
could be the savior of the company; if they ran things, the company would
be successful beyond belief. As a result, no function did a particularly good
job of working in coordination with the other functions. Today, these iso-
lated functions are often denoted by derogatory terms like functional silos
or chimneys.

Shortcomings of a Product Organization

One alternative to the functional organization is the product-focused
organization or product organization. This organization creates cross-
functional teams that focus on a project or product and sets clear goals and
objectives for the new PD program, holding the team responsible. It ded-
icates representatives from all of the needed functions to the program to
develop the product and process. And, if possible, it collocates teams so
that they will communicate constantly about the product and the cus-
tomer. This is sometimes called concurrent engineering because it is
designed to develop product and process concurrently rather than serially
(Fleischer and Liker, 1997). Having a product focus breaks down barriers
between the “silos” and aligns the company as a whole to care about what
is really important—satisfying customers so they will buy more products
and make the company profitable. The benefits of the product organiza-
tion are also clear-cut because they allow companies to:
• align different functions around common goals and objectives that
are needed for creating products that satisfy customers.
• communicate and coordinate effectively to reduce lead time.
• make well-informed product and process decisions from multiple
perspectives to increase product quality.

140
Morgan Liker sec 3 3/2/06 11:27 AM Page 141

Organize to Balance Functional Expertise and

Cross-Functional Integration

• create self-managing teams to be flexible and adaptable to changes

in the environment.

But the product organizational approach also poses problems, which

can be exemplified by Chrysler’s adoption of a platform team organization.
In this structure, Chrysler categorized vehicles into platforms—large car,
small car, minivan, etc., and collocated all the engineers from all the needed
functions to engineer a complete vehicle into one floor or a new technical
center. All the engineers reported to a “general manager” whose responsi-
bilities were similar to those of Toyota’s CE. However, as Sobek (1997)
observed, there were associated costs and problems with this restructuring.
For instance, Chrysler engineers spent an enormous amount of time coor-
dinating their work and sitting in meetings while some of the standardiza-
tion within functions (e.g., sharing common parts) got lost. Soon, each
platform became its own “chimney,” only in this case, it was a product
chimney rather than the traditional functional chimney. This led to an inef-
ficient utilization of resources across platforms, further fixing engineers
within their respective platforms. Furthermore, even though workloads
swing up and down over the life of a program, the general manager wanted
to maintain the same number of engineers because “sharing an engineer”
with another platform could mean losing that engineer.
Over time, a kind of empire building mentality evolved, and many of
the benefits of Chryslers’ platform team structure dissipated as people
pursued the territorial benefits of their own “product chimneys” (e.g.,
more engineers, bigger budgets, greater prestige). Top management saw
this trap and developed a solution, forming “technology clubs” across
platforms to bring together functional specialists to share technical infor-
mation and develop standards for components. Nevertheless, the techni-
cal clubs tended to play second fiddle to the incessant daily demands of the
programs—particularly as the platform general managers had authority
over the engineers. As G. Glenn Gardner, the first platform general man-
ager, put it, “If I do not own all of a person I do not own any of that per-
son. I need full-time engineers on the platform.”
Toyota seldom settles anything with compromises and seeing a choice
between a functional organization (with its functional expertise and the
efficiencies that come with sharing people across programs) or the prod-
uct organization that integrates systems across functions, Toyota’s view
will be, “I want them both.” The secret to Toyota’s success is combining a
strong functional organization based on deep specialization with the CE

141
Morgan Liker sec 3 3/2/06 11:27 AM Page 142

Section Three: People Subsystem

system as the other leg of the matrix. Using this matrix organizational
structure, Toyota manages to have it both ways.

Strengths and Weaknesses of the Matrix Organization

to Manage the PD Process
Since the 1960s, many organizations have developed and adopted vari-
ous versions of the matrix organization, with mixed results. It is in some
ways the best of both worlds and in other ways the worst of both worlds.
It provides:
• an excellent balance of functional expertise and cross-functional
integration.
• the technical depth and efficiency of the functional organization
with the customer focus of the product organization.
• flexibility in assigning resources to programs as well as technical
depth in responding with creative solutions to new problems.
NASA pioneered the matrix organization structure in the 1960s when
it was first contemplating space exploration.1 It was a solution that satis-
fied the need for deep functional expertise—to get all the individual vehi-
cle systems exactly right, using the latest technologies, meant that NASA
needed every part of the spacecraft to work together as a system. Mis-
alignment could be a matter of life or death for astronauts. NASA also
kept the functional organization structure, adding a program manage-
ment structure to manage the large government projects that are its bread
and butter. This meant that engineers reported to at least two people in
two different arenas: functional managers within their functional spe-
cialty and program managers who were leading each of NASA’s space
exploration programs.
As NASA’s experience demonstrates, the matrix organization has one
major flaw: It is confusing! It violates a core principle of personnel man-
agement that clearly stipulates that no one should have more than one
boss. As the saying goes, “A person with two bosses is like a dog with two
heads.” This leads to communication and leadership-direction prob-
lems—whose orders are to be followed—or engineers taking advantage of
the fact there is no clear authority and seeking the approval of the man-
ager most likely to say yes to their demands and needs. This is human

1. Toyota developed a form of matrix organization long before NASA.

142
Morgan Liker sec 3 3/2/06 11:27 AM Page 143

Organize to Balance Functional Expertise and

Cross-Functional Integration

nature. Moreover, it is an environment in which engineers can play bosses

against each other just as children play parents against each other, a situa-
tion that can lead to infighting between bosses. Toyota manages to avoid
these problems by grooming its CEs to play the program manager role in
a matrix in a manner that precludes these problems.

Toyota’s Original Matrix Organization: A Long Tradition

of Combining Two Structures
How does a lean PD system combine a strong functional organization with
a matrix organization and keep the peace between these two structures?
The secret is that it uses a combination of the intense customer focus (the
core of the Toyota DNA) and the CE system discussed in Chapter 7 to
make the program management part of the matrix work in harmony with
functions. It was in the 1950s that Toyota merged its unique CE system
into its homegrown matrix system.
Figure 8-1 presents a simplified version of Toyota’s matrix organiza-
tion. Originally, each product had one functional department and each

Functional Departments
Product Design Body Chassis Engine Test
Planning

Camry
Corolla
Celica
etc.

Chief Engineer Functional General Manager PD Engineer

• Most engineers report to functional managers.

• Engineers are assigned to projects as needed.
• Production Engineering is a separate division.
• Chief Engineer has a small staff of assistants.

Figure 8-1. Toyota’s Matrix Organization—“It’s the Chief Engineer’s Car”

143
Morgan Liker sec 3 3/2/06 11:27 AM Page 144

Section Three: People Subsystem

functional department reported to a “general manager” who had distin-

guished himself or herself as an excellent engineer and leader within that
particular function. The general manager’s job included:
• selecting and developing engineers in the specialty.
• coordinating performance reviews of the engineers reporting
to him.
• maintaining checklists of accumulated knowledge for the specialty.
• keeping the specialty state of the art.
• ensuring technical coordination, such as common parts across
vehicles.
• working with suppliers of components related to the specialty (e.g.,
resident engineers who come from the specialty suppliers).
• assigning the engineers to projects run by chief engineers.
Thus, the general manager had the responsibilities of a traditional
manager as well as a technical expertise in a given specialty and provided
administrative management, developmental leadership, and technical
mentoring. What the general manager was not responsible for was the
development of a vehicle. That was the sole domain of the chief engineer,
who likewise was not responsible for the administration or management
of the engineers. This structure gave the CE time to focus on the customer
and the product and gave the general managers time to focus on the man-
agement and development of the engineers.
This eventually evolved into Toyota’s matrix structure: The functional
managers make up one side of the matrix and the CEs make up the other
side. Normally, a matrix is viewed as a reporting structure in which each
engineer reports to a functional boss and a program management boss. At
Toyota, most engineers do not report to the CE. Instead, there is a “dotted
line” reporting relationship: When engineers work on a CE’s design pro-
gram, they are mainly reporting to the functional boss but dotted line
reporting to the CE. So what gives teeth to the dotted line? And why does
this work at Toyota?
To answer these questions, it is necessary to examine why so many
companies struggle with the matrix organization. As noted above, the
engineer in most matrix organizations has two bosses—the general man-
ager and the program manager. Because the general manager handles his
or her performance review, the engineer is more inclined to favor the gen-
eral manager. The Toyota matrix system would seem to almost guarantee
this bias by having the engineer report administratively to the functional

144
Morgan Liker sec 3 3/2/06 11:27 AM Page 145

Organize to Balance Functional Expertise and

Cross-Functional Integration

boss. Why would the working engineer pay any attention at all to the chief
engineer and the specific vehicle program? There are five reasons that
Toyota can successfully integrate the functions and programs:

1. Customer is first. From the moment an engineer joins Toyota, he

or she is never allowed to forget this principle. In Japan, new
Toyota engineers are even assigned to sell cars door to door, which
drills into them the customer-is-first philosophy—an engineer
exists to serve the customer, not the functional boss. Simultane-
ously, the engineer learns that the CE represents the customer.
The chief engineer controls the vehicle program by representing
the voice of the customer, so the top priority is for the engineers to
listen to the chief engineer. This cultural philosophy, and the
behavior that reflects it, is unusually strong in Toyota and essential
to a lean PD process.
2. Chief engineer is revered. As discussed in Chapter 7, every engineer
recognizes the engineering skill, leadership skill, and dedication it
takes to become a chief engineer. This merits a high level of
respect and compels every engineer to support the chief engineer.
3. Chief engineer has the power of executive sponsorship. It is the chief
engineer’s car and the chief engineer can tap any executive any
time for help. The CE may not have formal authority, but he or
she has plenty of access to a pool of executive authority.
4. General managers understand the importance of serving customers
and cross-functional cooperation. When conducting performance
reviews, the general manager takes very seriously the need for
soliciting feedback from other functions and from each engineer’s
CE. Thus, the engineer sees every senior official as a boss who can
influence his or her performance review.
5. Junior employees respect senior employees. The Japanese culture
reinforces the respect given to senior employees with more experi-
ence. Junior employees naturally defer to senior leadership, which
reinforces learning and clarity of authority.

A Fundamental Change to Toyota’s Matrix Organization

Toyota’s matrix organization worked just fine for decades, but as Toyota
grew and cars became more complex, the functional specialties prolifer-
ated. In 1976, the CE had to coordinate people from 23 departments in

145
Morgan Liker sec 3 3/2/06 11:27 AM Page 146

Section Three: People Subsystem

6 divisions; by 1991, this had doubled to 48 departments in 12 divisions

(Cusumano and Nobeoka, 1998). As the number of programs grew, func-
tional managers had a hard time managing the details of so many pro-
grams. Across the board, the system became too complex to manage.
In 1992, Toyota did something unusual. After decades of fine-tuning
one type of matrix organizational structure, the company fundamentally
reorganized it around three vehicle development centers, each of which
handled a different product family of vehicle platforms: rear-wheel drive,
front-wheel drive, and utility vehicles/van. In 1993, Toyota added a fourth
center to develop components and systems that cut across vehicle plat-
forms. This fourth center also housed most research and advanced devel-
opment, along with some general electrical engineering and engine
development work. In 1993, about 12,000 people worked on product
development. With the reorganization, each of the platform centers
housed under 1,900 people (with the largest group located in Center IV)
working on about five new vehicle programs simultaneously.
The result was smaller vehicle centers that considerably reduced the
coordination requirements for chief engineers and, in fact, allowed for
much greater coordination across the programs within a vehicle center. To
simplify the coordination requirements further, Toyota simplified the
functional departments. For example, two different divisions for body
engineering—interior engineering and exterior body structures—became
one body-engineering department within each of vehicle development
Centers I through III. Similarly, Toyota merged two chassis engineering
specialties into one, reducing the number of handoffs across functional
departments. Now, with three smaller organizations, the functional gen-
eral managers had fewer programs to support and could handle the added
specialties within their respective domains.
Each vehicle center also has its own planning divisions supported by
almost 200 planning people—about 10 percent of the employees in each
center. These planning divisions include the CEs and their staffs, who
managed the programs, and planners, who kept track of costs and timing
on every detail of each program. Even today, Toyota’s extensive planning
means that costs and timing relative to targets can be reported daily, which
enables Toyota to execute programs smoothly.
The vehicle center structure changed once more with the rise of Lexus
and the desire to separate this luxury car division from the rest of the
products. Figure 8-2 depicts the resulting matrix organization (earlier ver-
sion was in Cusumano and Nobeoka, 1998). Each center looks much like

146
 Center Head g -3 & 1-3
g rin n1 ion n
-3 e rin nee i sio at i s i o
Morgan Liker sec 3

Chief Engineer i v lu v
n1 ine ng in Di va D i
m 1-3 al tio E ng -3 s E -3 tra g eE g
Functional General Manager ra nic istra 1 ss i n 1 er erin icl erin
og ng ch dy n a w h
Pr nni Te min Bo visio Ch visio Po gine Ve gine
Pla Ad Di Di En En
3/2/06

Center I
11:27 AM
Page 147

147
Center II
Cross-Functional Integration

COMPONENT AND SYSTEM DEVELOPMENT

Center III
Organize to Balance Functional Expertise and

Source: Reprinted with changes from Jeffrey K. Liker, The Toyota Way (New York: McGraw Hill, 2004), 176, by permission of McGraw Hill

Figure 8-2. Toyota’s Vehicle Development Center Structure

Morgan Liker sec 3 3/2/06 11:27 AM Page 148

Section Three: People Subsystem

a smaller version of the original matrix organization. Most of the rear-

wheel drive vehicles are in Center I, and most of the front-wheel drive
vehicles are in Center II. The trucks and chassis-based sport utility vehi-
cles that had been in Center II were moved to Center I. A few front-wheel
drive vehicles are in Center I (e.g., the U.S.-based Avalon, Camry, Sienna,
Solara are in Center I). The third center is devoted exclusively to all Lexus
vehicles. Lexus simply has higher standards for everything, engineering
and manufacturing, and Toyota decided to keep it separate from other
products so it does not become a standard Toyota with a Lexus nameplate.
Note that the centralization of component and core system development
concentrates these developments as a shared resource to the development
centers so that they can be commonized across programs.

Chrysler’s Platform Team Structure: A Contrast to

Vehicle Development Centers
It has become quite common for automotive companies to organize their
PD program around vehicle platforms, but most do so without the CE
role. Sobek (1997) documented Chrysler’s platform team organization,
which provides an excellent contrast to Toyota’s vehicle development centers
and the role of the CE in the Toyota matrix organization structure.
The structure for Chrysler’s platform team organization was origi-
nally set up in 1989, about three years before Toyota’s reorganization.
Chrysler’s platform team organization was the company’s response to
problems that had arisen because the functions within its functional
organization did not communicate well or work well together. Company
executives decided they needed a radical change: to blow up this func-
tional organization and turn it completely into a product organization. At
first, Chrysler launched the platform team structure with the large car LH
platform, which was the large passenger car front-wheel drive platform
(Dodge Intrepid, Chrysler LHS, Chrysler Concorde, etc.). At the time,
Vice President Bob Lutz had already made the decision to convert
Chrysler’s purely functional organization to platform teams across the
board, and Chrysler soon created platform teams for its small car, mini-
van, Jeep, and truck divisions. The rapid change was motivated by one
simple reason: Chrysler was on the brink of bankruptcy. It was riding the
long wave of the k-car—produced on a single and very old platform—
and desperately needed a new product. Survival meant change. In this
environment, it was a bold move for Iacocca to benchmark Honda’s PD

148
Morgan Liker sec 3 3/2/06 11:27 AM Page 149

Organize to Balance Functional Expertise and

Cross-Functional Integration

system and then bet the company’s future on the platform team organiza-
tion. The concept was to pour the functional organization into a product
organization, using cross-functional teamwork as the driving force behind
the reorganization. As mentioned in Chapter 7, Chrysler collocated engi-
neers from across functions in a newly built technical center in Auburn
Hills, Michigan, designed to house a whole platform in one part of one
floor, so teams could continuously interact.
G. Glenn Gardner headed the LH platform program and became
Chrysler’s first “Platform General Manager.” Earlier in his career, Gardner
had, in fact helped shape the concept for the platform teams, leading to the
development of a number of successful Chrysler vehicles produced in a
“skunkworks” fashion. The teams had been set up, housed offsite,
removed from the Chrysler function-based bureaucracy, and given the
freedom to focus on the vehicle. The results were outstanding. Unfortu-
nately, Chrysler later disbanded the teams; team members returned to
their home functional departments, and all of their knowledge was lost.
After some experience working as an executive at Mitsubishi, where he
learned about cross-functional teamwork, Gardner returned to Chrysler.
Armed with new experience and new knowledge, he had no interest in
reviving the skunkwork approach; he wanted an approach that would sus-
tain PD teams from project to project. He insisted that:
• Chrysler supply him with all of the engineering specialists needed
to get the car designed.
• the manufacturing process engineers reported to him.
• every core engineer was on the project team 100 percent of the
time—not split with other responsibilities (the matrix was not
an option).
Gardner also insisted that if he had a well-selected team reporting to
him 100 percent of the time, he could do the job with about half the num-
ber of people working on traditional Chrysler programs. True to his pre-
diction, the LH team reduced the development time for the LH family of
vehicles from 4.5 to 3.5 years and did the job with 741 people instead of
the 1,400 people originally forecasted, saving $42 million. The overall
product came in under weight, $20 under target cost, and had better fuel
economy than targeted. In addition, it was a completely new platform with
a complete line of large cars and a new engine. The post-launch results
were stunning. The LH platform cars were attractive, well packaged, com-
petitively priced, and started the resurgence of Chrysler. The vehicles that

149
Morgan Liker sec 3 3/2/06 11:27 AM Page 150

Section Three: People Subsystem

followed in the other platforms were all successful in their own right, and
Chrysler became the low-cost producer of vehicles with high profit mar-
gin per vehicle.
As Figure 8-3 shows, the platform team organization that Chrysler
used was cross-functional and included engineering teams from body,
interior systems, chassis, powertrain, electrical/electronics, preprogram,
and the vehicle evaluation departments (Sobek, 1997).

• Five platforms: large car, small car, minivan, Jeep, truck.

• Platform lead by cross-functional Platform Direction Team:
Engineering member = Platform General Manager.
• Team members dedicated and colocated.
• Integrate across functions in platforms through technology clubs.

Platform Direction Team

Leaders

Finance Procurement Product Plan Manuf. (ops)

Engineering
G.M.
Members

Platform Team

Figure 8-3. Chrysler’s Platform System in 1989

An “executive engineer” heading each of these areas reported to the

general manager (just as Gardner had insisted), who ran the program with
a small staff of program managers similar to Toyota’s CE staff. The cross-
functional platform direction team ran the platform, while the product
engineer (the general manager) ran day-to-day operations. The platform
direction team included finance, procurement, product planning, and
manufacturing operations. The four functional groups each had represen-
tatives assigned to the platform direction team who reported in a dotted
line to the platform general manager. The role of the platform direction
team was to get the nonengineering cross-functional support to focus on
the customer and the product and stop territorial disputes that often occur
among nonengineering and engineering functions.

150
Morgan Liker sec 3 3/2/06 11:27 AM Page 151

Organize to Balance Functional Expertise and

Cross-Functional Integration

Since so much of the emphasis of the platform team structure is to

coordinate across different functional specialties, a great deal of time and
resources was devoted to communication. In Chrysler’s previous platform
organization, the platform engineering team did their work within their
specialty and then “threw it over the wall” to other groups who challenged
technical specifications and then threw the design back over the wall. This
sucked up a lot of time and energy and produced inferior designs. The new
platform team approach “got all the right functions together in the same
room,” accelerated the negotiation process, and helped everyone leave the
room on the same design page. When compared to its older dysfunctional
system, the platform team approach was a highly successful endeavor that
revolutionized the PD process at Chrysler. On the other hand, compared
to the lean PD system, it had several weaknesses:

1. Poor resource utilization of engineers. There is some waste of

resources because Chrysler’s engineers were committed to a pro-
gram from start to finish. In the life of a program, different num-
bers of engineers are needed at different times. Toyota addresses
this fact by using the matrix organization to add and remove
people from the program as needed.
2. Poor use of the platform general manager’s responsibilities. The dual
role of the Chrysler platform general manager as head of func-
tional general managers and something akin to the CE at Toyota
meant this individual spent a good portion of his or her time on
administration. This cut into the time spent on the systems inte-
gration role, which the CE provides at Toyota.
3. Poor use of meetings. Chrysler engineers had to spend a vast
amount of time in meetings, often going over administrative
things that took time away from working on technical product
development. Since they were working in cross-functional teams,
they had to listen to reports from all other functions, whether the
information was relevant or not. Sobek (1997) calls this commu-
nication by immersion in all of the details. Rather than communi-
cation by immersion, Toyota engineers do their own CAD work,
spending a lot of time at the terminal designing, using a pull sys-
tem, and seeking the information they need, when they need it, to
complete their tasks.
4. Poor coordination of engineers within their functional specialties. The
Chrysler platform teams focused so heavily on their own platforms,

151
Morgan Liker sec 3 3/2/06 11:27 AM Page 152

Section Three: People Subsystem

that engineers made little effort to coordinate their efforts within

their own functional specialties. For example, taking the time to
standardize parts within a function across vehicles suffered.
Chrysler added “technology clubs” so functional specialists, like
electronics engineers from different platforms, could meet and
discuss common issues, but this often took a backseat as each
engineer had to tend to the heavy demands of his or her own
vehicle program. In contrast, Toyota’s vehicle-development center
system takes the time to develop a deeper functional expertise,
capturing the learning and applying and/or standardizing it across
vehicle platforms.

It is easy to understand why Chrysler did what it did. Because of the

severe coordination problems across functional specialties, a radical
approach was devised: tearing down the functional organization and
replacing it with a completely new PD process that would allow engineers
to focus solely on the product. Meetings, morning to night, would force
coordination and assign everyone to one hierarchy dedicated to each plat-
form. This worked to a point. However, these efforts did not lead to the
vast improvements in lead time that a CE-driven lean PD process delivers.
(Toyota’s vehicle center system, for example, eventually reduced lead times
to 12 to 15 month programs.) By 2003, the Chrysler division of Daimler-
Chrysler was looking more closely at Toyota’s model. It has since strength-
ened the functional organization structure and created a CE-like role.
During Chrysler’s PD reorganization, Toyota was not standing still.
Company executives realized that they needed to revisit their strong func-
tional organization, which, at the time, was being solely driven by the CE
system. When Toyota started improving simultaneous engineering—to
improve integration of product and production system design—it became
clear that the next step of evolution required greater horizontal coordina-
tion across the functional organization. This led to additional innovations,
such as the obeya room, module development teams, chief production
engineers, and a slightly different role for the CE.

Simultaneous Engineering: The Obeya Room

In the early 1990s, Eiji Toyoda was concerned that Toyota was becoming fat
and stagnant. He wanted to renew the innovative and exciting environ-
ment of the early years, and a key part of that strategy was to use the G21

152
Morgan Liker sec 3 3/2/06 11:27 AM Page 153

Organize to Balance Functional Expertise and

Cross-Functional Integration

(Global 21) platform—which became Prius—for change (for a detailed

discussion of this, see Chapter 7). One of the two objectives of that proj-
ect was to, “develop a new method of developing cars for the twenty-first
century.” The person chosen to head the G21 project was Uchiyamada,
someone who had no experience in product development or as a chief
engineer. Uchiyamada had to innovate or fail and his solution was to seek
help from others, specifically from individuals who had spent their careers
in product development, instead of leading the project alone. The best way
to do this was to get technical leaders from each of the core functions
together in one room and ask them to help him lead the program. While
this may sound similar to Chrysler’s platform-direction team approach,
there is an important difference. Chrysler designed the platform direction
team to solicit broad participation from what are usually support func-
tions, such as purchasing and finance. Uchiyamada wanted technical assis-
tance from core engineering functions to help lead the actual development
of the vehicle. Moreover, there was no mistaking that Uchiyamada was still
the CE and the final authority on product decisions.
As discussed in Chapter 7, one of Uchiyamada’s first innovations was
the obeya, where once every two days or so the CE participated in a face-
to-face meeting with a team of specialists from the various design, evalu-
ation, and manufacturing functional groups. Here, the experts could work
with the CE to formulate ideas, address immediate issues, and make on-the-
spot decisions. Production engineering also joined in these meetings to
discuss and work on issues with the design engineers. Having the teams
meet in obeyas served two main purposes—information gathering and
information management. Information gathering is mainly the responsi-
bility of functional groups. Information management is about hammering
out and communicating the day-to-day decisions in a kind of war room
atmosphere, where the CE makes joint decisions with other leaders almost
immediately (not in days or weeks). The obeyas were equipped with simple
visual management tools laid out densely on the walls, such as graphs of
key metrics relative to target to support decision making and schedules
with checkpoints so that everyone could easily see every aspect of the pro-
gram, further forging a common understanding among the teams.
The obeya did not replace Toyota’s matrix structure, which had not
changed. It was an enhancement that added to the traditional CE
approach. Here, the CE would develop the vehicle-concept and then dis-
cuss it with the design and planning groups. He would then retreat and
write a plan, or concept paper. In addition, while the CE continued to

153
Morgan Liker sec 3 3/2/06 11:27 AM Page 154

Section Three: People Subsystem

control every aspect of the project, the obeya gave the cross-functional
team more direct input into decisions as they were being made.
Uchiyamada’s second innovation was to have the CE office do all the
scheduling. In the traditional CE system, all the teams put schedules
together and reported to the CE. In the new approach, the CE used the
obeya to manage this schedule, identifying different problem areas and
setting up task teams. Then the CE assigned a team member to be respon-
sible for coming up with countermeasures for any problem.
A third innovation emerged from Toyota’s need to embrace new tech-
nologies for the twenty-first century and was simultaneously applied by
Uchiyamada to the Prius development process. For the first time in
Toyota’s history, the development team used the Internet and email exten-
sively as a major communication media. Prior to this, Toyota had used
information technology conservatively. Uchiyamada came from the
research labs and was very comfortable with new technology.
A fourth innovation was to extend the impact of simultaneous engi-
neering and the simultaneous engineer (SE). Toyota had worked on simul-
taneous engineering for several years before the Prius program, but never
to the extent that Uchiyamada planned to use it. Because the Prius pro-
gram involved so much new engineering and such a degree of innovative
development and because top management was putting intense time pres-
sure on the team, Uchiyamada accelerated the use of the SEs. His plan met
with great success and began a new tradition at Toyota. As noted in Chap-
ter 4, there is now at least one SE on each of the several MDTs who act as
a program-dedicated representative from production engineering. This SE
is a production engineering expert who advises the program MDT on
manufacturing aspects of design within his or her specialty (i.e. stamping,
welding, etc.) and also serves as the program representative who advises
production engineering specialists who will perform the actual manufac-
turing engineering. In this dual capacity, the production engineer helps to
synchronize activities, reduce errors and rework, and build cooperation
across divisions. Thus, simultaneous engineering is a vital horizontal coor-
dinating mechanism.

Simultaneous Engineering: The Module Development

Teams and Chief Production Engineers
At this time, Toyota was also developing another simultaneous engineer-
ing initiative, which consisted of two main initiatives: 1) the modular

154
Morgan Liker sec 3 3/2/06 11:27 AM Page 155

Organize to Balance Functional Expertise and

Cross-Functional Integration

development team (MDT) and 2) a corresponding role to the CE, the chief
production engineer.
To some extent, these new initiatives represented a rather strange
departure from a system that seemed to be working very well. For many
years, in fact, Toyota had enjoyed a reputation for designing products for
manufacturability. It was able to maintain this reputation for the follow-
ing reasons:

1. A prerequisite for becoming a first-rate PD engineer was to

spend time in manufacturing to understand the manufacturing
environment.
2. Toyota’s customer focus mantra made it imperative that PD engi-
neers consider manufacturability technologies and issues.
3. PD engineers had to take production engineers seriously because
of the prominence of manufacturing, which makes production
engineering influential.
4. Both product engineering and production engineering kept,
used, and updated extensive checklists separately, ensuring
serious consideration of production in the product develop-
ment stage.
5. Production engineers attended key reviews along with the PD
engineers in the kentou (study drawing) stage to provide input
and were required to sign off on the design structures document
(the K4, which was discussed in Chapter 4).

However, as Toyota continued to streamline its product development

process (in some cases eliminating physical prototypes and radically
reducing tool-manufacturing times), the old interaction between PD engi-
neers and production engineers proved inadequate. It became clear that
Toyota’s new, high-velocity product development process required seam-
less collaboration. Moreover, Toyota wanted to improve its manufacturing
efficiency to a level that would allow the company to compete with low
labor rates in China. Company leaders realized less labor in manufactur-
ing depended on products designed in optimize labor utilization. In con-
nection with this, Toyota determined that a stronger and more intensive
involvement between product engineering and production engineering at
a higher level was needed to coordinate the extra complexity and need for
speed. It was with this in mind that the company created the module
development team (MDT) structure.

155
Morgan Liker sec 3 3/2/06 11:27 AM Page 156

Section Three: People Subsystem

Example of Module Development Teams for Body and

Production Engineering

Figures 8-4 and 8-5 illustrate MDTs for body and structures engineering.
The two examples are from the Toyota Technical Center (TTC) in Ann
Arbor, Michigan, and the corresponding production engineering organi-
zation in Erlanger, Kentucky, at Toyota Motor Manufacturing North
America headquarters.
Product engineers, housed at TTC, were organized by their respective
specialties (body engineering, electrical engineering, HVAC etc.) and, in
the case of body engineering, further organized by area of the car body—
front end, body in white (the car body structure), closures, and the under-
body (Figure 8-4). Each of these body subsystems has an engineering team
for each vehicle program (Camry, Avalon, etc.) led by a senior engineer.
From the production engineering perspective, they are organized into
comparable groups by function (stamping and structures, paint, final
vehicle assembly, etc.) and often further specialized within those func-
tional organizations.
For example, within the stamping and structures organization, engi-
neers are further organized by car body area very much like their col-
leagues in product engineering (closures, front end, body in white). Each
of these areas develops highly skilled, experienced engineers who become
SEs and represent their functional specialty on the program within the
various cross-functional MDTs. These teams meet regularly from the ear-
liest stages of the kentou—before the clay model has even been selected.
They work together as an extended team, making decisions jointly. This
supplements the process in which PD engineers make decisions based on
checklists and then ask production engineers to review these decisions.
Moreover, in North America, Toyota has created the role of chief pro-
duction engineer (CPE) to have overall responsibility for production
preparation and launch for each vehicle program, similar to the CE role in
product development. The CPE’s role is to lead the overall development of
the manufacturing process and coordinate the activities of the SEs across
all MDTs. In Toyota’s U.S. facilities, an important job for the CPE is to
coordinate with Japan (where most of the original production engineering
now occurs) and take a leading role in the transfer of the production
equipment to the U.S. plant. The creation of the CPE position further
demonstrates the challenges of coordinating the development of a com-
plex product in a high-velocity environment.

156
 Toyota Technical Center
Morgan Liker sec 3

Chief Engineer Chief Engineer Body and Structures Engineering

3/2/06

AVALON CAMRY General Manager

Front End
MDT
11:27 AM

AVALON CAMRY Exterior Interior Kino Trim Electrical

Staff Leader Staff Leader Manager Manager Manager Manager Manager
BIW
MDT
1 Front End 2 Front End
Page 157

2 BIW 2 BIW
Closures Front End

157
2 Closures 2 Closures BIW Closures Underbody
MDT Structure
1 Underbody 2 Underbody

Underbody
MDT

Simultaneous Engineering
Cross-Functional Integration
Organize to Balance Functional Expertise and

8 to 10 team members per group

Figure 8-4. Toyota Body Engineering Organization and Simultaneous Engineering

 Production Engineering
Morgan Liker sec 3

Die Simultaneous
Engineering Manager Engineering Manager
3/2/06

Estimating Facility & Die BIW Underbody Closures

Equipment Design Proc./Binder Proc./Binder Proc./Binder
11:27 AM

158
Page 158

Other CAMRY AVALON

Programs
CPT CPT
Leader Leader Underbody
Leader
Closures Closures
Section Three: People Subsystem

MDTs

Underbody Underbody

BIW BIW

CPT = Chief Production Engineer Front End Front End

MDT = Module Development Team

Figure 8-5. Toyota Production Engineering Organization and Simultaneous Engineering

Morgan Liker sec 3 3/2/06 11:27 AM Page 159

Organize to Balance Functional Expertise and

Cross-Functional Integration

During the early stages of the kentou process (discussed in Chapter 4)

production engineers from the SE group study electronically transmitted
design information before attending the biweekly modular development
team meetings. With production data and updated senzu (detailed marked
up manufacturing drawings) and checklists in hand, they discuss the
analysis of current design proposals. Then the MDT will spend an inten-
sive period analyzing, discussing and codeveloping multiple design alter-
natives. Because he owns the part from cradle to grave, the SE is motivated
to evaluate the quality and productivity implications for manufacturing of
the proposed designs.
The MDTs are an invaluable tool for early problem solving, coprod-
uct/process development, and isolating variability. The MDTs are also a
critical integration tool in which engineers from different disciplines
come together without being collocated and gain valuable insights into
the challenges of each other’s specialties. As shown in figures 8-4 and
8-5, each production engineer’s home base remains within his or her
functional specialty; the production engineers also travel to the Toyota
Technical Center (TTC) as required. During times of peak activity, the
production engineers and others may travel to TTC for a week at a time.
Temporary work areas are maintained at TTC for the use of the many
MDTs who are working closely with product development at any given
time. Toyota MDTs contribute much of the program integration and
communication benefits afforded by platform teams while maintaining
the superior functional knowledge sharing and personnel development
made possible by functional groups. Although only broadly utilized since
1997, MDTs have already had a significant and positive impact on Toyota
PD performance.
While the obeya and the MDTs evolved as parallel, separate systems,
they eventually merged into a unified Obeya system. In fact, MDTs are now
considered part of the obeya process and provide key input into obeya for
decision making and problem solving. This expanded obeya system has
aligned the CE with the cross-functional teams, strengthened Toyota’s
matrix system, and, with the use of the SEs, provided horizontal coordi-
nation across divisions, teams, and production. Obeya have also evolved to
a migratory construct; the main obeya is in product development early in
the program and moves to the manufacturing site in the stage of produc-
tion preparation for launch. It is important to note that none of this
supersedes the matrix structure and the role of the CE and functional
organization. That is still the main organization structure and very much

159
Morgan Liker sec 3 3/2/06 11:27 AM Page 160

Section Three: People Subsystem

intact. Obeya and MDTs are additional integrating mechanisms to tie

together different functional groups.

Organization as an Evolving Process

Earlier in this book, we mentioned that understanding Toyota’s PD system
was analogous to removing layers of an onion and, as the last two chapters
clearly show, Toyota’s approach to organizing product and process devel-
opment is clearly an evolving and living process. This is part of the power
of lean thinking, which emphasizes a learning organization—you are
always improving on what you have while maintaining a considerable con-
tinuity in the process. Even with the changes, Toyota’s PD system is philo-
sophically and fundamentally the same as it has been for decades. The CE
system is still vibrant, and the functional organization has been tweaked
and streamlined for the twenty-first century. Production engineering is
still as big and powerful as ever. However, product development, which
had become increasingly complex and unwieldy, has been broken down
into smaller, more manageable vehicle-platform chunks. Toyota has, to
some extent, reined in the CEs within the vehicle development centers,
placing more emphasis on parts commonization. In addition, there has
been a deliberate and extensive addition of horizontal-coordinating mech-
anisms through obeya and module development teams and SEs. Even after
all these changes, the CE’s talent, personality, and perseverance still deter-
mine the success of a car.
In following the second people LPDS principle, Organize to Balance
Functional Expertise and Cross-Functional Integration, your company is
laying the foundation for best utilization of your people resources and
decision-making responsibilities. The next chapter builds on the discus-
sion of the chief engineer and matrix organization and addresses the third
people LPDS principle: Develop Towering Technical Competence in All
Engineers, which reflects the lean philosophy of selecting, hiring, and
developing appropriate talent.

160
Morgan Liker sec 3 3/2/06 11:27 AM Page 161

Organize to Balance Functional Expertise and

Cross-Functional Integration

LPDS Basics for Principle Six

Organize to balance functional expertise and
cross-functional integration

Deep functional expertise is a requirement for LPDS but so is coor-

dination across functions to stay focused on the customer first.
That is why the matrix organization structure is so popular—it pro-
vides an opportunity to balance the functional organization and
the product organization. But the matrix in reality is often unbal-
anced. Either the functional organization is dominant, leading to
a bunch of technical specialists across functions that do not talk
to each other, or the product organization is dominant, and the
company loses depth of expertise and standardization of product
features. Toyota strikes the balance by beginning with the devel-
opment of towering technical competence within functions and
then layering on this the chief engineer system to keep functional
specialists focused on the customer and the vehicle.

161
Morgan Liker sec 3 3/2/06 11:27 AM Page 162
Morgan Liker sec 3 3/2/06 11:27 AM Page 163

CHAPTER 9

Develop Towering Technical

Competence in All Engineers
We develop people and new products simultaneously
using the Toyota way
UCHI OKAMOTA, former Vice President,
N. A. Body and Structures Engineering

TO EXCEL AT THE TALENT-DRIVEN BUSINESS of product development, a com-

pany must have highly-skilled, capable, motivated people. Achieving a lean
PD process with a precise and synchronized execution of a leveled flow
means that everyone working on a PD program must do his or her job cor-
rectly and on time. One weak link can disrupt the precise timing and bring
everything to a standstill. To prevent such disruption and ensure success,
a company must be willing to make major investments in the process of
selecting and developing technical competence in all of its engineers.
In a lean system, people learn best from a combination of direct experi-
ence and mentoring. Excellent engineers that fit in with a high-performance
PD do not graduate from college ready baked to handle important projects;
they are built slowly and from scratch. Toyota has always recognized this
truth and has developed rigorous selection and training processes to sup-
port it. In connection with this, Toyota engineers travel a career path based
on demonstrated competence, a crucial factor in a high-velocity PD
process. Speed in product development depends on “professional trust.”
Engineers in product development are like hockey players or members of a
special-forces team—they must be able to trust that others are doing what
they should be doing when they should be doing it. In turn, others must be
able to trust them. This professional trust has two elements:
1. Integrity. People must have the intent to do what they say
they will.
2. Competence. They must be capable of doing it.
Professional trust defined by integrity and competence can only evolve
over time. It is rooted in rigorous selection and training, and grows

163
Morgan Liker sec 3 3/2/06 11:27 AM Page 164

Section Three: People Subsystem

between professionals who consistently demonstrate battle-tested, reliable

performance.

A Philosophy for Hiring, Developing, and

Retaining People
Towering technical competence begins with the system a company uses to
hire, develop, and retain people. Many companies, unfortunately, do not
have a system or a philosophy that supports towering technical compe-
tence with any consistency. They may have a few special engineers who
excel at what they do simply by chance or some innate skill or drive. They
may also acquire “the best and the brightest” through internships, at hir-
ing fairs, or from universities. But all too often, these top-notch recruits
are plopped into a gaping hole and left to develop as they will. With no
process or program to guide them, they learn and develop haphazardly,
often moving from one area to another too quickly or disjointedly to
develop true expertise in anything at all. Further, since their supervisors
were likely developed in the same way, they often do not have the experi-
ence and technical skill set to provide any meaningful technical mentoring
to these new engineers.
A lean PD people system is a meritocracy and organized into a techni-
cal hierarchy created by developing and rewarding technical achievement.
At Toyota, the career paths of all newly recruited engineers consist of prac-
tical hands-on work that develops deep technical competence. The engi-
neers are evaluated regularly for six to eight years for demonstrated
technical excellence, as well as process, and standards adherence. Rewards
(advancement) are commensurate with progress and achievement. In
many companies, management is the province of well-educated MBAs. At
Toyota, the number of MBAs is conspicuously low. Upper management at
Toyota consists of former engineers who revere technical excellence, seeing
it as the true life-blood for product development. These managers have
been developed through the same system and usually know a job better
than the engineers reporting to them do. As a result, Toyota’s “mentoring
as leadership” principle works extremely well as it is perpetuated across
generations of engineers.
How a company identifies its core competencies and values strongly
influences its training and development practices. By viewing itself prima-
rily as an auto manufacturing enterprise (a core competency), Toyota
avoids many of the problems that other companies have in getting prod-

164
Morgan Liker sec 3 3/2/06 11:27 AM Page 165

Develop Towering Technical Competence in All Engineers

uct engineers to design for manufacturing. Manufacturing engineering

(which Toyota calls production engineering) is about as core as it gets. As
a result of having this “identity” Toyota’s engineers can do everything from
designing tooling to developing complete production equipment and
overseeing its construction, responsibilities that go considerably beyond
what most manufacturing engineers do in most industries.
Hiring and training practices also create and influence the organiza-
tional culture (or value system) needed to sustain a lean PD system. This
concept is best illustrated by example, and the example below revisits a
company that should by now be quite familiar to the reader: NAC. This
section provides an analysis of hiring/development practices at NAC and
a contrasting look at hiring/development at Toyota. The authors suspect
that many companies may see their own policies and cultural behavior
reflected in NAC’s policies.

Recruiting/Hiring Process at NAC

NAC has a decentralized hiring policy with each geographic/functional
area responsible for its own recruiting/hiring. The numbers are based on
a headquarters-authorized head count, which is incorporated into the
functional area budgets. There is some central screening through human
resources, which organizes recruiting visits to universities and then organ-
izes visits of potential job candidates to NAC. Individual departments then
get to decide on whom they want to hire. Once NAC places a new engineer
in a department, he or she is “subjected” to the whims and capabilities of
that particular department or manager—some may receive development
and mentoring, others may not.
NAC engineers are encouraged to move quickly from department to
department in order to “broaden their experience,” which means any
learning or mentoring tends to be rushed, chaotic, and unique to each
individual. However, by staying in the same job for several years, an engi-
neer risks being designated as deadwood: someone who is not going any-
where in the company. Those who need or want training may not get it
and develop slowly (if at all). Others who possess a great deal of initiative
“self train,” develop quickly, and often become do-it-my-way “cowboys”—
driving yet more variation into the PD system. NAC lacks a standardized
people development process; there is no consistent career path, and there
are no consistent criteria that determine evaluation and reward. What fol-
lows is an outline of NAC’s process for recruiting and hiring for product

165
Morgan Liker sec 3 3/2/06 11:27 AM Page 166

Section Three: People Subsystem

engineering and manufacturing engineering as well as some common

assumptions that many consumer-products companies make.

Recruiting/Hiring at NAC Product Engineering

To fill its product engineering ranks NAC traditionally recruits from the
top U.S. universities, by participating in university-based recruiting
initiatives. Typically, a large group of the best engineering students apply
for positions at NAC. To be considered, applicants must have a bache-
lor’s degree in mechanical, electrical, or chemical engineering. Many
have master’s degrees. They must pass a series of interviews in both the
engineering and human resource departments. A successful applicant
is usually hired by, and placed directly into the functional specialty for
which he or she applied. Once on the job, new engineers are gener-
ally expected to become almost immediately productive and are turned
loose on development projects with little in the way of structured men-
toring. They learn in the “pressure cooker” environment of a new prod-
uct program in a “trial by fire” methodology that produces a wide range
of capabilities.

Hiring at NAC Manufacturing Engineering

To fill positions in manufacturing engineering, NAC follows similar prac-
tices to those outlined above. Although applicants are officially required to
have a bachelor’s degree in an engineering discipline, NAC will waive this
requirement in lieu of experience. The manufacturing engineering group
does participate in some recruiting activities although NAC usually hires
people individually. The interview process takes place with both a manu-
facturing engineering manager and a human resources representative. The
hiring process is not particularly rigorous, but NAC gives heavy preference
to current NAC employees, transferring them into the department from
other NAC activities (e.g. from assembly plants or stamping plants). Just
as with product development, manufacturing engineering departments
take responsibility for training new recruits and there is little standard
protocol for this.
From the perspective of lean thinking, NAC’s recruiting/hiring process
is flawed and does not lend itself to creating a high-performance product
development system. The company makes three assumptions that are
detrimental to this process:

166
Morgan Liker sec 3 3/2/06 11:27 AM Page 167

Develop Towering Technical Competence in All Engineers

1. Engineers are professionally trained in college. By hiring top engi-

neers from top engineering schools, NAC believes it is getting
professionally-trained engineers and that the engineers have
learned the foundations of professional engineering and can be
productive immediately.
2. Each department is capable of developing its own engineers. Leaving
the development of engineers to each functional department is
perhaps the most dysfunctional assumption. In discussions with
company managers involved in recruiting/hiring, the authors dis-
covered that the prevailing attitude is “we are professionals so we
can develop professional engineers effectively.” Real-life experience
strongly suggests otherwise. What’s more, without a common
beginning or company-grounded initiation process, engineers
often develop more loyalty to their individual departments than
the company as a whole.
3. Manufacturing engineers do not require as rigorous technical and
engineering training as product development engineers do. This
reflects the bias of NAC toward product engineering as higher
status “real engineering.” There seems to be a belief that manu-
facturing engineering is somehow less professional and is dirty
work for the plant folks who do not need or have the applied
math and science disciplines required for more challenging
product development.

Training and Development at NAC

Employee development at NAC seems to revolve around breadth of expe-
rience. Almost as soon as they are hired, new engineers are told that broad
experience is important to career success. The prevalent belief is that any
one who stays in a job for more than a couple of years is not going to
advance. Although there is certainly a significant opportunity for on-the-
job training (OJT) at NAC, there is a lack of structure to the OJT process
and mentoring and teaching are not rewarded behaviors for supervisors.
Consequently there is little incentive for supervisors to develop new engi-
neers. So while there are engineering supervisors who take great care in
developing new talent they tend to be rare and their methods unique.
Most formal training at NAC is online and often approached with a “check
the box” mentality. For example, a series of classes is required for all NAC
product engineering personnel. However, many of the engineers feel that

167
Morgan Liker sec 3 3/2/06 11:27 AM Page 168

Section Three: People Subsystem

the classroom training is essentially irrelevant and has little to do with how
they do their jobs each day. Some of the training is considered valuable but
does not change the way work gets done and engineers have expressed a
desire for management to make some change in daily operations to reflect
things that are learned in the classroom.
There is certainly a good deal of mentoring at NAC. However, it is typ-
ically not technical in nature, designed to grow proven technical skill sets.
Much of the mentoring that we were told about was primarily about devel-
oping a career, focusing, for example, on how best to navigate the poten-
tially hazardous political waters of the corporation. Though career-path
development at NAC is often discussed, none of the people the authors
interviewed could identify a particular career path for their respective
functional specialty. Furthermore, they stated that people move around to
different functions far too often to develop deep knowledge of any partic-
ular engineering discipline. Product engineers in particular are often
moved into a new specialization before they have developed real compe-
tence in their current position.
Even in manufacturing engineering, where people do tend to stay in
one place longer, there is still no prescribed career path for developing spe-
cific technical skills. One of the reasons for this is because much of the core
manufacturing engineering takes place outside of NAC. Manufacturing
engineering management must rely on what an engineer has brought to the
job from his or her formal education, previous experience, or what they
may have learned from suppliers. Without a valued and structured men-
toring system and career path, NAC struggles to pass on standardized prac-
tices and tools to new engineers. This leads to a wide variation in the skills
possessed by each engineer; some engineers are excellent, some of the best
in the industry, while others are nearly incompetent, a situation that clearly
contributes to high-task variation in the NAC process and detracts from
NAC’s ability to predict outcomes, plan, and standardize accurately. As
noted in Chapter 5, high-task variation alone leads to queues and long lead
times. An inability to plan and predict clearly exacerbates these problems.

Developing People at Toyota

At this point, the reader should clearly understand that creating a lean PD
system entails not only adopting lean tools and a commitment to making
the organization lean but also a change of philosophy about the way things
get done. This is exemplified by the rigor with which Toyota selects and

168
Morgan Liker sec 3 3/2/06 11:27 AM Page 169

Develop Towering Technical Competence in All Engineers

develops both product development and production engineers, using both

OJT and mentoring in a fairly structured methodology. Right from the
start, Toyota gives a high priority to the nurturing and development of
engineering talent. In fact, people development at Toyota seems to be just
as important as product development. Toyota managers are trained to be
teachers and see every engineering project as an opportunity for develop-
ing its engineers. Developing people is fundamental to the manager’s job.
All managers view the performance of their teams as a direct reflection of
their own ability. It is personal.

Hiring at Toyota
In Japan, a position with Toyota is highly coveted, and the company’s hiring
process is notoriously rigorous (note that it was not always like this and
Toyota early on struggled to get good talent). Applicants from the best uni-
versities, such as Tokyo and Kyoto, far outstrip the available positions. Hir-
ing is centralized, and engineers are typically hired in large groups that form
a sort of freshman class each year. Classes are typically quite large and out of
a group of 300 new hires, the distribution of educational level is approxi-
mately as follows: 2 Ph.D.s, 198 master’s degrees, and 100 bachelor’s degrees,
all in an engineering discipline. At the time of hiring, new engineers are not
certain where they will end up. Although Toyota will certainly utilize their
respective specialties, the engineering organization in which they work is
determined as they move through the initial segment of the career path.
Toyota’s new engineering hires graduate at the top of their class in
grades, but that is not the only criteria considered during the hiring
process. Each engineering applicant goes through a series of intensive
interviews designed to provide a comprehensive look at personal charac-
teristics that determine whether a prospective hire will fit within the
Toyota culture. Each candidate is thoroughly examined, and sources of
information include professors who have a relationship with Toyota as
well as current Toyota engineers. In fact, some recent graduates employed
by Toyota as engineers are sent back to their universities to host recruiting
parties in order to learn about applicants at many levels. Listed below are
some key characteristics they look for in a new hire:

• Love of autos and technical work

• Technical capability
• Creative problem-solving ability (thinking outside the box)

169
Morgan Liker sec 3 3/2/06 11:27 AM Page 170

Section Three: People Subsystem

• Teamwork (nemawashi, cooperate, share information)

• Ability to “grasp situation” quickly, thoroughly, and at a detailed
level (what to look for, questions to ask, know what you need
to know)
• Ability to communicate a situation succinctly
• Discipline to work consistently to a time schedule
• Motivation to work to targets
• Dedication to craft and company (e.g., willingness to work hours
needed to get job done)

Training and Development at Toyota

The engineering career path at Toyota is commonly referred to as the “Toyota
T.” It is an inverted (upside down) “T” with the top of the “T” symbolizing
that an engineering career begins with a short time that is broad in scope and
the base of the “T” symbolizing that it evolves over a long time within a spe-
cific technical discipline. The typical freshman class will undergo about one
month of general training, including education on quality and orientation
on the history and traditions of Toyota. Next new hires will spend time doing
the manual work of building cars for about three to four months in a manu-
facturing plant. These engineers may then spend another two to three
months at dealerships where they may be required to sell vehicles door to
door. Toyota designed this training process to ensure that engineers under-
stand the car business from Toyota’s perspective as well as from the cus-
tomer’s perspective.
This common training regimen among each freshman class of engi-
neers also gives new employees a sense of common beginnings, an impor-
tant aspect of building a culture and instilling loyalty that lasts throughout
a career. The message is clear: Each employee works for Toyota not for a
specific function. During this orientation time, Toyota is constantly eval-
uating the new engineers to determine their best fit in the organization.

Training and Development at Toyota Body and

Structures Engineering
When a new engineer comes to the body and structures engineering
group, the department typically pairs him or her with a mentor (one of
the senior engineers). Each new engineer is also assigned an improvement
project, known as the “freshman project.” This is usually a small but chal-

170
Morgan Liker sec 3 3/2/06 11:27 AM Page 171

Develop Towering Technical Competence in All Engineers

lenging technical project (such as reducing the required number of wiring

clip holes in a part). The purpose of this exercise is to have the new engi-
neer use basic engineering tools and seek out others to accomplish the
task, a process that helps to teach about the Toyota way of engineering.
For instance, one thing Toyota mentors emphasize is that an engineer
should never just bring the answer to the boss. It is more important that
new engineers consider the impact of several potential solutions and
present these in decision matrix form or A3, thereby demonstrating that
they have thoroughly considered the full situation. The freshman project
continues the socialization process, further aligning the new engineer to
the Toyota Way. Everything is new and the freshman project is challeng-
ing, a markedly different experience from university education and the
general orientation of the first year at Toyota. For many new engineers,
this experience can be quite emotional; it often makes such a strong
impression that senior managers can still relate vivid details about their
own freshman projects.
After new engineers complete their four- to nine-month freshman
projects, Toyota assigns them to engineering specialties within the body
and structures engineering organization. The engineers know that they
must undergo a somewhat intensive two-tier OJT period (briefly
described in Chapter 6). Engineers who successfully complete this OJT
training earn a first-level engineering rank. The first tier, lasting about
two years, is heads-down work at the computer-aided-design (CAD) ter-
minal under the direction of a senior engineer (engineers must learn to
do their own CAD work). After this initial first tier period, a body engi-
neer can spend several more years (three to six) within this same techni-
cal specialty working on design of a few related body parts. Only then will
management recognize this individual as an independently functioning
lead engineer.
During the approximately eight-year development period, the man-
ager continues mentoring and interviewing the engineer three to four
times per year. The product of these interviews is not merely a manager’s
subjective opinion about job performance rating against peer perform-
ance. Instead, the mentor/manager uses Toyota’s standardized skill set
expectations to measure the engineer’s technical progress and adherence
to company processes and standard methodology. This information is
supplemented by input from a variety of people the engineer has worked
with. From these criteria, the manager outlines areas of improvement and
develops an action plan that is measured in the next interview. Toyota also

171
Morgan Liker sec 3 3/2/06 11:27 AM Page 172

Section Three: People Subsystem

employs a hoshin kanri (policy deployment) process (discussed in Chapter

15), so that each engineer has specific objectives that he or she is being
measured against. After being with the company 10 to 12 years, the engi-
neer becomes eligible for promotion to a first-level management position.

Training and Development at Production Engineering

Like their counterparts in body engineering, new members of the produc-
tion engineering organization come from the same freshman class and
receive the same basic training in the first year. New production engineers
are also assigned a mentor and a freshman project in the second year. In
production engineering, this project might be something like decreasing
the number of net surfaces or clamps required on a particular part fixture.
In the stamping engineering group (part of product engineering), a new
engineer’s career path typically proceeds as follows:
• Four to six months in a freshman project
• Three to four years in die design
• Two to three years in processing and binder development
• Two to three years in the tryout and construction at Tool and Die
Unlike other companies (including NAC), Toyota does not have union
constraints dictating who can do what, so Toyota engineers are free to par-
ticipate fully in tryout and construction activities at tool and die. They also
spend considerable time in the stamping plants as a matter of completing
their tasks. Here too, new engineers are interviewed three times per year
and evaluated against skills matrices.
After completing this development or apprenticeship period (about
eight years), stamping engineers may be invited to join the simultaneous
engineering organization, go to a stamping plant, or return to one of the
stamping functional specialties such as die design. These assignments or
deployments are planned with their managers, and the engineers can suggest
their preferences. After several more years within their discipline of choice,
they will be eligible for promotion to a first-tier management position.
For many companies considering lean PD, this significant investment
in employees may seem unrealistic, particularly in Western companies
with a high turnover rate of engineers. What these companies fail to
appreciate is that this process of a lean PD system develops knowledgeable
engineers while nurturing a vibrant lean culture. You can start this process
by using two elements of lean:

172
Morgan Liker sec 3 3/2/06 11:27 AM Page 173

Develop Towering Technical Competence in All Engineers

1. Standardization: By having all departments use standard skill

expectations to develop and measure new engineers, you are con-
tinually reinforcing and/or improving this skill set. Unlike many
companies that have employees review standards once in a while
in an online training class, you would actually apply standardiza-
tion criteria daily in determining the competence of your workers.
To appreciate this lean element’s importance, remember that stan-
dardization helps reduce variability in the PD system and that
standardization leads to flexibility.
2. Learning Organization: Being a leader in a lean organization also
means being a teacher. Within a learning organization, a primary
responsibility for managers is technical mentoring of engineers.
This mentoring process also prepares a whole new generation
of managers.

To augment the structured development process Toyota has a number

of mechanisms designed for both organizational and individual learning
and development. Toyota has repeatedly demonstrated a passion for learn-
ing and consistently builds opportunities to learn into the very foundation
of their development process. We will have a detailed discussion of how
Toyota builds learning and continuous improvement into their process to
create a lean learning system in Chapter 11. There are also important
implications for how these mechanisms support the development of tow-
ering technical competence in individual engineers.

Genchi Genbutsu Engineering

The phrase genchi genbutsu literally means the actual part, the actual
place, but for Toyota, it implies going to see the actual situation first hand
to understand deeply the current reality. It is one of the four core princi-
ples of Toyota’s internal Toyota Way document and is manifested
throughout the company (Liker, 2004). This hands-on approach to engi-
neering is critical to a lean PD system and fundamental to developing new
engineers. As Kiichiro Toyoda, founder of Toyota Motor Company,
observes, “One can never trust an engineer who does not have to wash his
hands before he eats dinner.”
In this day of high-tech engineering, it is very tempting for engineers
to divide their time equally between conference rooms and their cubicles.
Moreover, in an environment that is increasingly more inclined toward

173
Morgan Liker sec 3 3/2/06 11:27 AM Page 174

Section Three: People Subsystem

overseas outsourcing and “virtual engineering,” engineers may never get

close to the product they are working on. But as Kelly Johnson, the
famous head of Lockheed’s legendary Skunk Works has commented, “An
engineer should never be more than a stones throw away from the physi-
cal product” (Rich & Janos, 1994). This comment clearly reflects the spirit
of genchi genbutsu. Examples of this philosophy in action include engi-
neers spending preprogram time at dealerships, working on competitor
teardowns, or personally fitting parts on prototypes. The CE’s team also
meets with customers, test drives vehicles, and evaluates its own and
competitors’ quality data. The main point of genchi genbutsu is that you
can only develop quality products by having your engineers intellectually,
physically, and emotionally connected to those products. The next few
paragraphs describe some of the ways Toyota applies genchi genbutsu to
product development.

Competitor Teardowns
In tearing down competitor’s target products, Toyota identifies target vehi-
cles and specific components as “best” in the new vehicle’s class. The engi-
neers then reduce these vehicles to individual parts and subject them to a
competitive evaluation for quality, performance, and ease of manufacture.
They mount and mark up the disassembled parts on a teardown board
alongside Toyota’s current model parts, displayed for all participants
(including suppliers) to examine. In addition, they circulate the analysis
reports among all participating functional groups for evaluation and
comment. They now create these reports utilizing V-Comm technology, a
virtual A3-type report that includes digital pictures, problem description,
countermeasures and current product design geometry.

Prototype Builds
Body engineers practice genchi genbutsu during the prototype phase by
participating in both virtual and physical prototype builds. They visit
parts making sources and attend daily wrap-up meetings at the build site,
often fitting and assembling parts that give them a true feel for what they
have designed. Prototype phase is a time of intensive learning for the body
engineer, and being at the source is invaluable. In addition to working with
the SEs, body engineers work with the prototype specialists, Quality
Assurance (QA) specialists, and production-assembly team leaders, who

174
Morgan Liker sec 3 3/2/06 11:27 AM Page 175

Develop Towering Technical Competence in All Engineers

participate in the prototype builds. This phase, characterized by intense

interaction, generates many engineering changes.
When engineering changes are deemed necessary during the proto-
type phase, they are often made on the spot where issues are identified.
This is often at the build or parts making sources. Engineers mark up and
sign sketches or drawings that serve as authorization for the changes to be
incorporated. If changes cannot be made on the spot, body engineers must
respond within 48 hours with new or additional data. This keeps the
process moving forward while technicians are updating the actual product
database. Throughout this process, Toyota achieves a performance advan-
tage by using mutually supportive elements. This quick-change system
requires experienced, knowledgeable engineers who understand the full
implications of the decisions they make. They use tools such as checklists
and decision matrices to reach rapid but quality decisions; moreover, the
process allows engineers to work closely with the prototype build and
parts fabricators and stay close to the product.

Daily Build Wrap-up Meetings

Another problem-solving and learning mechanism Toyota uses during its
prototype phase is daily build wrap-up meetings. These are attended by
the CE (or his staff), body engineers, prototype technicians, production
team leaders, production engineers, and suppliers at the end of each day.
Participants candidly discuss issues encountered during that day’s assem-
bly or incoming part inspection. The meetings are held right at the build
site where participants can witness first hand the quality, cost, or produc-
tivity/ergonomic issue, and where they record issues/countermeasures and
give new assignments on the spot. Here again, it is easy to see the spirit of
genchi genbutsu personified by body engineers who work shoulder to
shoulder with production team leaders and prototype technicians who
crawl around the prototype vehicle, fitting panels and examining the
results of their designs within the body system.

Your Lean PD System Must Develop People

Companies trying to adapt a lean PD system become particularly frus-
trated and concerned when they learn about the depth of knowledge and
experience of Toyota’s engineers and the number of years Toyota takes to
recruit, train, and develop them. Because it requires a philosophical mind

175
Morgan Liker sec 3 3/2/06 11:27 AM Page 176

Section Three: People Subsystem

shift, this may be the most challenging aspect of the lean PD process for
companies to replicate. And it can take much longer than most companies
want to dedicate to implementing a lean system. But the philosophy
behind this is the backbone of the lean PD system, supporting many of the
LPDS principles in this book. Below are some of the reasons that Toyota’s
approach is culturally and historically unique, reasons that incidentally
illustrate how one lean principle supports another.
• In the 1930s, Toyota’s culture evolved out of a small company men-
tality where its engineers had to do almost everything hands-on
from the ground up.
• Over time, this necessity created the cultural value of genchi gen-
butsu, the Toyota approach to solving problems.
• This behavior reinforced the Toyota belief in learning by doing.
• To excel at this, Toyota placed value on developing engineers with
detail and deep expertise in focused areas.
• This value further supported the need for developing stable and
standardized processes so Toyota engineers could work off detailed
engineering checklists that reflect on-going learning.
• Because of the stability and homogeneity of past generations of
Toyota engineers (homogeneity in terms of the strong culture of
Toyota), a very similar set of expectations, values, and beliefs
among leaders who were doing the mentoring evolved. The engi-
neer truly learns the “Toyota Way” of engineering, regardless of
who is doing the teaching.
• This reinforced Toyota’s learning culture, which makes experi-
menting by trying things an everyday event and where mistakes are
not punished.
• This “open attitude” encourages the spirit of innovation, putting
engineers into challenging situations starting with the freshman
project.
Of course, no company can replicate Toyota’s approach or culture, but
every company can adapt the lean thinking to begin to Develop Towering
Technical Competence in All Engineers. The first step is to reinforce the
premise that it is “people” that sustain the system and the more excellent
the people, the more effective the system. And people need to be developed,
not simply recruited or purchased. (Chapter 17 returns to this issue of
building the culture and towering technical competence required for a
lean PD system.) The next LPDS principle extends this behavior by

176
Morgan Liker sec 3 3/2/06 11:27 AM Page 177

Develop Towering Technical Competence in All Engineers

emphasizing that companies should manage and nurture their suppliers in

much the same way they do manufacturing and engineering resources.

LPDS Basics for Principle Seven

Develop towering technical competence in all engineers

People provide the energy and intelligence for any lean system, and
product development is a particularly technical talent-driven enter-
prise. Consequently, LPDS requires that you focus significant time
and energy in developing towering technical competence for all
engineers. Start with a rigorous selection process, and then estab-
lish a technical mentoring system with regular evaluations that
base assessment on demonstrated technical competence. The
result will be significantly reduced task variation, powerful supplier
management capability, and a level of professional trust that will
enable lean product development speed. Toyota’s culture honors
technical capability and has created a technical meritocracy. This
culture perpetuates technical excellence through mentoring, strate-
gic assignments, and rigorous evaluations based on performance.
Anyone who wants to create LPDS has to be prepared to make a
significant investment in people selection and development.

177
Morgan Liker sec 3 3/2/06 11:27 AM Page 178
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 179

CHAPTER 10

Fully Integrate Suppliers into the

Product Development System
Achievement of business performance by the parent company
through bullying suppliers is totally alien to the spirit
of the Toyota Production System.
TAIICHI OHNO

DURING THE LATE 1990S, two U.S. auto companies came to the conclusion
that their true core competencies were designing, assembling, and market-
ing cars. They believed they could style vehicles, purchase parts or “mod-
ules,” bolt them together, and then sell and finance the car while parts
suppliers competed for the components business. The functional idea
behind this strategy was that outside suppliers would engineer most of the
vehicle and manufacture virtually the entire car while the auto companies
would do the final assembly. Even the engine was up for grabs. If someone
else could make a quality engine and sell it cheaper, then more power to
them. According to this model, megasuppliers would assume complete
responsibility not only for manufacturing and basic engineering but also
for the entire development of critical vehicle subsystems: seats, interiors,
brakes, axles, and exterior sheet metal. The philosophical idea behind the
strategy was to ask suppliers to take more responsibility, make greater tech-
nical contributions, and share risks “like they do in Japan.” Naturally, this
model had some attractive features for U.S. automakers to consider:

• Over time, they could shed a huge amount of fixed assets for man-
ufacturing and make tremendous cuts in investment costs for engi-
neering facilities, engineers, tooling, and equipment by pushing
these onto suppliers.
• Suppliers were typically more cost effective than U.S. auto compa-
nies, due to more flexible work rules and lower labor rates than the
union-dominated auto plants.
• Suppliers could develop greater specialized expertise, focusing only
on those things they engineered and built.

179
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 180

Section Three: People Subsystem

• U.S. auto companies could use hardball price-negotiation tactics to

force price reductions or give the business to another supplier.
• New web-enabled technologies for reverse online auctions would
allow real-time pricing competitions between suppliers to achieve
true world-class costs.

In short, this was a simple way for a company to reduce costs and at
the same time become more agile and quicker—wonderful assets with
which to enter the twenty-first century. When they compared themselves
with Japanese companies, U.S. auto companies were making more than 50
percent of the components for any given vehicle while Japanese companies
were outsourcing over 70 percent of their vehicle content. On surface, it
made great sense to adopt the Toyota supplier-relationship model, but
below the surface the plan was missing a few critical points.

A Part Is Not a Part, and A Supplier Is Not a Supplier

An automobile is a complex system. The way parts interact matters—even
tires, mufflers, and glove compartments must be engineered to fit a par-
ticular vehicle. You must develop tools and dies, set up production lines,
and manufacture the product to specification on time, with high quality
every time. There is nothing trivial about any part or any of these steps.
When customers buy cars, they do not care who makes the engine,
radio, seat, carpet, etc. They want and expect reliable quality and hold the
automaker totally accountable for anything that is not up to their expecta-
tions. Toyota recognizes this and makes sure that every car part reflects
Toyota quality. To achieve this, they make every supplier an extension of
Toyota’s PD process and lean logistics chain. Toyota delegates tasks to sup-
pliers, but ultimately, it is Toyota that is fully responsible and fully
accountable for all subsystems as well as the final product. Outsourcing
does not absolve Toyota of responsibility or accountability.
General Motors, Ford, and DaimlerChrysler have, at different times,
made genuine attempts to learn how to partner with suppliers by emulat-
ing the Toyota model. They have largely failed in these efforts because they
have not grasped the concept of true partnering. When the market gets
tough and there are serious earnings pressures, they have been less than
forthright with suppliers, vacillating between public statements of com-
mitment to partnership and trust and then unilaterally cutting supplier
prices after signing contracts. They have even cut off suppliers in the mid-

180
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 181

Fully Integrate Suppliers into the Product Development System

dle of a contract, resourcing it to a lower bidder. Now and again, they have
done so while using the designs of the first supplier. After a time, this
behavior backfires and those who practice it earn a reputation as an
untrustworthy business partner.
Surveys of U.S. auto suppliers consistently rate their supplier relation-
ship with Toyota near the top. For example, a 2005 survey by John Henke’s
Planning Perspectives ranked Toyota number one on an index based on 17
categories from trust to perceived opportunity, followed by Honda and
Nissan. Chrysler, Ford, and GM ranked fourth, fifth, and sixth respectively
(Sherefkin and Cantwell, 2003). Toyota had its best showing scoring 415
out of 500 (32 percent better than 2002) while GM was at an all time low
with a score of 114 out of 500 (29 percent worse than 2002). A survey con-
ducted by J.D. Power & Associates found that Nissan, Toyota, and BMW
were the best North American automakers in promoting supplier innova-
tion (Automotive News, Feb. 24, 2003). Honda and Mercedes also finished
above average in fostering innovation whereas the Chrysler group, Ford,
and General Motors all were rated below average. There are obvious rea-
sons why suppliers rank Toyota so highly:
• Works with new or struggling suppliers to get up to speed.
• Makes commitments to suppliers early in the product development
process and makes good on promises.
• Constructs contracts that are simple and for the life of the
vehicle model.
• Is the best at balancing a focus on cost with a focus on quality
compared to the other automakers.
• Honors the contracts—does not renege on them to save cost.
• Treats suppliers respectfully and respects the integrity of intellec-
tual property.
• Sets aggressive price reduction targets, but works with suppliers to
achieve the targets.
This does not mean “easy street” for suppliers. The suppliers the
authors interviewed consistently rate Toyota as their most demanding cus-
tomer—demanding in timelineness, innovation, quality, and cost reduc-
tion. For example, when Toyota discovered the prices it was paying
suppliers for many key parts were above the lowest prices competitors paid
globally, it issued a new target for all key suppliers as part of a program
designated CCC21. The new program asked suppliers to reduce prices by
30 percent for the next model line; typically this would cover a period of

181
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 182

Section Three: People Subsystem

about three years. Instead of rebelling, suppliers agreed to the new terms.
Why? Because Toyota agreed to work with them on cost reduction, even
offering to help suppliers change the product design through value engi-
neering. Because it responds to supplier concerns with integrity and capa-
bility, Toyota has established a great level of professional trust with its
suppliers, closely paralleling the trust that Toyota engineers have estab-
lished with each other.
As the 13 principles of our LPDS model show, Toyota has developed
a sophisticated system that encompasses people, processes, and tools and
technology and extends to all partners in the lean enterprise. As Toyota
partners, suppliers must follow the same or equivalent processes for
design and manufacture. Moreover, once accepted into the Toyota family,
they are taught to be effective partners. Cost reduction is one outcome of
the selection/teaching process. Toyota is a master at cost reduction inter-
nally and expects suppliers to master this discipline as well. In a lean PD
system, you cannot “bully suppliers” and squeeze the life out of them for
a price reduction. The bottom line, though always important, does not
drive supplier relations. Developing excellent processes and quality prod-
ucts is the goal, and to achieve this, companies need to extend the learn-
ing enterprise and truly partner with their suppliers.

The Power of the Keiretsu

In the 1980s, the authors visited Japan to learn about the highly publicized
keiretsu (set of interlocking corporations). In the keiretsu model, a broad
set of different types of companies cooperate in business and hold equity
in each other. Automakers hold equity in a close-knit group of affiliated
suppliers that are essentially part of the company. Under this arrangement,
suppliers were told which companies they could do business with; because
the affiliated automakers controlled this, they were able to trust the sup-
pliers with sensitive information, the kind of information generally kept
secret and guarded even within individual companies. What the authors
discovered in Japan, however, was that the supply chain in this model
looked more like a hierarchy of interlocking corporations rather than a
chain. A more accurate description of keiretsu then is that it is a hierarchi-
cal organization that does a great deal of parts outsourcing to small num-
bers of closely-knit, large volume suppliers who are given long-term
contracts and are at different levels of the hierarchy (Kamath and Liker,
1994). There is competition among suppliers, but typically two or three

182
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 183

Fully Integrate Suppliers into the Product Development System

suppliers make a given type of part and have 100 percent of the business
for a given vehicle program. Toyota selects these suppliers early in the
product development program, guarantees the business, and incorporates
them as part of the extended product development team.

Are All Suppliers Created Equal?

Toyota uses a tier structure for its suppliers, similar to a hierarchical orga-
nizational chart. It deals primarily with the first tier, the largest suppliers
who provide complete subsystems directly to Toyota. That tier manages
the second tier of component suppliers that ship parts to the first-tier
plants1 and so on. This makes the management task more efficient because
Toyota does not have to communicate directly with thousands of suppli-
ers. To further manage the keirutsu, Japanese suppliers have four major
roles for Toyota’s different vehicle programs, each of which are discussed
below (see Figure 10-1) (Kamath and Liker, 1994).2
1. Partner. This is the highest level, which includes companies like
Denso, Araco, and Aisin. These companies have grown to be
comparable in size to Toyota and are technically autonomous.
They can design their own subsystems and components and have
complete prototype and test capabilities. They are involved in the
earliest concept stages at Toyota, and they often develop sketches
before Toyota has created a contract or even developed formal
specifications for the subsystem. Partners have a large number of
“guest engineers” housed in Toyota’s design offices near Toyota
engineers for 2- to 3-year stays. These engineers help augment
Toyota’s engineering workforce without increasing Toyota’s payroll;
they collaborate on the design and solve design problems. While
the detailed design goes on back at the supplier’s engineering
organization, the guest engineers serve as key liaisons. By cycling
engineers through Toyota as guest engineers, suppliers are also
training their workforce in Toyota’s product development system.

1. There are exceptions to this. For example, for some basic raw materials like steel,
Toyota uses its purchasing leverage to deal directly with the suppliers and get a better
price based on its large volume and deals with these suppliers directly though they are
not first tier.
2. The details of these roles were first put together by Durward Sobek (Montana State
University) based on a research trip to Japan.

183
 Contractual Consultative Mature Partner

Design responsibility Customer Joint design Supplier Supplier

Product complexity Simple parts Simple assembly Complex assembly Complete

subsystem
Morgan Liker sec 3_ch 10–12

Customer specifications Complete design Detailed Critical Concept

provided or supplier specifications specifications
3/2/06

catalogue

Supplier influence None Present Negotiate Collaborate

on specifications capabilities

184
11:42 AM

Timing of supplier Prototype Post-concept Concept Preconcept

involvement

Component testing Customer Supplier input Joint Supplier

Page 184

responsibility
Section Three: People Subsystem

Supplier development Little Significant Strong Self-contained

capabilities

Source: R. Kamath and J. Liker, “A Second Look at Japanese Product Development,” Harvard Business Review, Nov.–Dec., 1994: 154–173

Figure 10-1. Maturity of Suppliers and Roles in Product Development

Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 185

Fully Integrate Suppliers into the Product Development System

There are only a few suppliers that fit the image of a full partner,
and even these suppliers must continually prove themselves.
2. Mature. A majority of first-tier suppliers are just a half step below
the partner level. They have matured to the point that they have
very strong engineering and manufacturing capabilities, but they
are a bit less autonomous and depend more on direction from
Toyota than partners. Their products are not quite as complex,
and they rely on specifications from Toyota. It is here that Toyota’s
set-based approach to setting specifications differs from the
approach used in U.S. auto companies. Whereas U.S. companies
set detailed and rigid engineering specifications for suppliers,
Toyota provides less restrictive specifications and views them as
targets (Ward et al, 1995). When delivering these somewhat vague
specifications to suppliers, Toyota often uses the word gurai, the
Japanese equivalent of “about.” One of the difficulties Toyota has
had working on engineering tasks with U.S. suppliers is that these
suppliers need explicit instructions, including detailed specifica-
tions and tolerances before they can act. Worse yet, if Toyota does
not specifically ask the supplier for something, it is not given. This
has been a frustrating experience, particularly for Toyota’s Japan-
ese engineers who are used to working with Japanese suppliers,
who often anticipate their needs. Mature suppliers do not wait to
be asked. They take initiative and suggest. Toyota wants the suppli-
ers to think for themselves, challenge the requirements, and provide
value-added ideas to the process.
3. Consultative. These suppliers make commodities like batteries and
tires, but Toyota also taps into their expertise, getting ideas for
products still being decided upon. Consultative suppliers influ-
ence the specifications by recommending their own innovations,
for example, a new tire with new characteristics. These products
are generally not technically complex, and there is less intense
engineering collaboration with this supplier group except around
the prototype testing and launch stages.
4. Contractual. Toyota purchases nuts and bolts, brackets, and spark
plugs—parts that do not require a major partnership. In many
cases, Toyota simply specifies what it wants, picking from a cata-
logue or engineers a special component, if needed, and then
selects a supplier. First-tier suppliers have a host of these com-
modity suppliers, but even with these contractual suppliers,

185
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 186

Section Three: People Subsystem

Toyota closely monitors quality, cost, and delivery. Toyota seeks

out contractual suppliers that deliver just-in-time shipments,
parts packaged in the right quantity and right container, and only
the best quality. These suppliers are also expected to work dili-
gently on cost reduction.

Toyota teaches the Toyota Production System to suppliers at all levels,

chooses its suppliers carefully, and is cautious about which suppliers it lets
into its extended family and to what degree it becomes intertwined with its
partners.

Selecting and Developing Toyota Suppliers to Partner: U.S.

Supplier Tire Example
The core keiretsu partners of Toyota in Japan have been part of the com-
pany’s extended enterprise for decades, so it is difficult for any new
suppliers to break into the network unless they have patented technology
that Toyota wants. Outside of Japan, in the early stages of launching
production, however, it is a different story: Toyota works to grow its local
supply networks.
One example of this is the tires developed by suppliers working with
the Toyota Technical Center in Ann Arbor, Michigan, for North American
cars. A tire seems to be a pretty simple part of a vehicle that can be easily
sourced just on the basis of price listings in a catalogue. Not according to
Toyota. The tire is an intricate part of the chassis and a key to controlling
noise, the feel of the ride, handling, safety, and even fuel economy. When
the chief engineer specifies his or her performance expectations for a vehi-
cle, e.g., handling and ride comfort, chassis engineers tweak the suspen-
sion and the tires to meet these objectives. The stopping distance is a
function of the tires and the brakes. If in optimizing ride comfort and han-
dling, the tires cannot withstand frequent stopping, the chassis engineer
must make up for it in the brake system. Toyota works through a detailed
process to specify, solicit, and qualify tires that are suitable for each vehi-
cle’s unique properties and tire specifications. What this means is that a
tire supplier has to take into consideration many technical issues, a lengthy
process that requires a strong supplier relationship.
The relationship between suppliers and Toyota’s expectations of the
supplier is very complex, even when it involves only one specific car com-
ponent, such as a tire. Because Toyota deals with only two or three suppli-

186
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 187

Fully Integrate Suppliers into the Product Development System

ers in a region, the company does not frequently bring on a new supplier
unless there is an unfilled need or an opening. A new supplier gets a very
small amount of business and is tested rigorously before getting any more
business. One aspect of this testing involves investing in the development
process as described below.

1. Tire R&D. Typically, tire development starts with the supplier

who is continually doing R&D to develop new tires. The supplier
must consider appearance, competition, performance require-
ments of the market, manufacturing capabilities, cost, govern-
ment regulations, and where it wants to market (e.g., to
automakers or just to aftermarket). The supplier develops a basic
tire profile by looking at different tire compounds—down to the
trees the rubber will come from (e.g., rubber trees in Vietnam are
different from those in India) and considering the tread pattern
(affects durability, wet and dry traction, hydroplaning, noise, cor-
nering). Variables in tire construction (e.g., number of belts and
of angles and materials of belts) are also thoroughly examined.
The supplier then performs computer simulations and physical
tests to assess other concerns (e.g., strain on tire, how much
movement tire elements get under pressure).
2. Setting requirement for the tire. A Toyota Motor Company tire
committee sets Toyota-wide standards for size, rolling resistance,
etc., and the chief engineer sets the tire requirements for the
development of a particular vehicle. These include objective
requirements (e.g., stopping distance) and subjective requirements
(e.g., the turning ability and handling). Because Toyota is commit-
ted to becoming a “green company,” the CE also considers fuel
efficiency. Often the specifications are relative to the current
model or a competitive vehicle with better cornering and handling
or better road feel for the driver. Toyota engineers benchmark a
variety of tires to see how they meet these specifications, including
tires used on competitive vehicles. They will also consider tires
presented to them by their suppliers, sometimes on the basis of
new technology. Toyota tests the tires in existing vehicles, looks at
customer feedback from the dealer network, and considers data
from J.D. Powers, Consumer Reports, Car and Driver, and other
sources. The company also checks on current and pending gov-
ernment regulations.

187
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 188

Section Three: People Subsystem

3. Request for Design and Development Proposal (RDDP). Toyota runs

the specifications into the RDDP document, which is a formal
request given to a set of selected suppliers to codevelop and quote
on the tires. The document typically has at least four pages of
detailed specifications, presented in the order of importance and
based on a specific vehicle (e.g., 1999 Camry, AC, ABS, no sun-
roof, and four doors). The quantitative targets for such things as
mass, speed rating, inflation pressure, and rolling resistance are
numerical. They also provide subjective requirements in relation
to a control tire Toyota has tested. For each subjective dimension,
a chart shows where the control tire is (green dot), what the target
is (red dot), and if it is different from the control tire (for exam-
ple, better grip, less noise when it hits a bump on the road, cor-
nering). One column in the chart indicates who is responsible for
testing conformance. Toyota performs tests on an actual proto-
type, while the tire maker performs tests on specialized equip-
ment. There is also a comments column in the chart. Toyota also
gives the supplier a target price, and there is very little room for
negotiation.
4. Awarding the business to a supplier. Engineering works with pur-
chasing to select a suitable supplier or suppliers, always including
one more supplier than Toyota is planning to use. Assuming
Toyota needs two suppliers, three suppliers are invited to submit a
quote. Typically, these are suppliers that already have a proven
track record with Toyota. The selected suppliers are expected to
codevelop the tires with Toyota, using their own funding.
5. Reviewing and testing the prototype tires. Toyota expects the sup-
plier to develop two tire alternatives for the first prototype sub-
mission (1S). Sometimes this is a brand new tire, but most often,
it is a derivative of an existing tire with one or more modifica-
tions. (The supplier, for example, may change nothing more than
the tread pattern.) Toyota will answer questions, test tires at the
Toyota test track while under development, and work with the
supplier throughout the process. At 1S, engineers thoroughly eval-
uate the two tires by reviewing data from the supplier and on the
test track. Toyota will then select one of the tires, or ask for some
combination of the two tire alternatives, or ask for additional
improvements. If there are difficulties meeting the CE’s targets,
the chassis engineers consult with the CE. The CE determines if

188
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 189

Fully Integrate Suppliers into the Product Development System

the tire is “close enough” or whether the engineers need to con-

tinue working toward a solution.
The supplier then provides a single tire at the second prototype
stage (2S) for evaluation. The tire development proceeds in tan-
dem with the development of the overall vehicle prototypes, but
this does not necessarily occur in lockstep. However, the tires at
prototype stage 2S must meet vehicle requirements and be avail-
able on time for the final confirmation build of the vehicle prior
to launch. For initial development, Toyota works with the prior
year’s model; final development is done on a prototype of the
new vehicle.
Toyota conducts tests on its North American vehicles at the
Arizona proving grounds near Phoenix, which has test tracks
accurately simulating different road conditions, including exact
replicas of segments of I-94 in Detroit (based on measurements
from a typical day), and a highway outside Los Angeles. Dry
tests, wet tests, and tests on ice are all conducted. The testers
take the vehicle to the limit, for example, turning on severe
curves. Toyota measures actual stopping distance, and if the
tire does not meet the requirements, the supplier is asked to
make modifications.
6. Choosing the final supplier(s). After the 2S build, Toyota drops the
supplier that does not meet the performance requirements. If all
three meet the requirements, Toyota purchasing will consider
other factors when deciding which supplier to drop such as who is
the incumbent for this car model. Once Toyota selects the sup-
plier(s) it prefers, it continues to monitor quality and delivery per-
formance through the initial months of launch to make sure both
continue to meet Toyota standards.

Every new supplier must go through all these steps and make required
investments in the development process with no guaranteed return on
investment. New suppliers, when first chosen by Toyota, would generally
not get tire business for a major new model but might supply only the
spare tire for a lower volume vehicle. Typically, it takes a supplier several
programs and years of engineering effort to get enough business from
Toyota to start collecting on the initial investment. Nonetheless, the com-
petition to become a Toyota supplier shows that the relationship with
Toyota is highly prized.

189
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 190

Section Three: People Subsystem

Partnering with Suppliers: Who Gets What?

The tire example above shows Toyota’s rigorous process for developing
and selecting components and suppliers and is indicative of a lean com-
pany’s expectations of its suppliers. But how does this partner paradigm
compare with traditional models of automaker-supplier relationships?
There are, of course, some similarities, but the differences (presented
below) underscore why a lean approach within the relationship supports
design, manufacturing, and, ultimately, profitability.

Suppliers Work Closely with a Company: Mutually Beneficial

Long-term Relationships

Traditionally, U.S. suppliers have not worked closely with U.S. auto com-
panies in the development stage. For suppliers working with lean compa-
nies, this is imperative. They must not only learn how to deliver on
requirements during this stage but must also pay thorough attention to
various detailed requirements and offer alternative solutions.
Gotsu-gotsu is a Japanese term that refers to how a tire responds to a
low frequency, high impact bump. The driver or passenger feels this
impact in the lower back. Buru-buru is the tire’s reaction to a low fre-
quency, lower impact that the driver or passenger feels in the belly. When
Toyota engineers say, “There is too much gotsu-gotsu,” the suppliers gener-
ally understand what that means and how to respond. In Japan, this is
taken for granted. In the United States, suppliers need to learn these and
similar terms to participate effectively in Toyota’s product development.
Toyota uses a deliberate step-by-step approach to teach terminology and
requirements, developing suppliers slowly and steadily.
This gradual development approach can be frustrating for suppliers,
especially since Toyota requires them to invest in development and set up
manufacturing lines. When Toyota was developing one vehicle in North
America, for example, a new supplier developed reinforcement beams
over a two-year period. The supplier did a good job developing and was
awarded the contract for the vehicle in question but lost its bid for other
contracts that followed. Thus, the supplier’s development cost was a hefty
investment leading to a relatively small yield. Eventually, however, the
supplier’s standards improved to a level that matched Toyota standards;
more work was awarded and the supplier gained the stability of a long-
term partnership with Toyota. In another example, Toyota brought on a

190
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 191

Fully Integrate Suppliers into the Product Development System

new supplier to develop a new type of energy management system. The

material the supplier developed for regular injection molding worked
better than expanded foam that was used previously. Toyota, however,
spent four years analyzing and evaluating the new foam material and
energy management system before committing to a small contract.
Because this particular material had never been tried in a production
vehicle, Toyota waited until the supplier secured a contract with another
customer to prove it was viable in actual production before finally com-
mitting to a contract.
New U.S. suppliers seldom meet Toyota’s expectations at first, and it
can be challenging for both parties to work together. For example, for
body fit and finish, automakers develop tolerances for individual stamp-
ings based on stacking analysis. This requires data from the supplier that
shows what tolerances it can hold. One young Toyota engineer received
tolerance data for stamped parts from a supplier, but the means and vari-
ances were the same for many different dimensions. Toyota had requested
coordinate measurement data for 1,000 parts. The engineer knew that
what he was looking at could not be right and was convinced that the sup-
plier must have fudged the data. He went to the supplier’s plant and helped
revamp the data collection system. The accurate data showed that the
plant had not met the tolerance criteria, so the supplier had to do a thor-
ough 5-why analysis to figure out the source of the variance and correct it.
The Toyota design engineer developed the supplier by teaching the proper
way to collect accurate data, analyze it, and develop corrective actions to
improve quality in manufacturing. In the traditional supplier-company
relationship, this seldom happens. Auto companies in this model also
require data, but they seldom analyze it as thoroughly, and when they do
find inconsistencies, they usually punish suppliers rather than teach them.
In a lean PD system, you teach suppliers that are willing to learn and
improve, and this enables a valuable, continuous partnership.

Price Is Not Everything

In a typical supplier relationship, once certain quality standards are met,
price becomes the company’s overriding consideration in choosing a sup-
plier. In lean, the supplier needs to meet the performance requirements
and the price targets but must also show an ability to partner with the
company day by day as details are smoothed out and concerns are
addressed. Toyota as a rule does not source on the basis of price alone. In

191
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 192

Section Three: People Subsystem

the tire example above, GM, Ford, and DaimlerChrysler all announced
aggressive targets for sourcing from China for American models to capi-
talize on the low labor rates. Bringing in China suppliers often means set-
ting a spec taken from the data of current suppliers, testing some tires for
conformance to the spec, and perhaps examining source plant facilities. If
the company is satisfied, and if the price is lower, the supplier gets the
business. Darrel Sterzinger, general manager of engineering design, chas-
sis, at the Toyota Technical Center comments on this:

That would be unthinkable at Toyota. I could not sleep at night if

I did that. If we did bring on a supplier from China for some rea-
son, they would have to go through the same codevelopment
process as other suppliers. They would have to compete in this
process. And we would start off by giving them a small job, like the
spare tire on a low volume vehicle. We would monitor their per-
formance. If they performed well on product development, qual-
ity, and delivery we might give them the spare tire on a higher
volume vehicle. And then, if they performed well over several
years, they might get the tires for a larger volume program.

Suppliers have burned Toyota with promises of low-cost alternatives.

In one case, a company’s prices were so competitive that purchasing
awarded it business for a rear tail lamp before engineering thought this
supplier was ready. It seems the company wanted the business badly and
was relocating the business to Mexico to get the benefit of lower labor
rates. Once the company launched manufacturing, the scrap rates were off
the charts by Toyota standards. Toyota engineers tried to develop the sup-
plier but were unable to make enough headway. It became clear that the
supplier simply could not meet Toyota standards and requirements. The
supplier was taken off the project, and the relationship was dissolved. The
lesson was that it is more expensive in the long run to pick the cheapest sup-
plier if this supplier is not ready to meet your requirements.

Losing a Bid
In traditional relationships, a number of suppliers bid on a contract and
someone wins. Not getting the contract may be painful for a supplier, but
because little was invested, little has been lost. In the lean approach, a small
group of suppliers competes throughout the development process.

192
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 193

Fully Integrate Suppliers into the Product Development System

Although each supplier makes a serious investment in R&D, some win and
some do not. But suppliers with an understanding of lean see the R&D
investment as an overall investment in a relationship: Losing a particular
program does not mean losing the investment. In fact, suppliers that work
with Toyota may lose several bids before they win lucrative contracts. Most
suppliers begin a partnership with Toyota that is paced incrementally and
is characterized by losing large contracts and winning small contracts until
Toyota decides that the balance can be reversed.

Relationship Development
As noted above, suppliers who do not satisfy a traditional enterprise on a
particular job are seldom given the opportunity to work for that enterprise
again. In contrast, a lean enterprise views supplier relationships in light of
development potential. This is particularly true at Toyota.
Toyota puts all new suppliers through a thorough, step-by-step regi-
men. For example, when Toyota first started working with General Tire,
the relationship began on a very small scale. Toyota was first tried out as a
supplier of spare tires on the Camry station wagon—a low volume vehicle.
The company then adapted this as a spare for the Sienna minivan. Toyota
constantly monitored performance, teaching the supplier the Toyota
approach to product development and manufacturing. At times the com-
pany failed to meet Toyota’s standards, but Toyota continued to teach as
long as the supplier was eager to learn. General Tire’s work was eventually
expanded to supplying all four tires for the Avalon and Solara—still rela-
tively low volume vehicles. Toyota then considered using the company as a
supplier for high volume trucks and SUVs. Gradually General Tire became
a valued and trusted Toyota supplier, but it took ten years.

The Guest Engineer System

Toyota always has a crew of hundreds of engineers from suppliers, resid-
ing full time in its product development office called guest or resident
engineers. While they have separate areas, they interact daily with Toyota
engineers. This has an obvious benefit—free engineering resources for
Toyota. But that is not the purpose. The purpose is integration.
When Toyota invites a supplier to send guest engineers, it is a signifi-
cant commitment to long-term coprosperity. The supplier knows they
have earned a long-term place in the Toyota enterprise. These are highly

193
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 194

Section Three: People Subsystem

coveted positions. The supplier will become intimately familiar with

Toyota’s product development practices and get advanced information on
new model programs.
The supplier can also realistically assume that engineers with a Toyota
experience will become better engineers. It is like sending employees on
the company payroll to a top engineering school—perhaps better. They
will learn the Toyota Way of engineering. They can bring what they learn
back to the supplier, enhancing the product development processes of the
supplier. This of course assumes that the customer has something to teach,
which in this case, with Toyota as the customer, is a good assumption.
Guest engineers rotate through this position usually in two- to three-
year stays. Large suppliers like Denso have many engineers at a given point
of time, so over the years, many of Denso’s guest engineers will have had
this deep Toyota experience. When we speak of how interchangeable
Toyota engineers are with those of key suppliers enabling flexible capacity,
the guest engineer system is a main reason for this.

The Supplier Stable

A traditional enterprise often relies on a selective group of favorite suppli-
ers, but because the primary purpose of the relationship is to acquire
needed supplies at a good price, such an enterprise does not hesitate to
widen its supplier base. If the existing suppliers are outbid or cannot meet
particular requirements, the company looks elsewhere without a backward
glance. In many cases, the relationship with the original supplier is per-
manently terminated.
A lean model, on the other hand, generally works with a small stable
of suppliers within the context of a broader plan. The goal is to keep these
suppliers busy and competitive and to motivate them to do their best,
sometimes with an eye to what they may contribute to other programs in
the future.
With respect to this broad and long-range philosophy, Toyota’s pur-
chasing department plans and manages how much business each supplier
will get on average over time. If a supplier is performing well but is not
selected for one particular program, that supplier is likely to be selected for
another program in the near future. If a supplier has performed poorly on
quality, product development, delivery, or meeting price targets, that sup-
plier may lose some share of the purchasing department’s proposed divi-
sion of contracts to be awarded but has the opportunity to regain the lost

194
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 195

Fully Integrate Suppliers into the Product Development System

share. Because Toyota is willing to work with suppliers to help them

improve, the suppliers are likely to work hard to meet Toyota’s standards
and requirements. Ultimately, they win contracts for other programs.

The Crux of Outsourcing Strategy

As mentioned earlier, Toyota successfully outsources over 70 percent of its
vehicle content and this seems to have encouraged other auto companies
to do likewise. But in trying to emulate Toyota’s success, most of these
companies do not fully appreciate or understand the strategy that makes
Toyota succeed: Although Toyota outsources parts and even engineering,
it does not outsource competence or relinquish control.
Like any company, Toyota sees many advantages in outsourcing,
including the flexibility of putting expert supplier engineers on PD pro-
gram teams to work on specific components as needed. However, Toyota is
careful when deciding what to outsource and what to retain in-house. Even
with outsourced components, Toyota is not willing to give up internal com-
petency, even though it may be cheaper or more convenient to do so.

Mastering Core Technology

Maintaining a core competency is a current management buzz phrase
among auto companies, but Toyota has its own unique interpretation of
this concept. Rather than seeing itself as just designing, assembling, and
marketing cars, Toyota defines its competency around the technology of
selling, designing, engineering, and especially manufacturing of trans-
portation vehicles. Moreover, when Toyota outsources, it does not relin-
quish control; it wants to learn and excel in new technology along with
suppliers. While it hands off certain responsibilities, Toyota never transfers
to its suppliers all of its core knowledge or full responsibility for any core area.
When new technology is core to a vehicle, Toyota distinguishes itself
from the rest of the pack by diligently working to master the technology
and becoming the best in the world at using it. As a lean organization,
Toyota is fully aware that mastering any core technology internally helps to
1) manage suppliers effectively (e.g., understand true costs), and 2) con-
tinue to learn as an organization to stay at the forefront of the technology.
Chapter 7 described in some detail the Prius hybrid vehicle develop-
ment, which depended on fundamental technology that Toyota had never
before engineered into a mass-produced vehicle. In particular, there were

195
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 196

Section Three: People Subsystem

three key technologies never before developed in-house: 1) the hybrid’s

electric motor, 2) the powerful battery, and 3) computer controls (IGBTs)
that switch the battery’s DC current to a different form.3 Because of the
short timeline to launch the Prius, a natural response would have been to
partner with outside companies with expertise in these three fundamental
technologies. Instead, even though President Okuda continued to move
up the release date, senior management and the Prius CE, Uchiyamada,
insisted on developing as much of the hybrid car in-house as possible.

Developing new capability: the hybrid electric motor and

computer controls
Toyota’s senior managing directors saw the hybrid electric motor and, specif-
ically, developing capability in applying the Insulated Gate Bipolar Transis-
tor (IGBT) to autos as an opportunity to corner the market on components
for future hybrid vehicles. IGBT are switches that convert DC current to
three-phase current and are key to the ability to move back and forth
between the electric motor and the traditional gas engine. As a result, Toyota
developed the IGBT in-house and, in the process, started a new semicon-
ductor manufacturing business. The development process was demanding,
conducted by engineers with no previous experience in this technology,
and Toyota invested 5 billion yen in the new plant. The return on this
investment is still paying benefits. Today, Toyota outsources many of these
parts originally developed in-house, but Toyota has a degree of control over
the supply of these parts and controls cost. Moreover, Toyota now knows
how to produce small runs economically and to reduce costs for these small
batch parts over time—a general lesson it can apply to niche vehicles.

Outsourcing the battery while maintaining capability

Though Toyota sorely wanted to develop new technology around the bat-
tery, there was a constant problem with the part driving the electronic
motor portion of the hybrid. In the end, Toyota had to outsource this
component. But rather than simply handing off the responsibility to a
supplier, Toyota established a joint venture company with Matsuhita—
Panasonic EV Energy (Itazaki, 1991). Having worked with Matsushita

3. The story of how Toyota developed these three components are discussed in detail in
the book, The Toyota Way (Liker, 2004).

196
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 197

Fully Integrate Suppliers into the Product Development System

before, Toyota was somewhat confident about the relationship, but this
confidence was tempered with a concern about differences in corporate
culture. Of specific concern was whether Matsushita had the proper disci-
pline to handle the quality control issues necessary to develop a completely
new type of battery. Fujii, Toyota’s engineer responsible for the battery,
eventually realized that there was a way to meld the style of the two com-
panies to address this issue. Thus, what began as a third-tier consultative
relationship eventually evolved into a second-tier mature relationship as
Toyota engineers worked hand in hand with their joint venture partner.

Changing Policy to Maintain Internal Capability

Even when it chooses to outsource a key component, Toyota prefers to
maintain internal capability and competency. Consider, for example, its
long relationship with Denso, which was a division of Toyota until becom-
ing an independent enterprise in 1949. Denso is one of the largest global
parts suppliers in the world, and through the keiretsu, Toyota now has con-
trolling interest with about 20 percent of the company. Over the years,
Denso has been Toyota’s electrical and electronic parts supplier of choice
despite its close relationships with Toyota’s competitors. As a rule, Toyota
wants at least two suppliers for every component, but Denso, operating
like a division of Toyota, has often served as the company’s sole electron-
ics’ supplier. This arrangement, though usually smooth, sometimes led to
conflict, but neither company seemed inclined to change it.
Then, in 1988, seemingly out of the blue, Toyota opened an electron-
ics plant in Hirose and began aggressively recruiting electrical engineers.
The compelling reason for this change in policy was that Toyota had rec-
ognized that electronics technology was becoming a prominent part of
vehicles. (Today as much as 30 percent of the vehicle content is electronics
related.) Even after years of outsourcing to Denso, Toyota was capable of
changing course and initiating a learning-by-doing program to “infuse its
entire organization with the skills and values essential to making electron-
ics a genuine core competence” (Ahmadjian and Lincoln, 2001). At this
time, about 30 percent of Toyota recruits are electrical engineers.
Using Keiretsu to maintain internal capability
As discussed earlier, Toyota maintains internal capability through its keiretsu
by having first-tier partners and mature suppliers that take major respon-
sibility for subsystem engineering and testing. Toyota is still dependent on

197
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 198

Section Three: People Subsystem

its suppliers because they have dedicated assets, like tooling designed for a
certain car model and in-depth product engineering knowledge, which is
difficult to duplicate. For this reason, Toyota maintains control through
direct ownership of a portion of each of its suppliers and on interlocking
boards of directors. In its move toward doing more business with U.S. sup-
pliers, Toyota (like the big-3) has insisted that first-tier suppliers set up divi-
sions dedicated to serving only Toyota. Furthermore, to sustain the integrity
of proprietorship, these suppliers are required to build and maintain fire-
walls with any of Toyota’s competitors that they may also be serving.
Using Keiretsu megasuppliers to build modules
One of the trends in the auto industry (as well as in many consumer-
driven businesses) is modularity. Like other products, cars can be divided
into a set of interdependent modules (interior cockpit, corner module,
etc.), each of which can be sourced to an outside supplier to engineer, then
built, and shipped in sequence to the assembly line. The automaker bolts
together the modules and the work is done. Toyota, preferring to keep
more control internally, was especially conservative about joining this
trend. Instead, Toyota created 13 or 14 keiretsu megasuppliers and, by
2003, it had developed its own unique strategy for modularity, one that
gave it a degree of control and internal competency. These new Japanese
megasuppliers have very broad technical and program management com-
petencies and take on responsibility for design, development, production,
and assembly of modules. It is important to note here that the megasup-
pliers remain part of the keiretsu network and that Toyota as the OEM
maintains redundant competencies to oversee their operations and devel-
opment. In addition, by establishing new joint ventures with these suppli-
ers, Toyota takes a substantial portion of the generated equity.
On surface, there is an inherent contradiction in supplier relationships
in the lean PD approach. On the one hand, when you do business with any
outside company, you need to treat them with the respect accorded a part-
ner. Moreover, when suppliers become part of the inner workings of your
company, they then become part of the extended network that make up
your enterprise. Trust and openly sharing information are critical to suc-
cess. On the other hand, it is important to define your core competency
properly and accurately, and then aggressively find ways to maintain it.
You also need to identify and monitor internal capability, a process that
sometimes prompts starting a new business or changing long-held poli-
cies—both a huge investment of resources. On some levels, Toyota may

198
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 199

Fully Integrate Suppliers into the Product Development System

seem unduly conservative and protective of its internal control. But it is

because of this that Toyota has managed to maintain a balance between
two apparently conflicting ideas by applying one invaluable principle: hold
outside partners to the same high standards as inside engineers and, until you
build trust, be reluctant to relinquish control. The level of trust will vary for
each company. For Toyota, even when trust is established, there is still clear
difference between being inside and outside of Toyota, and Toyota always
reserves the right to keep core technical competence to engineer and build
key components in-house.

Treating Suppliers Respectfully and Reasonably

When a U.S. supplier was asked how Toyota ranked as a partnering com-
pany, he answered with no hesitation that Toyota was his best customer,
following up with an example that explained his answer. He said that when
his other customers place an order in advance and decide they don’t need
as much as they ordered, they ask him to eat the cost. When Toyota adjusts
its order lower, it purchases the total number of parts originally requested.
When Toyota makes a commitment, it honors that commitment. In other
words, it plays fair.
The supplier had another interesting observation. When he deals with
Chrysler on a new launch, the company pulls out a quality procedures
manual the size of Webster’s dictionary. To make things worse, the man-
ual is constantly changing and keeping up with the changes consumes a lot
of time and human resources. This is typical and underscores why many
suppliers think that their big-3 American customers use bureaucracy, espe-
cially “quality” bureaucracy, as a tool to beat them up. Time after time,
confused or incomplete information from the customer turns into higher
costs and lower profits for the supplier.
Both U.S. auto companies and Toyota use bureaucracy—extensive
standards, auditing procedures, rules—in their day-to-day business with
suppliers. However, many suppliers view U.S. auto companies as highly
coercive, inconsistent, and incompetent. On the other hand, they see
Toyota as an enabling partner—demanding, but willing to work things out
together. Toyota engineers have the skills and experience to understand
critical issues and provide simple clear direction. They do not have to hide
behind layers of unnecessary administrative requirements or bureaucratic
jargon. One U.S. automotive interior supplier described working with
Toyota in this way:

199
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 200

Section Three: People Subsystem

When it comes to fixing problems, Toyota does not come in and

run detailed process capability studies 15 times like American
Auto. They just say, “take a bit of material off here and there and
that will be okay—lets go.” In 11 years, I have never built a proto-
type tool for Toyota. Knee bolsters, floor panels, IPs, etc. are so
similar to the last one it is not necessary to build a prototype.
When there is a problem, they look at the problem and come up
with a solution—focus on making it better not placing blame
(Liker, 2004).

Toyota has turned its structured “bureaucratic” relationship with sup-

pliers from coercive to enabling (Adler, 1999) with stable processes and
clear expectations. In contrast, most U.S. automotive companies con-
stantly reinvent their supplier processes, which can vary from engineer to
engineer and even department to department within the same project.
Without developing a fair and stable business base, it is impossible to get
to the higher levels of enabling systems and truly learning together as an
enterprise (Liker, 2004).
There is another significant disadvantage to the U.S. auto companies’
highly bureaucratic, competitive bidding approach to supplier relation-
ships: the tremendous hidden factory and transaction waste associated
with the maintenance of this system. Searching the globe for the lowest
cost means managing very large numbers of suppliers as well as introduc-
ing a steady stream of new suppliers into your system. These suppliers are
unfamiliar with your requirements and demand a great deal of attention
to get up and running. While administering complex contracts, managing
global bidding wars, and overseeing the constant introduction of new sup-
pliers into the process, U.S. automakers must maintain mammoth pur-
chasing organizations, deal with incredibly cumbersome and slow
sourcing processes, and live with constant variation of supplier perform-
ance in the development process.
The bottom line in a lean PD process is that you treat suppliers
respectfully and reasonably. After all, they are engineering and building
critical portions of the product that you are trying to sell to the customers
who you want to view the product as world-class goods. If the supplied
parts are inferior, the product you sell will be inferior. If the suppliers are
inferior, you should stop using them. However, if the supplier is engineer-
ing and building world-class components, you should treat that supplier
with respect. In Henke’s survey of auto suppliers, trust was the most

200
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 201

Fully Integrate Suppliers into the Product Development System

important measure ranked, and Toyota consistently scores at the top of

automotive companies. Without trust, there is no partnership.
Trust between Toyota and its suppliers is a two-way street; each part-
ner benefits because each partner is willing to go the extra mile down this
street to keep the relationship strong. As this chapter has illustrated,
Toyota demands much of its suppliers. During its global CCC21 initiative,
for example, Toyota asked its suppliers to reduce the price charged Toyota
by 30 percent for the next new model. This sounds like an impossible goal,
especially given suppliers’ tight profit margins. But Toyota never just
dumps a demand on suppliers; it makes a request and then works with the
supplier to achieve what is needed. In this instance, if Toyota had asked for
a 5 percent reduction, the supplier might have simply taken it out of profit
margin. Because taking out 30 percent would be prohibitive, the supplier
must find a different solution and this means examining every aspect of
the business from design to raw material to delivery to find true cost sav-
ings. As Darrel Sterzinger, general manager of engineering design chassis,
at Toyota Technical Center explained:

A true North American supplier cannot imagine 30 percent—it

boggles the mind. But when I sit down with them and explain
Toyota’s thinking, they can understand the purpose of it. It is not
the 30 percent we are thinking about. It is a new way of doing
business. We explain to them and look at their operation and then
they feel more comfortable. They think we are like the big-3 and
Toyota has gone wacko. If you just tell the supplier 30 percent
without working with the supplier—it is unreasonable. But for us
it is a whole way of thinking which starts with the design. If we do
not think about working together with the supplier as a partner-
ship and start talking about cost competition with other suppliers,
like GM, the suppliers will be very nervous.

Toyota never bullies or threatens its suppliers, which may explain

why it first termed the Toyota Production System the “respect for
humanity system.” This philosophy extends to all the partners with
which Toyota does business. The bar is set high for the supplier, and
the consequences of failing to step up and improve to Toyota’s standards
can be painful. However, there are financial rewards for working hard
to improve as well as the pride and satisfaction that come from success
and recognition.

201
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 202

Section Three: People Subsystem

The LPDS principle to fully integrates suppliers into the product devel-
opment system, means you must first get your own house in order, then go
out and find only the most qualified companies to partner with, working
with them to develop compatible systems and procedures. Ultimately, this
leads to working and learning together as an enterprise, which leads us to
the ninth LPDS principle: Build in Learning and Continuous Improvement.

LPDS Basics for Principle Eight

Fully integrate suppliers into the product
development system

Customers view purchased components as a part of the product

and want the whole product to be problem free. They do not care
if a problem was not your fault because your supplier was not reli-
able. Whoever sells the final product is responsible. For this reason,
suppliers of core components must have the same level of engi-
neering and manufacturing capability to contribute quality parts as
your lean enterprise has in engineering and manufacturing quality
products. In addition, suppliers must be compatible. They must fit
seamlessly into your product development system, your launch sys-
tem, and your manufacturing system. This requires learning how to
work together through repeated experiences. It is your responsibil-
ity to communicate clear expectations. To accomplish this, Toyota
brings selected suppliers into the simultaneous engineering process
very early in the concept stage. Suppliers make a serious contribu-
tion to simultaneous engineering, knowing that they are investing
ahead of the payback that will come in the production stage. This
is something to emulate.

202
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 203

CHAPTER 11

Build in Learning and

Continuous Improvement
The ability to learn faster than your competitors may be
the only truly sustainable competitive advantage.
DE GEUS (1988)

AT TOYOTA, LEARNING AND CONTINUOUS IMPROVEMENT are fundamental to

how each person does his or her job every day and are inseparable from
Toyota’s culture. Toyota sets challenging performance goals for every proj-
ect and holds both real-time and postmortem learning events (called Han-
sei or reflection) that encourage functional specialists to verify and update
their own knowledge databases. Learning and continuous improvement
are also embodied in a problem-solving process that develops root-cause
countermeasures: multiple potential solutions that prevent recurrence
(Ward et al, 1995). LPDS Principle 9 postulates that learning mechanisms
are embedded into the product development process; that learning excel-
lence is a basic characteristic inherent to a true lean learning organization;
and that effective learning and continuous improvement may be the most
sustainable competitive weapons in its arsenal. In fact, Toyota’s awesome
ability to learn quickly and improve at a regular cadence may well be the
characteristic of Toyota its competitors should fear most.

Defining Knowledge and Organizational Learning

Many theories purport to define organizational learning, knowledge
transfer, information management, and how these apply to product devel-
opment. It can be argued, in fact, that knowledge and information are the
stock and trade of product development. Literature on knowledge and
learning also provides numerous views on organizational learning and the
requirements for a successful learning organization. Senge (1990), for
example, claims that organizational learning is the “ability of a group of
people to consistently create the results the members truly desire.” Peter
Drucker (1998) observes that the future belongs to the “knowledge-based

203
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 204

Section Three: People Subsystem

enterprise” and, in his book, The Knowledge Creating Company (1995),

Ikujiro Nonaka concludes that the “one source of lasting competitive
advantage is knowledge.” Some scholars go a step further, maintaining that
the purpose of an enterprise is creating, storing, and applying knowledge
(Kogut & Zander, 1992; Conner and Prahalad, 1996).
In his article “Teaching Smart People How to Learn” (1998), Chris Argyris
argues, “Corporate success depends on learning” and postulates two types of
learning: single loop learning and double loop learning. Single loop learning
comprises error detection and correction without change to the underlying val-
ues of the system. This can be compared to a thermostat detecting a decrease
in temperature and turning on the heat without the ability to question what
it is doing. Double loop learning occurs when the actual operating norms
are questioned, which is fundamental to an organization’s ability to learn.
Other scholars point out two very different types of knowledge: the
first is explicit knowledge or information easily codified and transferred
without significant loss of content. Explicit knowledge includes “facts,
axiomatic propositions, and symbols” (Kogut & Zander, 1992). The second
category of knowledge is tacit knowledge or know-how. This type of knowl-
edge is complex, hard to codify, and difficult to transfer; it requires dense
ties and long relationships (Nelson & Winter, 1982; Kogut & Zander, 1992).
David Garvin (2000) affirms, “Knowledge is generally seen as a key
corporate asset to be leveraged and exploited” and defines a three-step
process required for organizational learning: information acquisition,
information processing, and application. Argyris (1992) emphasizes that
the litmus test of learning requires action: “From our perspective, there-
fore, learning may not be said to have occurred if someone discovers a new
problem or invents a new solution to a problem. Learning occurs when the
invented solution is actually produced.” Jeffrey Pfeffer and Robert Sutton
echo this sentiment in their book The Knowing-Doing Gap (2000), in
which they assert that acting on knowledge is the fundamental difference
between successful and unsuccessful learning within organizations. In fact,
Pfeffer and Sutton maintain that for all the attention given to organiza-
tional learning, little is accomplished. Garvin agrees: “Learning organiza-
tions have been embraced in theory but are still surprisingly rare.”

Explicit Versus Tacit Knowledge Transfer

Most companies focus on explicit knowledge, defined above as easily cod-
ified, transferred without significant loss of integrity, and generally stored

204
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 205

Build in Learning and Continuous Improvement

as facts, axiomatic propositions, or symbols. Historical dates, mathemati-

cal equations, and formulas fall into this category. Explicit knowledge is
sometimes referred to as “know what” knowledge. It is characterized by
voluminous databases.
By contrast, tacit knowledge is complex, “sticky,” and difficult to trans-
fer. Sharing tacit knowledge requires intricate ties between participants; it
entails longer, deeper relationships, such as those that develop between a
master craftsman and his apprentice. In fact, the apprenticeship tradition
was designed as a means to transfer tacit “know-how” knowledge from
master to student.
Dyer and Nobeoka (1998) suggest that tacit knowledge holds the most
competitive potential for companies even though it is difficult to learn
(you cannot merely imitate it), manage, and apply. Because it makes effec-
tive organizational learning difficult, many companies prefer to focus on
explicit knowledge, which can be more easily gathered and stored. The big
problem with explicit knowledge is that it can also be imitated. If one com-
pany can create an extensive database of explicit knowledge, so can a com-
peting company, and this dilutes the competitive advantage of both.
One of the main reasons that companies fail at imitating lean systems
is that they mistakenly copy only the “explicit” knowledge of lean tools and
techniques. By and large, these companies attempt to implement lean
without understanding the need to tap into the tacit knowledge of lean
culture, the know-how knowledge that enables an organization to learn
organically, adapt, and grow. They fail to grasp that in highly technical
environments, such as product development, tacit knowledge is the true
source of competitive advantage. One important study on automotive prod-
uct development supports this assertion (Hann, 1999). The study revealed
that die tryout knowledge is highly tacit, tends to be part specific, and is
very difficult to master. The author of the study also found that special-
ization, strong work routines, and continuous work fostered a significant
reduction in time to complete die tryouts. In combination, these findings
loosely define the power of effective lean learning.

Toyota’s Product Development Learning Network

From its inception, Toyota has consistently worked on developing ways to
collect, disseminate, and apply tacit knowledge, creating a learning net-
work that is applied enterprise-wide from product development to manu-
facturing. To understand this is to understand a piece of Toyota’s culture,

205
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 206

Section Three: People Subsystem

with its strong emphasis on the importance of people. For Toyota, trans-
ferring tacit knowledge means that people must get to know each other
well enough to share deep insights. Most often, this happens face to face
and one to one. What enables this transfer is a shared social philosophy,
which is consistently nurtured and sustained. There are several ways
Toyota forms a highly effective learning network in product development.
1. Supplier technology demonstrations. At the beginning of each pro-
gram, suppliers demonstrate technology that might be appropri-
ate for the new vehicle. This is a good opportunity for Toyota
engineers to learn about new developments (Kamath & Liker,
1994) and for Toyota to leverage supplier resources fully. Toyota
suppliers bring parts and meet face to face with Toyota engineers.
2. Competitor teardown analysis. Teardown exercises provide an
opportunity to learn about competitors. These hands-on exer-
cises are another example of genchi genbutsu and an excellent
way for engineers to learn. In lean PD, you also want to use these
learning tools to disseminate information so that all team mem-
bers learn from them. (Chapter 15 elaborates on this.)
3. Checklists and quality matrices. Toyota uses these tools to organ-
ize and store information so that people can apply it similarly
across the organization. (Chapter 15 elaborates on this.)
4. Learning focused problem solving. This represents the A3 prob-
lem-solving discipline that helps people learn while seeking last-
ing solutions. At Toyota, problem solving begins early (at the
source), is data driven, and includes a learning component. (Dis-
cussed in Chapter 14.)
5. Know-how database. The know-how database is the collection of
standards combined with design data and tools, such as digital
assembly (discussed in Chapter 15). The functional organizations
that use these databases (evolved from checklists) maintain, vali-
date, and update them as needed.
6. Hansei events. Hansei is a Japanese word for reflection. At these
reflection events, participants share their PD program experi-
ences, lessons learned, project shortcomings, and then discuss
and develop countermeasures. (Hansei events are discussed in
more detail later in this chapter.)
7. Program manager conferences. Program managers from various
projects meet once a year to discuss lessons learned and to pass

206
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 207

Build in Learning and Continuous Improvement

on new standards. The lessons are derived from each program’s

hansei or reflection events that the program manager leads.
8. Business Revolution Teams. These cross-functional teams are
formed to address single revolutionary improvement efforts.
Toyota high-level executives assign people to these teams full
time and each assignment can last six months to a year. The first
hybrid, Prius, began with a business revolution team, as did
Toyota’s effort to eliminate engineering changes.
9. OJT skills matrices and learning-focused career paths. Specific OJT
skill matrices and mentoring technical skills teach engineers
leadership and sets their career paths. Learning is built into
everyday assignments so engineers can use Toyota’s scientific
method—identify, evaluate, countermeasure, verify, communi-
cate (standardize)—to question and learn continuously. This
cycle of mentoring, learning, and applying until one has the
potential to mentor others is the heart of a lean learning system.
10. Resident Engineers (RE). Engineers are exchanged on temporary
assignment both within Toyota and with affiliated companies.
This is a learning opportunity for the RE and is also a method of
standardizing practices.

Learning from Experience

If there is no mechanism or culture in an organization for capturing,
retaining, and reusing knowledge, that organization is almost certainly
engaged in constantly reinventing the wheel. That said, it is only fair to
admit that learning from experience is often easier said than done, partic-
ularly when it involves very complex, episodic experiences. The process
requires conscious reflection, and very few organizations do this well or
even see the importance of doing it. According to Garvin (2000), there are
a number of reasons the learning from experience process fails.
1. Time pressures. Stressful time pressures impact most people in
every organization. As soon as one project is over, another one
(sometimes already behind schedule) looms and must be immedi-
ately addressed.
2. Oppressive workloads. People tend to be absorbed by their current
workload, often ignoring important things learned from past
(even recent past) experience.

207
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 208

Section Three: People Subsystem

3. Blaming. Organizational lessons-learned events often turn

into sessions marked by scapegoating, finger-pointing, and assign-
ing blame. As a result, only the loudest or most powerful are
heard at such events; other people are reluctant (and often silent)
participants.
4. Complex projects. Complicated projects thwart understanding,
causing frustration.
Garvin goes on to identify reflection, hansei in Japanese, as one of the
most potent learning mechanisms to confront these four pitfalls and has
five suggestions to help reflection events succeed.
1. Hold the reflection as soon as possible after the event. The loss of
valuable real-time information increases over time.
2. Focus on things under the group’s control. People should not waste
time confessing other people’s sins or policies that the group can-
not take action on.
3. Tolerate criticism and honest dialog. Participants should feel free to
express all relevant views without fear of repercussion. Personal
attacks should not be tolerated.
4. Must be a regular event. People must see this activity as part of
the job.
5. Must update standards and processes. Just talking about it doesn’t
fix it. The end result of each event must be some concrete, observ-
able improvement or people will view these events as worthless
and stop participating.

Hansei at Toyota
Hansei (reflection) has deep roots in the Japanese culture and begins in
child hood as a sort of time out when parents ask their children to reflect
on some juvenile indiscretion. Hansei requires a certain humbleness or
egolessness in order to search for and identify weakness in ones perform-
ance or character. It can be a very difficult process especially for western
engineers who often find the process quite foreign and whose egos can
sometimes get in the way. Hansei can sometimes be seen by westerners as
overly negative because of its focus on weakness since Japanese engineers
see little reason to discuss things that were done well. But hansei is a nec-
essary and powerful process for continuous improvement. In fact George
Yamashinta, former president of TTC says that in engineering there can be

208
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 209

Build in Learning and Continuous Improvement

no kaizen without hansei, as the nature of engineering work makes it nec-

essary to think deeply about the process. Each Toyota hansei event or han-
sei kai (reflection meeting) is designed to enhance organizational learning
from experience. There are three types of hansei:

1. Personal reflection. In this hansei exercise, a supervisor asks an

engineer to reflect on some aspect of his or her performance and
develop an action plan for improvement. A written response is
expected and will be reviewed by both parties. Specific goals are
set and a follow-up plan is outlined. This activity addresses a spe-
cific skill or capability that needs to be improved.
2. Real-time reflection. This hansei experience occurs at a group or
team level and is scheduled into the product development process.
These hansei kai usually take place at major milestone events,
suchas final data release or tool transfer to the stamping plant. PD
programs can last a year or more and you can lose much informa-
tion in that time, so these are regular events scheduled to take
place as soon as possible after the actual activities. The hansei
event can focus on a specific issue, such as looking at the problem
of some parts that arrived late for the prototyping event. They
might also reflect holistically on the prototyping event. Depending
on the issues involved, group or team hansei events can be cross-
functional or intra-functional. They are most often cross-func-
tional, focusing on internal customer feedback. Although flexible,
they typically follow a general outline and address the following
questions:
a. What were our goals and objectives? (often organized by
category)
b. How did we actually perform to our goals?
c. Why did it happen? (data analysis)
d. How will we improve next time? (a written improve-
ment plan)
These hansei events often lead to updating a relevant standard
or may require an A3 for reporting or problem solving. The
length of hansei events can vary significantly, but they are often
scheduled as two or three meetings, each lasting two to four
hours, within a two-week time period. Much of the actual “prep”
work occurs before the meeting date. Toyota’s A3 and “5 why”
problem-solving methodologies are rigorously employed.

209
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 210

Section Three: People Subsystem

3. Postmortem reflection. This is the “what went right, what went

wrong” lessons-learned event. The presentations are formal, with
most of the real analysis and reflection occurring before the meet-
ing date. At the meeting, representatives from each of the functional
groups review program performance and discuss results as well as
new ideas stemming from real-time reflection. Program managers
talk to participants to get feedback and synthesize these reflections
from their programs into a small number of lessons learned that are
shared at PM meetings held several times a year. At these meetings
or hansei kai, program managers produce written summary docu-
ments that are shared within and across other PD program teams.
Note that there is a distinction between the program manager and
the chief engineer and that these roles are not interchangeable. The
chief engineer is responsible for the product. The program manager
(not as high a level) is responsible for the process.

Ijiwaru Testing at Toyota

Testing and validation can be another important opportunity to learn
from experience in product development. At NAC, required part per-
formance specifications are set in advance and designs are tested for com-
pliance to these specifications. Learning in this environment is minimal
because it is strictly a pass-fail metric. Ijiwaru testing on the other hand is
the practice of testing subsystems to failure. By testing these subsystems
under both normal and abnormal conditions and pushing designs to the
point of failure Toyota engineers gain a great deal of insight into both cur-
rent and future designs and materials by understanding the absolute phys-
ical limitations of their subsystems. Consequently, Toyota engineers
develop a depth of product knowledge that is exceptional in the industry.
This practice also gives Toyota a great deal of confidence in the perform-
ance parameters of their products in the hands of their customers.

The Power of Problems

It should be pretty clear by this point that Toyota views problems as a natu-
ral part of product development. In fact, in a sense, the essence of product
development can be seen as a series of technical problems that must be
identified and solved. From this perspective then, companies who excel at
technical problem solving will do well at product development. And com-

210
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 211

Build in Learning and Continuous Improvement

panies that improve their technical problem-solving capability will improve

their product development competence. Consequently, Toyota looks for
and values technical problems as opportunities to learn, grow, and improve
its performance and encourages positive problem-solving behaviors. Con-
fronting, solving, and learning from problems is one of Toyota’s greatest
strengths as a product development company. Taking this approach will
help companies to confront and solve problems early, arrive at optimum
solutions quickly, and provide permanent resolution. This increases a com-
pany’s knowledge base, builds critical skills, and introduces superior solu-
tions that become a permanent competitive advantage other companies
will find difficult to replicate. In short, the lean PD process views problems
as opportunities—not only to improve products but also to improve the
core of a company’s product development capability.
By contrast, at NAC it is common to see problems as negative and
unexpected, an attitude that suggests problems shouldn’t occur at all.
When problems do surface, as they inevitably must, there is a lot of finger-
pointing or blame-gaming. This happens because managers and workers
at these companies see problems as indicators of poor performance. As a
result, individual engineers learn quickly to hide problems for as long as
possible. Of course, the hidden problems fester, and as the product design
continues to progress into a later cycle, they become even more difficult to
resolve. Once the problem is discovered, people have to scramble and
backtrack; other work is put on hold until the fire drill ends.
The Japanese Toyota engineering supervisors at the Toyota Technical
Center in Ann Arbor tell an interesting story about some American engi-
neers they hired into the center from competitor companies. As the super-
visors made their rounds and spoke to these engineers, they routinely
asked if they had any problems. The engineers automatically responded,
“No, no problem.” This response, mondani in Japanese, soon became a
semicomical in-house joke in which mondani was transformed into
“Monday night!” Although it began as nothing more than an amusing
expression, it turned out to be a very unamusing source of concern. When
the first design review forced problems into the open, Japanese supervisors
quickly learned that “no problem” was a big problem indeed.

Problem Solving at the Source

The prototype phase of product development is a period of intensive learn-
ing. As part designs become prototype parts, technicians and engineers

211
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 212

Section Three: People Subsystem

begin to assemble them, often encountering problems that they must

resolve in real time. In an environment fraught with problems, it is clearly
advantageous for a company to achieve high-quality, permanent solutions
(or countermeasures) quickly. To develop and sustain a lean PD process, a
company will need to transform these problems into organizational learn-
ing opportunities and subsequent continuous improvement. This means
investing considerable time and resources into perfecting problem-solving
capability so that there are mechanisms for capturing, verifying, codifying,
and sharing these solutions before they are lost. Toyota accomplishes this in
a number of ways, beginning with the standardized problem solving dur-
ing kentou, which continues throughout the PD process. The standardized
scientific problem-solving process:

• identifies the problem’s root cause

• evaluates the potential impact of several possible solutions
• produces a high quality countermeasure that can resolve the
immediate issue as well as prevent its recurrence
• verifies the countermeasure during subsequent hansei events
• communicates the result across programs by updating standards
and checklists, which are increasingly part of the “know-how
database.”

There has been a great deal written about Dr. Deming’s Plan-Do-
Check-Act (PDCA) process and Toyota’s practice of asking why five times to
solve problems at the root cause and we will not elaborate on it here. How-
ever, it is important to note that those methods are equally applicable in
product development as the shop floor. In product development it is crucial
to solve problems early, at the source, and permanently; and to learn from
these problems in order to improve the organization. In a lean PD process,
it is essential to build solutions into the continuous improvement process;
these become the starting point (the standards) for the next program.
Cross-checking
Cross-checking is one method employed by Toyota to discover problems
and check quality, especially from the prototype phase onward. This
applies to the process of understanding the true condition of parts and the
appropriateness and accuracy of the measurement system that is being
employed. You can achieve cross-checking by requiring several groups to
check the same parts/data independently. For example, prototype parts

212
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 213

Build in Learning and Continuous Improvement

might be checked on a supplier’s gauge, checked to templates by the body

engineer, and finally checked to a fixture at the build by a prototype tech-
nician. If someone identifies a discrepancy, rather than having one group
necessarily override the other, a detailed investigation is initiated to find
the root cause. In many cases, it is a measurement error (part locating,
holding, and gauging). If this is the case, the team will incorporate a sub-
sequent countermeasure on production gauging and fixtures and, if
appropriate, will update the standards.
Daily wrap-up meetings
Another potent learning and problem-solving mechanism utilized during
design reviews, prototype builds (physical and virtual), tool manufacture,
and launch is the daily wrap-up meeting. Held at the end of each day, typ-
ically on the shopfloor where the work is being done, the wrap-up meet-
ing is attended by all key participants, including suppliers, and is a strategy
that captures lessons learned, clarifies assignments, and generally aids in
real-time, course-correction decisions.

Ignorance: The Ultimate Expense

Many companies view paying for employees to learn as an unnecessary
cost. Anything that is not tactical or does not produce immediate, meas-
urable results is “fluff,” and those who endorse an opposing view are not
considered serious-minded, action-oriented business people. But the
absence of deep technical understanding drives a “more is better” philos-
ophy, which leads to more elaborate gauges, more reviews, more audits,
more inspections, and more checkpoints (because it is always “safe” to
check and check again).
This is an incredibly expensive approach to product development.
Companies that operate from this perspective heap quality initiative upon
quality initiative (QS 9000, ISO, QOS, Shanin, Six Sigma) and commit
scarce human and financial resources to these add-on initiatives, at the
expense of core engineering capability and real towering technical compe-
tence. On the surface, these quality initiatives demonstrate a “commit-
ment to quality” and make people feel that they have accomplished
something. In truth, however, they fail miserably in achieving those things
that guide an intelligent and balanced approach to fostering quality in a
PD process: the time, dedication, and hard work required for a deep tech-
nical understanding of that process.

213
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 214

Section Three: People Subsystem

Such companies, rather than understanding what is truly critical to

vehicle quality, generally focus on the trappings of quality rather than the
essence of quality. As Deming noted, however, you cannot “inspect in qual-
ity”—and this applies to product development and manufacturing. Fur-
thermore, constant inspection tends to create a culture of fear. Engineers
with a “common sense” technical understanding of the critical essentials,
are often afraid to speak out in this kind of environment, because they risk
being labeled “anti-quality.” For this reason alone, the “quality trappings
syndrome” is an insidious and potentially deadly resource-sucking spiral
that can drain the life out of a product development system.

Rapid Learning Cycles

Learning from experience is enhanced by repetition, and this is especially
true for complex or difficult tasks. In automotive product development,
new engineers acquire experience during multiple vehicle development
programs to master their discipline. In companies with very slow-moving
development programs and frequent job rotation, engineers rarely have
the opportunity to experience more than one development program and
focus only on one aspect of the product. On the other hand, companies
with very fast-moving product development programs and less frequent
job rotation have many more learning cycles for engineers across multiple
products—resulting in much shorter learning curves.
Once again Toyota takes Deming’s analysis of the Shewhart PDCA
cycle—plan, do, check, act—very seriously. Every project progresses
through this cycle. Within a product development program, each major
phase is a mini-cycle of the PDCA model; the entire PD program is a
macro-level reflection of the cycle. The faster the product development
cycle, the more can be cycled through it. Most importantly, PDCA devel-
ops towering technical competence and supports continuous learning,
and Build in Learning and Continuous Improvement may be the most
important LPDS principles for companies beginning to develop a lean PD
system. The next chapter connects this principle with the final LPDS prin-
ciple of the people subsystem.

214
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 215

Build in Learning and Continuous Improvement

LPDS Basics for Principle Nine

Build in learning and continuous improvement

The ability to learn and continuously improve may be a lean product

development system’s most powerful competitive weapon. Within this
framework, it is the tacit, “know how” knowledge that is most potent,
the most difficult knowledge to foster and manage. There are no short
cuts or IT solutions. Transfer and application of tacit knowledge
requires close ties and a good deal of time of the sort enabled by struc-
tured mentoring, OJT, strategic and aligned training, and lots and lots
of face-to-face time at the source. Toyota understands the essentials
of its business and builds tacit learning into the way work is performed
every day. At Toyota, tacit learning is not an add-on or extracurricular
activity. It is core curriculum that is learned through hansei, mentoring,
PDCA cycles, excellence in problem solving, teardowns, and other
experiences, all of which are focused on improvement.

215
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 216
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 217

CHAPTER 12

Build a Culture to
Support Excellence and
Relentless Improvement
TPDS is rooted much deeper in the culture in things like genchi
genbutsu, the chief engineer system, kaizen, TPS, etc. It is the totality
of it working together in the culture established across many years
that makes it all work. What is actually happening in your
workplace? A good understanding of that is critical. To have a clear
understanding of what your work is and how you are doing, that is
what is important.
TAKESHI UCHIYAMADA, Chief Engineer of the original Prius

AN ORGANIZATION’S CULTURE DEFINES what goes on in its workplace, and no

company can develop a lean PD system without a strong and vibrant cul-
ture. This chapter, which examines LPDS Principle 10, highlights a num-
ber of significant cultural elements at Toyota. All the other principles
discussed to this point are viable because culture makes them a living part
of how work gets done in a lean environment.

How Culture Can Stand Between You and Lean

Companies that have achieved impressive results applying lean concepts to
manufacturing often think of applying lean concepts to product develop-
ment. One reason for this is waste. As noted in Chapter 5, waste exists in
both manufacturing and product development. The assumption is that if
lean has eliminated or reduced waste in manufacturing, it can do the same
for product development. To assist this transformation, company engi-
neers attend courses on lean product development. Invariably, their
organizations expect them to bring back effective waste-busting tools that
will cut lead-time and cost. Of course, it is not that simple. Comments
from companies whose engineers have taken such courses or have
attempted to apply Toyota’s lean PD tools illustrate the problem:

217
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 218

Section Three: People Subsystem

• We invested millions in a “book of knowledge.” It is a web-based

system and several people were assigned full time to load it up with
standards and best practices. Best practices were solicited from the
field and entered into the system by someone in IT. But we are get-
ting almost no hits—engineers are not using it.
• We created a new role of chief engineer. A bunch of engineers in
different project manager roles were given this new title. But they
still acted just like the old project managers and still did not have
any power to get anything done.
• We value stream mapped and came up with great ideas. We created
A3s and developed action plans. Then we got three new programs
dumped on us, the crisis mode kicked in, and the action plans
went out the window.
As these examples show, companies cannot simply have their engi-
neers learn and apply these powerful tools and then sit back and watch the
waste evaporate. What is missing is a lean culture to sustain the tools.
Loosely defined, culture is the soft, imprecise, fuzzy stuff of everyday life.
Within any company, it is what people think and believe and what drives
daily priorities. Leadership and a company’s culture are inextricably inter-
twined. Culture defines who emerges as a leader and leaders define the cul-
ture. Edgar Schein (1988), one of the leading authorities on organizational
culture, provides a more formal definition of culture as:

. . . the pattern of basic assumptions that a given group has

invented, discovered, or developed in learning to cope with its prob-
lems of external adaptation and internal integration, and that have
worked well enough to be considered valid, and, therefore, to be
taught to new members as the correct way to perceive, think and
feel in relation to those problems.

An explication of four key concepts in this definition follows:

1. Culture operates at an unconscious level. By basic assumptions,
Schein means that culture, our core belief system, begins at an
unconscious level, the roots of which go back to early life experi-
ences. As individuals grow up and mature, they learn what is right
and wrong, what is good and bad, what they enjoy and what they
want to avoid. In much the same way, as people enter an organiza-
tion and begin to find their way around that organization, they

218
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 219

Build a Culture to Support Excellence and Relentless Improvement

learn what it values and rewards and what it punishes. People

modify their behavior accordingly, even though their deep-seated
personal cultural assumptions remain. The Toyota culture uses
many basic assumptions for defining the best way to “perceive,
think, and feel.” This is especially true in relation to problem solv-
ing and is a major reason why Toyota’s PD system is difficult to
teach—woven throughout its many tools and techniques are
assumptions on behavior that are rooted in both the Toyota and
Japanese culture. For those who grew up in Japan and who have
been at Toyota for many years, it is difficult to articulate a culture
that, for them, is second nature.
2. Necessity-driven and empirically-based production system. Toyota’s
PD system was invented, discovered, and evolved over decades to
cope with Toyota’s unique challenges in dealing with external
adaptation and internal integration. Toyota’s external adaptation
challenges started with building an automotive company from
scratch in a weak, post-World War II economy. The challenges of
internal integration were shaped by the “collectivist” Japanese
environment in which most companies assume employees should
subordinate their individual desires to the needs of the company
that employs them. This cultural and economic context—the fact
that the people had to band together to survive—made it rela-
tively easy for Toyota to get suppliers to buy into its specific goals
and processes. A corollary to this is that a collaborative spirit is
essential to lean product development. Historically, Toyota’s PD
system emerged from trial and error and from a scientific method
used to find real solutions to real problems that were rooted in the
broader socioeconomic context of the time.
3. Adapting systems. Toyota has made a tradition of adapting new
methods that work and fit into its cultural framework. Very sim-
ply, if a system or tool works, it is kept and used but only after it is
adapted precisely to a Toyota process. If it cannot be adapted, it is
dropped. This reflects Toyota’s empirical approach: working to
find real solutions to resolve real problems in actual experience
and not falling into the bureaucratic trap of letting internal beliefs
or policies dictate the best way of doing things.
4. Learn the system by doing. Toyota uses an explicit approach for
teaching the Toyota PD system to new employees in real-time and
real situations. People do not learn the Toyota Way in a classroom

219
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 220

Section Three: People Subsystem

or online. As discussed in Chapter 9, senior mentors take on the

responsibility of developing subordinates, and young engineers
learn by doing. Learning at Toyota is also a process of socializa-
tion. Although leadership style is not identical, every Toyota leader
teaches the same core assumptions with a very clear set of beliefs
about the philosophy of the Toyota PD system. The expectation is
that everyone will have the same shared beliefs and clear precepts
about what is considered good and bad practice in engineering
and work toward the same goals.

Things that support how to “perceive, think, and feel” in relation to

problems include some concepts already covered in this book: genchi gen-
butsu, set-based thinking, reverence for technical excellence, hansei, and
putting the customer first. This broadly-shared cultural DNA is funda-
mental to the success of lean thinking. Paradoxically, this same cultural
DNA is one of the reasons it is a challenge, even within Toyota, to teach the
lean product development system to new employees globally.
In his comprehensive explanation of culture, Schein also explores the
“strength” of a culture. By definition, culture is shared among members or
a group. Of course, not every individual will perceive, think, and feel in the
exact same way. In statistical terms, the shared variance is the culture, and
individual variation indicates deviations from the culture. Thus, a strong
culture is one in which many things are shared by a large cross-section of
people. Of course there are good and bad strong cultures, highly effective
and highly ineffective. Obviously, 100 percent consistency is impossible to
achieve—people, after all, come from different backgrounds. Diversity of
views can be a strength in problem solving. But Toyota works hard to
bridge differences, and as a result, most Toyota employees do share basic
assumptions about values, priorities, and how to get work done. In other
words, culture at Toyota is strong.

A Tool Is Not a Solution

An engineering vice president who heard about Toyota’s A3 reports
required every engineer in his organization to develop at least one A3 per
quarter. Engineers took their original reports and spent days squeezing
them down to A3 size to meet the requirement. But simply buying reams
of A3 paper, requiring engineers to write A3 reports, and expecting to get
the same results as Toyota will not work. At Toyota, A3 works because it

220
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 221

Build a Culture to Support Excellence and Relentless Improvement

takes place within a particular cultural context (see Chapter 14). As the
reader has already seen, Toyota has a long history of training engineers in
rigorous methods to collect information, identify real problems, get at
critical essentials, consider multiple potential solutions, get broad input
through nemawashi, creatively develop root cause countermeasures, and
use discipline in implementing. Once all of this is in place, Toyota engi-
neers follow up with standardization and continuous improvement. A
well-socialized Toyota engineer almost intuitively knows that getting input
from all the right people is necessary and he or she has learned from expe-
rience the value of presenting information concisely and visually. Without
this cultural context, the A3 is a mechanical requirement, an exercise in
summarizing complex information to please the boss. Without a deep
thought and consensus-based process, the A3 report is a tool generated for
the wrong reasons. In lean thinking, it is the process of producing not the
result of producing the A3 that makes it a powerful method.

Contributing to Customers, Society, and Community

As described in The Toyota Way, the roots of Toyota’s culture can be traced
to the founder of Toyoda Automatic Loom Works, Sakichi Toyoda. Estab-
lished in 1926, the company was Sakichi Toyoda’s response to seeing his
mother and others working their fingers to the bone weaving on primitive
manual looms. The founder’s invention eventually led to patents, globally
respected Toyoda power looms, and great wealth. Sakichi Toyoda could
have retired a rich man and let his son inherit his wealth and live in lux-
ury. But the purpose of the loom company was to contribute to society,
and to fulfill this purpose, so Sakichi Toyoda challenged his son, Kiichiro,
to continue this spirit of contribution. When Kiichiro returned from Eng-
land after selling a loom license to the Platt Brothers for 100,000 pounds,
he used these funds to finance the Toyota Motor Company, which was
established to continue the family’s legacy of contributing to society.
There are several ways Toyota pursues this idea of social contribution.
“Customer first,” for example, is a basic belief and a lean principle that a
company should exist to serve society. In many companies, a customer-first
attitude is replaced or subverted by a me-first culture, which trickles down
from the executive suite all the way to the engineers and the workers on the
shopfloor. Another way Toyota contributes to society is by providing jobs
in communities where Toyota cars are sold. A company that focuses as
much attention as Toyota does on eliminating waste in manufacturing,

221
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 222

Section Three: People Subsystem

might find it pragmatic to lay off employees during slow periods. Toyota’s
practice is to keep employees on the job, relying on attrition or severance
incentives that encourage employees to leave voluntarily rather than laying
them off. As the LPDS Principles 5 through ten show, Toyota is about people
and for people. When Toyota managers say, “people are its most important
resource,” it is not a hollow platitude. To this day, the Toyota Way is to think
beyond individual and short-term concerns to the long-term good of the
company (including the employees of the company) and society.

Technical and Engineering Excellence Are Intertwined in

the Culture
As discussed in Chapter 9, for most companies, technical excellence is
about hiring people with the right skills and educational background.
During the hiring process, a company may make an effort to determine
whether a candidate will “fit” in the company environment. Once a candi-
date is hired, however, there is often little (if any) effort to instill or rein-
force deep-seated cultural values. This is counterproductive. In a lean PD
system, getting a top student from a top engineering school guarantees
only one thing—a smart young person who has an opportunity to learn to
be a real engineer. At Toyota, formal education is a foundation that is not,
in and of itself, useful until employees have been fully acculturated.
Toyota’s cultural structure includes the following precepts:
• Run by engineers, making it a technical hierarchy
• Fundamentally a manufacturing company that translates into
core value-added manufacturing activities and those supporting
manufacturing
• Focuses on developing technical mastery using the “hands on”
Toyota scientific method
• The individual engineer is central to the product development system
• Learning and continuous improvement (every-day kaizen) is
fundamental to how work gets done
• Process discipline, hard work and loyalty is expected of everyone
(especially leaders)
• Data focused
These cultural precepts go back to Sakichi Toyoda, the “king of inven-
tors,” who learned from the ground up how to build power looms that
used steam engine technology. Following his father’s example, Kiichiro

222
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 223

Build a Culture to Support Excellence and Relentless Improvement

Toyoda likewise learned basic automotive technologies and processes from

the ground up. Given this tradition, some might find it strange that Fujio
Cho, who became president of Toyota Motor Company in 1999, was not
from the Toyoda family or even an engineer but a lawyer who graduated
from the University of Tokyo in 1960. How, one might ask, could a lawyer
run a technically-oriented manufacturing company? The answer lies in the
way that Cho was acculturated.
After joining Toyota, Cho spent 14 years in different staff jobs. Then in
1974, he was assigned to work with Taiichi Ohno to apply TPS to admin-
istrative operations. From that point on Cho’s life changed. He was men-
tored by Ohno, whose style was a harsh combination of beating up,
pressuring, and cajoling. Under Ohno’s guidance, Cho learned that to
improve administrative operations he had to go back to the basics of
understanding how TPS applies in the factory. Schooled in the harsh col-
lege of Ohno’s TPS—all on the shopfloor—Cho eventually became an
expert in TPS. He was so respected within Toyota that in 1988, he was
assigned to open Toyota’s first wholly-owned factory in the United States,
the Georgetown, Kentucky, plant. At the plant, Cho made daily visits to
the shopfloor to teach TPS directly to shopfloor team members and lead-
ers. His immersion in technical practices on the shopfloor later earned
Cho an honorary Doctor of Engineering degree from University of Ken-
tucky. It was the sum of these experiences that ultimately led to Cho being
named president of Toyota Motor Company, a position that he was able to
achieve only with a deep understanding of TPS.
The point of this story is twofold. First, it illustrates how Toyota devel-
ops, mentors, and invests in its personnel. Secondly, it illustrates what a
culture of technical excellence means: Everyone in the company, from the
shopfloor worker to the president, believes that the purpose of the com-
pany is to add value and that the way to add value is by perfecting a tech-
nical process. In lean thinking, having people do technical work to perfect
technical processes is the highest value within a company. Nontechnical
personnel exist to support this primary mission.
As emphasized throughout this book, Toyota is a manufacturing com-
pany run by engineers. This is important in a lean PD system because it
makes the individual engineer the center of that system—all decisions,
processes, and ideas germinate from the individual engineer working in
teams and reporting up to the chief engineer. What develops during this
process is “towering technical competence” that comes from learning by
doing from the ground up rather than from technical training exercises

223
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 224

Section Three: People Subsystem

that “upgrade” engineers. In a lean PD system, being an engineer is a call-

ing rather than a job. In combination, these are the elements that make a
company a culture of technical excellence that is firmly grounded in techni-
cal mastery, both in product development and manufacturing.

Discipline and Work Ethic

Technical excellence can mean many things. There is, for example, the
image of the brilliant but absent-minded inventor who gets intensely pas-
sionate about the invention of the moment, losing track of time and place.
The brilliant inventor can be completely disorganized, go on work binges,
make a mess and then take time off, leaving other people to try to clean up
the mess. Turn 180 degrees and you see what technical excellence means
within the Toyota culture, which expects something quite different. Toyota
engineers, like the brilliant but absent-minded inventor described above,
are expected to work hard, work long hours, demonstrate significant tech-
nical knowledge, and be passionate about their work. However, the key
difference is that they must be dedicated to The Toyota Way and commit-
ted to the discipline that entails.
When Toyota developed the first Prius, then President Okuda pro-
claimed that the car was the future of Toyota. Toyota engineers worked
slavishly, canceling all vacations, to meet timelines for a car that was, in
many respects, a total novelty in the automotive industry, one that
required new and unfamiliar technology. In September 1996, after years of
working on the concept, the engineers involved in this preliminary process
formally presented their styling concept to the board for program funding
approval. The board approved the detailed plan and funding for develop-
ment and what ensued was a marathon race to reach President Okuda’s
target date of December 1997—an unprecedented 15-month development
cycle (which later moved even earlier to October). Everyone understood
that achieving this aggressive goal and its corresponding timing targets
meant personal sacrifices. As an example, Mr. Yaegashi, who was a senior
manager late in his career and did not expect to lead a major engine devel-
opment program again, was recruited by a board member to lead the
hybrid engine team. He negotiated vigorously with the executives for con-
trol and for the best people (not money or position for himself). After
explaining the situation to his wife, he moved into the company dormitory
so that he could completely immerse himself in the enormous task at
hand. Mr. Yaegashi was doing what so many Toyota engineers have done

224
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 225

Build a Culture to Support Excellence and Relentless Improvement

during the course of the company’s long history—he put the company
first. His top priority during the hybrid-engine development process was
to sustain this commitment until the hybrid engine was completed. A per-
sonal life would be a distraction.
Chapter 10 described how outside suppliers become seamless exten-
sions of Toyota. This extends to the way in which suppliers’ engineers
interact with the Toyota culture. They are expected to be dedicated to the
company and have a strong work ethic, characterized by technical excel-
lence and discipline. When Toyota decided to establish a joint venture with
Matsushita to outsource the Prius battery technology, it first had to be
convinced that these qualities were in place. Toyota’s Electric Vehicle Divi-
sion had already codeveloped with Matsushita a nickel-metal hydride bat-
tery for an electrical version of the RAV4 sport utility vehicle, so the
company had a successful track record. Nevertheless, Toyota was con-
cerned about the differences in the companies’ cultures and whether this
would interfere with producing a high-quality battery. This concern was
alleviated when lead engineer Fujii noticed that a young Matsushita engi-
neer was pale and haggard. When Fujii discovered that the reason was that
the engineer had been up all night working, he relaxed (Itazaki, 1999). The
dedication he saw made him confident that that Toyota and Matsushita
could work together despite their cultural differences.
Toyota and Matsushita ultimately ironed out any cultural disparities
and produced a world-class hybrid vehicle battery, but that is not the main
point of the story. What really matters here is that Toyota values discipline
and work ethic and requires these of everyone—inside and outside the
company. All lean processes and tools described in this book are 100 per-
cent dependent on this discipline and work ethic paradigm. The following
examples show how and why.

• Standardization and working to process. Kaizen begins with a stable,

standardized process (see Chapter 13). All Toyota engineers believe
in the importance of standardization—investing in creating and
improving on standards and then strictly adhering to them when
they have been selected as the standards.
• Maintaining schedules. It is easy to use project planning software to
make beautiful charts with detailed timing, but Toyota engineers
actually take them as gospel and follow them precisely. For
instance, it is not entirely unusual for Toyota engineers to sleep
near their worksites to ensure that they start or finish something

225
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 226

Section Three: People Subsystem

exactly on time. Consider some of your most important deadlines,

the deadlines you would move heaven and earth to meet. Toyota
engineers view all schedules and deadlines in this way.
• A3 disciplined communication method. The process of boiling a
project down to the essential facts and creating a visual one-page
report is excruciating. Americans who work for Toyota report that
this is one of the most difficult and at times frustrating processes
to learn. You must have disciplined workers who have an absolute
commitment to the process, no matter how uncomfortable and
onerous that process is.
• Nemawashi. A key part of A3 report writing is the process of get-
ting consensus while the task is in progress. Meeting after meeting
with person after person seems tedious and wasteful. If this proce-
dure is not ingrained in the culture, engineers will quickly begin to
find shortcuts, but these inevitably defeat the purpose.

Following all of these detailed processes involves intensive communi-

cations and meetings and takes a lot of time and goes well beyond a 9 to 5
mentality. When Japanese coordinators come to the United States to work,
they often leave their families in Japan. Then they do what they did in
Japan—work long hours. This sends a strong and sometimes disturbing
message to their American colleagues that, for Toyota employees, there is
little life outside of work. Most Japanese businesses do not have “work-life
balance” programs. But Toyota soon learned that other countries, like the
United States, have their own culture and realized that it would have to
adapt to this by developing a hybrid culture that would accommodate cul-
tural differences without destroying either parent culture in the process.
In the United States, for example, family and personal interests are
important—life does not begin and end with work. This does not stop
Toyota from pursuing its commitment to discipline and the work ethic in
its U.S. affiliates. Toyota looks for and finds engineers committed to their
craft, individuals who love technical work and have a strong work ethic
with a high degree of discipline. Moreover, Toyota leadership reinforces
this by its commitment to creating excellent engineers.

Everyday Kaizen
One phrase that is constantly heard at Toyota is, “It’s how we work, how
we do our job every day . . . each time a bit better.” The phrase is a reflec-

226
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 227

Build a Culture to Support Excellence and Relentless Improvement

tion of Toyota’s commitment to kaizen. Kaizen is not a technique; it is a pas-

sion and way of life. Without a culture of kaizen, there can be no lean prod-
uct development process. But what does this mean and how can it be
translated into processes? A simple way is to show what happens during a
PD process. Engineers set specific, measurable, component-level goals to
build continuous improvement into each program, and every program is
an opportunity to improve over the last program. Every stage in the pro-
gram is a learning opportunity. Everyone learns from the first prototype
and does a better job on the second prototype.
One thing inherent to the kaizen spirit is humility, because once you
believe you are the best and unbeatable, kaizen is dead. In 2004, Toyota
reached what most Japanese and U.S. companies saw as the pinnacle of suc-
cess—over one trillion yen in profit ($10 billion) and growth, year in and
year out. Nonetheless, President Fujio Cho perceived a threat and declared
a crisis. The threat was complacency. This was not an anomaly; it is simply
one example of how Toyota constantly needs to reinvent itself (Automotive
Industry Management Briefing Conference, Traverse City, August 2004):

Why in the world would we want to re-invent ourselves when

business is good? Because any company not willing to take the risk
of reinventing itself is doomed. The world today is changing much
too fast. If you are not busy reinventing your company, I guaran-
tee you are falling backwards. Even worse, your customers are
probably looking elsewhere.

During this same time of unparalleled success at Toyota, we found the

spirit of kaizen not just with the president, but throughout all levels of
Toyota. It was very common for engineers and managers to tell us about all
the challenges they faced and how much work remains to be done in their
particular area of responsibility. We do not recall a single incident where a
Toyota employee, at any level, communicated a sense of complacency.
Desperate attempts to implement kaizen to reduce cost to save a com-
pany on the brink of bankruptcy is something any company would be will-
ing to try, but this “survival instinct ploy” is a poor indicator of how kaizen
works. The real test of kaizen is what a company does when it is on the
brink of unprecedented success. At Toyota, engineers and managers alike
have told the authors that “really we are not so good, we have many prob-
lems still,” afterward reciting an extensive list of hard work yet to be done.
This is the humble spirit of lean culture.

227
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 228

Section Three: People Subsystem

Customer First Spirit

At Toyota, one common denominator aligns everyone to the same goal. To

determine what this common denominator is, consider the following
questions:
• How can Toyota make a matrix organization work? In most com-
panies with a matrix, engineers have conflicting allegiance to the
functional boss and the program manager.
• How do different Toyota chief engineers avoid competing for the
best resources?
• How does Toyota use metrics and incentives to direct engineers
toward common goals?
• How do Toyota engineers work cooperatively with styling instead
of fighting over appearance versus function?
• How do product engineers work cooperatively with manufacturing
instead of pursuing only product engineering objectives?
The answer to all these questions is the same. It is customers come first.
There are many examples that illustrate how important this concept is to
Toyota; the one presented here should suffice to show how overarching
this concept truly is. In an interview with a group of Toyota body engi-
neers, the authors asked about their early interaction with stylists from the
design studio in the kentou phase of any particular program. In this phase,
designers responsible for styling present various clay models to engineer-
ing and engineering anticipates problems they will have from an engi-
neering and a manufacturing perspective. They develop many study
drawings to explore solutions. When asked how they resolve differences
when the best engineering solution does not correspond to the most artis-
tic design, the engineers were more than a little surprised. They responded
to this “strange” question by explaining styling and engineering functions
in terms of customer satisfaction. Styling, they observed, is trying to give
customers an attractive car they will feel proud to own. Engineering’s job
is to realize Styling’s vision without compromising aerodynamics, func-
tionality, or producibility. Engineers work hard to maintain the integrity
of styling—because their direct customers are the stylists.
Not long after this, one of the authors gave a presentation on Toyota’s
system at the design studios of one of the big 3, recounting the story
described in the previous paragraph. After the talk, a senior designer
approached him and said: “I almost fell over in my chair when you told

228
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 229

Build a Culture to Support Excellence and Relentless Improvement

that story. Engineering at our company is king. If our styling causes prob-
lems, they simply change it. They would never say we are their customer.”
Ironically, engineers in the same company have told the authors that their
styling colleagues think they are “king” and will not yield at all to make a
design manufacturable. This is clearly a cultural issue with neither party
willing to give in for the sake of the ultimate customer—the person who
buys the car.

Learning DNA
The learning organization was discussed at length in Chapter 11 and is
revisited here from a distinct but corroborative perspective. Toyota
strongly believes that the capacity to learn is the main source of competi-
tive advantage and that continuous improvement is about learning. Toyota
has two major cultural biases with regard to learning:
1. Learning is tacit. This is the most important one. By definition,
you can only transfer tacit knowledge when there are dense ties
under the guidance of a skilled mentor. At Toyota, every leader is a
teacher—personally training and coaching junior people in the
Toyota Way.
2. Learn by doing which means trying. You cannot learn by theoreti-
cally determining the best way and then executing only the best
way. There are many possible solutions, and you can only learn by
trying them, enjoying your success, and reflecting on your fail-
ures. If you are always trying to figure out the best theoretical
solution, you will be in a constant state of waiting, missing many
opportunities to learn.
Toyota leaders often refer to this learning-by-doing way of thinking as
part of the Toyota DNA. It is in employees’ genes to try out options and
learn from actual experiences. Leaders are guides, encouraging and watch-
ing for the right opportunities to impart significant lessons. This applies
to all associates and to outside partners as well. Andy Lund, an American
program manager for the Sienna minivan at the Toyota Technical Center,
explained how he learned this from a Toyota Japanese quality engineer
before joining Toyota:

A TMC Japanese quality engineer came to our plant from Toyota

to conduct an audit. He explained that the value of a bad part is

229
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 230

Section Three: People Subsystem

ten times the value of a good part because you will learn so much
more from that bad part on how to prevent the problem from
recurring again. If we go to a line and there is no bin for bad
parts—a Toyota engineer will ask: “Let me see your bad parts.” In
the early stages of launch of Sienna, we have in effect a 100 percent
return policy. If there are any defective parts on the Sienna, we
request the dealers to return the defective parts back to the plant
so that the Toyota quality engineers can review the actual part.
That is part of genchi genbutsu—looking at the actual part, not
just reading the field report, which we do first of course.

Accountability and Responsibility

Teams, teams, and more teams are almost an obsession at Toyota. Credit
goes to the team. Teamwork is the key to success. Paradoxically, however,
there is a saying at Toyota that “whenever everyone is responsible, no one
is responsible.” Every engineer must be accountable—everyone must
deliver. At Toyota, no one wastes time blaming or criticizing others, but
in the end, someone is responsible if something does not go right and
that someone stands up and takes the blame (or accepts responsibility)
for failure.
This willingness to accept responsibility is the spirit of hansei (see
Chapter 11) at work. When a program is running late because dies were
late, some individual will say it is his or her responsibility to get the dies
done on time. If a component part did not work out, some engineer will
take responsibility for not considering alternatives carefully. Hansei is
about reflecting, identifying things that did not go well, and then taking
responsibility. As one senior executive explained: “You need to feel really
bad and promise never to make this same mistake again.” Feeling bad and
sincerely committing to doing better in the future is the driver that sus-
tains kaizen. As the same executive observed, “You can not have kaizen
without hansei.”

Team Integrity
In a company that views learning and improving its people as essential to
create and sustain a competitive advantage, the main job of leaders is to
invest in teaching. Part of this is knowing how to treat the people being
taught. A corollary to this is knowing what not to do:

230
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 231

Build a Culture to Support Excellence and Relentless Improvement

• Don’t lay off people at the first sign of each business downturn.
• Don’t pit people against each other so you can reward the winners
and turn off the losers.
• Don’t leave new employees to their own devices or ambitions to
learn on their own.

The good old days of lifetime employment seems to have largely dis-
appeared from most businesses in Japan. At Toyota, however, this tradition
is alive and well. It is unlikely that anyone knows or remembers the last
time a full-time Toyota employee was fired. What is known is Toyota’s pol-
icy of dealing with employees who stop adding value. These people get a
“seat by the window,” meaning they get assigned to a job where they can
do no harm. A manager, for example, to whom no one reports, has a seat
by the window and is assigned tasks that cannot injure the company or
anyone it. While some might see this as a “cushy job” with few headaches,
in the culture of Toyota, where everyone feels self-imposed pressure to
perform at a high level, this is a very embarrassing position to have.
In choosing this solution and other solutions aimed at protecting its
integrity, Toyota maintains and nurtures the “towering technical compe-
tence” discussed in Chapter 9. Developing this competence is a very struc-
tured process, with a common set of socialization experiences, imprinted
upon new employees as soon as they join the company. Some might call this
“indoctrination” and shudder at the thought of individuality being stamped
out. To an extent, they would be correct. It is indoctrination, but its objec-
tive is not to eliminate free and creative thought. The true objective is to
indoctrinate each employee into the Toyota Way while supporting and
encouraging the creative thought needed to approach problem solving or to
offer new perspectives—within the context of how Toyota gets work done.
To achieve this, certain tenets of the Toyota Way are “grafted” into
employee DNA. For example, engineers must readily learn about and
accept genchi genbutsu, nemawashi, kaizen, the value of people and part-
ners, the role of the leader as a teacher, and the spirit of challenge can all
be considered DNA genes. If everyone has a different perspective on such
core issues, there will be no Toyota Way, and Toyota will lose the “golden
egg” that gives it a competitive edge.
What keeps Toyota teams aligned are common objectives, beginning
at the top and cascading to the bottom. The hoshin planning process (dis-
cussed in Chapter 15) determines goals company-wide; every employee
has objectives that are developed with his or her immediate supervisor,

231
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 232

Section Three: People Subsystem

and these objectives dovetail with the objectives of the next level up. Pur-
suing individual objectives aligns individuals into teams working toward
company objectives. This is possible only in a culture that accepts working
toward objectives outside one’s own individual interests.

Managing Upward, Downward, and Sideways:

Hourensou Management
Unfortunately, many modern-day engineering managers believe their role
in an organization is to attend meetings, keep abreast of the latest organi-
zational politics, make the tough decisions about the big problems in the
company, and generally look upward and outward. The philosophy seems
to be that a good manager is good at delegating, and good engineers
should work autonomously.
The principle of “hourensou” suggests a very different image of the Toyota
manager. This Japanese management concept can be interpreted as Hou (hou
koku—to report), Ren (renroku—to give updates periodically), and Sou (sou
dan—to consult or advise). In other words, Toyota leaders have the responsi-
bility of staying informed about the activities of subordinates so they can
report on key activities, give updates to their leaders, and advise subordinates.
We saw this in action when George Yamashina was president of the
Toyota Technical Center in Michigan. Yamashina seemed to be everywhere
at once, wandering about, asking questions, talking to technicians. All of
his managers were required to send him an e-mail at the end of each day,
summarizing in bullet points the key activities for that day. He got over 40
messages a day from his subordinates, and, reading them, particularly in
English, was time consuming. Nonetheless, he believed it was a very
worthwhile investment and read each one.
Yamashina had a broad view of the entire organization. To see the big
picture, he was constantly in motion, traveling from the Technical Center
in Ann Arbor to manufacturing sites where resident engineers were
located to the Arizona proving ground, to headquarters, to Japan, and
back in an endless cycle. When questioned about this, Yamashina
explained that by seeing the pieces, it was easier to see the whole. For
example, if one engineer in one part of the organization had already had
run tests with negative results, there was no reason for another engineer in
a different part of the organization to run the same test and discover the
same thing. The test result of the first engineer could be provided to the
second engineer and that would be that.

232
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 233

Build a Culture to Support Excellence and Relentless Improvement

The authors had an insightful conversation on the subject of houren-

sou with Yamashina and several American Toyota managers. One of these
was Chuck Gulash, vice president of the Toyota Technical Center, who
admitted that he was at first turned off by this practice:

Initially I was rejecting the concept because it seemed like micro-

management. Now I fully support the activity and I think I under-
stand it. I always believed in management by walking around, but
what was it I was supposed to be learning by doing that. So what?
You walk around. Hourensou provides an efficient and disciplined
way of knowing what is going on for me as an executive and allows
for sharing across the organization.

This quote vividly reflects the clash of Toyota’s culture with a typical
U.S. management culture. In the United States, “nosing around” is being
a bus body. It is a form of micromanagement. An effective manager should
delegate and then stay out of the engineer’s way. For a Toyota manager, this
is simply abdicating responsibility. How can you consult and advise if you
do not know what is going on? If you have no more information about
what is going on across the organization than any other engineer, what is
your value?

The Right Process Will Yield the Right Results

Information gleaned during the authors’ interviews with Toyota engineers
and managers in Japan and the United States shows that, among those who
are Japanese, many aspects of the lean culture are engrained and have a
direct influence on how they think and act. The three lean culture subsys-
tems—process, people, tools and technology—are truly part of their DNA.
Toyota has done well in indoctrinating U.S. managers and workers in lean
thinking, but getting these people to live and breathe “lean thinking”—
which is what their Japanese counterparts do—is a bit of a struggle. Japan-
ese managers believe unwaveringly that the Toyota Way is the right way. For
them, there is no question that: There is a process for doing everything and
following that process will lead to positive results. Cutting corners may work
from time to time but will not consistently lead to excellent results.
Most U.S. managers do not believe with the same conviction until they
see incontrovertible evidence that makes them believers. Andy Lund
explained the tensions he sometimes felt as Sienna program manager

233
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 234

Section Three: People Subsystem

between the Toyota Way and the expedient way. For example, part of his
job was to lead the hansei at the end of the program. In his role as program
manager, he led sessions devoted to reflecting on the program and had to
gather a lot of information and use the five-why method to analyze the
root causes. He met with engineer after engineer to listen to their points of
view on what had happened; frequently, he wondered whether talking to
yet another person would be of any value and was tempted to skip some
people. But each time he talked to a person he had considered skipping
over, he learned something surprising and informative. Lund’s struggle
was cultural: a battle between Toyota’s belief in the process and his Amer-
ican roots, which urged him to reach a conclusion quickly. What empha-
sizes the depth of this struggle is the fact that Lund grew up in Japan.

The Culture Supports the Process

Many automakers would like to adopt Toyota’s lean PD process. Some have
instituted major initiatives to learn from Toyota and are all too often dis-
appointed. They have tried A3 reports, functional build (screw body build),
a CE role, hoshin planning, and a know-how database. Each of these tools
has been helpful for a while, but their effect has eventually dissipated and
the tools themselves have fallen into the black hole of disuse. In most cases,
engineers and managers lost interest or returned to old ways that more or
less work. The main reason companies have so much difficulty adopting
and sustaining these simple, common sense principles is culture. Figure 12-1
compares the cultures of Toyota and NAC, the company that has been used
throughout this work as the antithesis of true lean thinking.
A quick glance shows how diametrically opposed Toyota and NAC are
on every critical dimension. NAC is a business driven company; meeting

Toyota NAC
Technical excellence Business excellence
Process discipline and work ethic Results focus
Kaizen every day New initiatives
Planning and detailed execution Just do it
Learning DNA No problem

Figure 12-1. Contrasting Cultures at Toyota and NAC

234
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 235

Build a Culture to Support Excellence and Relentless Improvement

expectations for quarterly profits for Wall Street is the highest objective, so
it has a finance-dominated culture. Technical excellence is secondary
because NAC is about getting bottom line results in any way at any cost.
Where Toyota reveres technical excellence and invests heavily in the devel-
opment of its people, many NAC executives are fond of saying that “costs
walk in on two legs” and focus efforts on people reduction, even if this
may lead to losing core competencies. Toyota is about the process. Follow
the right process and you will get the desired results. NAC is often moti-
vated by the latest, cutting-edge initiatives and technologies that can make
work easier and faster—shortening the line between two points. Forget
about the daily mundane activities, like detailed engineering, or building
cars that are not exciting. In contrast, Toyota is about continuously
improving mundane processes. Engaging in detailed planning to an
almost compulsive degree is the norm at Toyota. NAC’s result orientation
leads to a “just do it” mentality, without an effort to capture any learning
to leverage for the next program. Toyota is all about learning, program to
program, engineer to engineer. At NAC, asking for detailed explanations
of what has been done before is considered rude and a sign of incompe-
tence. A quick smile and a reassuring “no problem” is typical of NAC engi-
neers, no matter how complex a task is assigned. The same behavior at
Toyota would raise eyebrows. How can you do a good job in the Toyota
Way without deep questioning, nemawashi, going to see for yourself, shar-
ing insights with the team, and learning as an organization?
Given the culture at NAC (and similar companies), it is no real won-
der that implementing and sustaining Toyota-like development processes
can be nearly impossible. Three examples of what tends to happen are pre-
sented below.

Chief Engineering System. In the LPDS Principle 5, you develop a chief

engineer system to integrate development from start to finish. That is, the
chief engineer drives the entire product development system—this is a
foundation of the lean PD system. Several traditional auto companies rec-
ognized this and ordered that their company create chief engineers. In a
bureaucratic culture, this is easier said than done. The typical response
was to change the job titles of program managers to chief engineers and
give them some training to explain their new roles so then they could
become official “chief engineers.” This, of course, raises at least three ques-
tions: Will the new CEs have the technical expertise and organizational
respect to get the job done? Will functional bosses assign the right people

235
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 236

Section Three: People Subsystem

to programs at the right time? Will people who are evaluated by their func-
tional bosses and also report to a chief engineer on a program follow the
instructions of one or the other? It is not difficult to see why this process
is untenable. It is not surprising that the failure rate of these “instant CEs”
was quite high at all of these companies.

Front-load. LPDS Principle 2 states front-load the product development

process to thoroughly explore alternative solutions while there is maximum
design space. By front-loading, you anticipate and solve problems before
tools are even designed and before any capital investment. Toyota uses a
kentou phase to do this. In the result-oriented culture of NAC, new ques-
tions arise: Will the kentou phase be taken seriously? Will engineering
managers assign the best engineers to work on the kentou phase? Will engi-
neers have the time, know-how, or discipline to work through each and
every drawing, root out possible problems, and put in countermeasures?
Will they overcome functional boundaries and turf mentality to work col-
laboratively across functional organizations? In a “just do it” hurry-up
culture, will broad circulation of the kentou lead to deep reflection on each
detailed design feature? The global answer is “not likely.”

Level the workload. In the LPDS Principle 3, create a leveled product

development process flow, leveling the workload depends upon flexible
staffing as the program proceeds. At peak points in the program, you
need to pick engineers and technicians from flexible pools and from
suppliers. Here again, NAC’s culture elicits some interesting questions:
Can the company flexibly recruit engineers who will seamlessly con-
tribute to the engineering process? Will this pool of engineers be prop-
erly trained in the “NAC Way” to understand the design process and
design philosophy? Will engineers from this pool speak the same lan-
guage as full-time career employees? Will they be as motivated as NAC
engineers to contribute to the common goal of putting the customer
first? Again, not likely.
As this brief analysis illustrates, no amount of top-down mandated
process changes or lean tools will penetrate the wrong culture and create
the conditions needed to make lean tools and processes effective. Plopping
the process and tools into an existing, alien culture guarantees rejection, in
much the same way that a body will reject an organ transplant when the
organ is incompatible with the body’s other organs or systems.

236
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 237

Build a Culture to Support Excellence and Relentless Improvement

Leaders Renew the Culture

Companies seriously interested in emulating Toyota’s lean PD design often
ask the following question: “Once we have put these lean tools in place
how can we sustain them?” Implicit in this question is the understanding
that adopting a system does not necessarily mean the system will work and
continue to work over time. There is no guarantee that once a company
puts the effort into lean, the tools will take on a life of their own and sus-
tain themselves. Whether these tools thrive or wither often depends on
leadership. Moreover, it is important to remember that leaders get the cul-
ture they live and tolerate.
Within the Toyota system, leaders serve as the bearers of the Toyota
culture and exemplify the culture in their daily behavior. It can certainly
be tedious to follow the right process day in and day out. No Toyota leader
has ever assumed that lean sustains itself. On the contrary, the company’s
leaders intuitively understand that the natural evolution of a culture will
atrophy and deteriorate unless its leaders are continually renewing and
passing the DNA to others. Expressed in terms of thermodynamics, sys-
tems tend toward the lowest state of energy. Only by adding new energy to
arrest entropy (atrophy), can you maintain or improve a system. Leaders
are the primary source of energy; they arrest the atrophy of lean tools and
keep them thriving and evolving in the culture. It is they who can sustain
lean thinking.
This chapter concludes the five LPDS principles for the people subsys-
tem. The next section of this work examines the third subsystem, tools and
technology, and the final principles, 11 to 13.

237
Morgan Liker sec 3_ch 10–12 3/2/06 11:42 AM Page 238

Section Three: People Subsystem

LPDS Basics for Principle Ten

Build a culture to support excellence
and relentless improvement

Lean tools will not be effective unless used in a supportive culture.

Culture is the way work is done and the way people think about the
work and products. Some of the core cultural values that support
lean product development are genchi genbutsu, set-based thinking,
hansei, and putting the customer first. This broadly-shared cultural
DNA is fundamental to the success of lean thinking and a further
reason why it is a challenge, even within Toyota, to teach the lean
product development system to new employees globally. Key char-
acteristics of Toyota’s high performance culture, which should be
used within your own organization, include the following:
• Technical and engineering excellence must be highly valued.
• The culture must be based on discipline and a strong
work ethic.
• Improving through kaizen every day must be engrained as
the way to do work.
• Everyone involved in the development process must have a
customer-first spirit.
• Learning as an organization must be engrained in the com-
pany’s DNA.
• Individuals must be willing to stand up and take responsibil-
ity when things do not go well.
• Investing in engineers and treating them like valued assets
must be the norm.
• All engineers must step up to challenges as a matter
of course.
• Strictly following the right process for doing the work must
be highly valued.
• Mistakes must be viewed as learning opportunities.
• Leaders must be the culture bearers and lead by example
every day.

238
Morgan Liker sec 4 3/2/06 11:49 AM Page 239

SECTION FOUR

Tools and Technology

Subsystem
Morgan Liker sec 4 3/2/06 11:49 AM Page 240
Morgan Liker sec 4 3/2/06 11:49 AM Page 241

CHAPTER 13

Adapt Technology to Fit Your

People and Processes
The first rule of any technology used in a business is that automation
applied to an efficient operation will magnify the efficiency. The
second is that automation applied to an inefficient operation will
magnify the inefficiency.
BILL GATES, president and CEO, Microsoft

COMPANIES AROUND THE WORLD are trying to find ways to accelerate prod-
uct development, seeing this as a way to improve competitive advantage.
In many cases, their efforts to speed up the PD process focus on advanced
technology. But using rapid prototyping, digital simulations, product life-
cycle management, virtual engineering, and similar tools and technology
to revolutionize PD may not yield the hoped for result, primarily because
technologies are seldom exclusive. Any company can copy or purchase the
tools and technology used by any other company. Successful utilization of
such tools and technology depends on the ability to customize them in a
way that makes them exclusive and integrates them uniquely to the com-
pany using them. No one, for example, can deny that that tools and tech-
nologies have had a significant influence on Toyota’s ability to achieve
development cycles of 15 months and less. But it is important to recognize
that this occurred because Toyota has had the foresight and discipline to
customize tools and technology to fit within a broader framework, one
that includes people and processes.

Five Primary Principles for Choosing Tools

and Technology
Finding one’s way through the “technojungle” is no easy task. Rapidly
changing functionality along with the jungle’s many hidden hazards makes
identifying and choosing the correct path difficult. Decisions about which
tools or technology to adopt and when and how to integrate them into the
organization have significant implications for a company’s PD system. The

241
Morgan Liker sec 4 3/2/06 11:49 AM Page 242

Section Four: Tools and Technology Subsystem

selection process requires a substantial investment of both financial and

human resources and can result in organizational upheaval and the loss of
irreplaceable time, especially if the new tool or technology does not inte-
grate well with the other two LPDS subsystems, process and people. LPDS
Principle 11, adapt tools and technology to fit the people and processes, is a
prime directive for implementing and sustaining a successful lean PD sys-
tem, one that Toyota has internalized exceptionally well. We subdivide this
principle into five highly effective steps or subprinciples.
1. Technologies must be seamlessly integrated. Toyota integrates many
of its product development technologies into its V-Comm system.
V-Comm integrates surfacing/design testing, digital assembly,
simulation and the know-how database into a single seamless sys-
tem, which enables Toyota engineers to move from design to
ergonomic simulation, to update testing results provided by col-
leagues, and to have access to necessary standards and checklists.
This powerful suite of tools and real-time information is made
available to the engineers working on a program.
2. Technologies should support the process, not drive it. Technology con-
sultants often advise, “You need to constantly change your company’s
processes to keep up with the latest technology.” From Toyota’s per-
spective, this is backwards. Changing the process to conform to tech-
nology leads to instability, drives massive process variation, confuses
people, and creates tremendous waste. As companies tinker with
processes to force maximum results from some new whiz-bang
technology to demonstrate the wisdom of their strategy and invest-
ment, they waste time and money. All too often, the state-of-the-art
technology becomes obsolete within a single year. What ensues is a
mad rush to acquire the next technological fad, a move that is often
even more detrimental to an already dysfunctional process.
3. Technologies should enhance people, not replace them. In many
companies, the primary justification for major technology pur-
chases is reduction of labor costs—that is, how many people will
this replace? In a business that is talent driven and dependent on
technical expertise, this is clearly counterproductive. In product
development, it is best to choose tools and technology that make
the best use of engineers’ time and talents. Tools and technology
should never be seen as substitutes for expertise; they should com-
plement expertise.

242
Morgan Liker sec 4 3/2/06 11:49 AM Page 243

Adapt Technology to Fit Your People and Processes

4. Specific solution oriented: not a silver bullet. Technology can pro-

vide high-leverage if a company has a clearly defined purpose for
it. Searching for a nonexistent Holy Grail is futile. Technology is
never a substitute for the hard work that is required to make a
product development system competitive. Its potential lies in
supporting and accelerating that hard work once a lean process
is in place and highly skilled people are appropriately trained
and organized.
5. Right size—not king sized. Many western companies have a ten-
dency to buy the biggest, baddest, fastest, and newest tools on
the market. Our old friend NAC, for instance, often boasts that
it is going to leapfrog Toyota by technological one-upmanship.
This, however, seldom happens and the following example illus-
trates why. For decades, Toyota has successfully used notebooks
for its engineering checklists. NAC developed an impressive
online and fully integrated database, convinced that this innova-
tion would help it zoom past Toyota in knowledge management.
But the data was vacuous, owned by an independent “technology
group,” and rarely used. The point is that electronically storing
data is no substitute for engineers who develop knowledge over
time, create checklists to capture the knowledge, and rely on the
cumulative knowledge and the checklists to ensure that things
are being done properly.

Technology in Lean Product Development

Successful automotive product development relies on the successful appli-
cation of hundreds of diverse technologies. A detailed analysis of those
technologies is far beyond the scope of this book and this section covers
only a selected few that are central to the product development process.
The purpose here is to show how Toyota adheres to the principles dis-
cussed above, avoiding technology pitfalls. To accomplish this purpose,
the sections below are structured as a series of contrasting models (Toyota
and NAC) and how these mesh or fail to mesh with lean principles. It is
important to introduce this discussion by emphasizing that a lean envi-
ronment enables Toyota to 1) find the tool that fits, 2) make it work seam-
lessly in already effective processes, and 3) align the technology and tools
to enhance both product development and manufacturing.

243
Morgan Liker sec 4 3/2/06 11:49 AM Page 244

Section Four: Tools and Technology Subsystem

Digital Engineering at Toyota

Toyota has leveraged an integrated suite of digital tools all along the
product development value stream. They began digital engineering
implementation in Product Engineering and now have developed pow-
erful tools to enable engineers everywhere in product development. This
integrated suite of tools, commonly referred to as V-Comm, includes
their design and surfacing software, digital assembly software, numerous
databases including the Know-How database and database of standard
processes, the assembly sequence, as well as a number of communica-
tion tools.
Toyota has been progressively implementing digital engineering for
the past decade. Beginning with design tools for instrument panels,
stampings and vehicle body assembly in 1996, they progressed through
engine compartment and added supplier-designed parts by 1998. In 1999,
the Scion bB or black box program was the first vehicle to employ a full
suite of digital tools.
More recently, Toyota has adapted a new commercial design software
(CATIA V-5) and has also made dramatic enhancements to their Digital
Assembly software, allowing them to do even more work very early in the
development process.

Design Technology at Toyota

Toyota spends a significant amount of time customizing the design soft-

ware that it uses, ensuring that this software fits its process and methods
before it is used in a product development program. For instance, at
Toyota, the ability to design a part within its working environment and to
view as much or as little of that environment as needed for a complex
product is critical to software design. As noted in Chapter 5, one of the key
elements of Toyota’s design process is to resolve integration issues and
achieve system compatibility before completing designs. In this light the
benefit of this technology is obvious. Designing in an integrated product
environment allows Toyota engineers to view as much of the surrounding
design and as many design variations as they wish. With a single com-
mand, such as “show all parts within some distance of my part,” the soft-
ware lets an engineer see what he or she needs to see within the design
environment. Furthermore, by selecting specific feature codes from the
bill of material, engineers can view variations based on option packages

244
Morgan Liker sec 4 3/2/06 11:49 AM Page 245

Adapt Technology to Fit Your People and Processes

and the like. This helps reduce late engineering changes. Moreover, as part
of the seamless integration, and improved communication the factory and
dealership can use the same feature codes to maintain accurate communi-
cation throughout the enterprise.
Toyota’s design software also supports the LPDS Principle 4 “of rigor-
ous standardization to reduce variation.” By utilizing associative CAD
models of parts, Toyota engineers can easily morph standard construction
sections to fit new design parameters based on preset design rules. For
example, a roof bow (roof reinforcement) section (edge view) is predeter-
mined based on analytical modeling for roll over, etc. As new roofs take a
new sweep to fit the specific styling requirements of a new vehicle, engi-
neers can morph that roof bow to fit the new roof sweep while maintain-
ing critical section proportions.
Engineers can also apply this feature to die and fixture designs, mor-
phing standard components of the tools to fit new part design require-
ments. This saves time in both product design and tool design. At the same
time, it increases performance reliability, further supporting Toyota’s core
principle of reusability and allowing for better integration of design and
manufacturing.
A final important characteristic of Toyota’s design software is that it is
parametric. That is, as changes are made by one engineer that affect
another engineer’s design (whether product or manufacturing), related
parts are adapted accordingly. The changes are highlighted in a different
color and assigned a change code, alerting the second engineer that a
change affecting his or her design has been made. This engineer can then
review the data and contact the first engineer immediately if something
seems amiss. In practice, this clearly supports LPDS Principle 3 because
leveled flow depends on seamless cross-functional execution that prevents
a lot of rework loops. It also supports an engineer’s ability to design in
context “real time” and synchronizes concurrent engineering.

Virtual Manufacturing and Digital Visualization at NAC

We can appreciate the strength of Toyota’s approach to integrating tech-
nology, processes and people by contrasting it to NAC’s use of virtual
manufacturing and digital visualization. Designed to utilize new design
and surrogate design data to check the effects of tolerance stacking for part
clearances/interferences and manufacturing access for assembly, it can also
be used to study manufacturing cycle times.

245
Morgan Liker sec 4 3/2/06 11:49 AM Page 246

Section Four: Tools and Technology Subsystem

From a vehicle assembly perspective, NAC employs this technology

after design data is released as a way to check design accuracy and com-
pleteness. Engineers schedule virtual build events in a large room where
representatives from various disciplines gather for several days to review
issues. This culminates in a summary review by senior leadership. Unfor-
tunately, the virtual build events are scheduled late in the design develop-
ment process and are completely controlled by an isolated specialist group
with no other deliverables. As a result, engineers view the virtual factory
technology as just one more auditing tool that identifies problems. Lots of
issues are reported, but because they are reported late in the process, it is
often too late to do anything more than compromise on design changes.
Rather than learning from the tool and using it to benefit future designs,
engineers see it as a tool that leaves them vulnerable to criticism.
Toyota uses this technology at the front end of a process to identify
problems early. But it is important to note that it is not the software that
identifies problems but the engineers. The software is merely a tool that
generates virtual representations that engineers with deep knowledge can
use to identify problems and solve them. At Toyota these virtual tools,
combined with towering technical competence and excellent problem
solving processes, enable LPDS principle two: Front-load the PD Process to
Explore Alternatives Thoroughly.

Digital Assembly at Toyota

Since the early 1990s, Toyota has employed Digital Assembly (DA) during
the very early kentou phase of development and beyond. By utilizing early
scan, standardized design data, common components, and actual 3-D
manufacturing work station data, Toyota studies part clearance/body fit
up, ergonomics, assembly, cycle times, work station design, fixture net sur-
faces and locators, as well as craftsmanship (interior and exterior vehicle
fit and finish) issues. At Toyota, the work cells, stations, presses, etc., are
actual 3-D geometry from the factory floor, showing precise clearances
and constraints that workers will face on the factory floor. Among other
things, Toyota’s Digital Assembly allows engineers to:

• Study how individual components will be assembled into a vehicle

and identify potential design interferences long before designs
are completed. They can also see the effects of various tolerance-
stacking scenarios and design to maximize best-fit conditions and

246
Morgan Liker sec 4 3/2/06 11:49 AM Page 247

Adapt Technology to Fit Your People and Processes

design in high levels of craftsmanship with specially developed

Digital Assembly (DA) software.
• Use workability DA to study in detail the effects that design
changes will have on ergonomic issues involved in assembling a
vehicle. By utilizing DA in conjunction with the assembly plant
pilot team (hourly workers assigned for two years to work on
preparing for new vehicle launch) during the Kentou period, they
can address both current as well as anticipated human factor issues
and identify the ergonomically safest and most efficient way to
assemble the vehicle.
• Study detailed processes, such as welding or stamping, utilizing
data from a new product. Manufacturing engineering can deter-
mine welder access, cycle times, and even assembly work station
layout in parallel with product engineering.
• Optimize fixture designs using the process planner function of DA
by identifying potential part deflection points and access issues.

In the past, Toyota was unable to study many of these issues until the
first physical prototypes, which, in its view was far too late in the process
because changes were expensive and disruptive. DA resolves both of these
issues and enables designed-in countermeasures before the program hits
prototype. This generally results in fewer prototypes (in some cases none)
and better quality product saving time and money. This, in turn, allows
Toyota to not only start earlier but to exactly match the new product design
requirements to each specific plant in which it will be manufactured.
Further, by putting the power of this technology in the hands of the
individual engineer, Toyota is also adhering to its people principles. The
technology is readily available to design and manufacturing engineers
alike as a part of how they do their work. The availability of these data also
enables engineers to utilize actual design and real world manufacturing
operations information to begin basic Industrial Engineering tasks very
early in the process. Engineers can check sequencing, operating time esti-
mates, stack operations to check against takt times and conduct virtual
simulations to help make design decisions that optimize manufacturing
operations. The result is a technology that helps to drive lean manufactur-
ing to the very beginning of the development value stream—enabling a
lean from the start mentality.
You may recall that in Chapter 6 we discussed how the power of stan-
dardization enabled Toyota to build eight different body types on the same

247
Morgan Liker sec 4 3/2/06 11:49 AM Page 248

Section Four: Tools and Technology Subsystem

line without having to build, maintain, and change expensive pallets for
each body style. These digital tools are critical to maintaining that capa-
bility on new vehicle designs. In addition, by sharing digital information
throughout the enterprise, Toyota can bring multiple functional experts as
well as production associates together virtually to work with specific part
design data, detailed process information, actual manufacturing environ-
mental factors, as well as detailed quality and performance histories to
improve processes and optimize designs for all facets of manufacturing,
including the body shop, final assembly, paint, material handling and sup-
plier shipments.
By employing the technology early in, and consistently throughout,
the process, Toyota is also adhering to LPDS process Principle 2 on front-
loading. It is also making the technology seamless with other technologies
that engineers use. DA is also the primary technology employed at design
reviews. So, in addition to engineer-to-engineer communication, DA sup-
ports full-team or subteam integration.

Finite Element Analysis at NAC and Toyota

Formability finite element analysis (FEA) is a crucial tool for testing struc-
tural properties. In the world of designing dies to stamp out body parts, com-
panies use FEA to predict the formability of the metal and the effectiveness
of the draw die. The draw die is the first (except for the blanking die) and pri-
mary metal forming die in the manufacturing process and has a significant
impact on the rest of the manufacturing process. Consequently, it is impor-
tant to get this die right. Formability FEA software can predict material stress,
strain, compression, thinning, and fracture during the forming operation.
An animation function allows users to see when a defect is occurring
in the forming process and also shows material feed during the forming
process, which can be replicated during the actual die tryout process.
Based on the results of the formability FEA, engineers can modify part or
draw die design to optimize part forming before dies are made.
As powerful as formability FEA can be, its potential has not been fully
exploited at NAC. Despite the 100 percent application of formability FEA,
there is still a great deal of formability failure at die tryout. One reason for
this is that NAC does not standardize inputs to the FEA programs. In addi-
tion, there has been relatively little effort to develop statistically significant
correlation studies between FEA and actual die tryout. To its credit, to
make the FEA tool more effective, NAC has worked at addressing both

248
Morgan Liker sec 4 3/2/06 11:49 AM Page 249

Adapt Technology to Fit Your People and Processes

these problems. Because NAC does not have strong process or design stan-
dardization, the company’s stamping engineers use FEA to test unique
part designs and processes, and the tool does help in this capacity. More-
over, anything that makes FEA more effective will undoubtedly have a sig-
nificant positive impact on NAC’s manufacturing engineering process.
Toyota also uses formability FEA, but on a much more limited basis.
Fewer than one-third of Toyota parts go through the FEA process. Toyota
uses the FEA tool primarily for exceptional or unique parts—an extra step
that it takes only if absolutely required because running FEA takes time.
Because it scrupulously and rigorously implements process standardiza-
tion and high-level design, Toyota seldom needs to predict the formability
of most parts. Applying FEA to standard parts would be a form of waste.
Even so, Toyota has spent a good amount of time developing input stan-
dards for FEA use, and detailed checklists guide both FEA setup and
results interpretation.

Tools for Manufacturing Engineering and Tool Making

People often think of the development process in terms of its eventual
impact on manufacturing. In reality, there is a large amount of manufac-
turing in any product development process; the integration of product
and process design can make the difference between fast cycles with
processes that work right the first time and long cycles with a great deal of
engineering rework at launch. In fact, as Clark and Fujimoto (1991)1 have
suggested, strong manufacturing and manufacturing engineering skills are
critical enablers of excellence in product development. How tools and
technologies for production preparation are used in early product devel-
opment matters tremendously. The following contrastive study of how
tools and technology are used in manufacturing engineering and in tool
machining, construction, and tryout at Toyota and NAC illustrates why.

Checklists and Standardization Tools at Toyota and NAC

Throughout this book, the importance of rigorously applied engineering
checklists (both for product engineering and production engineering) has

1. Kim B. Clark and Takahiro Fujimoto, Product Development Performance: Strategy,

Organization, and Management in the World Auto Industry, Boston: Harvard Business
School Press,1991.

249
Morgan Liker sec 4 3/2/06 11:49 AM Page 250

Section Four: Tools and Technology Subsystem

been emphasized. At Toyota, this also applies to manufacturing engineer-

ing and tool making. In fact, specific process and part-based checklists are
ubiquitous in the Toyota PD system. By and large, Toyota incorporates
these checklists into the macro know-how database, which functional spe-
cialists update at each program’s production preparation stage. As noted
above, this even applies to tools and specific software applications (FEA),
and it goes almost without saying that the use of checklists extends to all
aspects of die design, preparation, and tryout. In contrast, NAC has only
recently begun utilizing standardization tools and checklists (attempting
to learn from Toyota), and only certain individuals on special pilot pro-
grams use them rigorously. If NAC hopes to develop a lean PD system,
these tools will need to become broadly owned and rigorously used.

Solids Die Design: NAC Versus Toyota

NAC recognizes the importance of solids die design and has the technical
computer capability to build solid models. However, it has only recently
begun to utilize it on all die designs. NAC began the solids-based die
design initiative around 2001, and implementation was slow. Suppliers do
all of NAC’s die designs and their resistance to making significant invest-
ments in this technology has inhibited NAC’s transition to solids-die
design. Another issue has been NAC’s insistence on working with in-house
design software and developing its own ancillary applications rather than
using commercially available die design software.
Toyota has been utilizing solids-based die design on all of its die
designs since the late 1990s. Toyota was very aggressive in adopting this
technology and recognizing its potential efficiency impact both on die
design and downstream processes. In its customary way, Toyota worked
intimately with the software company to customize the packages to
Toyota’s specifications, a beneficial relationship that ultimately also
improved the software company’s services to other customers. Toyota
already had a well-developed in-house die design and manufacturing
capability, so it did not have to convince outside die designers to use the
technology.
The benefits of solids die technology are obvious. When combined
with Toyota’s standardized manufacturing processes, solids die design
becomes a powerful tool for synchronizing cross-functional processes and
achieving concurrent execution without rework. Because they have access
to a standardized component library, die designers can select the right

250
Morgan Liker sec 4 3/2/06 11:49 AM Page 251

Adapt Technology to Fit Your People and Processes

component “off the shelf ” even before the product data has been fully sta-
bilized. Solids die design also works with design data in its native form
without the need for conversion and the associated loss of detail.
Using simulation technology supported by solids die design gives the
design group the ability to check clearances, automation and fundamen-
tal die functionality. Engineers can simulate production forming, part
transfer, scrap shed, and can also perform casting stress analysis. When
used in combination with Toyota’s checklists and standards, simulation
eliminates the need for many of the traditional reviews and much of the
rework common at NAC. Toyota can now design its dies with great detail
and accuracy. In addition to simulating actual die performance, Toyota
also utilizes simulation technology to enhance the manufacture of their
dies. It utilizes this capability to simulate die machining, create detailed
bills of materials for dies, and drive standardized die assembly sequences.
This, in turn, enables lean die manufacturing, discussed later in this chap-
ter. Another important advantage to solids die design is that it enables
high-speed pattern building, which is an important part of the die mak-
ing process at Toyota.

Pattern Making at NAC Versus High-speed Pattern Making

at Toyota
Patterns are representative die shapes made of foam and used for casting
dies. Pattern making at NAC has generally been a traditional craft-based
process. About 60 to 70 percent of the pattern is machined; the remain-
der of the pattern shape (depending upon the die/part type) must be built
by hand to pattern prints generated by the die design group. Pattern sur-
face finish is generally too rough for foundry purposes and must also be
hand finished.
One of the benefits Toyota derives from solids die design is its abil-
ity to support a high speed, automated pattern-making process. Toyota
uses a solids die design software suite called CADCEUS to develop a pat-
tern layering strategy that allows it to machine about 95 percent of its
foam die patterns. Three or four long rectangular foam boards are cut to
size and machined into intricate shapes, which are then glued together in
layers to create a single die pattern. This automated process requires less
than one-fourth of the time and none of the highly paid skilled crafts-
men or pattern prints necessary for the conventional pattern building
practiced at NAC.

251
Morgan Liker sec 4 3/2/06 11:49 AM Page 252

Section Four: Tools and Technology Subsystem

Die Machining: NAC Versus Toyota

NAC has made a significant investment in several very large, state-of-the-

art Computer Numerically Controlled (CNC) machines. These machines
are capable of machining dies up to 4,000 mm 3 2,500 mm and machin-
ing at a linear speed of 250 inches per minute (IPM). Because of the
increased machine speeds, NAC has reduced its stepovers to 0.5 mm, thus
decreasing the amount of hand finishing required for dies without
exposed (class one) surfaces.
NAC, however, has not made any other significant changes to its
machining technology or to the quality of the dies machined. Within
lean manufacturing, decreasing the cycle time of some processes while
others have longer cycle time, means that the longer-cycle time processes
will be bottlenecks. For this reason, Numerically Controlled (NC) tech-
nology has not significantly increased throughput or reduced lead time.
Moreover, NAC has far fewer CNC machines (about a dozen) than
Toyota has, and all of these are very large and produce large quantities of
dies, sometimes significantly more than are required (i.e., over produc-
tion). Finally, machining makes up only about 60 percent of NAC die
construction, leaving a great deal of craft-based hand work that varies
significantly among individual die makers.
Toyota has also made some very significant investments in CNC
machine capability, but has purchased many machines of various sizes,
primarily because dies for most of the parts on a car do not require large
machines. Toyota’s lead tool and die facility has more than twice the num-
ber of CNC machines and is organized in flow lines by die classification
(A-E). As one would expect from a lean manufacturing enterprise, Toyota
has identified part families and developed dedicated flow lines—machine
lines specialized for different sized dies leading to major reductions in lead
time and increases in overall throughput. Dies are scheduled onto the
smallest machine possible.
The high-speed capability of most of Toyota’s mills allows the com-
pany to decrease stepovers to less than 0.2 mm, and even class-one surfaces
require little, if any, hand work (even on radii). In addition, Toyota has
developed and patented many custom machining and cutting tools to
enable significant improvements in guide pin and wear pad accuracy.
Standardized, precision machining makes up more than 85 percent of
Toyota’s total die construction process, minimizing the amount of craft-
based handwork.

252
Morgan Liker sec 4 3/2/06 11:49 AM Page 253

Adapt Technology to Fit Your People and Processes

Toyota also focuses on precise machine scheduling. Every detail of

every die is scheduled for machining by the hour. Visual machine sched-
ule boards (located next to the machines) are used. Actual times recorded
by the operator are then reviewed each day in plant walk arounds.
Required cutters, work pieces, and cutter paths arrive at the machines JIT,
contributing to improved machine uptime.
Toyota’s high-precision dies enable rapid die construction, minimize
in-press adjustment, and consequently die tryout time. High-precision
dies are also critical to consistency in die performance. Between-die setup
variance is much higher than within-die setup variance (Hammett, et. al,
1999), and, according to Toyota, low tolerance (high-precision) machin-
ing of dies makes dies much more repeatable between press set ups. This
facilitates fast die setup in stamping operations and is central to any lean
PD system.
Toyota dies are assembled in work cells. Precision machining, stan-
dardized die construction, and lean manufacturing principles combine to
create an efficient construction process that is centered around specific-
purpose construction cells housed within A through E category construc-
tion bays. Cells, although not always U-shaped, contain all equipment and
materials required for performing specific standardized work within
equalized task times. Required materials and machined components are
delivered JIT to the appropriate construction cell. The assembly steps have
been dissected in great detail, and standardized work has been used to
reduce dramatically the time required to assemble dies. Checklists kept in
the cells facilitate standardized work and at-the-source inspection. Visual
boards show how the die assembly is progressing relative to a takt time,
and deviations flag an andon to call for support to get back on schedule.

Tryout Presses: NAC Versus Toyota

Because most of NAC’s dies require relatively long periods of tryout time,
most presses at NAC are large, high tonnage stamping presses equipped
with rolling bolsters to facilitate grinding outside of the press and quick
resetting of the dies. Toyota requires far less die tryout time, and most of
its presses are “spotting” presses. Less expensive than stamping presses,
they are used only to check basic die functionality. Toyota’s press layout
facilitates die transfer from spotting press to stamping press where a forty-
part run-off is stamped out. Dies are removed from the spotting press via
rolling bolsters onto a large die transfer mechanism and rotated to a

253
Morgan Liker sec 4 3/2/06 11:49 AM Page 254

Section Four: Tools and Technology Subsystem

stamping press. Any additional handling is facilitated by overhead crane.

This is the basis for single minute exchange of dies to effectively use the
tryout press.

No-Adjust Build at NAC Versus Functional Build at Toyota

One of the key tools utilized for both identifying and resolving individual
part, fixture, and assembly issues on the vehicle body is the functional or
screw body build. This is a systems approach to a part-by-part analysis of
the physical parts and subassemblies that enables understanding and facil-
itates adjustments to the fit and finish of the vehicle body. In the physical
version of this process, parts were literally screwed together into what is
called the screw body (later it was riveted together). The screw body was
then evaluated by teams. More recently Toyota has advanced from a phys-
ical screw body to a virtual (digital) build up of the body from “as manu-
factured” parts data for review. In either case, the philosophy is the same:
a systems approach to delivering customer perceived value, which guides
decision making within a complex environment (Hammett et al, 1999;
Ward et al, 1995b). To facilitate early identification of major fit issues in
the prototype phase, engineers use a preliminary functional build utilizing
prototype parts. The functional build is an effective decision-making and
learning aid in the body development process. However, engineers need a
great deal of experienced-based judgment to execute this complex process,
and effective mentoring is central to developing the right skill set.
When this process is described to engineers outside of Toyota, they
often ask for the specific technical basis for deciding when product dimen-
sions that do not match the nominal dimensions in the original database
are acceptable. When told how much discretion Toyota engineers are given
to make these judgment calls, they are aghast. As Chapter 9 showed, how-
ever, Toyota engineers have earned this “power of discretion” because of
their rigorous training and experience.
One constant to remember about Toyota is that it is an organization
that constantly changes. For example, the functional build process was a
key part of Toyota’s methodology for body engineering. The company rec-
ognized that stamping is more of an art than a science and that it is not
possible to get the stamped parts to match precisely the nominal dimen-
sions of the original CAD database. Achieving the nominal meant grind-
ing dies, which is expensive and time consuming. At present, Toyota is
changing its philosophy and working to achieve nominal dimensions that

254
Morgan Liker sec 4 3/2/06 11:49 AM Page 255

Adapt Technology to Fit Your People and Processes

will eliminate the need for grinding. Toyota engineers are confident that
with new simulation and modeling technologies they can get much closer
to nominal than was possible in years past when they originally developed
functional build. And with globalization and tools going every which way
for manufacturing and the sharing of platforms, architecture, and compo-
nent parts across vehicle programs, it has become more important to have
the tools and parts match the database. From the perspective of competi-
tive advantage, companies now in the process of learning functional build
(and there are many) may well have to compete with a Toyota that has
moved on to something substantially better.
Although NAC has experimented with functional build, its prevailing
vehicle build philosophy is that dimensionally correct components (using
nominal dimensions) will assemble into a dimensionally correct vehicle
body. Consequently, NAC places emphasis on stamping parts that adhere
to generic dimensional tolerance bands, tolerances developed for rigid
body parts such as machined blocks. Product engineers and assembly
engineers at NAC vigorously enforce the dimensions and tolerances,
sometimes ignoring the realities of the die development process. The real-
ity, of course, is that sheet metal stampings do not conform to tolerances
developed for rigid body, machined parts. Obviously, this policy of enforc-
ing the unenforceable leads to high costs of reworking dies, much longer
die tryout times, longer development lead times, and problems at launch.
Toyota’s functional-build process zeroes in on dimensional character-
istics that are meaningful to vehicle fit and finish, that is, dimensional
characteristics that impact the build or performance of a vehicle. Many of
the dimensional tolerances required of individual parts are meaningless
once the part is assembled into a vehicle. One example of this is a thin,
structurally weak part assembled to a thick structurally strong part. Once
the thin part is clamped to the thick part, it will conform to the thick part.
Spending a large amount of time in die tryout in order to make a dimen-
sionally correct “thin part” is wasted effort—the thin part will conform to
the shape of the thicker part at assembly. Moreover, dimensional tryout
represents a significant amount of money in a typical program. Over 20
percent of die costs is invested in reworking dies, which can exceed $20
million. Much of that cost is geared to achieve nominal dimensions and 10
to 20 percent of component dimensional issues account for 80 to 90 per-
cent of those rework costs (Hammett, Wahl, and Baron 1999).
Functional build can improve final product quality while simultane-
ously loosening tolerances and saving time and money (Hammett, Wahl,

255
Morgan Liker sec 4 3/2/06 11:49 AM Page 256

Section Four: Tools and Technology Subsystem

and Baron (1999). By focusing on vehicle system quality, functional build

takes a system optimization perspective using original design specifica-
tions as goals. If Toyota is having difficulty meeting a particular specifica-
tion during home line tryout, it may solve the problem in a downstream
operation or even change another related mating part that can be changed
more expediently. Indeed, as noted, Toyota has learned so effectively from
the functional build process and improved die design, surface modeling,
springback prediction, as well as the precision of die manufacturing, that
it is gradually moving away from functional build all together and build-
ing to true nominal dimensions. NAC has not developed this capability
and therefore may still benefit by seriously utilizing functional build,
which will require a cultural change among engineers.
Three-dimensional noncontact measuring
Optical scanning is one of the technological advances that has enabled
Toyota to move to a virtual “as manufactured” functional build process.
Toyota utilizes this technology to support functional build by scanning
parts manufactured at multiple locations and then assembling them vir-
tually in a central location even before parts are shipped to the build loca-
tion for physical assembly. Engineers also use this technology to measure
parts in process between manufacturing operations to determine the
source of variability in a manufacturing process quickly. Toyota employs
this technology in both development and production processes.
Fixtures are utilized throughout the body development process to
locate parts for functioning, measurement, and assembly. These fixtures
can be extremely expensive, with a single large checking fixture at NAC
costing as much as $250,000. NAC has focused a tremendous amount of
energy and resources on building elaborate checking fixtures. Though this
can provide reams of checking data, it keeps quality auditing groups busy
assessing endless measurements.
Toyota’s largest checking fixtures cost less than one-fifth of NAC’s and
produce more usable data. Instead of engaging in part inspection, Toyota
focuses more on process control and source monitoring, employing three-
dimensional noncontact measuring technology that produces relative
measurement of complete surfaces rather than the elaborate fixturing or
independent point measurements favored by NAC quality auditors. Fun-
damentally, the three-dimensional noncontact measuring technology
works by taking a point dense, three-dimensional “picture” of the part,
transferring it into the CAD environment, and comparing the part pro-

256
Morgan Liker sec 4 3/2/06 11:49 AM Page 257

Adapt Technology to Fit Your People and Processes

duced to the actual design geometry. Engineers or operators can immedi-

ately see any deviation between the two. Providing complete surface meas-
urement is more useful in process diagnostics than are isolated points, and
noncontact measurement systems have been shown to be faster, shop
friendly, and more accurate than point-based or laser-dependent tech-
niques (Hammett, Frescoln and Garcia-Guzman, 2003).

Adopting Technology to Enable Process

The examples presented above show that NAC and Toyota think about
technology in fundamentally different ways, with NAC focusing on the
technology itself and Toyota focusing, first and foremost, on the process.
NAC looks at the technology and asks, “What can this technology add to
our process? Can we justify purchasing it? How can we get the most for the
least amount of money from this technology?” Once purchased, the tech-
nology often requires that the current process be changed to make the best
use of it. On surface, this may seem logical, but in a lean PD system, it is
not. In a true lean PD system, the first step is to reduce waste in a process,
then look for opportunities in which the use of technology can support the
PD process and develop clear requirements the technology can meet.
Finally, if necessary, you work with software vendors to customize the
technology appropriately to fit the process. In a lean PD process, rather
than having technology drive changes in the process, the process leads you to
adopting technology that can enhance it. A lean organization understands
that its first concern is always to work at perfecting the process; technol-
ogy is useful only as an enabler or catalyst.
In manufacturing situations (e.g., making dies), NAC’s approach is to
invest in a small number of expensive and very large machining centers,
which creates batch building, poor synchronization across steps, and bot-
tleneck operations. Toyota, on the other hand, uses the lean concept of
one-piece flow, separating parts into part families and creating flow lines.
Through this approach, Toyota can synchronize steps in the process,
increase throughput, and reduce lead time.
Whether it looks at solids, FEA, or functional build, NAC sees tech-
nology as a silver bullet. Ironically, this idealization promotes ineffective
use of technology. Often, engineers are then blamed for not using it cor-
rectly. LDPS Principle 11, adapt tools and technology to fit your people and
processes, suggests that a more successful approach is to have a realistic and
pragmatic perspective, one that sees technology as an enhancement tool

257
Morgan Liker sec 4 3/2/06 11:49 AM Page 258

Section Four: Tools and Technology Subsystem

rather than as a silver bullet. It is from this position that lean enterprises
adapt more modest, less costly, and more effective technology.

LPDS Basics for Principle Eleven

Adapt technology to fit your people and processes

The following guidelines can help you make advances in technologies

that act as powerful PD system accelerators:
1. Integrate new technology seamlessly into existing tech-
nologies and your lean product development system before
you use it.
2. Use the technology to support your lean development
process, not vice versa.
3. Technology should enhance people, not replace them.
4. Do not look for silver bullets to enhance your product
development performance—there are no short cuts. There
are no ways to avoid the hard work required to develop a
high-performance product development system.
Remember that any one of your competitors can buy or
develop the same technologies. You get the most out of technol-
ogy when it not only fits within your system, but when it enhances
your processes and promotes continuous improvement—the
human is still responsible for getting the work done.

258
Morgan Liker sec 4 3/2/06 11:49 AM Page 259

CHAPTER 14

Align Your Organization Through

Simple, Visual Communication
“In business, excess information must be suppressed.
Toyota suppresses it by letting the products
being produced carry the information.”
TAIICHI OHNO

MANY OF THE PROBLEMS COMPANIES had in the “bad old days” before con-
current engineering were the result of the “chimney” phenomenon. Spe-
cialists lived in chimneys and communicated upward and with other
specialists, but poorly across chimneys. Today, if you ask a room full of
engineers if communication is important to effective product development,
you are likely to get amused shrugs—the answer is obvious. After all, prod-
uct development is information flow among many specialists. Stop com-
munication, stop information flow, and you stop product development.
Now, instead of “throwing the design over the wall,” engineers are taught to
communicate concurrently with a team of upstream and downstream spe-
cialists—across functions. Almost everyone understands that more com-
munication is better and that collocating engineers in the same office area
so they can communicate intensely every day is a PD “best practice.”
Given that everyone agrees that communication is critical to good
product development, what is left to say on this subject? Actually, quite a
bit, including the fact that more communication is not necessarily better.
And that sometimes face-to-face communication is not as good as written
documents. And that large-scale collocation may not necessarily be all it’s
cracked up to be.
If this is surprising, just think for a moment about endless concurrent
engineering meetings where time is lost just getting different functions to
agree on basic terminology and how unproductive this “intense” com-
munication can be. What you really want is selective communication that
gets the right information to the right people at the right time, so that
they can make good decisions. Inundating people with too much infor-
mation often means they cannot sort out what is core from what is

259
Morgan Liker sec 4 3/2/06 11:49 AM Page 260

Section Four: Tools and Technology Subsystem

peripheral. It is inefficient, ineffective, exhausting, and wastes time and

talent, and is sometimes less productive than the common practice of the
bad old days of throwing drawings over the wall and saying nothing else.
Somewhere between these two constructs is a happy medium that avoids
information overload but gets necessary information to others effectively
and efficiently.
Chapter 4 described how Toyota front-loads the product development
process. The essence of simultaneous engineering is bringing downstream
considerations to the table early in the development process, when options
are the most fluid. Set-based concurrent engineering was discussed as a
way to consider many options in this fluid stage and then narrow the range
simultaneously across functions. Obviously, communication is key to
doing this, but this means streamlined communication that makes every
note, chart, meeting, and report count. This chapter provides an overview
of the tools that Toyota uses to keep communication highly focused, sim-
ple, and visual in a lean PD system.

Chief Engineer’s Concept Paper: An Aligning Document

Chapter 7 discussed the central role of the chief engineer and Chapter 3
discussed how the CE’s concept paper launches and defines the core
parameters of the entire product development proposal at Toyota. The
concept paper is highly confidential, typically runs 15 to 25 pages in
length, and text is supplemented by tables, graphs, and sketches intended
to provide the team with a single unifying direction and decision-making
guideline. With this document, the CE aligns many functional specialists
efficiently toward a common vision.
This is not to say that the chief engineer creates this document in a
vacuum. Because Toyota’s PD process encourages the interchange of many
ideas to get the best ideas on the table, the CE pulls the vehicle concept
together by drawing on diverse inputs (from planning, styling, marketing,
purchasing, etc.). To integrate these, the CE holds many meetings and
often presides over heated discussion and debate. The CE examines the
customer data provided to him by the marketing department. Practicing
genchi genbutsu, he or she also observes and learns about the day-to-day
activities of his target audience first-hand. (Chapter 3, for example, men-
tioned the Sienna minivan chief engineer who personally drove through
every U.S. state, every Canadian province, and every Mexican state to
experience firsthand the many driving conditions of North America.)

260
Morgan Liker sec 4 3/2/06 11:49 AM Page 261

Align Your Organization Through Simple, Visual Communication

In addition to genchi genbutsu, the chief engineer relies on nemawashi,

getting proposals and reactions from many people and modifying the col-
lective input to reflect a consensus. Nemawashi is not peculiar to Toyota (it
is a staple of Japanese management), but it is central to any problem solv-
ing at Toyota. In fact, a common refrain of Toyota CEs is “My power comes
only from personal persuasion.” No final proposal goes to executive deci-
sion makers without broad circulation. So that essentially, the proposal is
already approved by the time of the formal meeting. Once the CE has a
vision for the new vehicle, he or she meets with both internal and external
technical specialists to identify subsystems that might be right for the vehi-
cle. This group of specialists often includes representatives from suppliers
who have developed a particular technology (such as in seating or light-
ing) that might be a good fit for the vehicle vision. The CE works to iden-
tify technologies that are right for the vehicle and then determines, with
the help of the specialist(s), which of the required technologies are already
fully developed and financially feasible. The CE team will invite suppliers
whose technologies pass the CE’s criteria to participate in technology
demonstrations for further consideration. The CE will also consult prod-
uct engineering specialists or visit manufacturing plants to get input on
the manufacturability of particular technologies or styling characteristics
that are under consideration. All of this ensures that the concept paper will
be viable and fully grounded in data and current capabilities. Once the
document is completed, the CE distributes the paper to all assistant CEs
and functional staff leaders on the program.
The way the concept paper is conceived and delivered illustrates the
importance of having a clear delineation of roles and responsibilities. It
lays the groundwork for knowing what to communicate and what not to
communicate. The lean view of communication is:
• If everyone is responsible, no one is responsible.
• If everyone must understand everything, no one will understand
anything very deeply.
• If all communication is going to everyone, no one will focus on the
most critical communication for their role and responsibility.
• If you inundate your people with reams of data, no one will read it.
At Toyota, while there is a great deal of information shared across
functions, it is targeted information. When a prototype of a vehicle is
being reviewed, each engineer represents a function. They come prepared
with checklists for their respective function to evaluate all critical points.

261
Morgan Liker sec 4 3/2/06 11:49 AM Page 262

Section Four: Tools and Technology Subsystem

Each engineer is intensely focused on his or her piece of the vehicle and
any interfacing components. Any suggestions go directly to the engineer
responsible for that part of the vehicle. Moreover, the responsible individ-
ual must consider the problem or suggestion and come up with a response
(though not necessarily on the spot). The individual writes comments,
concerns, or suggestions on a flip chart for that particular part of the vehi-
cle. He or she later fills out a wall chart stating the problem, the proposed
countermeasure, and when the action will occur.

The Cross-Functional Obeya

When cross-functional communication became a standard at Toyota, it was
originally handled through targeted meetings or reports and the CE’s inte-
grating role. But the practice took a major leap forward with the develop-
ment of the obeya or “big room.” As discussed in Chapter 7, CE Uchiyamada
used the obeya for the development of the Prius hybrid vehicle as a way to
compensate for his lack of experience. Whereas previous Toyota CEs had
engaged in weeks of discussions with individual engineers, one by one, before
making decisions, Uchiyamada discovered that despite his lack of in-depth
product knowledge, he was able to make decisions in a single brief meeting
with engineering managers representing different functional departments.
Uchiyamada’s decision supports the views of advocates of concurrent
engineering (simultaneous engineering) who have found that collocation
greatly intensified communication and led to solving problems early,
before a lot of capital commitment. But, as mentioned in Chapter 8, there
are some rather unique features of the obeya:

• Engineers are not collocated. It is the engineering staff leaders (lead-

ers of each functional group) who meet with the chief engineer
regularly. These engineering managers have desks in their func-
tional organizations and come to the obeya regularly (often daily)
for long, collaborative work sessions (not traditional meetings).
• Visual management is key to effective communication. Engineers
plaster the room’s walls and “mobile walls” with information
organized by vehicle part. The functional head responsible for that
part of the vehicle is responsible for posting and maintaining the
information, and this information allows anyone “walking the
walls” to assess program status (quality, timing, function, weight)
up to the day.

262
Morgan Liker sec 4 3/2/06 11:49 AM Page 263

Align Your Organization Through Simple, Visual Communication

• The obeya has evolved through careful PDCA. One of the innova-
tions the PDCA process has produced is that, as a program pro-
gresses, moving from engineering to prototyping in engineering
facilities to preparation of production in the plant, the obeya is
also moved. To accommodate this, the “traveling obeya” was devel-
oped to move downstream to the plant as the program moves
downstream. An additional modification was to incorporate the
module development teams into the obeya process. Each modifica-
tion in the obeya has been deliberate, studied, adjusted, and then
standardized across programs.
The obeya has been a critical part of Toyota’s success in radically
reducing lead time, but part of that success was that Toyota did not dis-
band the functional organization or collocate hundreds of engineers.
The obeya system truly combines the best of both the latest technology
and Toyota’s traditional lean practices. The obeya contains state-of-the-
art CAD computer systems and digital projection technology to enhance
real-time viewing of design, simulation, and test results to foster cross-
functional collaboration. However, paper visual management continues
to be a centerpiece of program management, but paper is now hung on
the walls of the obeya. Functional managers are responsible for informa-
tion in their areas of specialty and in typical meetings present the status
of their work referring to the visuals on the wall. Through regularly
scheduled (but selective) cross-functional meetings of key leaders,
Toyota has improved the functional organization by facilitating quick
decision making.

Alignment Tools
Any company that employs 500 to 1,000 technical professionals working
on pieces of a complex system and several hundred suppliers develop-
ing and testing components must have a system for aligning these indi-
viduals and their work. Alignment means you harmoniously bring together
all the individual inputs from various people at the right time to achieve
the desired objective. There are a limited number of ways to make this
happen:
1. Individual level. Each person can operate independently. If the tech-
nical requirements are crystal clear and if all these individuals have
the skill and knowledge to do exactly what is required, they can join

263
Morgan Liker sec 4 3/2/06 11:49 AM Page 264

Section Four: Tools and Technology Subsystem

their separate inputs and it will all fit together. This would require
very detailed and unchanging technical requirements.
2. Team level. One big team can hash out each and every detail in
meetings or virtual meetings to come to agreement each step of
the way. This is obviously time consuming.
3. System and subsystem level. This means dividing an overall system
into relatively autonomous subsystems. The subsystem teams, fol-
lowing clear standards, can work separately to ensure integration
within each subsystem and to meet the overall requirements nec-
essary for the subsystems to work together.
4. Horizontal integration. Different individuals and subsystems work
separately while an “integrating force” ensures the work is well
coordinated across parts of the system. This type of integration is
best facilitated by a super integrator who directs a number of
people in liaison roles or by cross-functional task groups.

Toyota uses all of these methods in varying degrees. The chief engineer
plays a super integrator role while module development teams manage
integration within subsystems. Driven by clear targets starting with the
chief engineer concept paper, standardized skills and checklists enable indi-
viduals to work separately. A variety of meetings brings people together to
focus on integration issues. In addition, Toyota uses a specific set of tools to
aid in the integration task, some of which are discussed below.

Nemawashi at Toyota
Nemawashi is not a tool in the traditional sense, but it is a key to integra-
tion and underlies the use of many other tools, such as A3 reporting
described later in this chapter. In Japanese, the word nemawashi originally
referred to making the preparations necessary for transplanting a large
tree. In the business world, nemawashi is about achieving consensus
among stakeholders prior to the actual formal decision-making event.
Nemawashi in product development usually involves communicating rel-
evant data or information to the appropriate PD team members and hold-
ing small, informal, usually technical, discussions about potential
solutions to design or manufacturing challenges. This often takes place
outside of formal meetings so that meeting time is used primarily to
inform upper level managers of the options and the group’s recommenda-
tion. An A3 or decision matrix typically communicates this.

264
Morgan Liker sec 4 3/2/06 11:49 AM Page 265

Align Your Organization Through Simple, Visual Communication

If the design or manufacturing challenge requires a major change in

process, in design standards, or significant funding, then a more formal
decision-making process will be used. All engineers, early in their careers,
learn the nemawashi process—share the problem with others as you work
on it, get others’ input, and buy in so the final product is better and has
already been signed off as it was being developed. You never want to be in
the position of defending your own solution, even if it is technically strong
and defensible.

The Ringi System at Toyota

The ringi system is a more formal decision-making process used for han-
dling significant decisions. In the ringi process, a small team of people
with the necessary expertise is assigned to analyze some specific issue or
challenge and recommend a solution. At the conclusion of the analysis
process, the team creates a decision document called a Ringi-sho, which
outlines the challenges, the countermeasure, and the potential implica-
tions, both positive and negative, of adopting the proposal. The team then
meets with all managers who will be affected by the proposal and requests
their approval. Sign off on the proposal is traditionally done with a man-
ager’s hanko, a personal stamp used only by managers at a certain level.
Originally, Toyota required a minimum of eight hanko for proposal
approval. However, in 1990 a group within Toyota initiated the “three-
stamp campaign” to reduce the number of approval stamps. While this
narrowed the number of people responsible for maintaining essential
alignment, it sped up decision making.
In product development, ringi typically takes place early in the process
during the kentou or study phase. Small cross-functional teams are given a
limited time period (approximately 30 to 90 days) in which to analyze a
challenge, meet with managers, and diffuse the document throughout any
effected product development organization. In product development,
ringi can be used when a novel product design requires a significant
change in the standard manufacturing process or production engineering
wants to try a new, potentially more efficient, nonstandard manufacturing
process. In both cases, product engineering, production engineering, and
the manufacturing plant would have to sign off on the ringi-sho.
Using ringi in product development has several advantages. It gathers
input from all effected parties and aligns effected groups, reducing deci-
sion making to a single step during the product development process. In

265
Morgan Liker sec 4 3/2/06 11:49 AM Page 266

Section Four: Tools and Technology Subsystem

addition, it provides a constructive outlet for nonstandard approaches

while simultaneously providing organizational support for standardized
designs and processes. The underlying message is to follow standards
unless there is a very good reason not to—good enough to go through the
ringi process and prove it.

Hoshin Management at Toyota

Hoshin management (a.k.a. policy deployment) is an effective tool for
aligning an organization toward the achievement of broader goals or
objectives and allowing that organization to react quickly to a changing
environment. In a lean organization, hoshin kanri is generally an annual
planning tool that aligns the organization’s long-term vision with its
shorter-term activities while also aligning the efforts of people in the
organization with the goals of the organization. (See Figure 14-1.)

Hoshin management aligns the activities of people

throughout the company so that the company can
achieve key goals and react quickly to a changing
environment.
(Shiba, Graham, and Walden, 1993)

Figure 14-1. Hoshin Management is an Alignment Tool

There are six primary components to hoshin. The first of these is com-
pany vision—the long-term vision of where the company wants to go,
what it is, and what it wants to become. The annual hoshin complements
company values. In connection with this, hoshin also considers specific
annual goals, the means to accomplish these goals, metrics to measure

266
Morgan Liker sec 4 3/2/06 11:49 AM Page 267

Align Your Organization Through Simple, Visual Communication

progress, target value for the metric, and deadline and follow up. There are
four phases to hoshin at Toyota.

1. Strategic planning. Strategic planning has different levels. In a

broad sense, it can mean developing a ten-year strategic plan iden-
tifying the specific target market for the entire company. Hoshin is
not used for this except as a vehicle for considering a set of short-
term steps to achieve the long-term vision. Like other strategic
planning approaches, hoshin identifies problems and opportuni-
ties based on company performance and other environmental
data (including shortcomings from previous hoshin). This, in
turn, can be used to develops a near-term, future-state vision
based on these factors.
2. Hoshin deployment. Deployment statements must be based on facts
and data, be operationally viable, and be aligned with the six pri-
mary hoshin components. At the Toyota Technical Center in Ann
Arbor (TTC) and at all Toyota facilities, the president’s hoshin
event kicks off the year. The president communicates his hoshin,
based on the chairman’s hoshin, to TTC employees (see Figure
14-2). These statements are communicated to the various func-
tional groups and each group must translate the hoshin into a
meaningful goal for that function. For example, the president may
make a hoshin of reducing product development lead time by 20
percent by employing new methods and tools. The vice president
of Production Engineering might then, in support, make a hoshin
of reducing Production Engineering lead time by 20 percent, by
more fully leveraging solids die design capabilities and an auto-
mated pattern machining project by the “X” program. The die
design manager then in turn develops several supporting hoshin,
such as training personnel, working with the technology supplier
to fully adapt the technology to fit the Toyota process, and pilot-
ing the technology on specific applications. At each level of
deployment, the participants go through a goal-negotiation
process called catchball. This catchball process allows participants
to develop a clear understanding of the hoshin and enables the
hoshin recipient to “enroll” in the objectives.
3. Controlling through metrics. Both results and means are measured
and reviewed on a regular basis in a PDCA methodology. In
the above example, TTC would measure both the reduction in

267
Morgan Liker sec 4 3/2/06 11:49 AM Page 268

Section Four: Tools and Technology Subsystem

Chairman hoshin
(Japan)

President TTC
interprets and adds
North American content

General manager
interprets and reviews
with TTC president

Department/area manager
interprets and reviews
with general manager

Note: Also done for all Toyota affiliate companies. (Toyota Auto Body, etc.)

Figure 14-2. Hoshin Example at Toyota Technical Center (TTC)

lead time (results) and the implementation of specific enablers

(means), such as solids die design or the automated pattern process.
This provides insight into progress in implementing the means and
whether or not your means are having their intended results.
4. Check and act. During the year, managers measure actual
progress against the goal and make necessary adjustments. In
most cases, managers are required to develop a fallback plan
that they can implement if the difference between the goal and
reality is too great.
A key to using hoshin effectively is to close the loop through rigorous
reviews at each level (see Figure 14-3). Each pair of levels must first agree
on the critical few objectives for the year and how they will be measured.
Then supervisor-team associate pairs meet periodically to review progress
toward the hoshin. At TTC, this occurs three times per year and each indi-
vidual is evaluated against specific hoshin targets. Although problems are
addressed during this performance review, the meeting focuses on the

268
Morgan Liker sec 4 3/2/06 11:49 AM Page 269

Align Your Organization Through Simple, Visual Communication

Review
Deploy

Figure 14-3. Hoshin Deployment and Review Process

hoshin—the specific objectives of the individual to meet the high-level

strategic objectives.
An interesting example of strategic use of hoshin in product develop-
ment was the chairman’s hoshin at the beginning of the twenty-first cen-
tury. Based on Toyota’s commitment to the environment, the chairman
requested an increase in average fuel economy through the use of new
technologies. The product development community responded with,
among other things, the Echo. Commitment to the environment is part of
Toyota’s mission statement and a core strategy to position the company for
the future. This hoshin launched many concrete initiatives to make a big
leap forward toward that vision.

Toyota’s A3 Problem-Solving Tool

A3 refers to a standardized communication format, a disciplined process
of expressing complex thoughts accurately on a single sheet of paper. As
the following comments made by Toyota managers regarding the A3
report show, it is much more than that:

“Force yourself to filter and refine your thoughts to fit one sheet
of paper in such a way that management has all of their questions
answered by reading a single piece of paper—it is the essence
of lean.”
“A3 is much more about disciplined thinking than it is about
any particular writing technique.”
“Imagine how you would feel if you wanted to give me a
report, but I insisted that you could only draw a single picture to
communicate your information?”

269
Morgan Liker sec 4 3/2/06 11:49 AM Page 270

Section Four: Tools and Technology Subsystem

A3 is a standardized technical writing methodology to create a report

on one side of a standard size piece of paper to guide problem solving and
achieve clear communication across functional specialties. There are four
different types of A3 forms (see Figure 14-4).

Current Situation
Problem Consciousness

Proposal Problem Status Info

Solving Story Story
Story Story

Proposal Type
Stories Report Type Stories

Figure 14-4. Four Types of A3 Stories

1. Proposal story. Used for proposing a plan or new initiative, this story
always revolves around a theme. Although it does not end with an
actual proposal, it requires a clear plan, identification of issues
that will have to be resolved, and a schedule. (See Figure 14-5.)
2. Status story. Used for giving the status of an ongoing initiative, this
story calls for actionable information (see Figure 14-6, page 270). What
was the objective of the project and how is it going relative to the objec-
tive? What was the planned versus actual implementation time line?
What issues need to be resolved, and what future actions are planned?
3. Informational story. Used to share information, for example, about
a development at a competing company or elsewhere in Toyota,
informational A3s are “free-form” and the layout and delivery of
the story is left to the writer to formulate.
4. Problem solving story. Used when a plan, goal, or standard exists and
the company is not meeting it (see Figure 14-7, page 271). That is,
there must be a problem. The problem-solving story needs to be
thorough, communicating the complete process of plan-do-check-
action. Embedded in this storytelling is Toyota’s approach to “prac-
tical problem solving,” making clear the goal, the data on the current

270
 Theme
Morgan Liker sec 4

Introduction Plan
Reason for
3/2/06

Basic concept, background, or Required Expected

Required Responsibility
basic strategy, and Condition Effect
Condition
how it fits into the big picture

What / How Why? What? Who?

11:49 AM

Proposal Unresolved Issues

Page 271

271
How to deploy Unresolved issues and
basic concept how to overcome obstacles
(Vital points) i.e., How to negotiate with related departments,
anticipated problems and resolutions

Action Plan (Schedule)

How to deploy plan

Schedule / Timeline

Author: Date:
Align Your Organization Through Simple, Visual Communication

Figure 14-5. Proposal Story Example

 Theme

I. Background IV. Total Effect

Morgan Liker sec 4
3/2/06
11:49 AM

II. Objectives

V. Unresolved Problems / Future Actions

272
Page 272

III. Implementation
Section Four: Tools and Technology Subsystem

Author: Date:

Figure 14-6. Status Report Story

 Theme
Morgan Liker sec 4

Answer the question: “What are we trying to do?

Problem Situation Countermeasures

3/2/06

• The standard (Resulting from cause analysis)

• Current situation • Temporary measure
• Discrepancy / Extent of the problem • Long-term countermeasure
11:49 AM

Rationale for picking up the problem

(Importance to business activity, goals, or values Implementation
of the organization)
What Where Who When
Target / Goal
Page 273

Actions to Location of Responsible Times,

273
be taken activity person dates
Measurable description of what you want to
change; quantity, time

Cause Analysis
Follow-Up
Problem:
• Unresolved issues and actions to address them
Potential causes
• How will you check effects?
Most likely direct cause:
• When will you check effects?
Why? Why? Why? Why?
• How will you report findings?
Root cause:
• When will you report findings?

Author: Date:
Align Your Organization Through Simple, Visual Communication

Figure 14-7. Problem Solving Report, Proposal Story Example

Morgan Liker sec 4 3/2/06 11:49 AM Page 274

Section Four: Tools and Technology Subsystem

situation, a detailed analysis of the root cause, countermeasures, and

the story of implementation. The follow-up must include the verifi-
cation (check) that the countermeasure worked, future actions to
use, and what was learned in the verification process. An example
of a problem-solving story for a safety issue is shown in Figure 14-8.
Although an employee’s immediate supervisor is the primary teacher
of A3 writing, Toyota offers universal “vital points” for both A3 writing
and problem solving during training, recommending specific uses for
graphs and other communication aids. Below are some vital points for
problem solving and for writing A3s.

Problem Solving Vital Points

1. Grasp the situation based on facts
2. Observe the problem firsthand
3. Address a single abnormal occurrence (one A3—one problem)
4. Observe the abnormal occurrence at the point of cause
5. Investigate the cause thoroughly and review all facts and data
6. Use temporary (containment) measures when necessary
7. Identify the root cause
8. Develop countermeasures and assignments, and set deadlines

A3 Writing Vital Points

1. Plan time to grasp the ENTIRE situation.
a) Consider a wide range of information sources
b) Base story on facts not opinions
c) Consider the long-term effect
2. Decide what kind of story you need to tell. Write to your audience.
Consider their needs and knowledge of the situation.
3. Relate the story to company values and philosophy.
4. Make the story flow in logical sequence.
5. Save words. Use graphs and visuals to tell your story whenever
possible.
6. Make every word count. Be specific and avoid jargon.
7. Consider the visual effect of each box on the page in helping you
tell your story.

274
 Injury Types Panels - Jan to Oct.
Morgan Liker sec 4

Injury Type # of Average # of manhours # of incidents resulting

# of incidents
incidents resulting lost per incident in lost days
Hand Hand Injury descriptions
in days off Hand 19.7 13
Back Back 37.6
Minor scrapes and cuts from sheet metal 13
Eye handling requiring in-house first aid 6 1 Eye 15.4 2
treatement Arm 17.5 1
Arm
Leg 19.3 1
Leg Major cuts from sheet metal handling -
Foot 6.3 0
requiring stitches or other medical 10 10
Foot treatment Head 24.6 2
Head Hernia 6.0 1
3/2/06

Dismemberment of fingers 1 1 Chest 0

Hernia 0
Lungs 0 0
Chest Broken bones (hands and fingers) 0 0
Neck 0 0
Lungs Pinches and bruises 0 0 Note: Major injuries are recorded to a maximum of 2 weeks
of lost time (i.e., broken bones, injuries requiring long
Neck Repetitive strain injuries - time off due to 1 1 periods of disability, death and dismemberment.
0 5 10 15 20 soreness or fatigue
Total Number of Injuries

Hernia
Head
Leg
11:49 AM

Arm
Eye
Back
Hand

Head
Arm
Eye
Back
Hand
Page 275

275
Align Your Organization Through Simple, Visual Communication

Figure 14-8. Hand Injury Reduction A3 Solving Report

Morgan Liker sec 4 3/2/06 11:49 AM Page 276

Section Four: Tools and Technology Subsystem

There is an interesting parallel between the way Toyota views the use
of space in its Toyota Production System and its A3 reports. In a lean fac-
tory, it is very bad to fill space with muda or waste, which is generally
excess inventory. High value-added floor space is very valued. “A lot of
extra stuff ” lying around leads to disorganization, and it is difficult to
distinguish the correct standard condition from the out-of-standard
condition. Likewise, in A3 reporting, the point is to have high value-
added documents in which it is easy to see the critical points unimpaired
by waste—too many words, elaborate explanations, graphs, etc. Muda in
documents obscures the message and often causes people to leave out
key points.
Toyota’s A3 reports and the discipline with which they are prepared
provide fast and accurate communication that the whole organization
understands—crucial for a lean PD system. The A3 also facilitates contin-
uous improvement. What the A3 report requires gets done, for example,
the know-how database will be updated to reflect any change in a standard
or addition to knowledge that resulted from the A3 process. In lean think-
ing, the focus is on learning from problem solving (not just fixing the pres-
ent situation), and the A3 is a tool that enables that effort.

Communication and Alignment at Toyota

Many companies have tried to implement similar communication meth-
ods and alignment strategies. But whether they use management by objec-
tives, project management, stage-gate models, consensus decision making,
collocation, resident engineers, cross-functional teams, or even A3 report-
ing, few seem to do this as effectively as Toyota.
The probable cause for this distinction is the way a company assigns
roles and responsibilities, follows through on managing these, and
whether it provides a minimum degree of organizational stability needed
to make these tools work. Toyota, which has a very strong functional
organization with across-functional integration, through the chief engi-
neer system excels at cross-functional communication because it provides
a working environment that is stable, standardized, and continuously
improving. This organizational stability starts at the leadership level,
which provides consistent direction about what is important. Stability at
the working level includes spending time within a functional specialty and
gaining in-depth knowledge. Stability also enhances the ability to learn
from program to program.

276
Morgan Liker sec 4 3/2/06 11:49 AM Page 277

Align Your Organization Through Simple, Visual Communication

Roles and responsibilities mean that there is always an individual

responsible for carrying through the actions. In other companies, the pen-
dulum too often swings either completely to individual accountability or
to teams, teams, teams. Toyota has found a healthy balance. Though the
A3 report is actually a group activity and nemawashi is critical to building
consensus in the A3 process, an individual author signs the report. If there
are coauthors, all share in the responsibility. Thus the A3 process is an
alignment tool that manages and make roles and responsibilities work. In
the communication and alignment process in lean PD, there is an impor-
tant interplay between teamwork and individual work. Individuals always
do detailed work. Teams provide ideas and input, share in decision mak-
ing, support each other, and share in implementation.
Ultimately, alignment and effective communication give a company
the ability to develop standards throughout the organization. People crit-
ically evaluate and improve on these standards, creating revised standards
as needed. This is, in fact, the backbone of learning as an organization.
The next chapter which covers the 13th and final LPDS principle, use
powerful tools for standardization and organizational learning, revisits this
concept.

LPDS Basics
Align your organization through simple, visual
communication

It is fairly obvious that communication is a good thing in product

development. You cannot develop new products without good
communication. But LPDS recognizes that you can get too much of
a good thing. Communication should be targeted, sufficient, accu-
rate, and focus on the essential facts. Toyota has developed a num-
ber of mechanisms to aid effective communication. The CE paper
provides important program direction and creates alignment. The
obeya system is a mechanism for on-going cross-functional com-
munication and status tracking. Nemawashi, the ringi system and
hoshin provide tools for organizational alignment. The A3 process
helps to bring discipline and standardization to improve the effec-
tiveness of all types of communication—especially communication
about problem solving.

277
Morgan Liker sec 4 3/2/06 11:49 AM Page 278
Morgan Liker sec 4 3/2/06 11:49 AM Page 279

CHAPTER 15

Use Powerful Tools for

Standardization and
Organizational Learning
“Engineers at the Toyota Technical Center use hetakuso-sekke,
which is the small booklet containing the failures
experienced in the past.”
KUNIHIKO MASAKI,
former President of the Toyota Technical Center, Ann Arbor

COUNTLESS COMPANIES HAVE SPENT untold hundreds of millions of dollars

chasing after the performance improvements promised by organizational
learning and effective knowledge management. They have made mega-
investments in the information revolution, pouring cash into networked
knowledge, massive online databases and all of the latest hardware and
software. Yet despite these colossal investments of both human and capi-
tal resources, most companies have continued to struggle to make organi-
zational learning a true competitive advantage. One reason is because their
focus has typically been on tools that manage explicit or procedural
knowledge, which is, although expensive, relatively easy to do, and easy for
competitors to replicate. As we have previously discussed, it is in leverag-
ing “tacit” knowledge, or know-how that is the greatest source of compet-
itive advantage. The focus must be on tools that help the organization
change the way things actually get done. This type of knowledge is embed-
ded in people and culture; it is around tacit knowledge that the best learn-
ing tools and technologies are built and designed.

How Does Your Organization Learn?

Chapter 11 identified organizational learning as a key source of Toyota’s
competitive advantage. But just how are they able to succeed where so
many other companies have struggled? What tools and methods do they
employ and how do those tools differ from what their competitors use?

279
Morgan Liker sec 4 3/2/06 11:49 AM Page 280

Section Four: Tools and Technology Subsystem

One way to understand Toyota’s tools and methods is to once again study
a contrastive parallel to NAC. Although staffed with many capable engi-
neers, NAC struggled to recreate itself as a learning organization. Like
Toyota, NAC recognizes the importance of learning, and many individuals
within the company have learned well through trial and error. These indi-
viduals grew increasingly more valuable over time. Unfortunately there
was no mechanism within NAC to spread what had been learned across
the organization and to the next generation of engineers—at least not to a
great extent. And if a veteran employee left the company, they generally
took years of accumulated wisdom with them.
A lean PD system thrives best in a company that understands and cul-
tivates organizational learning, develops systems, and evolves a culture
that captures tacit knowledge and turns it into standards that everyone
learns and passes down to others. The importance of learning is embod-
ied in many of the tools already discussed in this book. We have already
discussed a number of Toyota’s most effective learning tools (technical
mentoring, hansei, A3) in great detail, and we will not revisit them in this
chapter. This chapter focuses on a number of other lean PD tools that help
Toyota’s learning capability: know-how databases, checklists, competitive
teardowns, senzu, process sheets, and quality matrices. The power and
effectiveness of these tools is best illustrated by comparing how they are
used within an organization like NAC and within a learning organization
like Toyota.

Knowledge Database at NAC: The Body Development

Value Stream
Although NAC made multiple attempts to create knowledge bases to guide
and assist engineers, there was no central strategy for knowledge and
information management along the body development value stream.
Instead, many individual functions and locations developed their own ver-
sion of a knowledge database and, of course, caused informational incon-
sistency, even outright contradictions, across those databases. What
undermined this system even further was that the primary specialists are
seldom involved in the database creation, validation, or maintenance. In
general, these specialists had little faith in the information, a prerequisite
for any knowledge tool to work. Consequently, what information was
available was seldom used. To exacerbate this condition NAC did not have
the fundamental discipline, values, and reward system in place prior to

280
Morgan Liker sec 4 3/2/06 11:49 AM Page 281

Use Powerful Tools for Standardization and Organizational Learning

creating the database, and functional specialists did not view it as a par-
ticularly useful tool.
NAC has also invested in a knowledge-based engineering pilot. This
rule-based “intelligent” technology can continually accumulate and codify
new information and would utilize the latest data to actively guide engi-
neers in their design process, literally locking out certain choices and pro-
viding automatic design sequences. Developed and maintained by IT
staffs, and in some cases, outside contractors, who work to extract infor-
mation from engineers and download it into databases, this technology
has not only failed to yield the promised benefits, but it is, in our view,
potentially harmful. It has not worked because it has not earned credibil-
ity with the engineers; they have not been enrolled in the development
process. It has not worked because it violates one of the primary principles
of lean technology deployment; it seeks to replace, not enhance its user-
base. And it is potentially harmful because it removes the engineer as an
active participant in the learning process.

The Know-how Database at Toyota

The compilation of the many standards checklists Toyota has used for
over 40 years is the basis of its computerized know-how database. It is
important to understand that these years of accumulated experience
worked very effectively in paper form before they were ever computer-
ized. For example, engineering checklists were organized in notebooks
that were kept by individual functional groups. Each functional group
had its own notebooks (e.g., 3-ring binders). At the beginning of a pro-
gram, the production engineering group responsible for doors would
share its most updated door checklists with the body engineers responsi-
ble for doors. Since Toyota has such a clear organization of functional
roles and responsibilities it is not necessary to send all of the checklist
information every which way. It is clear which specialists are working on
which parts and only they need the information in notebooks for their
parts of the vehicle. The notebooks were not profound and did not
replace deep engineering knowledge. They just remind the engineer to
think of each aspect: Did you check whether two parts are interfering
with each other or not? Did you check that the gap conforms to stan-
dards? Does this ratio fall within a standard range? There may be a graph
showing not to exceed this level. In each case, the engineer physically
makes a check to note I thought of that or did that. It is much like a pilot’s

281
Morgan Liker sec 4 3/2/06 11:49 AM Page 282

Section Four: Tools and Technology Subsystem

flight checklist. It does not make the pilot a great pilot, but it can help
avoid basic mistakes.
The hetakuso-sekke described by Masaki-san in the opening quote is a
different type of standard reference guide mainly used in body engineer-
ing. In this case Toyota put together a set of rules of what makes a good
and bad design mainly through diagrams. For example, in body engineer-
ing many had to do with how to reduce weight. For example, there may be
a plate in which a hole can be made for weight reduction. When there is a
flange a corner radius can be used to minimize weight. It is considered by
senior engineers to be a “lightweight concept.” In fact, the name means
something like foolish engineering or shallow thinking designing. An
experienced engineer should not need such tips. But for a younger engi-
neer it can be a very valuable source of design tips.
Putting these drawing tips and the checklists on paper in the old days
was a useful way to maintain a knowledge database. But it was not the only
knowledge database. The real database resided in the heads of the experi-
enced engineers with “towering technical competence.” Each of these engi-
neers is a living database with extraordinary knowledge in a very specific
area. If you know who to talk to, or as long as the right people review the
design, that knowledge database is activated. So simple checklists or book-
lets are supplementary.
Putting these written forms of knowledge onto a computer does not
replace the deep knowledge of functional experts. And the written check-
lists did their job quite well for many decades. But a computerized know-
how database is still a significant advance. Engineering guidelines,
graphics, and practices are outlined and explained in greater detail than
was possible on handwritten checklists. Information is arranged by vehi-
cle/part or just part type, and within the part-type database, there is a
competitor benchmark component that allows engineers to view pictures
of competitor products and teardown analysis. Other data are organized
by manufacturing process/part type and include access to the quality
matrices and senzu discussed later in this chapter. In addition, the know-
how database is linked to the design database to facilitate importing and
exporting information/geometry. There are also manufacturing process
sheets, complete with descriptions, pictures, and even videos of processes
occurring right on the factory floor. Users can also access quality and per-
formance data by part by plant.
One potentially big step forward in computerizing the checklists is
turning them from simple rules of what to avoid or what numerical values

282
Morgan Liker sec 4 3/2/06 11:49 AM Page 283

Use Powerful Tools for Standardization and Organizational Learning

to use to explain the reasoning behind the rule. An engineer who sees the
old checklist has no way of knowing from the checklist the reason behind
the rule. It provides know-what but not know-why. The new know-how
databases are evolving to explain the reason why. This is not as important
when the experts who created the rules are right in the room with you in
Japan. But as Toyota is globalizing product development it is not as easy to
get access to the true experts, and it is important to include the reasoning
process so the engineer can think through the problem instead of simply
following a rule.
A key to the success of the know-how database at Toyota is seamlessly
integrating it into the larger system, V-comm. V-comm is a fully integrated
network of tools that links active design, simulation, test, and communi-
cation technologies along with the know-how database to provide engi-
neers with a powerful suite of tools to enhance their productivity. By
integrating the know-how database into the basic engineering tool set
Toyota emphasizes that learning is not an add-on or “extracurricular,” it is
a basic part of the job.
This database has been successful for a number of reasons. As previ-
ously noted, the underlying company values, discipline, and reward for
adhering to the process already exist, so people automatically use and learn
from this information. Moreover, the database is centralized; there are no
competing knowledge databases to create confusion or contradictions.
Functional specialists maintain, verify, and update their own portion of
the database, just as they did with their handwritten checklists. This typi-
cally takes place after a hansei event (a reflection or learning event dis-
cussed in Chapter 11). Finally, the database is designed to enhance the
performance of Toyota’s people, not replace them or withhold the design
process from them. In a lean PD process, individual engineers are central;
learning tools and technology should reflect this.

Communicating and Evaluating Sets

As we have previously discussed, set-based concurrent engineering
(SBCE) is a cornerstone of Toyota’s product development process. More-
over SBCE is a powerful source of knowledge and continuous improve-
ment. However, communicating, evaluating, and learning effectively from
numerous alternatives, each possessing diverse and technical design char-
acteristics can be challenging. Consequently Toyota engineers have learned
to utilize two important tools to aid in this task.

283
Morgan Liker sec 4 3/2/06 11:49 AM Page 284

Section Four: Tools and Technology Subsystem

Trade-Off Curves

A trade-off curve is a relatively simple tool that is consistently used by

Toyota engineers to understand the relationship of various design char-
acteristics to each other. In a trade-off curve a subsystem’s performance
on one characteristic is mapped on the Y-axis while the other is mapped
on the X-axis. A curve is then plotted to illustrate subsystem performance
relative to the two characteristics. Trade-off curves might be used to eval-
uate speed to fuel economy in the calibration of a given power train con-
figuration, or the size of a radiator to its cooling capacity. In one
particular case, an exhaust system supplier to Toyota created more than
40 different prototypes for one car program. Why make so many proto-
types? The answer was to vary different factors and make tests to develop
trade-off curves so that the Chief Engineer could understand the rela-
tionship of muffler back pressure to engine noise (see Figure 15-1) and
make an informed decision.

Exhaust System Supplier:

“The Chief Engineer wants to know what the trade-offs are.”

X
X

X
X X
Back Pressure
X
X
X
X
X

Noise Reduction

Figure 15-1. Multiple Prototypes Help Understand the Design Space

Trade-off curves are a fast and effective way to communicate about

very complex and technical performance attributes in a set-based environ-
ment. An actual tradeoff curve used by the Chief Engineer of the first
Lexus shows plotted on a graph of Max Speed (power) versus Gas Guzzler
Tax where luxury cars from the United States, United Kingdom, and Ger-
many sit compared to the stretch breakthrough target he set for the Lexus
LS400 (see Figure 15-2).

284
Morgan Liker sec 4 3/2/06 11:49 AM Page 285

Use Powerful Tools for Standardization and Organizational Learning

US-B
23 UK LEXUS
LS400
US-A
Fuel Consumption (MPG)*

22 $500

21 $650

Gas Guzzler Tax ($)*

20 $850

19 WG-A $1050
WG-B

18 $1300
WG-C
$1500
110 120 130 140 150
Max Speed (MPH)

* Combined city and highway fuel consumption

Figure 15-2. Trade-off Curve to Set Lexus Breakthrough Target

for Speed and Fuel Tax

Decision Matrices
When engineers at Toyota want to consider various design alternatives or
provide feedback or suggest solutions to design challenges, they commu-
nicate with matrices. As you will recall, one of the first lessons new engi-
neers learn from their freshman project is to think problems through
thoroughly, and part of this by process often includes presenting the team
with a matrix. Once again this is a relatively simple but effective tool for
communicating and evaluating alternatives. Design alternatives are listed
on one axis of the matrix while specific evaluation criteria are listed on
the other creating multiple cells. Each design alternative is then evaluated
against those criteria and a quantitative or qualitative value is entered in
the appropriate cell. For example an engineer might be evaluating design
A, B and C against the criteria of cost, weight, durability, and functional-
ity (see Figure 15-3). In this example, design versions A, B, and C are

285
Morgan Liker sec 4 3/2/06 11:49 AM Page 286

Section Four: Tools and Technology Subsystem

listed along the Y-axis while the evaluation criteria on the X-axis with
corresponding values for each. Note that these values are not precise
quantitative metrics but a subjective rating of achievement of the objec-
tive that allows for adding up the ratings across categories to a total
score. This might not seem like much of an engineering tool, but it does
give a rough ordering of the alternatives which is sometimes all that is
practical . . . and it can be quite powerful for experienced engineers mak-
ing decisions.

Design Cost Weight Durability Functional Total

Alternative Performance

A 1 2 2 2 7
B 3 2 3 1 9
C 2 3 1 3 9
Numbers 1–3 represent a simple rank ordering.

Figure 15-3. Sample Decision Matrix

Both of these tools not only make communication and evaluation

more effective but provide a key tool for learning and preserving knowl-
edge in the Toyota product development system.

Competitor Benchmarking Reports at NAC

Competitors provide an important and useful source of information in
developing the concept for a new vehicle. NAC studies the popular or
useful features and characteristics of competitor vehicles within the
same vehicle class or market segment for vehicles it plans to develop. It
benchmarks the competitor’s vehicle sales and performance data against
certain vehicle characteristics targeted for replication by the team. In
some cases, the team uses vehicle teardown analysis to identify the
underlying design enablers of those performance characteristics. NAC
then summarizes the results of these investigations in multipage reports
that program participants study. The team may follow up with a visit to
the teardown facility and further examine those features or characteris-
tics that fit within the vehicle concept; their findings are communicated
to functional groups with recommendations for possible application to
the vehicle that is being developed. The key phrase here is “communi-

286
Morgan Liker sec 4 3/2/06 11:49 AM Page 287

Use Powerful Tools for Standardization and Organizational Learning

cated to”—information flow is clearly unidirectional and is not even

flowing in the right direction.
Here again, NAC is copying a lean tool while missing the essence of the
tool. The engineers who need to use these results do not “own” the tear-
down process. Someone else in the company did the teardown and developed
a report. NAC has even subcontracted the competitive vehicle teardown
process to outside firms. However, hired guns achieve only so much before
moving on to other clients; even worse, they have no vested interest in pro-
viding data that is truly comprehensive and species specific to the compa-
nies with which they deal.
Because there is a cultural and professional separation between the
people doing the analysis and the people who must synthesize and act on
it, NAC engineers cannot fully benefit from these teardown exercises. This
is a serious flaw in the traditional PD system. Even if engineers learn some-
thing and apply it to one vehicle program, what was learned and applied
is rarely standardized or even communicated to other programs. As a
result, learning tends to be isolated and disjointed. The opportunity to
spread the learning organizationally has been lost.

Toyota Competitor Teardown and Analysis Sheets

Toyota uses a process that, on the surface, appears similar to NAC’s. There
are, however, significant differences in how that process is approached and
applied. After the CE concept paper identifies high-level vehicle perform-
ance characteristics, the module development teams (MDT), discussed in
Chapter 8, create component or subsystem level goals that are aligned with
the system or vehicle-level performance goals. In a lean PD process, these
component-level goals can be developed in several ways. One method is to
use the team’s preprogram plant visits to identify potential quality or man-
ufacturability issues with the current component. Another method is
competitor teardown analysis of best-in-class components.
Chapter 3 included a generic research example related to body devel-
opment, and this example serves to illustrate how MDTs create and align
component level goals. In the example, the module development team
responsible for closures identified hem issues (the binding of the edge of
the sheet metal on the door) on the previous version of its vehicle’s doors.
Reviewing assembly-plant quality data, the MDT found that the width of
the gap or margin between the front of the door and the rear of the fender
and the rear of the door and the front of the quarter panel varied to an

287
Morgan Liker sec 4 3/2/06 11:49 AM Page 288

Section Four: Tools and Technology Subsystem

unacceptable level. The group added this specific characteristic to its issues
list. With benchmarking, the MDT was also able to identify features on a
competitor’s door with more consistent margins.
After taking margin measurements and compiling comparison data,
they summarized their findings in a radar graph that identified specific areas
of concern at both the rear and front edge of the door (see Figure 15-4).
The teams then methodically disassembled and analyzed the door
assemblies for design or manufacturing characteristics that might lead to

Front Door Margin Comparison

Region A
0.8
0.7
0.6
Region G 0.5 Region B
0.4
0.3
0.2
0.1
0

Region F Region C

Vehicle A
Vehicle B

Region E Region D

Detail Region Vehicle A Vehicle B

Region A 0.5 0.3
Region B 0.6 0.6
Region C 0.1 0.2
Region D 0.2 0.3
Region E 0.8 0.5
Region F 0.1 0.2
Region G 0.4 0.3

Figure 15-4. Radar Graph Comparison—Areas of Concern at the

Rear and Front Edges of the Door

288
Morgan Liker sec 4 3/2/06 11:49 AM Page 289

Use Powerful Tools for Standardization and Organizational Learning

a better hemming condition. In this case, the MDT identified at least three
characteristics that led to an improved margin and one that enabled supe-
rior flushness.
After completing these analyses, the MDT developed study drawings
or kentouzu and a specific matrix plan for related, specific adjustments and
modifications for the new vehicle. Styling, body engineering, and produc-
tion engineering subsequently all signed this document and utilized it as a
design guide.
There were two key success factors to the benchmarking: 1) it was
owned by a team of engineers who specialized in and were responsible for
the door, and 2) the benchmarking was turned into a specific problem def-
inition with specific countermeasures. The same group that did the com-
parative analysis implemented the changes. Ownership, responsibility, and
good problem solving are all keys for a successful lean PD process.
This scenario is repeated multiple times across the program as each
group of functional engineering specialists on the program is responsible
for its own benchmarking and tear down process. It is a hands-on process
in which the engineers themselves literally crawl around competitor’s vehi-
cles busting knuckles and nicking fingers pulling off subsystems, reducing
them to their component parts, mounting them and creating an in-depth
technical analysis. The engineers enjoy the process and one of the side
effects is that by taking a hands-on approach the engineers truly learn and
usually a great deal more than just the narrow specification of a target part.
Best of all, it is tacit knowledge, and it is genchi genbutsu at its best.

Standardization Tools at Toyota: Engineering Checklists,

Quality Matrices, Senzu, Standardized Process Sheets
Standardization tools, such as checklists, are central to the Toyota PD
process. Former NAC engineers who now work for Toyota are emphatic
about this point, arguing that it is the main reason Toyota’s PD system is
consistently better than NAC’s. The reason for this is that there is a process
that makes these standardization tools add value. From the start, begin-
ning with the kentou period, each functional activity utilizes a set of engi-
neering checklists that guide decision making throughout the product
development process. Checklists may define crucial steps within a process
(process checklist) or provide guidelines for specific characteristics of a
product design (product checklist). They are based on first hand experi-
ence and are updated and validated regularly to incorporate any new data

289
Morgan Liker sec 4 3/2/06 11:49 AM Page 290

Section Four: Tools and Technology Subsystem

or technological developments. In all cases, these checklists contain very

detailed information about the product or process. Furthermore, the same
groups that use the checklists maintain and update them at the end of each
program and, as required, at hansei events.
As previously noted, one example of a product checklist is the quality
matrix. The production engineering department, for example, maintains a
specific quality matrix for each major sheet metal part on each vehicle (e.g.,
the Camry fender has its own quality matrix as does the Sienna minivan
door outer). Listed across the top of the matrix are all the steps in the man-
ufacturing process (see Figure 15-5). Listed down the left side of the matrix
are quality and productivity issues potentially associated with this particu-
lar part, based on its vehicle functionality and manufacturing process.
Complex parts may have hundreds or even thousands of individual con-
siderations. By including quality as well as productivity issues, the team can
begin considering “lean manufacturing issues” right from the start.

Commodity/ Process Steps Program Timing

Part Data

Intersection of Quality
Quality and Process
Characteristics
Know-How/ Detailed
Standards Planning

Figure 15-5. Quality Matrix and Know-How Database Integration

If a specific step in manufacturing potentially impacts a quality or

productivity issue, a dot indicates this relationship. In the know-how data-
base electronic version (V-comm) of the matrix, the user simply clicks on
the dot and the appropriate standard(s) appear. In addition, each part’s

290
Morgan Liker sec 4 3/2/06 11:49 AM Page 291

Use Powerful Tools for Standardization and Organizational Learning

standardized individual development and test plan is available through V-

comm. This electronic format gives easy access to products, processes, and
cross-referencing that was previously unavailable.
The matrix contains specific recommendations for product design
geometry as well as the limits of current manufacturing technology to pro-
duce a particular geometric characteristic. For example, the matrix might
contain design parameters, such as the width-to-depth ratio to be main-
tained to stamp a certain feature. Two important characteristics of these
standards should be highlighted: 1) they specify only those requirements
that are critical to manufacturing, and 2) they usually provide standards in
terms of ratios (depth to width) or “if-then” statements (if you require a
certain flange angle and length, then this size radius will be required for
quality bending). These characteristics provide solid guidance for effective
manufacturing while supporting maximum design flexibility.
Senzu or the stamping engineering drawing is another example of a
checklist/standardization tool. For each major stamped component, engi-
neers have a three-view drawing. All the special manufacturing require-
ments are marked on the drawing near the relevant place on the specific
part. (For example, the amount of springback compensation that must be
built into the die to achieve the correct flange angle will be noted on the
drawing near the point it is required. Or the amount of surface plussing
and the blend pattern utilized to achieve an optimized surface condition
will be noted on a class-one surface transition.) Like other checklists,
these senzu are updated at the end of each program and utilized as a start-
ing point for the next program. As described to us by one Toyota pro-
duction engineer:

“When we are close to the handoff to the plant we make notes on

the senzu drawing. What was the anticipation versus what did we
see? During the entire process, notes were kept by the process
engineer and stamping engineer. Engineering changes are docu-
mented. Major documentation happens right before handoff to
the plant. Mostly this is used for the next evolutionary cycle. If we
discover something major we occasionally feed that back immedi-
ately but that is unusual. We put it in the file with the expectation
that the next vehicle that is similar will use that information.”

Another important standardization tool is the standardized process

sheets that indicate the specific manufacturing process for each part.

291
Morgan Liker sec 4 3/2/06 11:49 AM Page 292

Section Four: Tools and Technology Subsystem

(Figure 15-6 shows a standardized process sheet for a front fender.) By

using these process sheets early in the PD process, engineers can design
parts within standard manufacturing parameters. Exceptions are rare and
typically require a ringi-sho, discussed in Chapter 14.

Figure 15-6. Standardized Manufacturing Process Sheets

Common construction sections are a standardization tool used to

capture standard architecture for each part and provide design anchors
for each vehicle. These sections enable the kentouzu (study drawings)
generated during the kentou phase. They dramatically reduce the
amount of work required of the body engineer as new design styles are
considered.

The Role of Standardization and Learning Tools

Anyone familiar with lean thinking understands that organizational
learning is one of Toyota’s core competitive advantages. What is less
understood is that organizational learning is only possible with living

292
Morgan Liker sec 4 3/2/06 11:49 AM Page 293

Use Powerful Tools for Standardization and Organizational Learning

standards that are seriously followed and regularly updated. While com-
petitors are working to become lean, Toyota’s lean system continues to
evolve simply because the company has built learning and evolution of
standards into its systems. Each program, each component design, and
each test conducted is an exercise in organizational learning through
updating of lessons learned and standardized practices. Slowly and
methodically making Toyota better, the power of organizational learning
sometimes confounds attempts to measure Toyota’s capability statistically
in conventional measurement terms (development lead time, product
cost, or product quality.) A better benchmark is the improvement trajec-
tory from model change to model change.
Humans learn; technology does not. In a lean PD process, however,
tools and technology can nurture and sustain human learning. But this
can occur only if engineers with “towering technical competence” in spe-
cific functional areas take responsibility for using these tools to develop
standards that become the company’s new (and ever-changing) best-
known way. It is up to leadership to empower employees to continually
challenge and improve these standards until they become new standards.
Whether these tools are manual or electronic, engineers responsible for a
part of the vehicle must “own” as well as use these tools. It is this owner-
ship that creates and cultivates a learning organization. Of course, with-
out towering technical competence, a well-developed functional
organization, and functional groups that take responsibility for main-
taining and using standards, we end up with NAC’s computer databases
that are rarely used.
This chapter concludes the examination of the thirteen principles of
LPDS and the authors’ attempt to decompose the Toyota lean PD system
into a LPDS model, a model that hopefully provides an understanding of
lean PD’s history, complexity, and power. Though the LPDS model on
paper is no substitute for the application if LPDS in real-time, the pur-
pose of this book is to explain the structure and lean tools of a strong and
workable system. A key goal of this book is also to convey that while spe-
cific aspects of lean PD may be individually valuable, what makes them
truly powerful is mutually supportive tools, processes, and human sys-
tems working in harmony. The next chapter describes how Toyota uses
principles working in harmony to achieve a coherent system of product
development; Chapters 17 and 18 continue this discussion and explore
how your company can develop and implement its own coherent lean
product development system.

293
Morgan Liker sec 4 3/2/06 11:49 AM Page 294

Section Four: Tools and Technology Subsystem

LPDS Basics for Principle Thirteen

Use powerful tools for standardization
and organizational learning

This chapter discusses some specific tools and methods that can
help you leverage the power of tacit, “know how” knowledge and
process, product and skill set standardization. These tools are not
complex, and do not rely on expensive IT solutions. But they must
be rigorous, clear, and owned, that is to say, maintained, validated,
and updated by the functional experts who are expected to utilize
them. Some of the tools discussed include the V-comm integrated
Know-How database, engineering checklists, quality matrices,
senzu, and standardized process sheets. The most crucial point
about organizational learning and standardization is however, that
the specific tools that an organization uses not nearly as important
as the type of knowledge on which they are focused, the owner-
ship of the learning process, and a strong cultural bias for learning
and recognition of the true power of creative standardization.

294
Morgan Liker sec 5 3/2/06 11:52 AM Page 295

SECTION FIVE

Creating a Coherent
Lean PD System
Morgan Liker sec 5 3/2/06 11:52 AM Page 296
Morgan Liker sec 5 3/2/06 11:52 AM Page 297

CHAPTER 16

A Coherent System: Putting the

Pieces Together
“The way to build a complex system that works is to
build it from very simple systems that work.”
KEVIN KELLY

THUS FAR IN THIS BOOK WE HAVE ORGANIZED our discussion of Toyota prod-
uct development into the three elements of the socio-technical model:
people, process, and technology. We have used these theoretical concepts
to simplify, codify and communicate what could otherwise be complex
and amorphous. And while organizing our observations independently
within these three categories aids in understanding Toyota and LPDS, it
is not the way the real world works. People, processes, and technologies
do not exist in isolation, insulated from each other and the outside world.
In the real world Toyota’s product development is an integrated evolving
system, and the three subsystems of the LPDS model presented in this
book interact, overlap, are interdependent, and work together to create a
coherent whole. Changes to one subsystem will always have implications
for the other two.
To illustrate this concept, take a simple mechanical system like an
engine. It is quite possible to have the best piston, the best cylinders, and
the best fuel injectors, but if they do not fit together, you have a bunch of
great engine parts that accomplish nothing. Add the complexity of human
systems into the mix, and you can see even greater implications. In product
development the power of system “fit” is quite profound. In fact, we have
found that the power of the system is often determined not by the effec-
tiveness of any single subsystem, but the degree to which all three subsys-
tems are aligned and mutually supportive. Moreover, product development
efficacy is not determined by the competence of any single functional
organization but by the seamless integration and collaboration of all of the
specialists that reside along the product development value stream. This
chapter examines both of these requirements: subsystem integration and
cross-functional integration.

297
Morgan Liker sec 5 3/2/06 11:52 AM Page 298

Section Five: Creating a Coherent Lean PD System

Many companies have strong individual subsystem attributes and

highly capable functional departments. But all too often, subsystem char-
acteristics do not fit together well, and functional organizations do not
collaborate at the level required for high velocity lean product develop-
ment. Often there is no “enterprise” perspective, the three subsystems
grind against each other while individual functional organizations are
insular and corporate cultures emphasize individual achievement driving
incompatible objectives. They are in a state of constant conflict, as the
organization seems to be locked in a perpetual struggle against itself. Con-
sequently, efforts to implement lean, and lean product development
processes in particular, go awry despite their best intentions.
We should emphasize that Toyota does not have complex system the-
ory masterminds who orchestrate their very complex systems. In fact a
hallmark of Toyota is the use of simple and common sense processes that
work. Any of the subsystems that we have described through the thirteen
principles is elegant in its simplicity. But taken together, the subsystems of
Toyota’s PD system are effectively aligned and mutually supportive to
create a high degree of system harmony. Moreover, all of Toyota’s func-
tional organizations throughout the product development process are
integrated and work collaboratively. The powerful synergistic effect pro-
duced by this is one of the most important reasons that Toyota’s PD sys-
tem is so successful.
Because the company consistently excels at integrating all of its
parts, the whole runs smoothly. The three subsystems explored in this
book—people, processes, and tools and technology—are elements of a
larger, comprehensive and harmonious system with a single purpose.
That purpose is to bring great products to market as quickly and effi-
ciently as possible, something that Toyota manages to do consistently.
Toyota has also learned that it takes the combined efforts of stylists, body
engineers, manufacturing engineers, toolmakers, and manufacturing
specialists to launch high quality products successfully. Integrating these
diverse functional organizations and aligning their efforts is key to effec-
tive product development (Clark & Fujimoto, 1991; Wheelwright &
Clark, 1992).
Thus, two things are necessary to create a high-performance lean PD
system: 1) the integration of subsystems into a unified, coherent system
whose single purpose is product development, and 2) the integration of
the various groups of diverse technical specialists required to develop a
new product. The greatest strength of a lean product development system

298
Morgan Liker sec 5 3/2/06 11:52 AM Page 299

A Coherent System: Putting the Pieces Together

lies in this seamless integration and in having a common culture that truly
supports the lean PD system.

Subsystem Integration: People, Process, Tools

and Technology
The first step in developing an aligned PD system is to establish what your
customer values. Then you develop a waste-free workflow or process to
deliver this value. However, efficient processes are useless if you do not
have the right people available at the right time. You must consider the
skills, practices, and organizational characteristics needed to execute the
process that will deliver customer value. Finally, you must have the tools
and technologies that support the activities of these people to enable them
to achieve their potential and empower them to excel. In manufacturing
and engineering, “cherry picking” single tools and practices without due
consideration of the systemic environment is a common failing in many
lean initiatives. However, as the opening quote of this chapter suggests, to
build complex systems you must start with simple systems that work. As
we will discuss in Chapter 17 you cannot attack your entire organization at
once. You must take bite-size pieces and slowly transform work stream by
work stream.
As discussed throughout this book, most consumer-driven companies
are struggling with PD development systems that are out of sync and fall
short of delivering customer value. Most companies do not invest in the
integration of processes, people, and tools and technology, nor do they
have a vision for a coherent PD system. One way to illustrate how purpose
driven, aligned, and mutually supportive subsystems of a lean PD system
succeed is to examine the integration of these subsystems from the per-
spective of the five lean principles of value, value stream, pull, flow, and
perfection described in Lean Thinking (Womack and Jones, 1996).

Identifying Value: Delivering Customer-Defined Value

Delivering customer-defined value is the first and arguably the most
important task in product development. If you do not create and deliver
something the customer values, you have wasted your efforts. In lean
thinking, delivering customer-defined quality becomes the core purpose
of the organization. Toyota succeeds at this by focusing process, people,
and tools on clear objectives. This process begins in the kentou or study

299
Morgan Liker sec 5 3/2/06 11:52 AM Page 300

Section Five: Creating a Coherent Lean PD System

period through the creation and diffusion of the chief engineer’s (CE)
concept paper. Based on the data and information gleaned from the CE
paper, competitor analysis sheets, and preprogram plant visits, the mod-
ule development teams set specific component level goals to achieve the
CE concept. Various functional representatives support the CE’s vision
for delivering value to the customer; in addition, these individuals
actively participate in the process by communicating the strategy to their
respective home organizations. Furthermore, both engineering and
manufacturing specialties are represented in the module development
teams, increasing the odds the organization will actually deliver value to
the customer.
These practices flourish within a culture that consistently practices a
“customer first” philosophy. The flip side of this is that having a customer
first context multiplies the effectiveness of your processes and tools.
Clearly, people, process, and tools combine to support customer-defined
value (see Table 16-1), and customer-defined value as a common culture
supports people, process, and tools.
Table 16-1. Driving Customer-Defined Value

PROCESS PEOPLE TOOLS

• Kentou study • Chief Engineer • CE concept paper
phase to analyze System • Competitive tear-
and agree on a • MDT cross- down analysis
specific strategy functional team sheets for setting
to deliver value to implement specific measura-
to the customer • Customer-first ble goals
• Preprogram plant philosophy
visits to identify pervades the
any current organization
quality issues

Enabling the Value Stream: Eliminating Waste

and Variation
In Lean Thinking, Jim Womack and Dan Jones (1996) emphasize the
importance of reducing or eliminating waste. Chapter 5 of this work elab-
orates on this theme, describing specific wastes that are particularly insid-
ious to the product development process. Nonessential or redundant

300
Morgan Liker sec 5 3/2/06 11:52 AM Page 301

A Coherent System: Putting the Pieces Together

activities that add no value to the product are time and resource-consuming
extravagances that become a serious drag on the value stream of any per-
formance product development.
In a lean PD system, you need to eliminate waste found in and gener-
ated by your product development process. At Toyota, this begins with
detailed scheduling and capacity planning, to identify the most efficient
use of available resources, and with cross-functional agreement to a stag-
gered data-release strategy to reduce the size of batches. Toyota’s A3 stan-
dardized communication and problem-solving discipline provides for
effective communication across functional organizations, minimizing
much of the waste caused by poor communication.
Standardized best practices and their associated checklists drive con-
sistent execution and support the broad responsibilities of the simultane-
ous engineer (SE). This, in turn, minimizes the need for hand-offs and
builds in accountability. The up-front kentou or study phase allows prob-
lems to be identified and resolved before the execution phase. This prac-
tice, combined with design and process standards, minimizes engineering
changes that are another tremendous source of waste. Toyota’s checklists
and standards, supported by culturally-ingrained process discipline,
enable execution of detailed work, eliminating unnecessary reviews and
quality inspections. Finally, as a learning organization, Toyota sees prod-
uct development as a repeatable process that is subject to Plan, Do, Check,
Act (PDCA). Every development program, and every stage within a pro-
gram, is an opportunity to identify opportunities to eliminate waste in the
next program.
The reason Toyota’s PD system combats waste so effectively is that the
various organizational subsystems reinforce each other. The SE could not
function effectively were it not for the checklists, senzu, and standardized
processes that minimize hand-offs. Nor could the SE be able to assume
the great responsibilities required of him or her without first traveling a
career path designed to develop appropriate skill sets for the SE role. The
kentou process would not be nearly as effective if it were not for the par-
ticipation of the cross-functional module development teams and tools
like quality matrices and digital assembly. The point is that, in each of
these cases, organizational subsystems work together to create a synergis-
tic effect, which is also manifested in the product designs that drive lean
manufacturing.
The kentou processes—early, intense involvement of the module
development teams, supported by tools such as the part-based quality

301
Morgan Liker sec 5 3/2/06 11:52 AM Page 302

Section Five: Creating a Coherent Lean PD System

matrix, senzus, and standard manufacturing processes—drive quality and

lean manufacturing to the very inception of the product. The combined
power of all these individual components makes it possible for Toyota to
exploit the full potential of lean manufacturing (see Table 16-2).
Table 16-2. Eliminating Waste in the PD Process

PROCESS PEOPLE TOOLS

• Minimize process • SE group and the • Checklists
hand-offs career path that • Sensu
• Detailed schedul- enables broad • Standard process
ing and capacity responsibility sheets
planning for • MDT to anticipate • Quality matrices
best resource and resolve issues • Up-front use of
utilization early digital assembly
• Kentou to mini- • Manufacturing • A3 communication
mize changes personnel in up-
and rework front planning

Eliminate or Isolate Variation

In any process, task and arrival variation combined with system overuse are
the greatest causes of long queues and subsequent protracted lead times
(Hopp & Spearman, 1996). As one countermeasure, using best-practice
templates in product development has a significant positive impact on
throughput times (Adler et al., (1996). That is not to say that it is possible
to eliminate all variation or that all variation is negative. On the contrary,
some variation is inherent to product development, and some is even posi-
tive because it can lead to exploring divergent ideas. Recognizing these two
peculiarities of variation led Toyota to the strategy of confining most vari-
ation to the preclay freeze phase of product development, thereby isolating
it from the execution phase.
A PD system culture is shaped by the greater culture in which it exists.
A culture that values adhering to standardized process and focuses on
detailed execution drives a PD system culture that abhors delays. Toyota
starts its PD process by convening module development teams far before
clay freeze to identify and resolve core-engineering issues that are likely to
cause delays in the execution phase. It uses schedules that minimize arrival
variation, and Toyota engineers work to standardize processes and check-
lists, which provide best practice templates to reduce task variation.

302
Morgan Liker sec 5 3/2/06 11:52 AM Page 303

A Coherent System: Putting the Pieces Together

Toyota treats tool manufacturing as a manufacturing operation and

applies lean principles to the process, resulting in low levels of variation
and WIP—high quality and short lead times. The value of team integrity
has made it possible to automate the tool manufacturing process; Toyota
toolmakers do not resist automation because of the trust created in the
company’s adherence to this value over the years. As technology advanced,
the toolmakers became CAD modelers, process planners, programmers,
and CNC machinists. These people, the process they are engaged in, and
the tools they use combine forces to make possible low levels of variation,
shorter lead times, and consistent, predictable outcomes for timing and
quality (see Table 16-3).
Table 16-3. Reducing Variation in the PD Process

PROCESS PEOPLE TOOLS

• Kentou for core • Cross-functional • Checklists
engineering and MDT gather • Standardized
early problem before clay freeze process sheets
solving before the • Disciplined to
execution phase schedules
• Standard • Trust from team
processes integrity
• Lean tool manu-
facturing process

Flexible Capacity
As discussed in Chapter 5, the ability to create flexible capacity is critical
to the highly cyclic environment of product development (Adler et al.,
1996; Loch and Terwiesch, 1999). Stated simply, it is the ability to have
resources available when required, without having to pay for them when
they are not. This allows an organization to bring the right resources to the
right place at the right time without the cost of negotiating with suppliers
or the expense of staffing to peak workloads.
The primary enablers of flexible capacity and the use of capacity relief
values at Toyota are standardized skills, standard processes, and design stan-
dards. This standardization makes it possible for technicians from pools to be
assigned to a given program JIT, perform with little or no direction, and move
on to another program as needed. (This standardization also allows Toyota
to release work to affiliated companies with little or no transaction cost.)

303
Morgan Liker sec 5 3/2/06 11:52 AM Page 304

Section Five: Creating a Coherent Lean PD System

Toyota’s culture of discipline and the practice of rewarding individu-

als for process adherence, emphasis on team integrity, and rewarding tech-
nical excellence further reinforce flexible capacity. The company’s cultural
values promote the technical skills and support waste-free flexibility. If a
company does not thoroughly understand and follow its standards, the
practices that support flexibility will degrade into confusion, delay, and
poor quality. Toyota extends these cultural values to its network of suppli-
ers; companies that supply engineers to Toyota are treated as “partners”
and the engineers are taught Toyota’s specific engineering processes as well
as Toyota’s culture (see Table 16-4).
Table 16-4. Creating Flexible Capacity

PROCESS PEOPLE TOOLS

• Well-understood • Career path • Checklists
standard designed to • Design standards
processes create standard • Standard process
• Front-loaded skills sheets
capacity planning • Affiliate compa-
and capacity relief nies are part of
valves family
• Technician pools
• Reward people
for process
adherence

Creating Pull and Flow

Once a company has reduced or eliminated waste and variation from a
single process and streamlined the value stream, the next task is to make
the remaining process steps flow (Womack & Jones, 1996; Rother & Shook,
1998). The goal here is to have a product move steadily from concept to
customer without interruption or delay. In product development, this
includes developing effective concurrent engineering capability along with
synchronized cross-functional tasks.
Participants in Toyota’s product development process stagger the
release of product and manufacturing data so that data is pulled as
required by the next functional organization while cross-functional teams
maximize the utility of the available data; participants do not attempt
work with unstable data. In the earliest phase of product development

304
Morgan Liker sec 5 3/2/06 11:52 AM Page 305

A Coherent System: Putting the Pieces Together

(kentou), for example, module development teams seek out data that, in
some respects, seem related to things that may not be real-time concerns
until months later. But the plant visits, matrices, and digital assemblies
used by the MDT’s are staggered, real-time activities. They are appropri-
ate because they provide stable data that impacts the early stages of PD in
a way that precludes problems in later stages or even in manufacturing. In
addition, Toyota’s cultural bias for detailed execution drives a thorough
understanding of subtasks. This enables meticulous task design and syn-
chronization, which, when combined with standards and standardization
tools, eliminates review events. This creates a steady movement or flow of
data from clay freeze to SOP. As discussed above, this is especially true in
the tool-manufacturing phase of product development, when lean man-
ufacturing concepts are utilized to create flow in Toyota’s tool and die
operations. The result is process flow and subsequent short lead times
(see Table 16-5).
Table 16-5. Creating Flow

PROCESS PEOPLE TOOLS

• Staggered design • Detailed • Standard process
release execution • High precision
• Synchronized • Trust from team machining and
processes for integrity patented tools
simultaneous exe- • Broad knowledge • Digital assembly
cution of PD process early in the
• Kentou early • MDT process
problem solving
• Lean tool
manufacture

Enable Efficient Manufacturing

One of the three primary purposes of an effective product development
system is to create designs and processes that support high-quality, waste-
free manufacturing. Your greatest opportunity to impact the cost, quality,
and manufacturing efficiency of a product is during its development. You
access the true power of lean manufacturing when you apply lean princi-
ples to the product and process from the start. Throughout this book are
examples and descriptions of ways in which Toyota’s PD system acts as a
key enabler for the company’s production system. From the very beginning

305
Morgan Liker sec 5 3/2/06 11:52 AM Page 306

Section Five: Creating a Coherent Lean PD System

of the PD process, MDTs examine the impact of new designs on efficiency

and ergonomics. Engineers utilize design standards, a modularity strategy,
and standardized manufacturing processes to minimize variation and
speed up the production ramp-up phase.
The staff production engineers and the plant production engineers
belong to the same centralized organizations and share knowledge and
goals. Production engineers keep their own checklists, which they share
with product development at the beginning of any new program. In
stamping, standardized tool and die manufacturing practices, like preci-
sion machining and construction, speed up setup times and minimize
between setup variations (see Table 16-6).
Table 16-6. Enable the Toyota Production System

PROCESS PEOPLE TOOLS

• Kentou • Cross-functional • Quality matrices
• Hansei MDT activity • Digital assembly
• Precision die w/production • Patented machine
making to mini- pilot team leader tools
mize setup and • Production engi- • Quality matrices
reduce manufac- neering a single, with quality and
turing variability centralized organ- productivity issues
• Design around ization. Plant and • Digital assembly
standard pro- engineering staff tools at kentou
cesses, common have common
modular architec- goals and
ture (locators/ experience
construction • Manufacturing is
sections/weld a priority
location)
• Preprogram
plant visits for
designed-in
countermeasures

Perfection: Build in Learning and Continuous

Improvement
“Pursue perfection” is the final step in lean transformation advocated by
Womack and Jones (1996). It is an interesting expression, implying that

306
Morgan Liker sec 5 3/2/06 11:52 AM Page 307

A Coherent System: Putting the Pieces Together

there is no end to how much better a process can become through the con-
sistent application of lean methodologies. Lean is a journey, not a destina-
tion, and only by learning and continually improving can organizations
compete in the hypercompetitive product development environment that
currently exists. It bears repeating that learning is a fundamental part of
Toyota’s DNA (Spear & Bowen, 1999) and that Toyota’s learning is about
acquiring, sustaining, and passing on valuable tacit knowledge. In a lean
PD system, numerous tools and technologies, processes, and organiza-
tional practices support the culture characteristics that create a powerful
learning network. This book has covered a few of these, showing how each
of them has been consistently communicated, applied, and practiced at
Toyota (see Table 16-7).
Table 16-7. Building in Learning and Continuous Improvement

PROCESS PEOPLE TOOLS

• In-process • Technically-skilled • A3 problem
reflection/hansei managers solving
events • Learning DNA • Learning focus
• OJT and • Skills based career • Supplier
mentoring path and evalua- technology
tion demonstrations
• Teaching as lead- • Know-how
ership database
• Users update stan- • Freshman project
dard checklists • PDCA cycle

Cross-Functional Integration
Aligned and mutually supportive lean product development subsystems
are a solid foundation for a coherent PD system that is more powerful than
the sum of its parts. However, product development performance also
depends on the integration of functional organizations without diluting
the specific assets and good characteristics of individuals in the functional
organization being integrated. Bringing high quality products to market
successfully requires the efforts of a large group of diverse technical spe-
cialists. There must be appealing styles from the design studios, practical
and workable designs from product engineering, capable processes from
manufacturing engineering, quality tools on time from tool and die, and
high quality products from manufacturing. You create great products

307
Morgan Liker sec 5 3/2/06 11:52 AM Page 308

Section Five: Creating a Coherent Lean PD System

when all of these functional activities are goal aligned, synchronized, inte-
grated, and reinforce each other. The degree to which they act harmo-
niously toward a single goal determines the success of the enterprise. Seven
cross-functional integrators that have evolved at Toyota were discussed in
previous chapters (particularly Chapter 8). They are worth revisiting in
connection with the information presented in this chapter.

Integrated Development Teams. Toyota’s cross-functional develop-

ment was formalized fairly recently, but similar teams have existed for
decades, working informally to meet common goals. The teams consist of
representatives of functional specialties involved in the early development
of product and processes when decisions have the greatest impact on the
ultimate success of the program. Because the participants remain a per-
manent part of their respective functional organizations, the danger of lost
or unshared technical knowledge across programs is minimal.

Obeya Team System. Another recent development at Toyota, the obeya

team integrates various product development participants throughout the
life of a program. Managers of each functional organization meet in a war
room with the CE and staff several times a week; these meetings enable fast
decision making and information sharing across functions.

Checklists and Standardization. This is a somewhat surprising source

of integration at Toyota because it seems to reflect what occurs during a
single process or operation. But when functional groups work reliably to a
standard process or design standards, other groups know what to expect
from them and when to expect it.

Functional Build. Previously discussed in Chapter 13, functional build is

a key cross-functional integrator because it brings together various func-
tional specialists to make tactical decisions based on system-level criteria.
Diverse technical specialists work in close physical proximity to the vehi-
cle and to each other, sharing technical communication across functions.
Each specialist contributes knowledge from his or her respective organi-
zation, but the group makes decisions based on objective data and a sin-
gle purpose.

A3 Standardized Communication. Accurate communication is crucial

for integration. Given the number of specialized groups in a product

308
Morgan Liker sec 5 3/2/06 11:52 AM Page 309

A Coherent System: Putting the Pieces Together

development project with its own jargon and terminology, this can be dif-
ficult to achieve. Because the A3 format uses graphics and short, precise
phrases, it bridges these differences and, quite literally, puts everyone on
the same page.

Resident Engineers. Toyota temporarily assigns resident engineers from

suppliers both within and outside of Toyota for periods of up to three
years. These temporary assignments, especially to affiliated companies,
have a positive effect on integrating the various organizations and spread-
ing standardized operating procedures and technical knowledge. This
practice promotes a sense of belonging to a common corporate entity.

Hansei Events. During these reflection events, different groups come

together to discuss performance on an ongoing or recently completed pro-
gram. This event not only provides an opportunity to learn and improve,
but an opportunity for cross-functional groups to identify opportunities
for better coordination of their respective activities. Discussing common
outcomes helps different functions build a sense of shared destiny.
Toyota does not leave cross-functional integration in product devel-
opment to chance. It uses these seven mechanisms to integrate the many
diffuse technical specialists required to develop a new vehicle, without
the risks posed by the platform team approach. Through these integra-
tors, its product development subsystems, and its culture, Toyota has
evolved an integrated, aligned, and coherent PD system. The operative
word is “coherent.”

309
Morgan Liker sec 5 3/2/06 11:52 AM Page 310
Morgan Liker sec 5 3/2/06 11:52 AM Page 311

CHAPTER 17

Eliminating Waste in the Product

Development Value Stream
“I clearly remember an argument with my father about starting a
new project. I was against the project, and I won the argument. But
then my father asked me to give the project a try anyway, which I did.
Much to my surprise, it turned out to be a great success. From then
on I did less arguing and more practicing.”
KIICHIRO TOYODA (referring to his father Sakichi Toyoda)

THE PREVIOUS CHAPTERS OF THIS WORK presented the principles and frame-
work of the lean product development system, supplemented by illustra-
tive examples of specific methods and cultural practices that enable or
limit the potential of this high-power strategy. At this point, the reader
may well be wondering how to use the information in this book to trans-
form your existing PD system into a lean PD system. In the next two chap-
ters we will provide tools, methods and insights designed to aid you in this
challenging and exciting journey. This chapter focuses on improving the
product development process through a value stream focus and the appli-
cation of lean PD process principles. Chapter 18 will examine proven
methods for transforming to a lean culture.
As posited by Rother and Shook (1998), “A value stream is all the
actions (both value added and non-value added) currently required to
bring a product from raw material to the arms of the customer or through
the design flow from concept to launch.” Value stream mapping (VSM) is
an effective technique for graphically drawing these activities, as well as the
flow of information and product between those activities. (Toyota, which
developed this concept for manufacturing, calls it the Material and Infor-
mation Flow Diagram.) By mapping the value stream, you can visualize
the entire process, which then supports fundamental process reinvention
that requires you go forward to the most critical step—developing a future
state value stream map. The current state is the foundation. The future
state is the vision of where you want to go. For Rother and Shook, VSM is
a proven tool for improving manufacturing processes and the missing

311
Morgan Liker sec 5 3/2/06 11:52 AM Page 312

Section Five: Creating a Coherent Lean PD System

ingredient in many failed lean manufacturing initiatives. The same

authors explain that VSM is powerful because:
• It helps you visualize more than a single process.
• It helps you see more than waste—it helps you see the sources
of waste.
• It serves as a common language for all participants.
• It brings you beyond fixing individual problems in the future state
to a coherent vision of a future state system.
• It forms the basis of an implementation plan. It helps you
design the whole system and becomes a blueprint for lean
implementation.
• It makes decisions about flow apparent.
• It shows the link between information and material flow.
Central to value stream mapping is a systems philosophy of managing
change. Since you are seeking to change a complex system, it is not enough
to identify isolated problems in particular processes and fix those problems.
Therefore, value stream mapping never stops with a current state map. The
current state map provides grounding in reality, but the real leap is in develop-
ing a vision for the future state. This is what provides a vision for the future
system and the subsequent action plans you must implement to achieve it.
Although Rother and Shook include product development as a part of
their definition of VSM, one of the authors of the current work (Morgan,
2000) was the first to develop a specific adaptation of VSM for the prod-
uct development environment (PDVSM). While focused on product
development, the methodology can be applied to any process that crosses
functional or organizational boundaries and where tasks are parallel and
interdependent. Because it is so critical to the change process, an overview
of the PDVSM tool merits further attention, both in the context of this
chapter and in a case study in the appendix demonstrating its use. A sep-
arate PDVSM workbook (also by Morgan) provides a step-by-step expla-
nation of the PDVSM process.

Product Development Value Stream Mapping (PDVSM)

Many of the issues endemic to complex processes are particularly prob-
lematic in the PD process, and the PDVSM tool in product development
is at least as useful as (or perhaps even more useful than) VSM is in man-
ufacturing. Here are some reasons why this tool is so powerful:

312
Morgan Liker sec 5 3/2/06 11:52 AM Page 313

Eliminating Waste in the Product Development Value Stream

1. Task and arrival variability resulting in long queues and wasteful

work and data-in-process inventories are pervasive in the PD
process. Although some variability may be inevitable, even bene-
ficial, due to the nature of design work, the authors’ studies and
the previously-mentioned research by Adler demonstrate that it
can be managed.
2. Non-value added activities or wastes are rampant in the PD process
just as they are in traditional manufacturing processes. The longer
time frames and complex nature of the PD process work tends to
obscure a great deal of insidious non-value-added activity.
3. Discernable pattern of product evolution from one state to another
over time. However fitful, the PD process does progress from
concept to customer. In fact, the PD process consists of many
progressive flows of information and decisions and parallels
similar issues in manufacturing (e.g., batching versus single
piece flow).
4. Capacity and scheduling-related issues. System utilization is one
of the best predictors of lead times in manufacturing and prod-
uct development systems. Whether measured in person-hours or
throughput, both types of processes must deal with capacity
constraints. Product development systems typically have big
peaks and valleys in workload, and the peaks operate at levels far
beyond their capacity.
5. Hand-offs from one functional activity to another. The greatest
challenges are often found at the intersections of activities,
whether in manufacturing or PD.
6. There is a work process that you must continually analyze, stan-
dardize, and improve. Although the nature of product develop-
ment work and manufacturing work differs, both can be
enhanced through process improvement efforts.
7. Pressures for lead-time reduction. The focus of value stream map-
ping is on improving cycle times and time in system, especially
as compared to the actual value-added time. Continually achiev-
ing shorter time to market is a system level goal of high-per-
formance product development systems.
8. Tasks must be synchronized. In product development, you must
synchronize concurrent tasks across functional organizations or
work centers to minimize the waste of rework and maximize the
benefits of concurrent or simultaneous engineering.

313
Morgan Liker sec 5 3/2/06 11:52 AM Page 314

Section Five: Creating a Coherent Lean PD System

9. Constraints must be identified and managed. PD processes, like

manufacturing processes, are only as good as the weakest link.
10. Creating flow. Once you have eliminated waste, you must make
the overall process flow by synchronizing cross-functional tasks
and identifying your constraints. This is as important in PD as it
is in manufacturing.
Just as with manufacturing processes, the PD process can be improved
by value stream mapping and diligent implementation of the resulting
action plan by a cross-functional team.

Addressing Some Differences Between PD and

Manufacturing VSM
While manufacturing and PD processes may have some common charac-
teristics, product development and engineering environments are signifi-
cantly different than manufacturing, and we have yet to find a company
that has been successful in improving PD performance simply by moving
shopfloor tools to PD. To use PDVSM effectively you must understand
some of the unique aspects of the PD environment and how it contrasts
with a manufacturing environment.
1. Product development is largely concerned with the flow of data
rather than a physical entity. The main focus is on the data value
stream and data are more elusive than physical raw materials. Later
in the process we look at tool and die making and other manu-
facturing processes but early on it is all data. An important char-
acteristic of data is that it can reside simultaneously in multiple
locations, allowing many of the activities in PD to operate con-
currently rather than in sequence.
2. Temporal measures in PD are calculated in weeks, months, and even
years (as opposed to minutes and seconds in manufacturing); are
often ill defined; and can be highly variable. This has important
implications for both the mapping process and the learning/con-
tinuous improvement process.
3. The nature of the work in PD is intangible compared to that of
traditional manufacturing. Much of the work is intangible, even
invisible. It is what Peter Drucker referred to as “knowledge
work.” By its nature, it is more diverse and less predictable.

314
Morgan Liker sec 5 3/2/06 11:52 AM Page 315

Eliminating Waste in the Product Development Value Stream

4. Data, information, and product flow is often nonlinear and multidi-

rectional. Much of the work is iterative, cyclic, or narrowing in
nature. Rather than a continuous, consistent march from raw
material to finished product, the PD process is a fitful progression,
punctuated by significant setbacks. Information and data flow
reciprocally between multiple activities simultaneously in the PD
process. The PD process is not as predictable as traditional manu-
facturing and requires substantially more and different types of
communication.
5. There is a larger, more diverse group of participants in the PD
process. The PD process requires many technical disciplines or
functional activities, each of which contains multiple tasks
and subtasks.
Although these issues differentiate the typical PD processes from man-
ufacturing processes, be aware that the PD process inherently shares many
of the characteristics that occur in all multistage processes.

Specific Challenges and Countermeasures for Mapping the

PD Process
Table 17-1 shows some of the unique characteristics of the PD process that
present significant challenges for a mapping methodology. You will need
to address these challenges individually, along with specific mapping tech-
niques as countermeasures.
Table 17-1. VSM in Product Development Versus Manufacturing

Product Development Traditional Manufacturing

Process Process
Virtual data flow Physical product flow
Weeks and months Seconds and minutes
Primarily knowledge work Physical manufacturing
Nonlinear and multidirectional Linear evolution
flows
Large, very diverse group of Primarily manufacturing
technical specialists organization

315
Morgan Liker sec 5 3/2/06 11:52 AM Page 316

Section Five: Creating a Coherent Lean PD System

Virtual data
In a manufacturing environment value stream mapping focuses primarily
on the material flow. Information/data primarily supports the material
evolution from raw materials to finished goods. The tendency of physical
materials to reside in one place at a time definitely simplifies the mapping
process. In product development, you need to be concerned with the evo-
lution and flow of ideas and data. The fact that data can reside simultane-
ously in multiple locations is crucial to concurrent engineering (see Figure
17-1) but makes the mapping process (as well as coordination of activities)
somewhat more complicated because there are simultaneous activities that
you must display on the map.

Version 2.2b
Version 2.1
E/C 1A–8C
Version 1

Styling Body and Structure Engineering

Version 2.2b E/C Req. 1.5

Version 1 E/C Req. 1.2

Manufacturing Engineering

Process ver.1.3
Version 1 E/C Req. 1.5

Binder Development Out to Lunch.

Waiting for data.

Die Design

Figure 17-1. Virtual Data Resides Multiple Places Simultaneously

You can address this difficulty by creating multiple-functional tiers or

horizontal layers, aligned with a single time scale, in which you can see
many different activities occurring simultaneously at any given time dur-
ing the PD process (see Figure 17-2). This will give you system level
insights into the process. From this perspective, VSM is useful for facili-
tating concurrent engineering.
Simultaneous activities also complicate your ability to “go and see” or
“go to the source,” as is recommended in traditional value stream map-

316
Morgan Liker sec 5 3/2/06 11:52 AM Page 317

Eliminating Waste in the Product Development Value Stream

Months Before Start of Production

25 24 23 22 21 20

Clay Scan
Clay
O Release

Level II Product Data Level II Update

Level I Level II
C C
Body Engineering C O Release Release

Product
Product
WIP
Product
Product
L I Process L II Process Level II
Die Processing KO C D C
Process

LI 5 FEA Cycles
Product Rev
Process
Process
WIP

Review L I Binder FEA L II Binder

Binder Development & FEA O KO D C CR CD

Product WIP Binder Process

& Process
Review
Die Design
Die Design KO D D

WIP Binder
& Process
Prog Mgmt Photo Cad Eng
Prototype KO D

Prototype
Die Design

Patterns

Figure 17-2. Time Scale and Functional Process Layering Applied

to PD Value Stream

ping. After all, people, like materials, cannot reside in more than one
place at a time. However, the longer task time frames associated with the
PD process gives you sufficient time to record multiple functional activi-
ties through engineering activity logs and interviews as well as to employ
various database technologies to capture movement of virtual data
instantaneously.
Longer time frames
The longer, more variable time periods associated with the PD process is
another important distinction from typical manufacturing where task
times are measured in minutes or even seconds and are usually stable,
predicable, and subject to little variation. You measure the task times in
product development in weeks, months, and even years, and these can be
quite variable (see Figure 17-3).
For this reason, PDVSM tacks the time scale located at the top of the
page on Figure 17-4 so that you can draw up all activities with respect to
this scale. It is also possible to locate major scheduled milestone events to
which you can compare actual events (see Figure 17-4).

317
 Initial Milestone Milestone Final Milestone
Release Release I Release II Release
January February March April May
Morgan Liker sec 5
3/2/06
11:52 AM

318
Page 318

Frt Ctr Mbr v2

Fndr Inr v5
WIP Hood Otr v11 Hood Otr v8 E/C Change
Data Hood Invr v2 Hood Inr v1.2 Requests
Section Five: Creating a Coherent Lean PD System

Manufacturing Engineering

Figure 17-3. Product Data Release Time Frames

Morgan Liker sec 5 3/2/06 11:52 AM Page 319

Eliminating Waste in the Product Development Value Stream

Figure 17-4. PDVSM Data Release and Program Milestone Representation

As the level of mapping focus changes, you should change the time
scale accordingly. When you are mapping higher-level cross-functional
activities, for instance, a time scale in weeks or even months is appropri-
ate. If you zoom in on an activity to map a specific process, your time scale
will probably be in working days (see Figure 17-5).
Knowledge work
In traditional manufacturing, work takes place on the factory floor in the
form of employee labor and machine processing. In contrast, much of the
work involved in product development is knowledge work, occurring in
the worker’s mind. If you are not documenting this work, it will be invis-
ible and therefore difficult to map. You can collect timing data for your
current state map for slow moving physical objects such as dies or fixtures
using tool tags. Figure 17-6 is an example of a tool tag that was used to

319
Morgan Liker sec 5 3/2/06 11:52 AM Page 320

Section Five: Creating a Coherent Lean PD System

Months Before Start of Production

23 22

Release I
WIP Level II
Release
Die Process

Initial Process
D C
160 h 40 h
TT: 24 h
TIS: 40 h
VR: 60%
WIP Process
Data E/C Change Request
(die tip)
Binder Dev.

Level I Binder Development

C D
D
Rev x4 Rev x5
TT: 60 h
TIS: 120 h
VR: 50% FEA Analysis
FEA

C
C 8 Cycles FEA
3 Cycles FEA
TT: 68 h
TIS: 100 h
VR: 68%

6/25 6/26 6/27 6/28 6/29 6/30 7/1 7/2 7/3

Binder Dev.

E/C request
to die processor
D
120 h
Waiting for Possible form Request new
Level II Rev issue at current Rev tip angle from
die tip angle die processor

FEA Analysis Cont.

x
x
FEA R x FEA FEA
FEA

Rev R
Sunday
x
Rev FEA FEA FEA Rev FEA
x
x
TT: 33 h * Investigate binder * Investigate
TIS: 60 h
tonnage adjustments optimum
VR: 55%
die tip angle

Figure 17-5. PDVSM Different Levels of Magnification

(month, upper, versus days, lower)

320
Morgan Liker sec 5 3/2/06 11:52 AM Page 321

Eliminating Waste in the Product Development Value Stream

Tags are affixed to the tool and updated by plant associates or

material handlers every time an activity is performed on the tagged tool.

Front of Tag

Manufacturing Activity Log

Part # ________________

Start End Operation

Date Time Time Category Operation Description / Comments
Setup/Teardown
Machine Cycle
Manual Activity
Re-setup
Delay/Queue
Track for activity (value
Setup/Teardown
Machine Cycle added) and track for
Manual Activity duration of setup, machine
Re-setup
Delay/Queue and manual processing
Setup/Teardown (and any delays).
Machine Cycle
Manual Activity
Re-setup
Delay/Queue

Date Verified: _________ Verified by: ________________________

Back of Tag

Tooling Movement Log

Date Time From To Move Description

Track for movement in

plant.

Log TO and FROM data,

date and time, and reason
for the move.

Date Verified: _________ Verified by: ________________________

Figure 17-6. Example Data Collection Using Tool Activity Tags

321
Morgan Liker sec 5 3/2/06 11:52 AM Page 322

Section Five: Creating a Coherent Lean PD System

follow the flow of tooling development over time and generate activity
logs with actual times. You can record data on timing in engineering activ-
ity logs, shown in Figure 17-7, for binder development. Figure 17-8 shows
the actual hand-drawn current state map of the binder development
process from this data.
Although logs and interviews have their limitations, you can support
them through cross-referencing and the data-tracking technologies dis-
cussed above. Virtual and physical manifestations of the knowledge work
are also available as evidence of work performed. Virtual manifestations
include computer graphics of part designs, test result animation, and data.
Physical manifestations (such as clay models, drawings, prototype parts,
tools, and finally the finished product) also serve as indicators of project
status, location, or quality.
We should note that for purposes of improving the process extremely
precise data is not always necessary. Ballpark estimates of times can be a
basis for seeing large amounts of waste and a future state vision can be
constructed to significantly improve the process. Often very effective value
stream mapping workshops are conducted with cross-functional teams
and estimates by participants are used to supplement existing data.
Complex information flow
In manufacturing, the value stream is typically linear and unidirectional,
marked by discrete transition from one state to the next until the finished
good emerges from the process. A specific process step, once completed
correctly, does not have to be repeated. In product development, however,
much of the work is iterative, with data and information flowing back and
forth between functions in a complex web of activity. When combined
with the many different types of data and information flows, this can add
more complexity to your mapping assignment.
Data flow that is important to capture in product development
includes primary data releases, feedback, engineering changes, scheduling
information, and “unofficial” data exchanges. You need to identify deci-
sion points and process iteration because both cause major queues and
serious process delays. There are many different types of data/information
flows to map:

• The product data itself while it is in a virtual state. This includes

both partial and complete product data release dates as well as
engineering changes.

322
 Act/Tot
Month Week PART STATUS SUMMARY ENGINEERING ACTIVITY (Hrs)
Clay freeze
1
Morgan Liker sec 5

1 3

WIP data released by body eng. Waiting for official work Waiting for work order 0/40
4
order to start
3/2/06

Scheduled milestone I missed by body eng Waiting for work order

1 0/40

Milestone I data released Waiting for work order

2 8/40
Got OK to review WIP data despite no work order Review initial WIP data
2 3
Waiting for work order 0/40

Waiting for work order

4 8/40
11:52 AM

Milestone II missed by body eng Waiting for work order

1 0/40
Level I process received from die processing
Work order received. Immediate kickoff Update binder development to level I status
2 32/40
Pulled most recent version of product from body eng
3 3
Milestone II release. Pulled level II data from body eng Waiting for FEA reviews. Update binder development to level I status.
16/48
Possible formability issue at FEA—body eng notified 3 versions of binder submitted to FEA—three cycles performed
Formability issues at FEA. Discussing with body eng on course of action Waiting for FEA reviews. 4 different versions of binder submitted
4 20/40
Page 323

Reworking binder to try to resolve issue. Working with FEA to FEA—6 cycles performed
Milestone III release missed by body eng. Reworking binder Waiting for FEA reviews. 2 more versions of binder submitted

323
1 20/40
to try to resolve formability issue. Working with FEA to FEA—2 cycles performed
Waiting for updated data FEA ran 2 more cycles—no luck
2 0/40
4 3
Updated level II data received from body eng Rework level II binder to account for updated product
40/48
Ship updated binder and die design for their kick-off meeting
Milestone III release Waiting for data and FEA review. Prepped and shipped new binder
4 8/40
to FEA to verify formability—1 cycle performed
1 Pulled final data from body eng Working on other parts. 32/40
Update binder to final release
2 Working on other parts. Update binder to final release. Shipped final
16/40
binder to die design + FEA for final check. (FEA is busy with other parts.)
5 3 Waiting for binder development review meeting with customer.
0/40
FEA ran 1 cycle with new binder—no issues
4 Stamping plant has issued change in manufacturing line. Binder Review meeting. No issues.
0/40
development is unaffected
1
0/40

2
0/40
6 3
0/40
Eliminating Waste in the Product Development Value Stream

4
0/40

Figure 17-7. Example Activity Log Summary, Binder Development Activity—Door Interior Panel
 Scheduled Scheduled Scheduled
0 1 Milestone I 2 Milestone II 3 Final Release 4 5

Clay Mile I Mile II Final

Morgan Liker sec 5

Freeze Release Release Release

Updated
Updated Level II

Body Eng.
Level I
3/2/06

Level II
Level 1 process
process
11:52 AM

Review Formability
WIP Data Update to Level I Level II Rework Level III Update
Problem Solve Bind
O O D R Dev
Rev
80 h 120 h Bind R R/D C
R 40 h RWK 60 h
Dev RWK
KIO

Binder Dev.
No official TT: 8 h Still waiting Wait for Waiting

324
work order TIS: 40 h for official TT: 56 h TT: 40 h product TT: 48 h TT: 48 h for meeting
VR: 20% TIS: 80 h TIS: 80 h TIS: 80 h TIS: 80 h
Page 324

and no process work order concession

VR: 70% VR: 0% VR: 0% VR: 60%
& process
x3 ver x6 ver Rev

Level I FEA Formability Problem Solve Verify Fix Buyoff FEA

C
40 h

FEA
Binder Development Process Performance RWK Rev RWK Rev
Based on 8 hr days and 4 weeks per month:

Total TT = 112 hrs 3 cycles 10 cycles 1 cycle 1 cycle

Section Five: Creating a Coherent Lean PD System

Total TIS = 620 hrs (from first receipt of data)

Die design Die design

Binder Dev VR = 18%

Figure 17-8. Binder Development Current State VSM

Morgan Liker sec 5 3/2/06 11:52 AM Page 325

Eliminating Waste in the Product Development Value Stream

• Administrative direction or information given by control organiza-

tions, such as the program team. This might include milestone
dates and status to schedule, engineering change authorization,
decisions and approvals, purchase orders and quantities, bills of
material, etc.
• Feedback information communicated in response to some pro-
gram development activities. Examples might include manufactur-
ing feasibility feedback on a part design, or feedback from some
functional integration event, such as prototyping or report out
events on status to schedule, and so on.

You must document each of these information flows in the mapping

process, differentiating them by color, type of lines, and specific icons. You
must simultaneously engage in the process of narrowing the data. Nar-
rowing refers to the process of reducing a number of potential design solu-
tions until only a single selection remains. This process also takes place
over time and you can illustrate it on the map using a single color to show
multiple activities or solutions working simultaneously within the same
function. These activities are reduced over time until only one solution
remains and is then passed on to the next activity.
Large, diverse group of specialists
The PD process requires the efforts of large and diverse groups of techni-
cal specialists (see Figure 17-9). Pure manufacturing usually involves only
manufacturing people, either in direct labor or in a support role.
This difference clearly illustrates why PDVSM is so critical to “seeing”
your process. It will assist the many functional organizations to identify the
complex web of product development interdependencies, and, as previ-
ously mentioned, enable effective concurrent engineering by identifying
specific activities across functional organizations at any given point in time.

PDVSM Workshops
Utilizing engineering activity logs to obtain the data required is an accu-
rate way to create a current state PDVSM. However, because product
development cycle times can be fairly long, this can be time consuming
and should be used only if accuracy is critical. An alternative way to create
both the current and future state maps is in PDVSM workshops. These
three-day workshops were developed by Morgan (2001) as he began to

325
 Version I?
Updated Timing
Recover Plan
Morgan Liker sec 5

PND II Rel February

Program Management
3/2/06

E/Cs
E/C Req 15
11:52 AM

Body & Structure Engineering

E/C Req 15a

326
Page 326

WIP ver 14

Manufacturing Engineering

Major
Concern
Section Five: Creating a Coherent Lean PD System

FEA Binder Dev

Figure 17-9. Process Requires Large, Diverse Group of Specialists

Morgan Liker sec 5 3/2/06 11:52 AM Page 327

Eliminating Waste in the Product Development Value Stream

work with companies on improving existing PD systems and have proven

to be effective in a variety of product development environments (see Fig-
ure 17-10). Gathering data through tags and logs can lead to highly accu-
rate data, but the process can take weeks or even months. PDVSM
workshops require only some preliminary work and using estimates of
times can be completed in a few days. Figure 17-10 shows a sample agenda
from an actual three-day PDVSM workshop. One advantage of these
workshops is cross-functional dialogue that activity logs do not permit.
Getting a cross-functional team to engage in deep dialogue focused on a
common process, developing common objectives for performance, can be
quite powerful in and of itself. (Of course, having collected data via activ-
ity logs a workshop format can still be used for constructing the value
stream maps.)
The first step in organizing a workshop is to choose a small knowl-
edgeable group to identify what product or product family will be
mapped, the level of detail required, and the start and end points. This is
scoping the project. Once the group understands this, it will need to iden-
tify the organization’s customer and what value the company delivers to
that customer from the process. Based on this information, the group can
determine who should attend the workshop. Participants from all process
functions that you are intending to map in the workshop should be pres-
ent or represented, including the internal or external customer of the
process. The needs of the customer and the results of the process should
be aligned. Therefore, before having your participants start the workshop,
you need to gather supporting data from the target mapping project and
create a map framework (similar to that discussed for PDVSM) from
activity logs. Once you do this prework, the three-day workshop will go
something like this:

• Day one PDVSM workshop. The first day of the workshop begins
with a brief discussion of PDVSM and the scope and objectives of
the workshop. The participating team lays out the project and
reviews the map framework that was created during prework. All
functions are laid out along the Y (vertical) axis of the map frame-
work and the correct time frame is presented along the X (horizon-
tal) axis. (The authors typically print this framework on paper that
is 3 or 4 feet wide by 5 or 6 feet long.) Then the team begins to
recreate the process, utilizing large “sticky notes” for process boxes
and drawing by hand the information flows. The team should have

327
 PDVSM Workshop Framework

PREWORK WORKSHOP
Morgan Liker sec 5

SCOPING DAY 1 DAY 2 DAY 3 Management

Report Out &
3/2/06

Overview of Lean PD Overview of Lean Product Time Bounded Commitment

VSM “A tool Development Implementation
Who is the customer? for improving Principles Plan 72-hour response
How does the process processes” Discussion
11:52 AM

deliver value?
Implementation-
What value is created? Data for Current Enabler

328
Current State Map Proposals
Workshop goals
Page 328

State Map Opportunities/ Follow-up

What to map Identify Waste

Start and end points Status update to

Workshop management on
Who should Current Future State 30 day, 60 day,
participate? State Map Map Creation 90 day, 1 year
Creation
What data is required/
Section Five: Creating a Coherent Lean PD System

available?

Figure 17-10. PDVSM Workshop Framework Agenda

Morgan Liker sec 5 3/2/06 11:52 AM Page 329

Eliminating Waste in the Product Development Value Stream

brought with them all relevant historical data so they can draw
upon it to maximize the accuracy of the map. You can employ a
number of tools, techniques, and methods to increase the chances
of a successful mapping event, but that is beyond the scope of this
chapter. If you scoped your project correctly and the team’s first day
of the workshop was effective, they should have a completed cur-
rent state map and a very tired but excited group of people.
• Day two PDVSM workshop. On the second day, the team begins to
create the future state map. There should be a great deal of energy
and anticipation from the first day of the workshop where partici-
pants began to see some of the opportunities for improving their
PD process. This is a natural result of “seeing” that process for the
first time. The team needs to resist the temptation to start improv-
ing the individual pieces of process immediately. The authors fore-
stall this temptation by a discussion session focused on the 13
principles of lean product development covered in this book, giv-
ing particular attention to the principles, methods, and techniques
addressed in Chapters 3 to 6 (the process section of this book):
– Create leveled flow and eliminate rework in your process by
front-loading problems.
– Design quality into the product design, achieving system
compatibility before component completion.
– Create cadence mechanisms to drive the process forward
together.
– Synchronize cross-functional activities to transfer the right
information at the right time.
– Integrate your suppliers into the process.
This discussion will lead the team to identify additional oppor-
tunities for improvement and provide proven countermeasures
to address those opportunities. As they study the current state
map, participants should be actively engaged in questioning what
they are looking at, asking “where are the wastes?” and “how can
you use the principles to develop effective countermeasures?”
Once this is completed, the team can begin to create the future
state map of their process.
• Day three PDVSM workshop. On day three, team members work on
a time bound implementation plan based on transforming their
process to the future state. They must identify specific process
enablers that will allow or “enable” the improved performance

329
Morgan Liker sec 5 3/2/06 11:52 AM Page 330

Section Five: Creating a Coherent Lean PD System

level of the future state process. How, specifically, will you do

work differently to make the future state a reality? Proposal A3s
are an excellent tool for this purpose. You combine the individual
A3s into a detailed implementation plan that includes metrics and
then develop a PDCA approach to executing the plan. Those A3s
are some of the same documents that are posted in the obeya and
rigorously debated over at the cross-functional design reviews.

Finally, the team reports to senior management, those empowered to

make necessary changes or purchase required tools or technology. The
company should set a time limit (within 72 hours) for the senior manage-
ment team that has been involved from the beginning of the project to
respond to the team’s proposal.

Learning to See Product Development as a Process

The PDVSM process may be the first time that the participants are able to
truly see their PD process, and, in that sense, it is an invaluable learning
tool. The knowledge produced by the PDVSM exercise alone is well worth
the time required. Moreover, PDVSM is a communication tool, serving as
a common language between disparate functional organizations. For the
first time, functional activities can begin to understand their respective
roles within the whole system context and the effect that their actions have
on other functional activities. The workshop format brings these func-
tional organizations together and focuses them on the process—not on
fault finding. A common language facilitates a deep understanding of your
product development process. Without this, system level, holistic
improvements are impossible. PDVSM also brings out cause and effect
relationships, making them more evident. The long delay that normally
exists between cause and effect in the PD process disappears when reduced
to a value stream map. Lastly, PDVSM enables you to see overlapping con-
current PD activities, showing all on-going activities in the PD process at
any given time. This helps you to gain significant insights into effective
management of concurrent activities as well as opportunities to create
greater concurrency. PDVSM is perhaps the most effective tool for
improving PD concurrency because of its ability to display multiple func-
tional activities simultaneously at different levels of detail.
It is important to remember that learning and continuous improve-
ment cannot stop with PDVSM and your process redesign efforts. One of

330
Morgan Liker sec 5 3/2/06 11:52 AM Page 331

Eliminating Waste in the Product Development Value Stream

the hallmarks of a lean system is continuous learning and improvement. It

is critical that you think of this improvement effort as the beginning of a
completely new way of developing products and not as an end in itself.
Changing the PD process is necessary but not sufficient to create a lean
product development system. In fact, changing the process may be the easy
part. In the next chapter we will examine what it takes to make real change
in your culture and people systems.

331
Morgan Liker sec 5 3/2/06 11:52 AM Page 332
Morgan Liker sec 5 3/2/06 11:52 AM Page 333

CHAPTER 18

Getting to Culture Change: The

Heart of Lean PD
“Certainly, the thieves may be able to follow the blueprints and
produce a loom. But we are modifying and improving our looms
every day. By the time the thieves have produced a machine from the
plans they stole, we will have already advanced well beyond it.”
KIICHIRO TOYODA responding to theft of blueprints from
Toyoda Automatic Loom Works

ONE OF THE BIG MISTAKES many companies made in applying TPS to transform
traditional manufacturing environments was to view TPS as a tool kit. Value
stream mapping described in Chapter 17 is a powerful tool for understanding
the process flow and where to reduce waste in the value stream, but it is just a
tool. And it focuses mainly on only one of the three subsystems of the LPDS
model—the process subsystem. Unfortunately, if the transformation process
ends with a few workshops and a few improved value streams, your efforts will
be mostly for naught. Without real culture change your value streams will
start to fill back up with waste and before long look much like where
you started. Many companies ask us how to “sustain the lean changes made”
and that is the wrong question. The issue is not putting in a technical lean fix
and then having some magic chant that makes the change stay in place. The
organizational culture needs to be changed so that making improvements and
having the discipline to follow the best known procedure is a way of life.
In recent years, the authors have worked with a number of organiza-
tions interested in developing a lean product development system mod-
eled after the Toyota PD system. Most of these organizations are just a few
years into the journey. All have discovered that the transformation
requires some radical changes or kaikaku within existing PD systems.
While working with these organizations, the authors have also learned a
few things, including some basic truths of lean PD transformation:

1. Transforming PD into a lean process is more complex and less precise

than transforming manufacturing into a lean process. There are so

333
Morgan Liker sec 5 3/2/06 11:52 AM Page 334

Section Five: Creating a Coherent Lean PD System

many variables, parallel activities, interdependent paths, and com-

plex feedback loops that it is impossible to model the product
development process precisely. Value stream mapping, for exam-
ple, can be used both in lean product development as well as in
lean manufacturing, but it does not yield the same precise results.
Changes in cycle times, up times, takt times, etc., are never as pre-
cise in product development. This does not mean it is a futile task;
it is simply a different task than changing a manufacturing process
requiring a different approach. Although there are limits to the
degree of precision, dramatic improvements are possible.
2. Cultural issues increase the complexity. Holding workshops and
developing value stream maps with detailed plans of action may
be complex tasks, but they are relative child’s play compared to
dealing with all of the cultural issues that must be resolved before
a company can create an environment that supports lean product
development.
3. Engineers are engineers and tend to want to reduce lean PD method-
ologies to technical tools. This does not work. Transforming to a
viable lean product development system requires much more than a
set of sophisticated tools; it necessitates a human system renaissance.
4. Senior leaders must be intensely involved in the transformation
process but they typically do not engage at a significant level. The
importance of senior leader commitment to lean manufacturing
transformations has been well documented, but getting this com-
mitment is a challenge in and of itself, even more so than in
efforts to transform manufacturing. Because implementing
change to a lean PD system is a journey filled with complexities,
high levels of risk, and far-reaching organizational implications,
the committed participation of senior leaders is essential.
5. Senior leaders must understand the commitment and have patience.
Patience is a luxury few leaders seem to be able to afford. If lean
PD was simply a matter of implementing a few tools and pulling
out some waste (read cost), then most senior leaders would have
the appropriate level of commitment. Unfortunately, this is the
typical level of understanding and commitment. If the money
does not show up immediately, senior leaders quickly lose
patience. But lean PD is not as likely to show immediate cost sav-
ings. As we have seen the power of lean is in changing the basic
structure of the management of people, processes and technology

334
Morgan Liker sec 5 3/2/06 11:52 AM Page 335

Getting to Culture Change: The Heart of Lean PD

and thus a shift to a new way. A new way of managing is not fin-
ished in two to three years and cannot be delegated to a middle-
management level lean department.

Although each of these truths represents a significant challenge, the

organizations the authors have worked with have made improvements
that strongly suggest these challenges can be confronted and overcome and
that results are well worth the time and energy involved. One reason for
this is that most of these product development organizations began the
journey because they recognized they had to make fundamental improve-
ments to a process that was seriously out of control. A second, and even
more important reason, is that once the results start to come in these
organizations have begun to recognize that the methods and techniques
utilized during kaikaku are the beginning of a journey, not an end goal.

Develop an Internal Change Agent

In Lean Thinking, Jim Womack advises that the first step on the path to a
lean revolution is to find an internal change agent. We agree. It is impor-
tant that someone in the organization truly own this effort—someone who
has the respect of the organization, is unrelenting, and is perhaps even a bit
tyrannical, and who will drive the change process through the inevitable
difficulties it will encounter. Although this person must understand the
development process in your organization, he or she need not be an expert
in lean product development. Such expertise is helpful, but it is more
important for this person to believe passionately in the need for change and
be committed to learning. The suitable internal change agent must have
appropriate organizational rank, authority, and credibility to make things
happen, as well as the unflinching support of the most senior leadership in
the organization. Furthermore, this individual must be accountable for the
results, with tangible, time-bound deliverables. With these characteristics
and an excellent teacher, your internal lean change agent can be developed.

Get the Knowledge You Need

Changing a PD system is a complex undertaking, and your change agent or
senior leadership should seek out an experienced and knowledgeable
teacher. It is advisable, of course, to get someone with first-hand experience
in lean product development and who has experience in changing a product

335
Morgan Liker sec 5 3/2/06 11:52 AM Page 336

Section Five: Creating a Coherent Lean PD System

development system. (Someone retired from Toyota is one possibility for

this role.) Such individuals are a relatively rare commodity. Indeed, there
are many more people with commensurate experience in lean manufac-
turing, than those possessing the combination of lean product develop-
ment and lean transformation experience we describe. In fact, it is nearly
an empty set because so few PD organizations have transformed to lean.
Given the choice between a change agent who knows something about the
theories of lean product development and someone with actual experience
in a lean PD system, your best choice is the latter. In some cases a skilled
lean manufacturing change agent can be helpful but it takes dedication to
learning about lean product development, which as we have noted, is dif-
ferent from TPS.

Identify Manageable Work Streams to Understand PD

as a Process
As we have said, we advocate that you start your transformation with the PD
process and let the work drive your lean PD system. But, you can’t work on
something you can’t see. In most organizations, the PD process is long, com-
plex, and poorly understood. To see the process you must understand the
main tasks required to bring a product from concept design into manufac-
turing, as well as the sequence of those tasks. This is the product-develop-
ment value stream. The challenge is coming to grips with a process that is
typically a long iterative endeavor, involving many diffuse technical disci-
plines, and thousands of individual steps. But as W. Edwards Deming taught:

“If you can’t describe what you’re doing as a process, you don’t
know what you’re doing.”

We described PDVSM in Chapter 17 as a tool to help understand your

PD process. But where do you start? At a high level you will have very gross
activities such as concept design, engineering, and testing. How can we
take action on such macro-level activities? To get your mind around prod-
uct development as a process it can be very useful to move down one level
and divide the product development value stream into a number of
smaller individual work streams that experienced, technically knowledge-
able teams can work on.
Work streams are usually major steps within a process, such as proto-
typing or parts procurement; they can even be the complete development

336
Morgan Liker sec 5 3/2/06 11:52 AM Page 337

Getting to Culture Change: The Heart of Lean PD

of a specific product subsystem, such as a door-assembly development

work stream in the case of automobiles. Often these are boxes in what we
call the macro-level value stream—the highest 30,000 foot level. As you
understand at this level where the waste is and where you want to go with
your future state you can then pick out individual process boxes and
develop full-blown value stream maps for these processes. We call these
work streams. Each work stream should have its own cross-functional
teams, its own more detailed current state map, a detailed future state
vision, current state and target metrics, and an action plan. In fact, in many
cases, we do not even develop an action plan at the level of the first macro-
level value stream map. Rather the work plans are at the work stream level.
Of course if the product is simpler and the organization relatively small a
single map may be sufficient (as illustrated by the People Flo appendix).
By decomposing the entire PD value stream into these individual work
streams, you can make the process much more manageable. Simultaneously,
you will be engaging the deep technical knowledge necessary to recognize
true opportunities and make decisions about potential process improve-
ment enablers. In this way, technical specialists can focus on the area of the
process that they understand best and enlist the support of their home
organizations, thus bringing core functional organizations into the effort.
One example of how to organize this effort is to organize your work
stream teams according to the various functional organizations involved in
the PD process. For example, you might have a product planning work
stream team, a concept development work stream team, a prototype devel-
opment work stream team, etc., all organized around a specific product or
product family. There are many possible ways to organize your efforts,
depending on your product development value stream. The important
point is that you need to identify and organize around the critical work
streams that make up your PD value stream. In a large organization, you
should assign the work-stream team leaders to this effort full time; they
form the nucleus of the change team reporting directly to the change
agent. You should also maintain strong links between each of the team
leaders and their home functional organization, with the full support of
that organization’s line management.

Integration Mechanisms (Obeya/Design Reviews)

We have found that it is best to treat your change effort like a new product
program in a lean PD system and your change team as a lean PD project

337
Morgan Liker sec 5 3/2/06 11:52 AM Page 338

Section Five: Creating a Coherent Lean PD System

team. In this way, you start to establish norms and practices and lead the
effort by example. It is also important to integrate your change team and
not leave members to work on their respective work streams in isolation.
One of the best ways to do this is to collocate the team in an obeya, the
same way Toyota collocates its product team leadership, and uses it as a
lean product development strategy room. You should assign a section of
the obeya walls to each of the work stream teams. Here, they can post the
latest information and share value stream maps, A3s, pilot and learning
trial status, and other relevant initiative metrics across teams. Each of the
individual work stream teams can use the room as a meeting location
where they can learn what the other teams are working on. This informal
cross-team communication should be supplemented and supported by
formal meetings at least weekly to give team leaders the opportunity to
review each other’s value stream maps, A3 progress, and process sheets in
a structured disciplined way that enables them to provide valuable input
into each other’s efforts. Because of the interdependency of most tasks in
product development, this “socialization” process among the teams is
critical. You must always remember that you are working to create an
integrated product-development value stream—not isolated work
streams that lead to optimizing local process at the expense of the greater
process. Only in this way can you and the individual work stream teams
truly understand the challenges of the current state and collaborate on
creating the future state.

Enrollment of the Line Organization

Your line organizations must own your conversion to a lean PD system—
by this we mean those with operational responsibility for getting out the
product designs such as director of engineering and managers of engi-
neering departments. Do not relegate it to the status of a staff initiative.
This requires senior leadership to make career commitments to the effort
and back it up by supplying the required resources and selecting the best
people to lead it. Leadership must send a message that they are serious
about the transformation process. In addition, functional line leadership
must own the development and execution of the strategy. One way to
accomplish this is by creating implementation teams tasked with the exe-
cution of the changes identified by the work stream teams. This must be
one of the line leader’s primary objectives, and his or her career success
should be tied to the success of the effort. Remember that there is noth-

338
Morgan Liker sec 5 3/2/06 11:52 AM Page 339

Getting to Culture Change: The Heart of Lean PD

ing more important to any business than product, and the success of
your lean product development conversion may determine the very sur-
vival of the enterprise.

Start with Your Customer

There is no way around this prerequisite and you have to get it right.
Take the time and effort to truly understand the nature of your market,
your competitors, and especially what your customer perceives as value.
The spirit of your customer must be pervasive in your organization—a part
of every decision you make—at every level. To deliver on this in a tangible
way you must align the entire organization and manifest customer value
throughout. One of the best ways to do this is to develop your own ver-
sion of the CE paper that spells out the value-creating strategy of each
product development project and how each person will contribute to
that goal. Identify what this product must be and what it will not be
and communicate this consistently. Make certain that your process
includes a method for alignment (such as hoshin kanri) that will allow all
participants to create aligned objectives that are understood at all levels.
Make the objectives performance based and measure success. Finally,
make your customer a part of every discussion and decision in your
organization. Always ask, “What is best for our customer?” And then act
on the answer.
Beyond being clear on what your customer needs in new products, you
need to understand what customers define as value to improve the process
of product development. The basic tenet of Toyota Quality Management
is that every function has a customer. Ultimately, this refers to the buyer
and user of the product, but there are many intermediate customers along
the value-creating chain. Recall, for example, an example mentioned ear-
lier in this book, which described the relationship between Toyota’s body
engineers and styling engineers. The styling engineers were interim cus-
tomers whose designs would attract end customers, and the body engi-
neers’ initial thrust was to satisfy the needs of these interim customers by
staying true to their vision.
One final recommendation is to be certain to make your CE and your
project team powerful customer advocates within your organization. They
must bring intimate knowledge of customer-defined value to bear on the
product under development and have the respect and organizational clout
to make things happen.

339
Morgan Liker sec 5 3/2/06 11:52 AM Page 340

Section Five: Creating a Coherent Lean PD System

Grasp the Current State of Your Lean Product

Development Process

It is essential to start your lean conversion with a full and brutally honest
understanding of your existing product development process. Toyota
refers to “grasp the situation” as the first step of any problem solving or
improvement process. Only when you truly understand your current
process can you create a future state for that process. And only when you
fully grasp the future state process can you begin to make good decisions
about organizational structure, roles and responsibilities, required skill
sets, and the tools and technologies that will best support the execution of
a lean PD process. In other words, let the needs of the process drive other sys-
tem requirements. By doing this, you will drive alignment of people,
process, and technology. If you begin reorganization without a deep
understanding of the work you need to do, your future vision will be unin-
formed and unrealistic and you will invite unanticipated future resistance
that will likely lead to confusion and churn. This process must be focused,
deliberate, and systematic. Value stream mapping is a key tool for facili-
tating this process, and this begins with a deep and thorough assessment
of your current processes, which forms the foundation for developing a
future state vision.
If you were to visit a physician who prescribed progressive radical
surgery before conducting even a routine examination, you would prob-
ably run, not walk, out of the practice or hospital where this occurred.
Nonetheless, that is exactly what many intelligent managers do within
the context of product development system transformation. They sub-
ject their organizations to an ever-changing array of “remedies” without
fully understanding the ailment. In both cases, it is clearly preferable to
use a more scientific approach that includes precise data collection, rig-
orous data analysis, meaningful diagnosis, based on experienced judg-
ment, thoughtful prescription of a validated remedy, and thorough
follow-up.
Industry research suggests that during the 1980s or 1990s, nearly
every large company created a concurrent engineering program of one
type or another to improve its PD process. Given this, it is likely that your
own company participated in this trend. The solution at that time was to
create a “phase-gate model,” defining clear phases that ended in gates con-
taining specific requirements before a program could pass through to the
next phase. Companies developed standard timing at each gate, and the

340
Morgan Liker sec 5 3/2/06 11:52 AM Page 341

Getting to Culture Change: The Heart of Lean PD

gates were set up to maintain and monitor these PD processes. Invariably,

most companies found there was a need for increasing detail to define
these “standardized processes.” Today, the authors work with many com-
panies in which leadership truly believes that their people are following
these phase-gate models, or that any deviation from the model is the
cause of all current ailments. Close examination of the current state of
product development in these companies shows that there is usually little
resemblance between formal process requirements and what is actually
occurring. The premise is flawed, and its first fallacy is that an outside,
centralized organization can develop a detailed formal process in isola-
tion, teach it, enforce it, and expect people to follow it. There is simply
too little interaction (if any) among the people, process, and technology,
to support these fantasy models.
Experience and research show that most companies do not truly
understand their current state processes. As a result, they often believe that
product development in their companies requires far less time and
resources than it really does. As an example, one of the authors worked
with a company that assumed minor component design could be delivered
eight to twelve weeks from receipt of the master product-design informa-
tion. However, close examination of historical data from past programs
(design storage data from corporate servers, purchase orders, etc.)
revealed delivery times that were closer to sixteen weeks, with many
requiring more than twenty weeks to complete. Without this, data man-
agement was just assuming an arbitrary target and lacked a clear plan for
achieving it.
Another aspect in the PD process that companies commonly under-
estimate is the number and effect of engineering changes. Late engineer-
ing changes and the resulting expensive rework that they cause are the
number one source of waste in every complex PD process, regardless of
industry. Companies commonly underestimate these changes by 50 per-
cent or more.
Still another mystery for many product development organizations is
how their engineers spend their time. There has been a great deal of dis-
cussion about engineers in North American companies spending signifi-
cantly less time doing “engineering work” than their counterparts at
Toyota. Although the research associated with these claims is not conclu-
sive, the authors’ experiences with both product development systems sug-
gest that there is some truth to this. The question that emerges from this
is: what is it exactly that these engineers spend their time doing?

341
Morgan Liker sec 5 3/2/06 11:52 AM Page 342

Section Five: Creating a Coherent Lean PD System

A number of the companies assume that their engineers spend most

of their time in meetings. However, empirical data the authors collected
suggest other time wasters. This data shows that although specific activi-
ties vary across companies, engineers in non-lean companies spend a great
deal of time on the following:
• administrative tasks, such as checking parts lists or chasing down
purchase orders.
• creating nonstandardized development and test plans for their
parts and developing customer work arounds to adjust ineffective
planning systems.
• providing status information to third-party reporting organiza-
tions (usually to be provided to senior leadership).
• filling out forms, populating databases, and other tasks associated
with demonstrating compliance with requirements for the benefit
of auditing organizations such as Quality Assurance who monitor
the core engineering team.
Although there was no significant difference in the time engineers
spent in meetings, there was a big difference in the cadence and effective-
ness (value added) of the meetings attended by engineers in lean and non-
lean systems. Consequently, it can be quite useful to reexamine how you
manage meetings, who attends (and who does not), what their purpose is,
and the cadence in which they occur.
While it is clear that attending meetings where no one makes a deci-
sion and no new information is exchanged is non-value-added time, the
distinction between value added or non-value-added engineering activi-
ties is less clear. The value of specific creative aspects of certain engineer-
ing activities, for example, may be difficult to judge. In many companies
where such activities are considered “the natural iterative nature of the
work,” the result is often shoddy or incomplete engineering that requires
rework later in the process. This often results in engineering changes that
drive significant delays, expense, and frustration to downstream activities.
Firms that do not subscribe to this fuzzy interpretation of creative devel-
opment work and operate within the strictest definitions of rework are the
most productive. A previously cited example can be revisited here to illus-
trate this point: reworking dies by press grinding to produce an acceptable
panel. Truly lean companies (like Toyota) see this as waste and an indica-
tion that the die engineering process is flawed. Consequently, they rigor-
ously attack the source of the waste and make “die tryout” a target of

342
Morgan Liker sec 5 3/2/06 11:52 AM Page 343

Getting to Culture Change: The Heart of Lean PD

process improvement efforts. The bottom line is that lean enterprises have
a clear grasp of their real world PD value stream and know-how value is
created for their customers, and the specific sources of non-value-added
time. A big part of this understanding comes from PDVSM, but you must
also look at your current state of the entire system of people, processes,
and technology.
When you study your PD process, you should choose experienced
people from your core product development groups as your task force
leaders because they will provide valuable insights into the current state of
your product development value stream, particularly within their respec-
tive disciplines. Be aware, however, that much of what they will provide
will be anecdotal and incomplete, and because they each come from dif-
ferent disciplines, their stories will often contradict each other. This
should not come as a surprise, but it should also not be viewed with dis-
may. Describing a PD system is a bit like the ancient parable about the
three blind men describing an elephant for the first time. Each function
sees the system from a unique and limited vantage point. The solution:
collect real data. PDVSM is one tool for doing this and organizing the data
in a sensible manner.

Driving to Real Culture Change

There is a reason that we showcased PDVSM as a tool in Chapter 17. It is
the same reason that we recommend value stream mapping as a starting
point for transforming manufacturing processes to lean. The reason is that
the value stream is the process of delivering value to your customers—it is
your reason for existing. Without high value adding processes there is no
reason for your organization. Thus we start with a focus on the customer
and the processes that adds value to your customer. PDVSM provides a
tool for doing this. It also provides a concrete way to get started on the
more difficult problem of changing your culture which is what will make
lean PD something real and sustainable.
Culture is the shared values and beliefs of an organization. The key
word here is “shared” because cultures vary in strength based on how much
is shared. In strong cultures, the organizational population has strong val-
ues and beliefs in common. In weak cultures, different people think and
believe different things and have little in common. For a lean product
development organization to be successful, the best culture includes shared
values and beliefs about five things: organizational priorities (what really

343
Morgan Liker sec 5 3/2/06 11:52 AM Page 344

Section Five: Creating a Coherent Lean PD System

matters), the way work gets done, the way people communicate with each
other, the way problems are solved, and the way decisions are made.
In most traditional product development organizations, the culture is
quite weak. There are no strong, commonly held beliefs and values. People
are often beaten down and have concluded from their experiences that
product development is a chaotic, uncontrollable process in which mis-
takes inevitably slip through and spending time fixing errors is natural and
inevitable. They are often cynical of leadership and its ability to manage
the place and leery of any “new program” to improve things.
To create a high-performance PD organization with a strong culture,
you will need to remember many of the things discussed in this book and
act upon them. The customer comes first. Product development is about
creating valuable products for customers. People need to work together in
teams toward common goals. Leaders must be technically strong and have
valuable experience that they can pass on to junior members. The best way
to understand a problem is to go and see first hand (genchi genbutsu).
Deadlines and targets are to be met. It is always possible to achieve a chal-
lenging goal if you try hard enough. No detail is insignificant. Standard-
ized processes are necessary for continuous improvement. And so on. The
actions taken in implementing lean processes reinforce these beliefs and
values every day. Success breeds success.
Moving from a weak culture means moving away from negative work
attitudes and behaviors engrained in your people and moving toward a
positive, forward-looking, high-performance culture. It will be a challeng-
ing journey, one that will occasionally present tempting detours you
should avoid. The first thing many companies think of, for example, is
instituting a culture change program alongside of process improvements
and technical changes. The goal of such programs is to have technical
experts value stream map, eliminate waste, and develop tools while
“change management” experts change the culture. Unfortunately, a full
frontal assault to change a company’s culture never works. Culture is subtle
and does not respond well to change by directive. Telling people what to
think, communicating “new” values and beliefs through slogans and
emails, and educating them in the new way does little, if anything. In fact,
telling people to change their thinking is more likely to reinforce the very
thought patterns you are trying to change. People tend to become
affronted or defensive and resistant when approached in this way.
A better way to change culture is by changing the way people do their
work. In fact, if you do a good job with the value stream-mapping work-

344
Morgan Liker sec 5 3/2/06 11:52 AM Page 345

Getting to Culture Change: The Heart of Lean PD

shop, you are already making progress in changing culture. Consider the
following example. In the current situation, there is a standard process for
doing engineering work. Management’s myth is that people follow the
phase-gate process. When management finds things are not going well, it
turns to the formal process of rewards and punishments. Tighten up the
deadlines, find people to blame, fire someone, and let everyone know that
they need to follow the phase-gate process to the letter. If a company is
seriously committed to changing culture, however, a value stream-map-
ping workshop, immediately challenges some of the old cultural norms by:
1. taking an honest look at the current reality.
2. getting a cross-functional team of people together to share their
realities from different perspectives.
3. admitting there is something broken in the current system, and it
is not the fault of any one person, and we are focusing the team
on the process.
4. letting this team help define the future state by enrolling them in
the process.
5. empowering the team to follow up with real action.
6. setting up a cross-functional team to experience success.
7. demanding that top management take this seriously and support
real change.
One value stream-mapping workshop is not enough to tip the scales
on culture change. But it is a start because you have begun the process of
getting people engaged in asking the right questions and have empowered
them with a tool that can provide meaningful answers. Of course, more
important than the workshop are the changes that follow. To assess the
scope and breadth of those changes, you will need to ask yourself other
questions: Are there serious efforts by the company to implement the
changes? Is there immediate follow up with action items? Are you creating
new metrics to track progress? Does senior management continue to take
an interest and seriously watch the change first hand? Does management
allow enough time and create the right environment for people to work on
and implement the improvements? Are you working on winning over con-
verts who can become leaders of the new culture? If you can answer these
affirmatively, you are on the right track.
A tool like A3 is also an opportunity to start to drive cultural change,
but only if the leaders engage seriously in becoming the models of behav-
ior that they are encouraging in others. Leaders must:

345
Morgan Liker sec 5 3/2/06 11:52 AM Page 346

Section Five: Creating a Coherent Lean PD System

• put the customer before their careers in their decision making.

• demonstrate the same level of discipline and rigor that they expect
from the rest of the organization.
• create common objectives and reward the right behaviors.
• focus significant energy, time, and resources to the hiring and
development of the people who determine the culture.
In this way, day-by-day and step-by-step, leaders can create the path of
culture change. They must have patience and understand that culture
change is a bit like the giant flywheel described in Jim Collins’s path-break-
ing book Good to Great (HarperCollins Publishers, 2001). In the beginning,
it takes a great deal of concentrated force just to achieve one turn of the fly-
wheel. The organization struggles just to get everyone moving in the same
direction. However, if you stay at it, pushing consistently in the same direc-
tion, little by little, momentum grows until finally the wheel is a whirring
blur of seemingly endless energy. As Collins observes, it is never clear (nor
does it matter) which push made this happen—or what single action cre-
ated the now powerful culture—it was the sum of all that came before it.

People: The Heart of the Lean Product

Development System
A company is made up of people, but as a common aphorism tells us,
people are not your greatest asset—the best people are. When applied to
product development, this means having people with excellent technical
skill sets. Companies that want excellent people can make them or find
them. Toyota works at doing both—it invests in a rigorous selection
process and then spends years teaching employees the Toyota Way through
supervised experiences. For companies that have to start with an existing
workforce but have some flexibility to bring in new people through expan-
sion and replacement, the six tips presented below can be useful.
1. Begin at the beginning with your hiring process. Be certain you
understand the characteristics that define a successful PD engineer,
and test for those characteristics through a rigorous assessment
process. Review your hiring record. Make sure you are selecting
only the very best candidates, no matter how long it takes.
2. Invest in your people. It takes time to make a great engineer. You
cannot rush the process or expect an engineer educated or trained
elsewhere to be great in your company. In fact, a strong mentoring

346
Morgan Liker sec 5 3/2/06 11:52 AM Page 347

Getting to Culture Change: The Heart of Lean PD

system, time guidelines, and an insistence on demonstrated compe-

tencies are crucial. Set up individual development plans for all your
people, based on skill-set achievement tied to career progression.
Note that developing towering technical competence takes time.
Examine your current progression system to determine if engineers
are rotating too quickly and broadly to develop deep expertise.
3. Develop a technical mentoring system. Establish a technical appren-
ticeship. A university does not teach the skills that define a great
engineer; these skills are learned on the job, working closely with
engineers who are already great. Do not assume it will happen
automatically. The process needs structure. Assign mentors, assign
the right projects, set objectives by time, assess progress, and select
the best. Reward teaching and mentoring as a leadership funda-
mental. Do not promote anyone who does not have the requisite
skills in a basic discipline—build a technical meritocracy.
4. Understand the skill sets that are required. The skills necessary to be
successful in your new, lean PD process may be different from what
you currently have. New technologies (such as simulation or virtual
reality) may require skills that do not currently exist in your organiza-
tion. Anticipate these needs and “future” your skill-set requirements.
5. Augment basic OJT with classroom training. This is especially true
for specific methodologies or techniques (e.g., new design soft-
ware) that are specific to your company and that can be codified
and taught in a classroom setting.
6. Set up periodic reviews with functional leadership. Assess the pro-
gram. Is it delivering the results you need? Is it still current? Are
engineers meeting their targets based on the hoshin plan. Assess
how well engineers are getting input from functional bosses and
program managers. To get the best results, partner with HR and
functional leadership.

A Roadmap for Lean Transformation

We are often asked for an implementation road map. What is the step-by-
step process to implement lean product development? The answer of
course is that there is no one roadmap for all companies. This is not some-
thing you can implement like a piece of software. It is an organic, evolving
process much as it evolved over decades at Toyota. The closest thing we
could develop as a road map is some general directional advice, summarized

347
Morgan Liker sec 5 3/2/06 11:52 AM Page 348

Section Five: Creating a Coherent Lean PD System

in Figure 18-1. It is shown as a set of discrete phases, which is already an

oversimplification as in reality these phases will overlap. Also, they are
shown as a linear sequence and each company will need its own sequence
that makes sense given how things evolve in the change process. But the
general process is probably valid:

1. Initial Preparation (2–4 months)—Some preparatory work is

needed to get the key executives and managers on board, get some
help, get people generally aware of what this is about, and set up
an obeya from which to run the change process. Note that in this
initial phase we are not expecting that senior management is com-
mitted but rather supportive. Senior management cannot be truly
committed since they have not experienced real lean PD. Nor do
we expect complete training before getting started but rather some
general awareness. Most of the important learning will begin by
doing in the implementation phases. Thus, this initial preparation
is very important but also something you want to do quickly. One
can view it as the front-loading of product development where if
you do all the preparation just right, the implementation will go
smoothly but that would be a mistake. At this point you have not
really begun “designing” your lean PD process. You are just setting
the stage. This is more like learning to swim than designing a
detailed mechanism. At some point (in months, not years) you
have to jump in the water and get your feet wet.
2. Pilot Lean Processes (Minimum 1 year)—As discussed earlier we
recommend starting with action in the process subsystem. This is
where you jump in the water. You need to start with the customer,
identify your key workstreams, map the current and future states,
and then get to work implementing. Metrics should be specific to
the projects to measure the cost, quality, and lead time of your PD
projects. In this phase, not everybody will be involved but you
should focus on pilot projects. The main objective is to get experi-
ence and learn the power of lean PD. The teams involved will get
an opportunity to experiment with and experience all of the lean
PD tools in the process of actual use and implementation. You
need to get some traction, learn from the pilots, and start to
develop the cultural change by doing, so there is some momen-
tum to go into the more dramatic transformations to your organi-
zation. This will take at least one year. When you have successes

348
 Pilot Lean Lean Lean Tools
Initial Preparation Processes Organization & Technology Lean Enterprise
Morgan Liker sec 5

Senior PDVSM Develop Assess Current Identify Core

Management —Preparation C.E. System Technology Supply Areas
Support —Workshop Support
Define Functional Develop
3/2/06

Appoint Identify Key Specialties & Define Supplier

Lean Steering Workstreams Matrix Structure Technology Hierarchy
Team & Needs
Champion
Appoint Identify Core Pilot Early
Workstream Engineering Customize Supplier
11:52 AM

Identify Outside Leaders—Teams Competencies Technology to Involvement

Sensei Support Lean
Processes
Work Stream Implement Expand Supplier
Awareness PDVSM Mentoring Involvement
Page 349

Training —Current & Training Develop Digital —Resident

—Future (LPDS System Prototype & engineer

349
Principles) Process Design —VE VA
Set up Lean —Action Plan
Þ Þ Þ Þ —Supplier
Project —Implement Develop & Development
Management (trials and pilots) Implement Spread Lean
Obeya —Follow-up New Hire Support Tools
Selection Process —A3, Quality Develop Flexible
Matrix Work Force
Evaluate & Standards
Modify Develop Policy
Measurement Deployment
Systems System Institute PD
Obeya System
Getting to Culture Change: The Heart of Lean PD

Employ
Supportive Lean
Tools; A3s,
Checklists, etc.

Figure 18-1. Roadmap for Implementation Process

Morgan Liker sec 5 3/2/06 11:52 AM Page 350

Section Five: Creating a Coherent Lean PD System

under your belt, some trained internal consultants, and senior

management are getting excited about lean as the way forward
you are ready for the heavy lifting.
3. Lean Organization (Years 2–5)—After getting some experience in
implementation and when senior management is more convinced
that lean PD is real, applicable, and produces results, you can
begin the more arduous task of changing your organization. We
should note that a number of the companies with which we have
worked never got to this stage. Once they got measurable
improvements in the value steam pilots they believed they had
mastered lean and doing more value stream mapping and process
improvement was all there was to it. They made a serious mistake.
They had just gotten started with the easy stuff. Now is the time to
start to take seriously the concept of a “chief engineer system.” We
emphasized that the chief engineer is much more than a tradi-
tional project manager or even more than what many companies
call “chief engineer.” It takes Toyota decades to raise a chief engi-
neer and the chief engineer is part of a broader cultural system
that supports this critical role. You do not have decades, but you
cannot expect to change business card titles and have a real chief
engineer. We suggest starting with a pilot project and picking the
person closest to the characteristics we described as the chief engi-
neer at Toyota. Then let that person participate in developing a
selection and development process for future chief engineers.
This is also the time to reexamine your organizational structure.
You may have a matrix but is it effective? Do you have the right
functional departments to give you the core engineering compe-
tencies you need? Are the functional departments building strong
technical expertise? And do you have a process like policy deploy-
ment that aligns engineers toward a common focus on meeting
congruent targets?
4. Lean Tools and Technology (Years 2–Forever)—You already have
made a good start on this in the first year, but in year one you are
focused on pilots and you only focused on tools and technology
that required little or no capital investment. In the pilots you will
discover limitations of your current technology. This provides the
starting point of looking at what types of technology will be needed
to support true lean PD. Digital prototyping and an effective review
process may be something you already have or do not have. It is

350
Morgan Liker sec 5 3/2/06 11:52 AM Page 351

Getting to Culture Change: The Heart of Lean PD

essential for any complex product in this day and age. Even if you
have it, review it and we guarantee there is great opportunity for
improvement—not necessarily in the technology but in the way it is
used, how you organize to exploit the information from a strong
prototype review, and using the results as part of future checklists.
You can now also work on spreading the tools that have worked for
you across the organization like A3, quality matrices, product and
process standards, and obeya.
5. Lean Enterprise (Years 3–Forever)—Once you have some internal
mastery and some stability to your own development process you
can begin to bring in suppliers and even your customer to create a
true lean enterprise. Again we recommend piloting with a few key
suppliers before spreading broad policies across the board. There
is a lot of learning needed to do this right. You need to know
enough to be a teacher before you can start to spread these prac-
tices to suppliers for example. You need to have stable processes to
integrate your customers and suppliers into before they can par-
ticipate in the enterprise. Another major task at this stage is to
develop a flexible pool of resources. Again, until you have your
processes standardized and documented it will be difficult to train
outside technical resources on the standardized approach.

In summary, this is a process of learning by doing, reflecting, and

improving. It is PDCA at all levels. In terms of the LPDS model, we are sug-
gesting that you do some preliminary work to get key leaders and resources
on board, dive into the process box using value stream mapping as a guid-
ing tool, and through initial pilot projects, begin to develop your people
and tools and technology. Once you have a foothold of some experience
and knowledge you can begin the process of planning broader organiza-
tional and technological changes. If you continue this process step by step,
continually reflecting, understanding the true current reality, and develop-
ing a bold but realistic vision for the next step, then you cannot fail.

Leadership and Building in Learning and Continuous

Improvement
As the reader has no doubt discovered by now, there is a big difference
between management and leadership. Managers plan, organize, control,
and generally work through the formal system. Leaders capture the hearts

351
Morgan Liker sec 5 3/2/06 11:52 AM Page 352

Section Five: Creating a Coherent Lean PD System

and souls of the people—they make things happen and people want to follow
them. For this reason alone, “change management” is little more than an
industry myth. You do not manage cultural change; you lead it. Two ques-
tions that immediately emerge from this assertion underscore the chal-
lenge associated with leading a culture change: If the existing bureaucratic
organization is the way it is because there are many managers and few
leaders, how can managers suddenly learn to lead? And how can they learn
to lead a change to the new lean culture if they have never experienced it
and do not understand it in their gut?
The way of the lean leader, especially for a leader in a PD organization,
lies in teaching, and one cannot teach what one does not understand. To
transform the organization, the leader must change first and do so in ways
that are visible. By living the change, showing the way, implementing new
work processes, leading cross-functional teams, and using the lean PD
tools, people create the opportunity to develop into real transformational
leaders. Those who learn to teach in this manner open the doors to build-
ing in learning and continuous improvement.
The current business environment is hypercompetitive, and it is not likely
that things will calm down any time soon; you cannot afford to think in terms
of completing this effort. You must build learning mechanisms into your
process, making them part of how you develop products. Furthermore, you
will need to establish an oversight group, institutionalize your gains, standard-
ize across PD projects, manage shared resources, and maintain process disci-
pline. Above all, you must use all of these to drive continuous improvement.
The concept of finishing your transformation to lean PD contradicts lean
philosophy. Lean is about continuous improvement in adding value to cus-
tomers. It is a journey of eliminating waste through problem solving and con-
tinuous improvement. If the journey stops, continuous improvement stops.
When that occurs, an organization can no longer call itself lean. One thing
that distinguishes Toyota from other lean enterprises is that the Toyota organ-
ization is not only a great teacher but also a great student. Offer an observa-
tion or suggestion and it is likely to be seriously considered (or studied) for
its potential. On the same note, Toyota has always engaged in the study of
feedback, whether from its end customers or the people on its shopfloor.
Feedback is a gift to a learning organization and a threat to a rigid bureaucracy.
In a lean product development system, it is always accorded attention.
Lean PD is about jumping off into the improvement abyss. It is risky.
It is exhilarating. There is no return. We hope our work has inspired you
to take the leap and begin your long PD transformation journey.

352
Morgan Liker back 3/2/06 11:54 AM Page 353

APPENDIX

Applying Value Stream Mapping to

a Product Development Process:
The PeopleFlo Manufacturing Inc. Case
by Dr. John Drogosz

PEOPLEFLO IS A SMALL START-UP COMPANY that designs and manufactures pumps

for chemical, petrochemical, and food processing applications. The company
was founded by a team of people committed to applying lean manufacturing
philosophy and tools in a unique and comprehensive way. Starting with
a “clean slate,” PeopleFlo’s management team designed a new product line and
built every core business process into one interdependent lean enterprise.
They developed patented technologies, simplified the product so that it could
be flexibly built in lean cells, and met every major timing milestone.
An essential part of the company’s lean enterprise vision was to
rethink how best to design new products. This meant slashing the typical
product development cycle from three to four years in the pump industry
down to less than one year. In addition, it meant achieving breakthroughs
in design for setup reduction, design for cycle-time reduction, and design
for inventory reduction. To achieve these goals, the company started with
a clean sheet of paper and used the value stream mapping tool not only to
detail the best way to design, validate, and launch production of a new
pump product but also to manage the product development process. The
first step was to start with a high-level map that showed high-level activi-
ties, key decisions, and integration points that were necessary to design a
new pump. Figure A-1 shows the major phases of the product develop-
ment process and its milestones.
Once the high-level process map was defined, each process was
mapped in more detail. The tasks and key information flows were delin-
eated and timing was set for each task. Figure A-2 shows the process archi-
tecture for the preliminary design phase.
As part of the mapping activity, PeopleFlo incorporated several lean
product development concepts into its development process. For example,
activities were included that allowed design time to examine multiple

353
Morgan Liker back 3/2/06 11:54 AM Page 354

Appendix

Figure A-1. High Level Product Development Map & Master Time Line

Figure A-2. VSM of Preliminary Design Phase

354
Morgan Liker back 3/2/06 11:54 AM Page 355

Applying Value Stream Mapping to a Product Development Process

alternatives (set-based concurrent engineering). In addition, reflection

events were hard-coded into the plan to ensure that learning was captured
all the way through the development process.
In addition to using the value stream map to define a new PeopleFlo
product development process, company leaders used it as a visual program
management tool. Figure A-3 illustrates how they used the visual controls
to highlight problems/opportunities and indicate program status.

Figure A-3. VSM Visual Controls

355
Morgan Liker back 3/2/06 11:54 AM Page 356

Appendix

Figure A-4. Visual Controls and Open Issues List

Teams held “morning market” meetings around the value stream map
boards to report status. As Figure A-4 illustrates, the program board
showed current status regarding timing; red-dot visual indicators were
placed directly on the map to indicate where issues were discovered. Any
red dots required an immediate countermeasure. An open issues list was
also posted at the VSM program board. In addition to acting as a rapid
problem-solving tool, the list was also used to capture learning for
improving future programs.
As the product development cycle progressed, the team members con-
tinued to add new lower-level maps and include tasks and information
flows that they had missed in creating the early-stage VSM. By the end of
the first product development cycle, they had clearly documented the best
way to create their first product family of pumps. Figure A-5 shows the
overall process architecture for PeopleFlo’s product development process.
The development team is now using the value stream maps from the
first family of pumps as the framework for the next family of pumps they
are currently designing. The plan is to continue to apply the VSM

356
Morgan Liker back 3/2/06 11:54 AM Page 357

Applying Value Stream Mapping to a Product Development Process

Figure A-5. VSM Process Architecture for Pump Family 1

approach to all future product development programs and customize this

approach for each product family’s specific requirements.
The result has been the development of a complete line of pumps that
are in production in less than two years. In that time, PeopleFlo was able
to design an innovative new generation product, with 50 percent fewer
parts than comparable pumps and develop a unique fixturing system that
eliminates changeover time on machining centers. A true one-piece flow
cell without any changeover time allows flexible production. One cell has
the ability to machine ten different pump parts, then paint, assemble, and
ship 80 percent of parts sold, within 24 hours of receiving the order—
unheard of within this industry. The cost for a comparable pump made by
a conventional competitor was slashed by 50 percent.
The key to the success of this start-up business was a combination of
people, process, and technology. Success factors included starting with a
clean slate, assembling the right team of employees and business partners,
and building one interdependent design-manufacturing system, with one
set of goals, based on lean philosophy and tools.

357
Morgan Liker back 3/2/06 11:54 AM Page 358
Morgan Liker back 3/2/06 11:54 AM Page 359

BIBLIOGRAPHY

Chapter 1
Womack, James P., and Jones, Daniel T. (1991), The Machine That Changed
the World: The Story of Lean Production. New York: Harper Perennial.
Morgan, James M. (2002), High Performance Product Development; A Sys-
tems Approach to a Lean Product Development Process, The University
of Michigan, Ann Arbor MI.
Liker, Jeffrey K. (2004), The Toyota Way: 14 Management Principles from
the World’s Greatest Manufacturer. New York, McGraw-Hill.
Taylor, James C. and Felten, David F. (1993), Performance By Design, Pren-
tice-Hall, Englewood Cliffs, NJ.
Nadler, David and Tushman, Michael L. (1997), Competing By Design,
Oxford University Press, New York, NY.

Chapter 2
Morgan, James M. (2002), High Performance Product Development; A Sys-
tems Approach to a Lean Product Development Process, The University
of Michigan, Ann Arbor MI.
Liker, Jeffrey K. (2004), The Toyota Way: 14 Management Principles from
the World’s Greatest Manufacturer. New York, McGraw-Hill.

Chapter 4
Cusumano, Michael A., and Nobeoka, Kentaro (1998), Thinking Beyond
Lean, The Free Press, New York, NY.
Ward, Allen C., Sobek, Durward K., II, Cristiano, John J., and Liker, Jeffrey
K. (1995), “Toyota, Concurrent Engineering, and Set-Based Design,”
in Liker, et al., eds. Engineered in Japan, Oxford Press, New York;
pp. 192–216.

Chapter 5
Liker, Jeffrey K. (2004), The Toyota Way:14 Management Principles from the
World’s Greatest Manufacturer. New York, McGraw-Hill.
Rother, Mike, and Shook, John. (1998), Learning to See, The Lean Enter-
prise Institute, Brookline, MA.
Adler, Paul S., Mandelbaum, Avi, Nguyen, Vien, and Schwerer, Elizabeth
(1996), “Getting the Most out of Your Product Development Process,”
Harvard Business Review, Mar.–Apr. 1996, vol. 74, no. 2; pp. 134–151.
Reinertsen, Donald G. (1997), Managing the Design Factory, The Free
Press, New York, NY.

359
Morgan Liker back 3/2/06 11:54 AM Page 360

Bibliography

Hopp, Wallace J., Spearman, Mark L. (1996), Factory Physics, Irwin,

Chicago, IL.
Morgan, James M. (2002), High Performance Product Development; A Sys-
tems Approach to a Lean Product Development Process, The University
of Michigan, Ann Arbor MI.
Loch, Christoph H. and Terwiesch, Christian (1999), “Accelerating the
Process of Engineering Change Orders: Capacity and Congestion
Effects,” Journal of Product Innovation Management, Apr. 1999, vol. 16,
no. 2.
Cusumano, Michael A., and Nobeoka, Kentaro (1998), Thinking Beyond
Lean, The Free Press, New York, NY.

Chapter 6
Kramp, Eric E. (2001), How soft issues influence hard work, loyalty and a
sense of pride to build superior products at Toyota, Ford Motor Com-
pany Internal Presentation, Dearborn, MI, 6 Dec.

Chapter 7
Liker, Jeffrey K. (2004), The Toyota Way: 14 Management Principles from
the World’s Greatest Manufacturer. New York, McGraw-Hill.
Itazaki, Hideshi (1999), “The Prius that Shook the World: How Toyota
Developed the World’s First Mass-Production Hybrid Vehicle,” Tokyo,
Japan—The Kikkan Kogyo Shimbun, Ltd. (translated by A. Yamada
and M. Ishidawa).
Sobek, Durward K., II (1997), Principles that Shape Product Development
Systems: A Toyota-Chrysler Comparison, UMI Dissertation Services,
Ann Arbor, MI.

Chapter 8
Sobek, Durward K., II (1997), Principles that Shape Product Development
Systems: A Toyota-Chrysler Comparison, UMI Dissertation Services,
Ann Arbor, MI.
Cusumano, Michael A., and Nobeoka, Kentaro (1998), Thinking Beyond
Lean, The Free Press, New York, NY.

Chapter 9
Rich, Ben R. and Janos, Leo (1994), Skunk Works, Little, Brown and Com-
pany, New York, NY.

360
Morgan Liker back 3/2/06 11:54 AM Page 361

Bibliography

Hammett, Patrick C., Wahl, Shannon M., and Baron, Jay S. (1999), “Using
Flexible Criteria to Improve Manufacturing Validation During Prod-
uct Development,” Concurrent Engineering: Research and Applications,
Dec. 1999, vol. 7, no. 4; pp. 309–318.
Liker, Jeffrey K. (2004), The Toyota Way: 14 Management Principles from
the World’s Greatest Manufacturer. New York, McGraw-Hill.

Chapter 10
Kamath, Rajan R. and Liker, Jeffrey K. (1994), “A Second Look at Japanese
Product Development,” Harvard Business Review, Nov.–Dec., vol. 72.
no. 6; pp. 154–170.

Chapter 11
Ward, Allen C., Liker, Jeffrey K., Cristiano, John J., and Sobek, II, Durward
K. (1995), “The Second Toyota Paradox: How Delaying Decisions
can make Better Cars Faster,” Sloan Management Review, vol. 36, no.
3; pp. 43–61.
Senge, Peter M. (1990), The Fifth Discipline, Doubleday/Currency, New
York, NY.
Drucker, Peter F. (1998), “The Coming of the New Organization,” in Har-
vard Business Review on Knowledge Management, Harvard Business
School Press, Boston, MA; pp. 1–20.
Nonaka, Ikujiro and Takeuchi, Horotaka (1995), The Knowledge-Creating
Company: How Japanese Companies Create the Dynamics of Innova-
tion, Oxford University Press, New York, NY.
Kogut, Bruce, and Zander, Udu (1992), “Knowledge of the Firm, Combi-
native Capabilities, and the Replication of Technology,” Organization
Science, Aug. 1992, vol. 3, no. 2; pp. 383–397.
Conner, Kathleen R., and Prahalad, C. K. (1996), “A resource-based theory
of the firm: Knowledge versus opportunism,” Organization Science,
vol. 7, no. 5; pp. 477–501.
Argyris, Chris (1998), “Teaching Smart People How to Learn,” in Harvard
Business Review on Knowledge Management, Harvard Business School
Press, Boston, MA; pp. 81–108.
Garvin, David A. (2000), Learning in Action, Harvard Business School
Press, Boston, MA.
Nelson, Richard R., and Winter, Sidney G. (1982), An Evolutionary Theory
of Economic Change, Belknap Press, Cambridge, MA.

361
Morgan Liker back 3/2/06 11:54 AM Page 362

Bibliography

Pfeffer, Jeffrey and Sutton, Robert I. (2000), The Knowing-Doing Gap, Har-
vard Business School Press, Boston, MA.
Dyer, Jeffrey H., Nobeoka, Kentaro (1998), “Creating and Managing a
High Performance Knowledge-Sharing Network: The Toyota Case,”
Strategic Management Journal, vol. 21, no. 3; pp. 345–367.
Morgan, James M. (2002), High Performance Product Development; A Sys-
tems Approach to a Lean Product Development Process, The University
of Michigan, Ann Arbor MI.
Hann, D. (1999), “Organizational Forgetting,” unpublished study, Harvard
Business School, Boston, MA.

Chapter 12
Liker, Jeffrey K. (2004), The Toyota Way: 14 Management Principles from
the World’s Greatest Manufacturer. New York, McGraw-Hill.

Chapter 13
Clark, Kim B., and Fujimoto, Takahiro (1991), Product Development Per-
formance: Strategy, Organization, and Management in the World Auto
Industry, Harvard Business School Press, Boston, MA.

Chapter 14
Sobek, Durward K., II (1997), Principles that Shape Product Development
Systems: A Toyota-Chrysler Comparison, UMI Dissertation Services,
Ann Arbor, MI.
Morgan, James M. (2002), High Performance Product Development; A Sys-
tems Approach to a Lean Product Development Process, The University
of Michigan, Ann Arbor MI.

Chapter 16
Wheelwright, Steven C. and Clark, Kim B. (1992), Revolutionizing Product
Development, The Free Press, NY.
Clark, Kim B., and Fujimoto, Takahiro (1991), Product Development Per-
formance: Strategy, Organization, and Management in the World Auto
Industry, Harvard Business School Press, Boston, MA.
Womack, James P. and Jones, Daniel T. (1996), Lean Thinking, Simon and
Schuster, New York, NY.
Hopp, Wallace J., Spearman, Mark L. (1996), Factory Physics, Irwin,
Chicago, IL.

362
Morgan Liker back 3/2/06 11:54 AM Page 363

Bibliography

Rother, Mike, and Shook, John (1998), Learning to See, The Lean Enter-
prise Institute, Brookline, MA.
Adler, Paul S., Mandelbaum, Avi, Nguyen, Vien, and Schwerer, Elizabeth
(1996), “Getting the Most out of Your Product Development Process,”
Harvard Business Review, Mar.–Apr., vol. 74, no. 2; pp. 134–151.
Loch, Christoph H. and Terwiesch, Christian (1999), “Accelerating the
Process of Engineering Change Orders: Capacity and Congestion
Effects,” Journal of Product Innovation Management, Apr., vol. 16, no. 2.

Chapter 17
Rother, Mike, and Shook, John (1998), Learning to See, The Lean Enter-
prise Institute, Brookline, MA.
Morgan, James M. (2002), High Performance Product Development; A Sys-
tems Approach to a Lean Product Development Process, The University
of Michigan, Ann Arbor MI.
Morgan, James M., Learning to See Product Development, The Lean Enter-
prise Institute, Brookline, MA.
Collins, Jim (2001), Good to Great, HarperCollins Publisher, New York, NY.

363
Morgan Liker back 3/2/06 11:54 AM Page 364
Morgan Liker back 3/2/06 11:54 AM Page 365

INDEX

A3 tool, 269–76 Breakthrough quality, 32, 124, 284–85, 353

for alignment, 277 Bureaucratic organization, 135, 136, 199
hansei events and, 209 Business partner. See Partnering
multiple solutions and, 171 Business Revolution Teams, 44
nemawashi and, 226
problem-solving points, 274 CADCEUS, 251
problem-solving report, 220–21, 275 CAD (Computer-aided-design), 99, 171, 256,
story types, 270–74 303
writing vital points, 274 Camry, 43, 60, 148, 156, 193, 290
Adler, Paul, 80 Capability, 196–99
Advanced degrees, 164, 169 Capacity
Advanced Engineers, 45 flexible, 88–89, 303–4
Advanced technology planning, 44–46 relief values, 303
Aerospace industry, 101 utilization, 78, 79–80
Aisin, 183 Car and Driver, 187
Alignment tools, 263–69 Car/truck “crossovers,” 7
Andon, 94 Catch-ball process, 31, 267
Annual planning tool. See Hoshin kanri CATIA V-5 software, 60, 244
Approval stamp (hanko), 265 CCC21 program, 181, 201
Araco, 85, 183 CE. See Chief engineer
Arizona proving grounds, 189, 232 Cells, 97, 253, 357
Asia, 6 Cellular manufacturing, 67
Automation, 241, 303 Central, 85
Autonomation (jidoka), 94 Change management, 312, 344, 352
Avalon, 148, 156, 193 Changeover time, 357
Checklists, 101–4, 289–92
Batch size, 67 Chief engineer (CE)
Benchmarking reports, 286–87, 289 concept paper, 30–31, 260–62
Best-in-class companies, 8 leadership, 119
Big 3 automaker nonexpert for Prius, 126
body development, 4 responsibilities, 118–19
bureaucracy in, 199 reverence for, 120
customers and, 228 role, 29–30
first-tier suppliers, 198 as voice of the customer, 137
NAC and, 13 Chief engineer system, 117–38, 235–36
“Big room.” See Obeya Chrysler, group facilitation at, 135–37
Binder and process development, 107–8, 322, cultural icon behind, 118–20
323 leadership model, 131–34
Blue Sky project, 111 Lexus and Prius engineers, 120–23
BMW, 121 NAC and, 134–35
Body Prius, new CE/new process, 125–31
development, big-3, 4 tale of two engineers, 120–23
engineering, 56, 156–57, 159–60 at Toyota, avoiding compromises, 137–38
structures document (K4), 54, 64 Chief production engineer (CPE), 156
structures engineering and, 51–53 Chimneys, 77, 135, 141, 259
team, 32–36 China, 6, 155, 192
“Book of knowledge,” 218 Cho, Fujio, 223, 225, 227
“Brain drain,” 64 Chrysler
Brainstorming session, 127 group facilitation at, 135–37
Brand DNA, 46 platform team organization, 141
Brand identification, 45 platform team structure, 148–52

365
Morgan Liker back 3/2/06 11:54 AM Page 366

Index

“skunkwork” approach, 149 Corporate culture. See Culture

suppliers and, 199 Cost reduction, 182
“Clean sheet” planning approach, 45 Cost targets, 57–58
Closure subassemblies, 111 CPE (Chief production engineer ), 156
CNC (Computer Numerically Controlled) Craft-based process, 251, 252
machines, 252, 303 Creativity, 231. See also Styling
Coherent lean PD system, 297–309 Cross-checking, 212–13
cross-functional integration, 307–9 Cross-functional activities, 82
perfection in, 306–7 Cross-functional integration, 139–61, 307–9
pull and flow, creation of, 304–6 best structure, 139–42
subsystem integration, 299 Chrysler’s platform team structure, 148–52
value identification, 299–300 evolving organization process, 160
value stream and, 300–304 matrix organization, 142–48
Collins, Jim, 346 module development teams in, 154–60
Common architecture, 54–55 obeya room, 152–54, 262–63
Common construction sections, 292 simultaneous engineering, 152–60
“Common sense engineering,” 15 through CE system, 137
Common vehicle platforms, 84 Cross-functional processes, 104
Communication, 259–77 Cross-functional synchronization, 86–88
cross-functional, 276 Cross-functional team, 97
and evaluation of sets, 283–86 Cross-functional teamwork, 149
with functional specialists, 59 Crown, 119
“information broadcasting,” 96 Culture, 217–38
PDVSM as, 330 definition of, 218–20
selective, 259–60 of discipline, 99–100, 197, 302, 304
See also A3 tool; Visual communication focused on customer, 137
Community, 221–22 hourensou management and, 232–33
Compatibility before completion, 50–51 leaders’ renewal of, 237
Competitive advantage, 8–9, 203, 255, 279, 292 lean concepts and, 217–20
Competitor benchmarking reports, 286–87 learning DNA, 220, 229–32
Competitor teardowns, 174, 287–89 management and, 232–33
Component library, 250–51 NAC/Toyota contrasted, 234
Component quality matrix, 53 right process/right results, 233–34
Compromise. See “No-compromise goals” societal contribution, 221–22
Computer-aided-design (CAD), 99, 171, 256, supportive of process, 234–36
303 technical excellence and, 222–29
Computer controls (IGBTs), 196 tools and, 220–21
Computerized checklists, 103 values shared, five areas, 343–44
Computer Numerically Controlled (CNC) Culture change, 333–52
machines, 252, 303 current state, lean PD process, 340–43
Concept paper, 30–31 integration mechanisms, 337–38
Concurrent engineering, 140, 340. See also internal change agent, 335
Simultaneous engineering leadership and building in, 351–52
Consumer Reports, 187 lean transformation roadmap, 347–51
Continuous flow, 76 line organization enrollment, 338–39
Continuous improvement, 203–15, 306–7, obtaining necessary knowledge, 335–36
351–52 people, heart of lean PD system, 346–47
Core competencies, 164–65, 195–96, 198 real, driving to, 343–46
Core technology, 195–96 work stream identification, 336–37
Corolla, 12, 119, 125 your customer, starting with, 339

366
Morgan Liker back 3/2/06 11:54 AM Page 367

Index

Current state. See Value stream mapping “Direct order document” (Shijisho), 31
Customer Discipline, 99–100, 197, 224–26
contribution to, 221–22 Documentation. See Visual communication
culture focused on, 137, 143, 339 Double loop learning, 204
delivering value to, 30–32 Downsizing, 75–76
intermediate, 228–29, 339 Drogosz, Dr. John, 353–357
value characteristics of, 28 Drucker, Peter, 27, 203
See also Voice of the customer
Customer-defined value, 27–37, 124 Early design process, 58
identification process, 299–300 “Early problem solving,” 62
Lexus case example, 32–36 Echo, 269
at NAC, 28–29 Einstein, Albert, 15
as principle one, 36–37 E-mail, 154
at Toyota, 29–36 Employee
“Customer first” value, 55, 228–29, 300 DNA, 231
Customer-value characteristics, 122, 123 layoffs, 222, 231
“Customer value” elements, 43 for lifetime, 231
Cycle planning, 83–85 See also Technical competence
Cycle time, management, 93–94 Enabling partner system, 199–200
Engineer
Daihatsu, 85 collocation, 259, 262–63
Daily wrap-up meetings, 175, 213 resident, 309
Daimler-Chrysler, 137, 152, 180, 192 tasks, non-lean companies, 342
Database. See Software See also Advanced Engineers; Chief engineer;
Decision-making process, 265–66 Technical competence
Decision matrices, 285–86 Engineering
Defense industry, 119 cadence mechanisms, 93–94
De Geus, 203 checklists, 101–4
Deming, W. Edwards, 102, 212, 214, 336 excellence, 222–29
Denso, 183, 194, 197 guest engineer system, 193–94
Derivative vehicles, 42–44, 68 skill-set standardization, 101
Design, 58 styling feasibility and, 46
Designed-in quality (mizen boushi), 40 See also Chief engineer; Simultaneous
Design factory, front loading, 41–42 engineering
Design-release stagger, 91–92 Ergonomics, 306
Design standardization, 100, 101–4 Error proofing (poka-yoke), 94–95
Design technology, 244–45 Error state, 94
Design reviews, 337–38 Excellence. See Culture
Detailed scheduling, 90–91 Explicit knowledge, 204–5
Development cycles
12-month programs, 131 Factory Physics (Spears and Hopp), 77
15-month programs, 224, 241 FEA (Finite Element Analysis), 107, 248–49
Die Feedback loops, 70
design, 250–51 Finite Element Analysis (FEA), 107, 248–49
engineering, 106–7 First prototype submission (1S), 188
machining, 252–53 5-why analysis, 191, 209
Digital assembly, 246–48 Fixtures, 256
Digital engineering, 255 Flawed process logic examples, 83
Digital tools, 59–60 Flexible capacity, 88–89, 104, 303–4
Digital visualization, 245–56 Flexible production, 357
Dimensional tolerances, 255 Flexible staffing, 88–89

367
Morgan Liker back 3/2/06 11:54 AM Page 368

Index

Flow General Motors (GM), 180, 192

across functions, 91–92 General Tire, 193
barriers and facilitators of, 76–81 Generation X lifestyle, 30
cells and, 97 Global 21 (G21) platform, 125–27, 130, 152–53
creation of, 304–5 Global Body Lines, 111
Flow lines, 252, 257 Global CCC21 program, 181, 201
Focus group interviews, 122 Good to Great (Collins), 346
Ford, 180, 192 Go to the source. See Genchi genbutsu
Ford, Henry, 67, 99 engineering
Formability FEA software, 248–49, 250 “Green company,” 187
“Freshman project,” 170–71 Guest engineer system, 193–94
Front door margin comparison, 34, 288
Front-loading design factory, 236 Hand finishing, 252
Front-loading PD process, 39–66 Handoffs, 146, 301
advanced technology planning, 44–46 Hanko (approval stamp), 265
case example, kentou, 60–64 Hansei (reflection), 112, 203, 208–10, 230, 234
common architecture, 54–55 Harbour Top Ten North American Assembly
derivative vehicles on existing platforms, Plants, 6
42–44 Hasegawa, Tatsuo, 119
for design factory, 41–42 Hemming operation, door edge, 33, 35, 36
digital tools, leveraging of, 59–60 Henke, John, 181, 200
within individual program, 46 Hetakuso-sekke, 279, 282
investment and variable cost targets, 57–59 Hidden factory, 200
kentou (study), 51–53 Hidden problems, 211
kokokeikaku (K4) document, 64 High-precision dies, 253
re-use principle, 54–55 High-speed pattern making, 251
right person, work, time, 64–65 High-velocity environment, 156, 163
set-based concurrent engineering, 47–51 Hino, 85
standardizing lower-level activities, 53–54 Hiring. See Technical competence
at Toyota, 51–53, 56–57 Horizontal coordination mechanism, 154
vehicle-level goals, 55–56 Hoshin Kanri (policy deployment), 31–32,
Fuel economy, 130, 187 171–72, 231–32, 266–69
Fuel-electric hybrid vehicle. See Prius Hourensou management, 232–33
Functional build, 254–57 Human resources. See Technical competence
Functional “chimneys,” 135 Humility, 227
Functional departments, 146, 152 Hybrid vehicle. See Prius
Functional expertise, 139–61. See also Cross-
functional integration Idea proposal stage, 55
Functional-organizational level scheduling, 91 Ijiwaru testing, 210
Functional program teams, 31 Implementation teams, 338
Functional specialists, 59 Improvement, 229–32. See Continuous
Fundoshi scheduling, 90–91 improvement; Culture
Future state. See Value stream mapping India, 6
“Fuzzy front-end,” 65, 82 Individual program, front-loading, 46
Industrial engineering, 247
G21 (Global 21) platform, 125–27, 130, 152–53 Information. See Knowledge
Gap reduction, 32–36 “Information broadcasting,” 96
Gardner, G. Glenn, 136, 141, 149 Inner lift gate problem, 62–64
Gates, Bill, 241 Innovation, 121, 125, 152–54, 181
Genchi genbutsu engineering, 32, 46, 173–75, Insulated Gate Bipolar Transistor (IGBT), 196
230, 260, 289

368
Morgan Liker back 3/2/06 11:54 AM Page 369

Index

Integration mechanisms. See Design reviews; pulling through PD system, 95–97

Obeya tacit, 204–5, 206
Interarrival variation, 78–79 transfer, 204–5
Internal capability, 197–99 See also Checklists
Internal change agent, 335 Knowledge-based engineering pilot, 281
Internet, 154 Knowledge Creating Company, The (Nonaka),
Inventory, 276 204
Investment targets, 57–58 Knowledge work job shop, 68
Iterative point-based design, 47, 50 Kousu Yamazumi, 85
Kozokeikaku (K4), 54, 64
Japan, 101, 119, 169, 179, 231
Japanese bubble economy, 125 Leadership, 351–52
J.D. Power & Associates, 11, 181, 187 company culture and, 218, 345–45
Jidoka (autonomation), 94 four types of leaders, 132–34
JIT (Just-in-time), 253 “mentoring as,” 164
Johnson, Kelly, 174 senior leaders, 334, 338
Just-in-time (JIT), 253 See also Chief engineer; Mentoring
“Lead Manufacturing Engineer,” 57
K4 (body structures document), 54, 64 Lead time, 78, 263. See also Obeya
Kaizen, 98, 102, 110, 225, 226–27, 230 Lean
Kanban cards, 95 communication, view of, 261
Kanto Auto Body, 85 elements of, 172–73
K-car, 148 enterprises, 10, 343, 351
Keiretsu, 182–83, 197–99 hallmarks of system, 331
Kelly, Kevin, 297 manufacturing, 3, 5, 247, 305–6
Kentou (study phase) principles, 176
body and structures engineering, 51–53 technology in PD, 243–49, 257
case example, 60–64 thinking, 75–76
common architecture, 54–55 transformation, 306–7, 347–51
early stages of, 40, 56–57 See also Waste
execution phase and, 85 Lean Product Development System (LPDS),
flow and, 82 15–24
front-loading PD process, 236 coherent systems approach, 16
K4 and, 64 people subsystem, 21–24
MDTs and, 156, 301–2 principles 11 to 13, 23–24
problem solving in, 60–64, 212 principles 1 to 4, 17, 19–20
Kentouzu (study drawings), 51, 54, 55, 64 principles 5 to 10, 21–23
Kimbara, Yoshiro, 125 process subsystem, 17–20
“King of inventors,” 222 research behind, 4–5
Know-how. See Tacit knowledge sociotechnical system (STS), 15–17
Knowing-Doing Gap, The (Pfeffer & Sutton), two necessary elements of, 298
204 See also Coherent lean PD system; LPDS
Knowledge principles
accessing necessary, 335–36 Lean Thinking (Womack and Jones), 300, 335
“book of,” 218 Learning, 203–15
core, at Toyota, 195 building in, 306–7
database, NAC, 280–81 cycles, rapid, 214
data flows to map, 322, 325 DNA, 229–32
definition of, 203–4 from experience, 207–10
explicit, 204–5 ignorance and, 213–14
as fundamental element in PD, 96 leadership and building in, 351–52

369
Morgan Liker back 3/2/06 11:54 AM Page 370

Index

power of problems, 210–13 seventh principle basics, 177

tools, 292–93 sixth principle basics, 161
Toyota’s network, 205–7 STS subsystems and, 17
See also Technical competence tenth principle basics, 238
Leveled product development process flow, third principle basics, 98
67–98 thirteen principles, 5
across functions, 91–92 thirteenth principle basics, 294
barriers and facilitators of, 76–81 Lund, Andy, 229, 233–34
culture and, 236 Lutz, Robert, 10, 136
cycle planning, 83–85 Luxury car, 121, 122. See also Lexus
detailed (fundoshi) scheduling, 90–91
execution phase, 85–86 Machine scheduling, 253
flexible capacity, creation of, 88–89 Machine That Changed the World, The
“fuzzy” front end, 82 (Womack, Jones, & Roos), 3, 6
kentou and, 82 Management cycle time, 93–94
knowledge pulled through, 95–96 Manufacturing drawing. See Senzu
in nontraditional manufacturing, 92–95 Manufacturing engineering, 165
power of, 67–68, 98 Manufacturing environment, 314–15
process logic, role of, 82–83 Margin for error reduction, 32–36
product development as process, 68–70, 71 Market demand, 89
queuing theory and, 76–81 Market share, 7
resource allocation, 83–85 Masaki, Kunihiko, 85, 279, 282
staggered releases, 91–92 Matrix organization
synchronization, 86–88 for CE system, 131
unevenness, heading off, 90–91 change to Toyota’s, 145–48
wastes in, 70, 72–76 general manager job, 144
workload leveling, 83–85 multiple bosses in, 118
Lexus at NAC, 135
LS400, 284–85 strengths and weaknesses, 142–43
LS 430 sedan, 27 Toyota’s original, 143–45
margin for error halved, 32–36 Matsushita, 196–97, 225
tale of two CEs, 120–25 MBAs, 164
trade-off curve, breakthrough target, 284–85 MDT. See Module development team
vehicle development structure, 146–48 Mentoring, 164, 168, 171, 347
Line organization, 338–39 Mercedes Benz, 121, 124, 125
Linking disciplines, departments, suppliers, Meritocracy, 164
9–10 Merrill Lynch analysis, 7
Lockheed, 174 Mexico, 192
Lower-level activities, 53–54 Milestone requirements, 83
LPDS. See Lean Product Development System Mizen boushi (designed-in quality), 40, 58
LPDS principles Model age, 7
basics, 277 Model life span, 8
eighth principle basics, 202 Modularity, 198–99
eleventh principle basics, 258 Module development team (MDT)
fifth principle basics, 138 component-level goals and, 287–89
first principle basics, 36–37 as customer value delivery step, 31–32
fourth principle basics, 114 cross-functional teams, 87, 304–5
ninth principle basics, 215 kentou and, 51–53
principles 1 to 4, 17–20 as new initiative, 154–55
principles 5 to 10, 21–24 SEs in, 154
second principle basics, 65–66 Muda (non-value-added), 74, 276

370
Morgan Liker back 3/2/06 11:54 AM Page 371

Index

Multiproject management, 41, 90–91 as evolving process, 160

Mura (unevenness), 68, 75, 90–91 platform team, 148–52
Muri (overburden), 68, 75 product-focused, 140–42
simultaneous engineering, 152–60
NAC. See North American Car Company See also Cross-functional integration; Matrix
Nakamura, Kenya, 117, 119 organization
NASA, 142 Outsourcing, 195–99
NC (Numerically Controlled) technology, 252 core technology mastery, 195–96
Nemawashi, 221, 226, 235, 261, 264–65, 277 by Japanese companies, 180
New product development revolution, 3–13 by keiretsu, 182
categories, four broad, 41–42 new capability, 196–97
linking disciplines, departments, suppliers, Overburden (muri), 68, 75
9–10
next competitive frontier, 5–8 Pacemaker process, 97
next dominant core competency, 8–9 Pace setting, 93–94
Toyota as focus, 10–13 Parallel “work streams,” 69–70, 71
Niimi, Atsushi, 111 Part families, 257
No-adjust build, 254–57 Partnering, 180–81, 199–202
“No-compromise goals,” 124, 126, 137–38 Patents, 109, 252
Nominal dimensions, 254–56 Pattern making, 251
Nonaka, Ikujiro, 204 PDCA (Plan-Do-Check-Act) cycle, 102, 212,
Non-value-adding activities, 76, 342 214, 263, 301
North American Car Company (NAC) PDVSM (Product development value stream
bureaucratic organization, 135 mapping), 312–31
customer-defined value process at, 28–29 complex information flow, 322, 325, 343
“early problem solving” at, 62 connections revealed by, 70
explained, 13 knowledge work in, 319, 321, 322, 323, 324
hiring/recruiting at, 165–67 longer time frames in, 317–19, 320
process standardization, 105 multiple-functional tiers in, 316–17
product development manager, 134–35 PD/manufacturing VSM differences, 314–15
technology in PD, 245–46 PD process mapping, 315–25
training/development at, 167–68 specialists involved, 325, 326
Numerically Controlled (NC) technology, 252 virtual data and, 316
as VSM adaptation, 69
Obeya (big room) workshops, 325, 327–30
cross-functional, 262–63 See also Value stream mapping
cultural change and, 337–38 People
as innovation, 126, 152–54 development of, 175–77
MDTs and, 159 right person, work, time, 64–65, 299
simultaneous engineering, 152–54 subsystem, 21–23
Ohno, Taiichi, 5, 72, 179, 223, 259 See also Technical competence
OJT (On-the-job training), 167, 171, 347 PeopleFlo Manufacturing Inc. case, 353–57
Okamota, Uchi, 163 Phase-gate model, 340–41, 345
Okuda, Hiroshi, 48, 131, 196, 224 Plan-Do-Check-Act (PDCA) cycle, 102, 212,
One-piece flow, 67, 97, 257, 357 214, 263, 301
On-the-job training (OJT), 167, 171, 347 Platform team organization, 141
Optical scanning, 256 “Point-based” parameters, 101
Organizational learning, 203–4, 279–94. See Poka-yoke (error proofing), 94–95
also Standardization Policy deployment (hoshin kanri), 31–32,
Organizational structure 171–72, 266–69
“best,” 139–40 Post-World War II economy, 219

371
Morgan Liker back 3/2/06 11:54 AM Page 372

Index

Preventive measure. See Mizen boushi Production engineering, 105, 156, 158–60, 165,
Principles. See LPDS principles 172–73
Prius Production plants, 58
battery for, 196, 225 “Professional trust,” 163
as Business Revolution Team project, 44 Prototype builds, 174–75, 188–89
chief engineer for, 125–31 “Pull boards,” 96
development history, 128–29, 224–25 Pull system, 67, 304–5
G21 platform for, 127–31, 152–53 Pumps, 356–57
key technologies, 195–96
SEs involvement in, 154 Quality
styling, 48–49 initiatives, 213
tale of two CEs, 120–25 matrices, 95, 290–91
Problems See also Breakthrough quality; Mizen boushi
attitudes toward, 211 Queuing theory, 76–81
multiple alternatives to, 51 capacity utilization and, 78
power of, 210–11 seven wastes and, 81
quick solutions, 53–54 traffic jam analogy, 79–80
solving at source, 211–13 variation and, 100
standardized scientific process, 212 WIP and, 77
Process and binder development, 107–8
Process flow Radar graph comparison, front doors, 34, 288
engineering cadence and, 93–94 RAV Four, 27, 30, 225
in nontraditional manufacturing, 92–95 RDDP (Request for Design and Development
Process logic, 82–83 Proposal), 188
Process standardization, 100, 104–12 Reflection (hansei), 112, 203, 208–10, 230, 234
die construction, 109–11 Relentless improvement. See Continuous
die engineering, 106–7 improvement
process and binder development, 107–8 Relentless pursuit of perfection, the, 32
for production engineering, 106 Request for Design and Development Proposal
tool and die manufacturing, 108–9 (RDDP), 188
at Toyota, 106–7, 108, 109–12 Resident engineers, 309
Process subsystem, 17, 19–20 Resource allocation, 83–85
Product Resource utilization. See Capacity utilization
“chimneys,” 141 Retention. See Technical competence
concept, 121 Return on Investments (ROI), 29
families, 108, 125 Re-use principle, 54–55
organization, 140–42, 149 Rework, 50, 245, 342
platforms, management, 41–42 Ringi system, 265–66
Product development ROI (Return on Investments), 29
coherent systems approach, 16
execution phase, 85–86 Satellite companies, 88
flow, 94–95 Screw body build, 254–57
globalizing, 283 SE. See Simultaneous engineer
next dominant core competency, 8–9 Seal surface wrinkle condition, 62–64
PeopleFlo Manufacturing Inc. case, 353–57 “Seat by the window,” 231
as process, 330–31 Second prototype stage (2S), 189. See also
streamlining at Toyota, 155 LPDS principles
system, next competitive frontier, 5–8 Senzu (manufacturing drawing)
Product development value stream mapping. die engineering and, 107
See PDVSM individual component development plans,
Product families, 356–57 114

372
Morgan Liker back 3/2/06 11:54 AM Page 373

Index

MDTs and, 159 communicating and evaluating sets, 283

part-specific, 59 competitors and, 286–89
production engineer and, 54, 106 of design, 100, 101–4
simultaneous engineer and, 53, 57, 59 engineering checklists, 101–4
updated at program end, 291 of engineering skill-set, 101, 112–13
Set-based concurrent engineering (SBCE), -flexibility paradox, 89
40–41, 47–51, 283 know-how database, Toyota, 281–83
Seven wastes, 70, 72–74, 81 knowledge database, NAC, 280–81
Shijisho (“direct order document”), 31 learning tools and, 292–93
Shiomi, 130 of lower-level activities, 53–54
Shiramizu, Kousuke, 29 organizational learning and, 279–80
Shook, John, 131 of process, 100, 104–12
Short-tem cost reductions, 75 role of, 292–93
Sienna Minivan, 43, 148, 193, 229–30, 233–34, tools at Toyota, 289–94
260, 290 Standardized component library, 250–51
Simulation technology, 251 Standardized process sheets, 291–92
Simultaneous engineering Standardized skills inventories, 112
chief production engineers, 154–60 Standardized work. See Standardization
drawings, evaluation, 152–54 Start of production (SOP), 7, 57
essence of, 260 Start-up business case, 353–57
module development teams in, 154–60 Status boards, 96
Simultaneous engineer (SE), 53 Stepovers, 252
impact of, 154 Sterzinger, Darrel, 192, 201
responsibilities, 56–57, 301 Stopping distance, 186, 189
synchronization and, 86–88 Study drawing (kentouzu), 51, 54, 55, 64
targets and, 57–59 Study phase. See Kentou
Single loop learning, 204 Styling
Single minute exchange of die (SMED), 109, clay models and sketches, 46, 47–48
254 engineering feasibility and, 46, 228–29
“Skunkworks approach,” 149, 174 freeze, 7
SMED (single minute exchange of die), 109, Subsystem integration
254 customer-defined value, 299–300
Society, 221–22 efficient manufacturing, 305–6
Sociotechnical systems theory (STS), 15–17 flexible capacity, 303–4
Software people and processes, 299
commercial design, 244 perfection/continuous improvement, 306–7
formability FEA, 248–49, 250 pull and flow, creation of, 304–5
know-how database, Toyota, 244, 281–83 tools and technology, 299
parmetric, 245 value stream and, 300–302
for pattern-making, 251 variation, eliminate/isolate, 300–303
See also V-Comm technology waste elimination, 300–302
Solara, 148, 193 “Supermarkets,” 67
Solids die design, 250–51 Supplier
Speed, 86, 89 bids and pricing, 191–93
Spotting press, 253–54 consultative, 185
“Stage-gate model,” 105 contractual, 185–86
Staggered design releases, 91–92, 96 four major roles, 183–86
Staggered vehicle launches, 85 long-term relationships, 190–91, 193
Stamping press, 253–54 mature, 184, 185
Standardization, 99–114 partnering with, 183, 185, 190–95, 304
categories, three, 100–113 respect for, 199–202

373
Morgan Liker back 3/2/06 11:54 AM Page 374

Index

selecting/developing for Toyota, 186–89 Three-dimensional noncontact measuring,

stable of, 194–95 256–57
tier structure, 183–86 Three Ms, 74–76
tire example, 186–89 Throughput time, 78
Supplier integration, 179–202 “Throwing the design over the wall,” 259
keiretsu and, 182–83 Tires, 186–89, 190, 193
outsourcing strategy, 195–99 Togo, Yukiyasu, 121
partnering with suppliers, 190–95 Tokyo Auto Show, 130
parts and, 180–82 Tools, 220–21, 249–50
tier structure, 183–86 adaptation of technology, 257–58
Toyota suppliers to partner, 186–89 body build and, 254–57
treatment of suppliers, 199–202 checklists, 101–4, 249–50
U.S. supplier tire example, 186–89 for die machining, 252–53
Suzuki, Ichiro, 121, 122, 123–25, 134 for pattern-making, 251
“Swim lane,” 70 for solids die design, 250–51
Synchronization, 86–88 for standardization, 249–50
Synergism. See Subsystem integration tagged, 319, 321
System compatibility, 50–51 and technology subsystem, 23–24
tryout presses, 253–54
Tacit knowledge, 204–5, 206, 229, 279, 289, See also Technology and tools
307. See also V-Comm technology Towering technical competence. See Technical
Takt time, 93, 97, 99 competence
Task variability, 78 Toyoda, Eiji, 121, 125, 152
Teamwork, 230–32, 338 Toyoda, Kiichiro, 173, 221, 222–23, 311, 333
Teardowns, 174, 287–89 Toyoda, Sakichi, 15, 221, 222, 311
Technical competence, 163–77 Toyoda, Shoichiro, 121
genchi genbutsu engineering, 173–75 Toyoda Automatic Loom Works, 88, 221, 333
lean PD system and, 175–77 Toyota
philosophy for retention, 164–65 checklists, 103, 251, 289–92
recruiting/hiring at NAC, 165–67 common sense as hallmark, 298
recruiting/hiring at Toyota, 112, 168–70, culture, 143, 220, 222, 304
346–47 customers first at, 137, 228–29
training/development at NAC, 167–68 digital assembly at, 246–48
training/development at Toyota, 170–73 DNA, 143, 307
Technology and tools, 241–58, 299 integration of functions, programs, 145
adopting to enable process, 257–58 lead time, 136, 263
in lean product development, 243–49, lean environment at, 243
350–51 learning from, 12–13
for manufacturing engineering, 249–57 market value, 11
selection of, five principles, 241–43 maxim, PD planning, 40
for tool making, 249–57 patented tools, 109, 252
See also Standardization; Tools quality of products, 11
“Technology clubs,” 141, 152 reason for focus on, 10–12
The Knowing-Doing Gap, (Pfeffer & Sutton), spirit of innovation, 121, 125, 181
204 success, components of, 15
The Knowledge Creating Company, (Nonaka), “system integrator” role, 136–37
204 training/development at, 168–69, 170–72,
The Machine That Changed the World, 280
(Womack, Jones, & Roos), 3, 6 Toyota Auto Body, 85, 88
The Toyota Way (Liker), 11, 32, 69, 221 Toyota Auto Loom, 88, 221, 333
3 C’s, 121 Toyota Crown, 117

374
Morgan Liker back 3/2/06 11:54 AM Page 375

Index

Toyota Industries, 88 targeting process, 30, 32

Toyota Manufacturing North America, 111 See also Customer-defined value
Toyota Motor Company, 173, 221, 223 Value stream, 27, 300–302, 304, 311
Toyota Motor Manufacturing North America, Value stream mapping (VSM), 69–70, 353–57
156 current state, 311–12, 340–43
Toyota Production System (TPS) future states, 311–12, 337
process/people/tools table, 306 power of, 312
“respect for humanity system,” 201 workshop, 345
standardized work and, 99 work streams, 336–37
suppliers and, 186 Value system. See Culture
Toyota Quality Management, 339 Variable cost targets, 57–58
Toyota Sensei, 4 Variation
“Toyota T,” 170 destructive power of, 100
Toyota Technical Center (TTC) isolation and minimization, 40, 302–3
American engineers at, 211 two types of, 78–79
former president of, 85 See also Kentou; Queuing theory
hoshin deployment at, 267 V-Comm technology, 174, 242, 283, 290
hourensou management at, 232–33 Vehicle
MDTs from156–59 assembly engineering, 111–12
supplier treatment, 201 center, Toyota, 146–48
tire suppliers for, 186 closure subassemblies, 33–36
Toyota Way, the, 132, 171, 173, 194, 222, 231, development centers, 146, 148–52
233–34 drive analysis, 30
Toyota Way, The (Liker), 11, 32, 69, 221 geometry, 43
Toyto body and structures engineering, 170–72 launches, 85
TPS. See Toyota Production System Vehicle-level architecture, 123–24
Trade-off curves, 43, 284–85 Vehicle-level goals, 55–56
Traffic jam queuing theory analogy, 79–80 Vehicle-level performance objectives, 28, 31,
Training and development. See Technical 124
competence Vehicle platforms, 7, 42–44, 84, 247–48
Trust, 163–64, 181, 182, 198–99, 200–201 Vehicle styling. See Styling
Tryout presses, 253–54 Venn diagrams, 49
TTC. See Toyota Technical Center “Virtual cell,” 97
Twenty-first century car. See Prius Virtual checks, 109
Virtual data, 316–17
Uchiyamada, Takeshi “Virtual engineering,” 174
G21 project head, 125–27, 130–31, 153 Virtual manufacturing, 245–56
innovations of, 153–54 Visual communication, 259–77
obeya and, 262 A3 tool at Toyota, 269–76
as Prius CE, 48–49, 121 and alignment at Toyota, 276–77
quotation, 134, 139, 217 alignment tools, 263–69
Uminger, Glenn, 67 CE’s concept paper, 260–62
Unevenness (mura), 68, 90–91 cross-functional obeya, 262–63
Unique vehicle platforms, 7 machine scheduling boards, 253
Unleveled flow, 89 Visual controls, 355–57
Visual management, 94
Value Voice of the customer, 122, 137
characteristics, 30 VSM. See Value stream mapping
decomposition process, 31
engineering, 182 Wada, Executive VP, 130–31
hierarchy, 31 Ward, Al, 27

375
Morgan Liker back 3/2/06 11:54 AM Page 376

Index

“War on waste,” 68, 75 product development as process, 330–31

Waste at Toyota, 301
lean culture and, 217 Wholly-owned subsidiaries, 88
muda, 68 Wind noise. See Gap reduction
recognizing, 70–71 WIP (work-in-process), 77, 303
reduction, 257 Within-function synchronization, 86–87
root causes of, 81 Work cells, 97, 253
seven, 70–74, 81 Work ethic, 224–26
three Ms, 74–76 Work in progress (WIP), 77, 303
of transactions, 200 Workload leveling, 83–85
in two broad areas, 27 Work streams, 69–70, 71, 336–37
Waste elimination, 300–302, 311–31
PDVSM and, 312–25 Yaegashi, Mr., 224
PDVSM workshops, 325–30 Yamashinta, George, 208, 232–33

376
Morgan Liker back 3/2/06 11:54 AM Page 377

ABOUT THE AUTHORS

Dr. James M. Morgan has more than 24 years experience in automotive

product development and operations management, including almost 20
years at TDM; a tier one automotive supplier of engineering services, tools,
dies and vehicle subsystems where he was vice president. He holds MS and
Ph.D. degrees in Engineering from the University of Michigan where he
completed a three-year, Shingo Award-winning comparative study of
Toyota and a North American competitor’s product development systems.
Dr. Morgan’s research has lead to the creation of a coherent systems
model of lean product development which he has utilized in analyzing and
improving the development of new products in several fortune fifty com-
panies in both the United States and Europe. Dr. Morgan has published a
number of articles and developed and taught classes and seminars at the
University of Michigan, M.I.T., the Lean Enterprise Institute, the Lean
Enterprise Academy, and the Society of Automotive Engineers.
Dr. Morgan is currently an engineering director at Ford Motor Company.

Dr. Jeffrey K. Liker is Professor of Industrial and Operations Engineer-

ing at the University of Michigan. Dr. Liker has authored or co-authored
over 70 published articles and book chapters and seven books. He is
author of the international best-seller, The Toyota Way: 14 Management
Principles from the World’s Greatest Manufacturer (McGraw Hill, 2004),
which speaks to the underlying philosophy and principles that drive
Toyota’s quality and efficiency-obsessed culture. The companion (with
David Meier) Toyota Way Fieldbook (McGraw Hill, 2005), details how
companies can learn from the Toyota Way principles. He is also the Editor
of Becoming Lean: Inside Stories of U.S. Manufacturers (Productivity Press,
1997), and winner of the 1998 Shingo prize (for excellence in manufactur-
ing research). He has also won Shingo prizes for his research in 1995, 1996,
and 1997. Other books by Dr. Liker include Engineered in Japan (Oxford
University Press, 1995); Concurrent Engineering Effectiveness: Integrating
Product Development Across Organizations (Hanser-Gardner, 1997), and
Remade in America: Transplanting and Transforming Japanese Manufactur-
ing Methods (Oxford University Press, 1999). He is active as a keynote
speaker, speaker for executive retreats, and lean consultant, independently
and through a company he cofounded—Optiprise, Inc.

377
Morgan Liker back 3/2/06 11:54 AM Page 378