Engineering Management

profilecamila89
98409-PDF-ENG.pdf

Another Look at How Toyota Integrates Product Development

by Durward K. Sobek, II, Jeffrey K. Liker, and Allen C. Ward

Harvard Business Review Reprint 98409

For the exclusive use of R. Nigaglioni, 2018.

This document is authorized for use only by Rolando Nigaglioni in 2018.

2 P H OTO S BY M org a n S e g a l

hallenged by world-class competitors, manufacturing

companies in the United States have undergone a renaissance in the last decade. The renaissance started on the shop floor with an emphasis on built-in quality, the elimination of waste, and faster throughputs. But attention quickly turned upstream to product development, where Japa- nese companies were outperforming

U.S. competitors on nearly every measure: speed to market, design quality, product-design manufac- turability, cost, and productivity. Observers concluded that the key to Japanese success, and U.S. industry’s weakness, was integration – both between product design and manu- facturing-process design, and with marketing, purchasing, finance, and other business functions.

I D E A S AT W O R K

The company that’s famous

for integration also excels

at building functional

expertise.

Another Look at How

Toyota Integrates

Product Development by Durward K. Sobek, II,

Jeffrey K. Liker, and

Allen C. Ward

C

Durward K. Sobek, II, is an assistant professor of mechanical and industrial engineering at Montana State University in Bozeman. Jeffrey K. Liker is an associate professor of industrial and operations engineering at the University of Michigan in Ann Arbor. Allen C. Ward is an adjunct researcher at the Uni- versity of Michigan and the president of Ward Synthesis, an engineering con- sulting company in Ann Arbor.

For the exclusive use of R. Nigaglioni, 2018.

This document is authorized for use only by Rolando Nigaglioni in 2018.

Copyright © 1998 by the President and Fellows of Harvard College. All rights reserved. 3

I D E A S AT W O R K

A great many companies attacked the issue head on. Typical solutions were such product-development tools as quality function deploy- ment and Taguchi methods. Compa- nies also introduced organizational solutions; those solutions ranged from keeping the basic functional organization intact and assigning people to temporary project teams to disbanding the functional organiza- tion altogether in favor of organizing around products, as Chrysler did in the early 1990s. (Here we use the term function broadly to mean the vari- ous groups of specialized expertise required to make new models work – including the engineering special-

ties within the design process, such as electrical, body, or test engineer- ing, as well as other business func- tions, such as manufacturing and marketing.)

The new solutions have brought substantial improvements to the companies and dramatic results in the marketplace. But they have also created problems of their own. Cross-functional coordination has improved, but at the cost of depth of knowledge within functions, be- cause people are spending less time within their functions. Organiza- tional learning across projects has also dropped as people rotate rapidly through positions. Standardization

across products has suffered because product teams have become auton- omous. In organizations that combine functional and project-based struc- tures, engineers are often torn be- tween the orders of their functional bosses on the one hand and the de- mands of project leaders on the other. As these new problems take their toll, U.S. companies are beginning to see the effectiveness of their prod- uct-development systems plateau. More important, that effectiveness seems to have leveled off far short of the best Japanese companies.

This article explores how one of those companies, Toyota, manages its vehicle-development process. We

For the exclusive use of R. Nigaglioni, 2018.

This document is authorized for use only by Rolando Nigaglioni in 2018.

studied Toyota’s process for five years through in-depth interviews at all levels of management. Interest- ingly, we found that in many ways the company does not resemble what is often considered the model of Japanese product development – it has maintained a functionally based organization while achieving its im- pressive degree of integration, and many of its practices are actually similar to those that U.S. companies employed during their manufactur- ing prime earlier in this century.

We can group Toyota’s managerial practices into six organizational mechanisms. Three of them are pri- marily social processes: mutual ad- justment, close supervision, and in- tegrative leadership from product heads. The other three are forms of standardization: standard skills, standard work processes, and design standards. Alone, each mechanism would accomplish little, but every piece has its own role and at the same time reinforces the others, un- like many of the sophisticated tools and practices at companies in the United States, which tend to be im- plemented independently.

Together, the mechanisms give Toyota a tightly linked product- development system that achieves cross-functional coordination while still building functional expertise. This balance allows the company to

achieve integration across projects and over time, as well as within projects. U.S. companies have con- centrated on bringing the functions together within projects, but a single- minded focus on that goal can actu- ally undermine attempts to share information across projects. Cross- functional teams, for example, work well within individual projects, but the temporary, personal nature of these teams makes it hard for them

to transmit information to teams on other projects.

Toyota, by contrast, seems to go to the opposite organizational extreme. It relies on highly formalized rules and standards, and puts limits on the use of cross-functional teams. Such rigid policies can have enormous drawbacks. To avoid those draw- backs, Toyota has added a number of twists to ensure that each project has the flexibility it needs and still benefits from what other projects have learned. The result is a deftly managed process that rivals the company’s famous production sys- tem, lean manufacturing, in effec- tiveness.

Coordination Based on Writing One of the most powerful ways to coordinate one’s efforts with those of people in other functions is to talk to them face to face. In this manner, each party gets the other’s point of view and can quickly make adjust- ments to find common ground. This mutual adjustment often takes the form of a meeting: a product designer and a manufacturing engineer, for example, get together to discuss the effects that a proposed design for a particular car body would have on the cost of production.

Direct contact between the mem- bers of different functions is cer-

tainly important – some say it is the essential in- gredient in getting func- tional groups that have traditionally been at odds to work together. Indeed, many observers, manag- ers, and engineers claim that face-to-face interac- tion is the richest, most appropriate form of com-

munication for product develop- ment. Numerous companies now colocate functional experts so that interaction can occur with much greater ease and frequency. Often these companies have done away with written forms of communica- tion because, as some claim, written reports and memos do not have the richness of information or interac- tive qualities needed for product development.

Meetings, however, are costly in terms of time and efficiency, and meeting time increases with coloca- tion. Meetings usually involve lim- ited value-added work per person, and they easily lose focus and drag on longer than necessary. Engineers in companies we’ve visited often complain of not having enough time to get their engineering work done because of all the meetings in their schedule.

Toyota, by contrast, does not co- locate engineers or assign them to dedicated project teams. Most peo- ple reside within functional areas and are simply assigned to work on projects – often more than one at a time – led by project leaders. By root- ing engineers in a function, the com- pany ensures that the functions de- velop deep specialized knowledge and experience.

In lieu of regularly scheduled meetings, the company emphasizes written communication. When an issue surfaces that requires cross- functional coordination, the proto- col is first to write a report that pre- sents the diagnosis of the problem, key information, and recommenda- tions, and then to distribute this document to the concerned parties. Usually, the report is accompanied by either a phone call or a short meeting to highlight the key points and emphasize the importance of the information. The recipient is ex- pected to read and study the docu- ment and to offer feedback, some- times in the for m of a separate written report. One or two iterations communicate a great deal of infor- mation, and participants typically arrive at an agreement on most, if not all, items. If there are outstand- ing disagreements, then it’s time to hold a meeting to hammer out a de- cision face to face.

In such problem-solving meet- ings, participants already under- stand the key issues, are all working from a common set of data, and have thought about and prepared propos- als and responses. The meeting can focus on solving the specific prob- lem without wasting time bringing people up to speed. By contrast, at many U.S. companies, attendees often arrive at meetings having done

4 harvard business review July–August 1998

h ow t oyo t a i n t e g r at e s p r o d u c t d e v e l o p m e n tI D E A S AT W O R K

Toyota combines a highly formalized system with twists to ensure that each project is flexible and benefits from other projects.

For the exclusive use of R. Nigaglioni, 2018.

This document is authorized for use only by Rolando Nigaglioni in 2018.

little or no preparation. They can spend the first half of the meeting just defining the issue, and responses are shoot-from-the-hip reactions to a problem that people have had little time to think about.

Toyota takes its focused style of meeting quite seriously. One engi- neer we talked to showed us his schedule for the day, which included two meetings at separate times with the same group of people. When asked why he would schedule sepa- rate meetings with this group, he explained that they needed two meetings to discuss two distinct problems. It was important not to confuse the issues by combining them into one meeting.

Once the writer of the original report has consulted with all inter- ested parties, he or she writes a final version of the report that presents all sides of the question. The overall reporting process therefore has two benefits. First, it documents and summarizes analysis and decision making in a convenient form for the rest of the organization. Second, and more important, it forces engineers in every function to gather opinions from other functions regarding the ramifications of the changes they are proposing.

Twist: Although Toyota often re- lies on written communication as the first line of attack in solving problems, it does not suffer from the voluminous paperwork we associate with bureaucracy. In most cases, en- gineers write short, crisp reports on one side of size A3 paper (roughly 11 ´ 17, the largest faxable size). The reports all follow the same format so that everyone knows where to find the definition of the problem, the re- sponsible engineer and department, the results of the analysis, and the recommendations. The standard for- mat also helps engineers make sure they have covered the important an- gles. The result is a clear statement of a problem and solutions that is accessible not only to people within a particular project but also to those working on other projects.

Writing these reports is a difficult but useful skill, so the company gives its engineers formal training in how to boil down what they want to

communicate. Supervisors see to it that engineers do the appropriate groundwork to ensure that all perti- nent views are taken into considera- tion. Toyota has also created a cul- ture in which reading these reports is highly valued and essential to do- ing one’s job well. Indeed, we heard about a certain Toyota executive who refused to read any report longer than two pages.

Mentoring Supervisors In product development, supervi- sion traditionally took place within individual functions. Electrical engi- neers, for example, were supervised by other electrical engineers because only they fully understood the work involved. Recently, some U.S. com- panies have experimented with cross-functional team-based organi- zations in order to force engineers to think beyond the needs of their own function. Chrysler, for example, is organized around product platfor ms rather than functions, and the plat- form team leader heads all product engineering in the platform.

Toyota, however, has not forgot- ten the value of instructive supervi- sion within functions. Supervisors and higher -level managers ar e deeply involved in the details of en- gineering design. In fact, young engi- neers (anyone with less than ten years’ experience) must usually get approval from their functional su- pervisors not only for the designs they propose but also for each step involved in the process of arriving at the final design.

The company depends on supervi- sors to build deep functional exper- tise in its new hires – expertise that then facilitates coordination across functions. But functional supervi- sors also teach engineers how to write reports, whom to send the re- ports to, how to interpret reports from other functions, and how to prepare for meetings. Direct supervi- sion thus works in concert with mu- tual adjustment in order to promote coordination.

Twist: To American eyes, such in- tensive supervision would seem to

be a kind of meddling that stifles the creativity and learning of new engi- neers and other specialists. U.S. companies are moving in the oppo- site direction as they preach em- powerment, with superiors acting as facilitators rather than bosses. But Toyota has succeeded in keeping its supervision fresh and engaging, in two ways. Like Toyota’s supervisors on the factory floor, managers in product development are working engineers. Instead of merely manag- ing the engineering process, they hone their engineering skills, stay abreast of new technology, maintain their contacts and develop new ones, and remain involved in the creative process itself. Functional engineers are not frustrated by the experience of working under someone less skilled than they are. In many U.S. companies, by contrast, engineers

who rise through the ranks become managers who stop doing engineer- ing work.

Perhaps more important, Toyota’s managers seem to avoid making de- cisions for their subordinates. They rarely tell subordinates what to do and instead answer questions with questions. They force engineers to think about and understand the problem before pursuing an alterna- tive, even if the managers already know the correct answer. It’s not a boss-subordinate or even a coach- athlete relationship, but a student- mentor relationship.

Integrative Leaders Perhaps the most powerful way to integrate the work of people from diverse specialties is to have a leader with a broad overview of the whole. Many U.S. companies have recently been moving toward a heavyweight- project-management str ucture. Heavyweight project managers coor- dinate all the specialists from func- tional departments around a com- mon project with a common set of

Supervisors are deeply involved in their subordinates’ work, without giving orders.

h ow t oyo t a i n t e g r at e s p r o d u c t d e v e l o p m e n t I D E A S AT W O R K

harvard business review July–August 1998 5

For the exclusive use of R. Nigaglioni, 2018.

This document is authorized for use only by Rolando Nigaglioni in 2018.

goals. Their authority in these ma- trix organizations comes from their complete control over their particu- lar project rather than from any di- rect supervisory authority over the individual functions.

Toyota’s equivalent is the chief engineer. Each chief engineer, based in one of Toyota’s three vehicle- development centers (which oversee long-term planning across projects), maintains full responsibility for a single vehicle program but wields no direct power over the functions.

Indeed, Toyota’s chief engineers come close to matching what others have described as the prototypical heavyweight project manager. Be- fore attaining their position, they must demonstrate both exemplary technical expertise and fluency in synthesizing technical knowledge into clever, innovative designs. Toy- ota’s managers feel strongly that

only a good designer can evaluate the quality of someone else’s design. Chief engineers also need to be able to conceptualize whole systems. It is one thing to understand the me- chanics of a brake system and an- other to apply that knowledge to- ward an actual brake system design; but it is quite another thing to be able to conceptualize a brake system and visualize how it can be integrated with the rest of the vehicle. By con- trast, a number of companies with heavyweight product managers do not have such stringent technical re- quirements.

All chief engineers have a small staff of 5 to 15 engineers to assist them in managing the development process and in coordinating the work of the functional specialties. The hundreds of other engineers on the project report only through the functional chain of command. The chief engineer has no formal author- ity over them, so he must “per- suade” them to help him realize his vision for the vehicle. One former

chief engineer described the position as being the “president of the vehi- cle”: just as the U.S. president heads the country but has no direct author- ity over legislation (beyond vetoes), so a chief engineer cannot dictate what functional engineers do. But his extensive technical expertise wins him tremendous respect, even admiration, from functional engi- neers – a key source of his enormous informal authority.

The limits on the chief engineers’ power, despite their prestige, are real, and the engineering expertise and equal rank of the general man- agers in charge of the functional areas can keep chief engineers from making potentially dangerous mis- takes. For example, in designing a new model of the Celica sports car several years ago, the styling depart- ment suggested a longer front- quarter panel. The change would

have increased the panel’s extension into the top of the front door, allowing the door to curve back at the top, thereby creating an angular and more ex- citing look. The manufac- turing engineer assigned

to door panels, however, opposed the change because the altered panel would be difficult to produce.

After assessing both sides, the chief engineer for the vehicle fa- vored the altered front panel. Never- theless, the manufacturing engineer felt strongly that the change was un- wise. If Toyota had organized around projects rather than functions, styling would likely have gotten its way, and the car might well have suffered production problems. But because the chief engineer’s author- ity was only informal, the manufac- turing engineer was able to raise the issue to the level of the general man- ager of manufacturing, who strongly challenged the chief engineer. After substantial argument, the two sides reached an innovative compromise that achieved the cutaway look that styling wanted with a satisfactory level of manufacturability.

Such incidents explain why one Toyota engineer, when asked what makes a good car, replied, “Lots of con- flict.” Conflict occurs when people

6 harvard business review July–August 1998

h ow t oyo t a i n t e g r at e s p r o d u c t d e v e l o p m e n tI D E A S AT W O R K

A chief engineer is less the manager of and more the lead designer on a project.

from different functional areas clearly represent the issues from their perspective. Its absence im- plies that some functional areas are being too accommodating – to the detriment of the project as a whole. Still, when managers resolve con- flicts through organizational influ- ence, horse trading, or executive fiat, the results are often poor. It is the ability of chief engineers to see the broad picture clearly – and the ability of functional managers to contain the chief engineer’s enthu- siasm – that leads to highly integrat- ed designs. And while the chief en- gineers keep individual projects on track, the autonomous functional

For the exclusive use of R. Nigaglioni, 2018.

This document is authorized for use only by Rolando Nigaglioni in 2018.

decisions. His authority over design decisions stems from the fact that the vehicle is quite clearly “his car.” He is therefore less the manager of and more the lead designer on the overall project.

As lead designer, chief engineers design (and subsequently manage) the entire process of developing the product, and they personally articu- late the vehicle concept that be- comes the blueprint for the entire program. That concept includes the major dimensions of the vehicle; de- cisions on such major systems as the transmission; the variety of models to be offered; the characteristics of the target customer; sales projec- tions; and targets on weight, cost, and fuel economy. Chief engineers integrate the work of the functions by planning how all the parts will work together as a cohesive whole, soliciting input from the various en- gineering, manufacturing, and mar- keting functions, of course. Once a chief engineer has designed the over- all approach for a car, the different functions fill in the technical details that are required to realize the vehi- cle concept.

Some of the remaining integration problems at U.S. companies may in fact stem from a lack of precisely this kind of system design. Even companies with able heavyweight product managers tend to jump di- rectly from product concept to the technical details of engineering de- sign. They bypass, without going through, the very difficult but im- portant task of designing the overall vehicle system: planning how all the parts will work together as a cohe- sive whole before sweating the fine details. At Toyota, the chief engi- neer provides the glue that binds the whole process together.

Standard Skills Every company depends on highly skilled engineers, designers, and technicians to bring a product to market. Organizations can coordi- nate their activities by giving each person within a specialty the same set of skills to accomplish his or her tasks. When we know what to expect of others because they are trained in a certain way, we can re-

quest specific services with relatively little effort in coordination. In engi- neering, most U.S. companies rely heavily on universities or special- ized training companies to provide their people with the skills needed to do their jobs.

Toyota, by contrast, relies primar- ily on training within the company. It views training as a key compe- tency, worth developing internally rather than outsourcing. Engineers receive most of their training through the intensive mentoring involved in direct supervision, although the company also runs a training center with instructors who are experi- enced Toyota engineers. The process not only develops excellent engi- neers but also teaches new hires Toyota’s distinct approach to devel- oping the body, chassis, or other sys- tems in a vehicle.

Additionally, Toyota rotates most of its engineers within only one function, unlike U.S. companies, which tend to rotate their people among functions. Body engineers, for example, will work on different auto-body subsystems (for example, door hardware or outer panels) for most, if not all, of their careers. Be- cause most engineers rotate primar- ily within their engineering func- tion, they gain the experience that encourages standard work, making the outputs of each functional group predictable to other functions. In addition, rotations generally occur at longer intervals than the typical product cycle so that engineers can see and learn from the results of their work.

That consistency over time means that the company’s engineers in the manufacturing division, for exam- ple, need to spend less time and en- ergy communicating and coordinat- ing with their counterparts in design because they learn what to expect from them. Indeed, Toyota firmly believes that deep expertise in engi- neering specialties is essential to its product-development system. We often heard such comments as, “It takes ten years to make a body engi- neer” in our conversations with the company’s managers. In short, the widely held notion that Japanese companies rotate their personnel

harvard business review July–August 1998 7

h ow t oyo t a i n t e g r at e s p r o d u c t d e v e l o p m e n t I D E A S AT W O R K

engineers and managers ensure that knowledge and experience fr om other projects are not forgotten in the current one.

Twist: Chief engineers do differ in one important respect from even the best heavyweight project managers. The latter typically delegate deci- sion making to functional teams, while retaining authority over the team’s decisions and taking respon- sibility for implementing those deci- sions throughout the development process. If a heavyweight project manager doesn’t like a decision, he or she can veto it. By contrast, a chief engineer takes the initiative by personally making key vehiclewide

For the exclusive use of R. Nigaglioni, 2018.

This document is authorized for use only by Rolando Nigaglioni in 2018.

broadly and frequently simply does not apply to Toyota.

Twist #1: Rotating locally and building functional expertise would seem to create rigid functional boundaries, or chimneys, in which engineers work only to be the best in their function. An electrical engi- neer, for example, might aim to de- velop the most elaborate electrical design possible, without thinking about how that design will work with the rest of the vehicle. But we have found that the so-called chim- ney effect is not the result of young engineers being too loyal to their functions or too narrow-minded about what cars need. Rather, it is usually the result of experienced en- gineers and managers hoarding their knowledge, which becomes the ba- sis of their power in an organization rooted in functions.

To avoid such political conflict, Toyota takes care to rotate most of

its senior people broadly. Engineers at the bucho level – which usually means the head of a functional divi- sion (for example, power-train engi- neering for front-wheel-drive pas- senger cars) with at least 20 years’ experience – typically rotate widely across the company to areas outside their expertise. Such moves force buchos to rely heavily on the experts in their new area, building broad net- works of mutual obligation. At the same time, buchos bring their own experience, expertise, and network of contacts that they can use to facil- itate integration.

Twist #2: Buchos (and chief engi- neers) encourage their people to see the needs of the product as a whole, but Toyota also keeps design engi- neers aware of the ramifications of their decisions throughout the de- velopment process. These engineers retain responsibility for their parts

of the car from the concept stage to the start of full production. A door- systems engineer, for example, works with stylists to determine the concept of the door and then devel- ops the detailed design by working with production engineers and out- side suppliers. The engineer also goes to the factory to be part of the launch team as the vehicle ramps up to full production.

Flexible Work Standards The stereotypical bureaucratic way of coordinating work processes is to specify in detail the content of each step in the process. Tasks are prepro- grammed so that one group knows what to expect from another and when to expect it, with little or no communication required. Factories use this kind of coordination exten- sively, standardizing the tasks at each workstation to ensure that the work is done consistently and in a

set amount of time. All the workstations can then be easily coordinated by a schedule.

Many U.S. companies have tried to apply this concept to product devel- opment, notably General Motors with its four- phase process. A special team at GM defines the

process in great detail, telling each department what it needs to do when, whom to send results to, what format the information should take, and so on. The plan for the styling function alone covers the length of one wall in a sizable conference room. The four-phase process is al- most never followed as its authors envisioned, however, because the process is so detailed that every ve- hicle program has exceptions that force designers to deviate from the prescribed process – the real world resists such intensive planning. In addition, a separate group develops and maintains the details of the standard process; as a result, the peo- ple who must follow the process do not have ownership of it, and the prescribed processes are not likely to be truly representative of the actual one. Indeed, the four-phase process seems to do little to shorten cycle

times or to bring other benefits that such thorough planning aims to pro- duce. Companies such as General Motors face a dilemma: the more they attempt to define the process of product development, the less the organization is able to carry out that process properly.

Toyota, by contrast, has success- fully standardized much of its devel- opment process. Product-engineer- ing depar tments follow highly consistent processes for developing subsystems within a vehicle. Rou- tine work procedures – such as design blueprints, A3 reports, and feedback forms for design reviews – are also highly standardized. The overall process of developing a vehicle fol- lows regular milestones. Indeed, the suppliers we visited in Japan could describe from memory Toyota’s ve- hicle-development process because it is so consistent from model to model. Every model has a concept, styling approval, one or two proto- type vehicles, two trial production runs, and finally a launch; and sup- pliers know the approximate timing of each event. (For more on how Toy- ota uses standards to coordinate its work with suppliers, see “A Second Look at Japanese Product Develop- ment,” by Rajan R. Kamath and Jeffrey K. Liker, HBR November– December 1994.)

Twist #1: How does Toyota avoid the pitfalls that other companies have experienced with work stan- dards? When you talk specifics with Toyota engineers – such as how many prototypes are built and tested, when designs are finalized, or how long a particular phase takes – the re- sponse is typically that it varies case by case. The actual standardized work plans are kept to a minimum; they often fit on a single sheet of paper. The basic process in the eyes of the participants is very consistent from model to model, but the imple- mentation of the concept is indi- vidually designed for each vehicle program. Intense socialization of en- gineers through on-the-job training creates a deep understanding of every step, as well as a broad under- standing of the expectations at mile- stones and final deadlines. The simplified plans allow flexibility,

8 harvard business review July–August 1998

h ow t oyo t a i n t e g r at e s p r o d u c t d e v e l o p m e n tI D E A S AT W O R K

To prevent the chimney effect ’s political conflicts, engineers at the bucho level are regularly rotated to areas outside their expertise.

For the exclusive use of R. Nigaglioni, 2018.

This document is authorized for use only by Rolando Nigaglioni in 2018.

ucts that use common parts across platforms. Engineering checklists contain detailed information con- cerning any number of aspects, in- cluding functionality, manufactur- ability, government regulations, and reliability. The styling department, for example, has a checklist for the license-plate well that contains plate dimensions, bolt hole loca- tions, regulations on tilt angles and illumination for various world mar- kets, and restrictions on curvature radii. And every part of the car body has a separate manufacturing check- list that shows what angles will pro- duce a good part, what kinds of inter- faces avoid problems in assembly, and other guidelines.

Engineers use the checklists to guide the design throughout the de- velopment process. The checklists are particularly important for the intensive design reviews that every vehicle program undergoes. Hun- dreds of engineers come together to study a vehicle or prototype at key junctures, looking for problems and opportunities for improvement. What keeps these extremely large meetings from becoming chaotic is that all engineers come with a list of all the items they need to verify from their perspective. If the design conforms to the checklist, the part is highly likely to meet a certain level of functionality, manufacturability, quality, and reliability. If it does not, discrepancies between the check- lists and the design become the focal points of discus- sion among the divisions. The design review check- lists are another example of using written forms of communication to im- prove face-to-face meetings.

Once in place, design standards add predictabil- ity across vehicle subsys- tems, and between product design engineers and manufacturing engi- neers. The engineer responsible for audio speakers, for example, can take advantage of existing specifica- tions for door sizes and door compo- nents and can begin designing speak- ers without coordinating directly with the other engineers working on door components. As a result, Toy-

ota is able to bring new products to market quickly – as it demonstrated with the RAV4 mini-sport-utility vehicle, which was brought to mar- ket in 24 months, carved out a new product niche in Japan, but still drew on existing design standards for 80% of its makeup.

Engineering checklists also facil- itate organizational learning across generations of vehicles. Toyota trains its engineers not only to record prod- uct histories but also to abstract from that experience in order to update existing capabilities. When an engi- neer lear ns something new, the knowledge can be incorporated into the checklist and then applied across the company to every subsequent vehicle. Those lessons reside with the organization, not in one person’s head. If an engineer leaves, the knowledge he or she has gained is captured in the checklists and re- mains with the company. Just as standardization is the key to contin- uous improvement on the factory floor, standards are the basis for con- tinuous improvement in engineer- ing design.

Twist #1: Again, such standardiza- tion smacks of the kind of bureau- cratic approach that U.S. companies seem bent on avoiding. But rather than presenting design rules that have been imposed by a central staff, the checklists explicitly define cur- rent capabilities as understood by the responsible designers. They are

living documents: product and man- ufacturing engineers update the standards with every vehicle pro- gram. New information is quickly and efficiently disseminated through- out the organization and into inter- facing divisions, without any meet- ings taking place.

Twist #2: Toyota’s continuous and overlapping product cycles also help

harvard business review July–August 1998 9

h ow t oyo t a i n t e g r at e s p r o d u c t d e v e l o p m e n t I D E A S AT W O R K

common understanding, and contin- uous improvement, while hard dead- lines keep the project on track. The company thus gains the efficiencies offered by standards without stifling its engineers. The standards also save product developers the trouble of reinventing a new process for each individual project.

Twist #2: Another difference is that the standard work procedures are maintained by the people and de- partments that use them, not by a centralized staff that may be tempted to standardize for the sake of stan- dardization. As a result, standards are more likely to be simple and to the point, relevant and up-to-date. They are therefore more likely to be followed. In addition, the people who use the standards understand their intent, so deviations are per- fectly permissible as long as consis- tency (and thus predictability for other functions) is maintained. At Toyota, developing the product and designing standard development processes are considered to be insep- arable tasks.

Living Design Standards In the past, product developers often used standardized product rules to guide their work. Many companies, however, seem to have shied away from design standards in recent years. Engineers at automakers in the United States have told us time and again that design standards are largely ignored at their companies. Arguing that technology is changing too fast for standards to be valuable, they boast about “starting from a clean sheet of paper” in new prod- uct-development projects. (Test en- gineers, of course, rely on standards to ensure that the final product meets government regulations and other requirements, but those guide- lines concern the product’s function instead of providing information for the product’s design.) Design stan- dards appear to be archaic or stifling to companies that depend on inno- vation for success.

Toyota, however, still maintains voluminous books of engineering checklists to guide design work. These checklists act as the first cut at designing manufacturable prod-

When an engineer learns something new, the knowledge

is incorporated into a checklist and applied to all

the company’s vehicles.

For the exclusive use of R. Nigaglioni, 2018.

This document is authorized for use only by Rolando Nigaglioni in 2018.

How the Coordinating Mechanisms Work Together

Contin uous,

overla pping

produ ct cyc

lesStable, long-term employment

keep standards fresh. The company launches new vehicles on a regular basis, several times every year. It al- so has annual product renewals, and a major model change every three to four years, unlike other companies that stretch out their product cycles. Accordingly, standards are revisited every couple of months (as opposed to being used once and then put away for a couple of years); they nev- er become outdated. The frequent

changes to the checklists also give engineers continual opportunities to develop and hone their skills.

Managing Product Development as a System Together, these six mechanisms make up a whole system, each part supporting the others. Mentoring supervision serves mainly to build functional expertise, but it also teaches young engineers how to

write and interpret reports, work with chief engineers, and under- stand and use standards. The chief engineer’s prestige reinforces the importance of expertise while it also balances out the functional bent of the other engineers. The chief engi- neer also promotes mutual adjust- ment by providing the working in- structions for each vehicle program and by resolving cross-functional disagreements.

10 harvard business review July–August 1998

h ow t oyo t a i n t e g r at e s p r o d u c t d e v e l o p m e n tI D E A S AT W O R K

Stability and Power

The functional organization, with its intensive mentoring,

trains and socializes engineers in ways that foster in-depth

technical knowledge and efficient communication.

Three types of standards interact and support one another

to improve the speed of development while allowing

flexibility and building the company’s base of knowledge.

Levels of StandardizationIntegrative Social Processes

Standard Skills

intensive mentorship

local rotation

broad rotation at higher levels

Standardized Work Processes

consistent but minimal processes

standards maintained by departments

Design Standards

voluminous checklists

living documents

Integrative Leadership

chief engineer as lead designer

Mutual Adjustment

mix of written communication and

meetings

long-term socialization and development

Direct Supervision

working engineers

mentoring supervisors

Customer Focus

For the exclusive use of R. Nigaglioni, 2018.

This document is authorized for use only by Rolando Nigaglioni in 2018.

For their part, the three types of standards interact and support one another to boost the pace of develop- ment; at the same time, they allow flexibility and build Toyota’s base of knowledge. Without the other mechanisms providing reinforce- ment, each mechanism would not be nearly as effective. (See the exhibit “How the Coordinating Mecha-

nisms Work Together.”) Indeed, the two halves of Toyota’s

system – social processes and stan- dards – interact in powerful ways. The functional organization, with its intensive mentoring, trains and socializes engineers in ways that fos- ter in-depth technical knowledge and efficient communication. With- out deep tacit knowledge about how

to develop products, standardization would become a bureaucratic night- mare. In turn, the common use of the different standards makes all functions automatically aware of the constraints imposed by interfac- ing groups and gives focus to reports and meetings. Toyota shows that companies do not need to choose be- tween functional depth and cross- functional coordination – each can facilitate the other within the right environment.

Toyota’s balanced approach also benefits from basic company poli- cies that provide a foundation for the whole system. With a stable and long-term workforce, the company can afford to invest heavily in train- ing and socializing its engineers; it knows that the investment will pay off for many years. The company also places great emphasis on satis- fying customers. Most of its engi- neers in Japan, for example, are re- quired to sell cars door to door for a few weeks in their first year of hire. Both factors help discourage the functional loyalties that might other- wise afflict a company with Toyota’s structure.

These synergistic interactions give Toyota’s system its stability and power. They enable the auto- maker to integrate across projects as well as within them. Design stan- dards, for example, facilitate integra- tion across functions while promot- ing the use of common components in simultaneous projects, and pro- vide a ready base of knowledge for the next generation of products.

Implications for Other Companies Toyota’s mix of practices may not be right for other industries, or even for other companies in the auto indus- try. Different environments, differ- ent corporate cultures, and different circumstances mean that a com- pany’s product-development system must be uniquely designed to suit its distinct needs. Indeed, Toyota’s sys- tem is not necessarily perfect even for Toyota. Although the company has succeeded mightily with its new products in mass-market sedans and luxury cars – two well-defined seg- ments of the marketplace – it has re-

harvard business review July–August 1998 11

h ow t oyo t a i n t e g r at e s p r o d u c t d e v e l o p m e n t I D E A S AT W O R K

Little face-to-face contact.

Predominantly written communication.

Close supervision of engineers by managers.

Large barriers between functions.

No system design leader.

No rotation of engineers.

New development process with every vehicle.

Complex forms and bureaucratic procedures.

Obsolete, rigid design standards.

Reliance on meetings to accomplish tasks.

Predominantly oral communication.

Little supervision of engineers.

Weak functional expertise.

System design dispersed among team members.

Rotation at rapid and broad intervals.

Lengthy, detailed, rigid development schedules.

Making up procedures on each project.

No design standards.

Succinct written reports for most communication.

Meetings for intensive problem solving.

Technically astute functional supervisors who mentor, train, and develop their engineers.

Strong functions that are evaluated based on overall system performance.

Project leader as system designer, with limitations on authority.

Rotation on intervals that are longer than the typical product cycle, and only to positions that complement the engineers’ expertise.

Standard milestones – project leader decides timing, functions fill in details.

Standard forms and procedures that are simple, devised by the people who use them, and updated as needed.

Standards that are maintained by the people doing the work and that keep pace with current company capabilities.

How Toyota Avoids Extremes

Mutual Adjustment

Design Standards

Standard Work Processes

Direct Supervision

Integrative Leadership

Standard Skills

CHIMNEY EXTREME TOYOTA BALANCE COMMITTEE EXTREME

For the exclusive use of R. Nigaglioni, 2018.

This document is authorized for use only by Rolando Nigaglioni in 2018.

are not panaceas, and they do have significant drawbacks. One must weigh the benefits and drawbacks of a particular practice, including how it contributes to all aspects of inte- gration (including integration across projects) and how it affects other parts of the system.

Finally, the success of Toyota’s system rides squarely on the shoul- ders of its people. Successful product development requires highly compe- tent, highly skilled people with a lot of hands-on experience, deep techni- cal knowledge, and an eye for the overall system. When we look at all the things that Toyota does well, we find two foundations of its product- development system: chief engi- neers using their expertise to gain leadership, and functional engineers using their expertise to reduce the amount of communication, supervi- sion, trial and error, and confusion in the process. All the other coordinat- ing mechanisms and practices serve to help highly skilled designers do their job effectively. By contrast, many other companies seem to as- pire to develop systems “designed by geniuses to be run by idiots.” Toyota prefers to develop and rely on the skill of its personnel, and it shapes its product-development process around this central idea: people, not systems, design cars.

Reprint 98409 To place an order, call 1-800-988-0886.

acted late to the recent major shifts in consumer demand: first to mini- vans and then to sport-utility vehi- cles. So design standards and inter- nal socialization, for example, may make for nimble and innovative product development, but perhaps at the cost of discouraging some big leaps in thinking.

Nevertheless, we believe that Toyota’s system has important im- plications for other companies. First, integrated product-development processes should be developed and implemented as coherent systems. Individual best practices and tools are helpful, but their potential can be fully realized only if they are inte- grated into and reinforce the overall system. Toyota was fortunate in that it was able to develop its system over decades through an incremen- tal, almost unconscious, process of taking good ideas and adapting them to the existing structure. Other com- panies that conclude they are going down the wrong track and need a major overhaul of their product- development systems do not have the luxury of developing their sys- tem gradually over time. They will need to be much more conscious of designing a coherent system.

Second, well-designed systems should balance the demands of func- tional expertise and cross-functional coordination. The chart “How Toy- ota Avoids Extremes” describes fea- tures of the two opposing sides: the chimney extreme, characterized by

strong functional divisions, and the committee extreme, characterized by broad-based decision making and weak functional expertise. Toyota, for example, uses both written forms of communication and face-to-face contact to the extent that each is useful and efficient.

Achieving the proper balance, however, is no easy task. Many of Toyota’s current practices – such as an emphasis on written communica- tion, design standards, and the chief engineer – seem to have been stan- dard practice in the United States in the 1950s and earlier. But in the 1960s and 1970s, as U.S. automakers neglected their development processes, systems that were once sound and innovative gave way to bureaucracy, internal distrust, and other distractions that brought the companies close to the chimney ex- treme. In reaction, those companies seem to have swung toward the other end of the spectrum. Results in the short term have been encouraging, but the deficiencies of the commit- tee extreme may well appear soon. Some companies are discovering them already.

The key is to strike the appropri- ate balance for one’s situation. It may be perfectly appropriate in some circumstances to rely almost solely on meetings for communica- tion and problem solving or to aban- don standard procedures completely. But such practices are not good for all organizations at all times. They

12 harvard business review July–August 1998

h ow t oyo t a i n t e g r at e s p r o d u c t d e v e l o p m e n tI D E A S AT W O R K

For the exclusive use of R. Nigaglioni, 2018.

This document is authorized for use only by Rolando Nigaglioni in 2018.