Another Look at How Toyota Integrates Product Development

8/18/2019 Another Look at How Toyota Integrates Product Development

http://slidepdf.com/reader/full/another-look-at-how-toyota-integrates-product-development 1/18

Challenged by world-class competitors, manufacturing companies in theUnited States have undergone a renaissance in the last decade. Therenaissance started on the shop oor with an emphasis on built-in quality,the elimination of waste, and faster throughputs. ut attention quic!ly turned

upstream to product development, where "apanese companies wereoutperforming U.S. competitors on nearly every measure# speed to mar!et,design quality, product-design manufacturability, cost, and productivity.$bservers concluded that the !ey to "apanese success, and U.S. industry%swea!ness, was integration&both between product design andmanufacturing-process design, and with mar!eting, purchasing, 'nance, andother business functions.

( great many companies attac!ed the issue head on. Typical solutions weresuch product-development tools as quality function deployment and Taguchimethods. Companies also introduced organi)ational solutions* those

solutions ranged from !eeping the basic functional organi)ation intact andassigning people to temporary pro+ect teams to disbanding the functionalorgani)ation altogether in favor of organi)ing around products, as Chryslerdid in the early s. /0ere we use the term function broadly to mean thevarious groups of speciali)ed e1pertise required to ma!e new models wor!&including the engineering specialties within the design process, such aselectrical, body, or test engineering, as well as other business functions, suchas manufacturing and mar!eting.2

The new solutions have brought substantial improvements to the companiesand dramatic results in the mar!etplace. ut they have also created

problems of their own. Cross-functional coordination has improved, but at thecost of depth of !nowledge within functions, because people are spendingless time within their functions. $rgani)ational learning across pro+ects hasalso dropped as people rotate rapidly through positions. Standardi)ationacross products has su3ered because product teams have becomeautonomous. 4n organi)ations that combine functional and pro+ect-basedstructures, engineers are often torn between the orders of their functionalbosses on the one hand and the demands of pro+ect leaders on the other. (sthese new problems ta!e their toll, U.S. companies are beginning to see thee3ectiveness of their product-development systems plateau. 5ore important,that e3ectiveness seems to have leveled o3 far short of the best "apanese

companies.

This article e1plores how one of those companies, Toyota, manages itsvehicle-development process. 6e studied Toyota%s process for 've yearsthrough in-depth interviews at all levels of management. 4nterestingly, wefound that in many ways the company does not resemble what is oftenconsidered the model of "apanese product development&it has maintained afunctionally based organi)ation while achieving its impressive degree of



integration, and many of its practices are actually similar to those that U.S.companies employed during their manufacturing prime earlier in thiscentury.

6e can group Toyota%s managerial practices into si1 organi)ational

mechanisms. Three of them are primarily social processes# mutualad+ustment, close supervision, and integrative leadership from productheads. The other three are forms of standardi)ation# standard s!ills, standardwor! processes, and design standards. (lone, each mechanism wouldaccomplish little, but every piece has its own role and at the same timereinforces the others, unli!e many of the sophisticated tools and practices atcompanies in the United States, which tend to be implementedindependently.

Together, the mechanisms give Toyota a tightly lin!ed product-developmentsystem that achieves cross-functional coordination while still building

functional e1pertise. This balance allows the company to achieve integrationacross pro+ects and over time, as well as within pro+ects. U.S. companieshave concentrated on bringing the functions together within pro+ects, but asingle-minded focus on that goal can actually undermine attempts to shareinformation across pro+ects. Cross-functional teams, for e1ample, wor! wellwithin individual pro+ects, but the temporary, personal nature of these teamsma!es it hard for them to transmit information to teams on other pro+ects.

Toyota combines a highly formali)ed system with twists to ensure that eachpro+ect is e1ible and bene'ts from other pro+ects.

Toyota, by contrast, seems to go to the opposite organi)ational e1treme. 4trelies on highly formali)ed rules and standards, and puts limits on the use ofcross-functional teams. Such rigid policies can have enormous drawbac!s. Toavoid those drawbac!s, Toyota has added a number of twists to ensure thateach pro+ect has the e1ibility it needs and still bene'ts from what otherpro+ects have learned. The result is a deftly managed process that rivals thecompany%s famous production system, lean manufacturing, in e3ectiveness.

Coordination Based on Writing

$ne of the most powerful ways to coordinate one%s e3orts with those ofpeople in other functions is to tal! to them face to face. 4n this manner, eachparty gets the other%s point of view and can quic!ly ma!e ad+ustments to 'ndcommon ground. This mutual adjustment often ta!es the form of a meeting#a product designer and a manufacturing engineer, for e1ample, get togetherto discuss the e3ects that a proposed design for a particular car body wouldhave on the cost of production.



7irect contact between the members of di3erent functions is certainlyimportant&some say it is the essential ingredient in getting functionalgroups that have traditionally been at odds to wor! together. 4ndeed, manyobservers, managers, and engineers claim that face-to-face interaction is therichest, most appropriate form of communication for product development.

8umerous companies now colocate functional e1perts so that interaction canoccur with much greater ease and frequency. $ften these companies havedone away with written forms of communication because, as some claim,written reports and memos do not have the richness of information orinteractive qualities needed for product development.

5eetings, however, are costly in terms of time and e9ciency, and meetingtime increases with colocation. 5eetings usually involve limited value-addedwor! per person, and they easily lose focus and drag on longer thannecessary. :ngineers in companies we%ve visited often complain of nothaving enough time to get their engineering wor! done because of all the

meetings in their schedule.

Toyota, by contrast, does not co-locate engineers or assign them todedicated pro+ect teams. 5ost people reside within functional areas and aresimply assigned to wor! on pro+ects&often more than one at a time&led bypro+ect leaders. y rooting engineers in a function, the company ensures thatthe functions develop deep speciali)ed !nowledge and e1perience.

4n lieu of regularly scheduled meetings, the company emphasi)es writtencommunication. 6hen an issue surfaces that requires cross-functionalcoordination, the protocol is 'rst to write a report that presents the diagnosis

of the problem, !ey information, and recommendations, and then todistribute this document to the concerned parties. Usually, the report isaccompanied by either a phone call or a short meeting to highlight the !eypoints and emphasi)e the importance of the information. The recipient ise1pected to read and study the document and to o3er feedbac!, sometimesin the form of a separate written report. $ne or two iterations communicate agreat deal of information, and participants typically arrive at an agreementon most, if not all, items. 4f there are outstanding disagreements, then it%stime to hold a meeting to hammer out a decision face to face.

4n such problem-solving meetings, participants already understand the !ey

issues, are all wor!ing from a common set of data, and have thought aboutand prepared proposals and responses. The meeting can focus on solving thespeci'c problem without wasting time bringing people up to speed. ycontrast, at many U.S. companies, attendees often arrive at meetings havingdone little or no preparation. They can spend the 'rst half of the meeting +ustde'ning the issue, and responses are shoot-from-the-hip reactions to aproblem that people have had little time to thin! about.



Toyota ta!es its focused style of meeting quite seriously. $ne engineer wetal!ed to showed us his schedule for the day, which included two meetings atseparate times with the same group of people. 6hen as!ed why he wouldschedule separate meetings with this group, he e1plained that they neededtwo meetings to discuss two distinct problems. 4t was important not to

confuse the issues by combining them into one meeting.

$nce the writer of the original report has consulted with all interestedparties, he or she writes a 'nal version of the report that presents all sides of the question. The overall reporting process therefore has two bene'ts. ;irst,it documents and summari)es analysis and decision ma!ing in a convenientform for the rest of the organi)ation. Second, and more important, it forcesengineers in every function to gather opinions from other functions regardingthe rami'cations of the changes they are proposing.

Twist: (lthough Toyota often relies on written communication as the 'rst line

of attac! in solving problems, it does not su3er from the voluminouspaperwor! we associate with bureaucracy. 4n most cases, engineers writeshort, crisp reports on one side of si)e (< paper /roughly = >, the largestfa1able si)e2. The reports all follow the same format so that everyone !nowswhere to 'nd the de'nition of the problem, the responsible engineer anddepartment, the results of the analysis, and the recommendations. Thestandard format also helps engineers ma!e sure they have covered theimportant angles. The result is a clear statement of a problem and solutionsthat is accessible not only to people within a particular pro+ect but also tothose wor!ing on other pro+ects.

6riting these reports is a di9cult but useful s!ill, so the company gives itsengineers formal training in how to boil down what they want tocommunicate. Supervisors see to it that engineers do the appropriategroundwor! to ensure that all pertinent views are ta!en into consideration.

Toyota has also created a culture in which reading these reports is highlyvalued and essential to doing one%s +ob well. 4ndeed, we heard about acertain Toyota e1ecutive who refused to read any report longer than twopages.

Mentoring Supervisors

4n product development, supervision traditionally too! place within individualfunctions. :lectrical engineers, for e1ample, were supervised by otherelectrical engineers because only they fully understood the wor! involved.?ecently, some U.S. companies have e1perimented with cross-functionalteam-based organi)ations in order to force engineers to thin! beyond theneeds of their own function. Chrysler, for e1ample, is organi)ed around



product platforms rather than functions, and the platform team leader headsall product engineering in the platform.

Toyota, however, has not forgotten the value of instructive supervision withinfunctions. Supervisors and higher-level managers are deeply involved in the

details of engineering design. 4n fact, young engineers /anyone with lessthan ten years% e1perience2 must usually get approval from their functionalsupervisors not only for the designs they propose but also for each stepinvolved in the process of arriving at the 'nal design.

Supervisors are deeply involved in their subordinates% wor!, without givingorders.

The company depends on supervisors to build deep functional e1pertise in itsnew hires&e1pertise that then facilitates coordination across functions. utfunctional supervisors also teach engineers how to write reports, whom to

send the reports to, how to interpret reports from other functions, and how toprepare for meetings. 7irect supervision thus wor!s in concert with mutualad+ustment in order to promote coordination.

Twist: To (merican eyes, such intensive supervision would seem to be a !indof meddling that sti es the creativity and learning of new engineers andother specialists. U.S. companies are moving in the opposite direction asthey preach empowerment, with superiors acting as facilitators rather thanbosses. ut Toyota has succeeded in !eeping its supervision fresh andengaging, in two ways. @i!e Toyota%s supervisors on the factory oor,managers in product development are wor!ing engineers. 4nstead of merely

managing the engineering process, they hone their engineering s!ills, stayabreast of new technology, maintain their contacts and develop new ones,and remain involved in the creative process itself. ;unctional engineers arenot frustrated by the e1perience of wor!ing under someone less s!illed thanthey are. 4n many U.S. companies, by contrast, engineers who rise throughthe ran!s become managers who stop doing engineering wor!.

Aerhaps more important, Toyota%s managers seem to avoid ma!ing decisionsfor their subordinates. They rarely tell subordinates what to do and insteadanswer questions with questions. They force engineers to thin! about andunderstand the problem before pursuing an alternative, even if the

managers already !now the correct answer. 4t%s not a boss-subordinate oreven a coach-athlete relationship, but a student-mentor relationship.

Integrative Leaders

Aerhaps the most powerful way to integrate the wor! of people from diversespecialties is to have a leader with a broad overview of the whole. 5any U.S.



companies have recently been moving toward a heavyweight-project-management structure. 0eavyweight pro+ect managers coordinate all thespecialists from functional departments around a common pro+ect with acommon set of goals. Their authority in these matri1 organi)ations comesfrom their complete control over their particular pro+ect rather than from any

direct supervisory authority over the individual functions.

Toyota%s equivalent is the chief engineer. :ach chief engineer, based in oneof Toyota%s three vehicle-development centers /which oversee long-termplanning across pro+ects2, maintains full responsibility for a single vehicleprogram but wields no direct power over the functions.

4ndeed, Toyota%s chief engineers come close to matching what others havedescribed as the prototypical heavyweight pro+ect manager. efore attainingtheir position, they must demonstrate both e1emplary technical e1pertiseand uency in synthesi)ing technical !nowledge into clever, innovative

designs. Toyota%s managers feel strongly that only a good designer canevaluate the quality of someone else%s design. Chief engineers also need tobe able to conceptuali)e whole systems. 4t is one thing to understand themechanics of a bra!e system and another to apply that !nowledge toward anactual bra!e system design* but it is quite another thing to be able toconceptuali)e a bra!e system and visuali)e how it can be integrated with therest of the vehicle. y contrast, a number of companies with heavyweightproduct managers do not have such stringent technical requirements.

(ll chief engineers have a small sta3 of B to B engineers to assist them inmanaging the development process and in coordinating the wor! of the

functional specialties. The hundreds of other engineers on the pro+ect reportonly through the functional chain of command. The chief engineer has noformal authority over them, so he must persuadeD them to help him reali)ehis vision for the vehicle. $ne former chief engineer described the position asbeing the president of the vehicleD# +ust as the U.S. president heads thecountry but has no direct authority over legislation /beyond vetoes2, so achief engineer cannot dictate what functional engineers do. ut his e1tensivetechnical e1pertise wins him tremendous respect, even admiration, fromfunctional engineers&a !ey source of his enormous informal authority.

The limits on the chief engineers% power, despite their prestige, are real, and

the engineering e1pertise and equal ran! of the general managers in chargeof the functional areas can !eep chief engineers from ma!ing potentiallydangerous mista!es. ;or e1ample, in designing a new model of the Celicasports car several years ago, the styling department suggested a longerfront-quarter panel. The change would have increased the panel%s e1tensioninto the top of the front door, allowing the door to curve bac! at the top,thereby creating an angular and more e1citing loo!. The manufacturing



engineer assigned to door panels, however, opposed the change because thealtered panel would be di9cult to produce.

(fter assessing both sides, the chief engineer for the vehicle favored thealtered front panel. 8evertheless, the manufacturing engineer felt strongly

that the change was unwise. 4f Toyota had organi)ed around pro+ects ratherthan functions, styling would li!ely have gotten its way, and the car mightwell have su3ered production problems. ut because the chief engineer%sauthority was only informal, the manufacturing engineer was able to raisethe issue to the level of the general manager of manufacturing, who stronglychallenged the chief engineer. (fter substantial argument, the two sidesreached an innovative compromise that achieved the cutaway loo! thatstyling wanted with a satisfactory level of manufacturability.

Such incidents e1plain why one Toyota engineer, when as!ed what ma!es agood car, replied, @ots of con ict.D Con ict occurs when people from

di3erent functional areas clearly represent the issues from their perspective.4ts absence implies that some functional areas are being too accommodating&to the detriment of the pro+ect as a whole. Still, when managers resolvecon icts through organi)ational in uence, horse trading, or e1ecutive 'at,the results are often poor. 4t is the ability of chief engineers to see the broadpicture clearly&and the ability of functional managers to contain the chiefengineer%s enthusiasm&that leads to highly integrated designs. (nd whilethe chief engineers !eep individual pro+ects on trac!, the autonomousfunctional engineers and managers ensure that !nowledge and e1periencefrom other pro+ects are not forgotten in the current one.

Twist: Chief engineers do di3er in one important respect from even the bestheavyweight pro+ect managers. The latter typically delegate decision ma!ingto functional teams, while retaining authority over the team%s decisions andta!ing responsibility for implementing those decisions throughout thedevelopment process. 4f a heavyweight pro+ect manager doesn%t li!e adecision, he or she can veto it. y contrast, a chief engineer ta!es theinitiative by personally ma!ing !ey vehiclewide decisions. 0is authority overdesign decisions stems from the fact that the vehicle is quite clearly hiscar.D 0e is therefore less the manager of and more the lead designer on theoverall pro+ect.

( chief engineer is less the manager of and more the lead designer on apro+ect.

(s lead designer, chief engineers design /and subsequently manage2 theentire process of developing the product, and they personally articulate thevehicle concept that becomes the blueprint for the entire program. Thatconcept includes the ma+or dimensions of the vehicle* decisions on suchma+or systems as the transmission* the variety of models to be o3ered* the



characteristics of the target customer* sales pro+ections* and targets onweight, cost, and fuel economy. Chief engineers integrate the wor! of thefunctions by planning how all the parts will wor! together as a cohesivewhole, soliciting input from the various engineering, manufacturing, andmar!eting functions, of course. $nce a chief engineer has designed the

overall approach for a car, the di3erent functions 'll in the technical detailsthat are required to reali)e the vehicle concept.

Some of the remaining integration problems at U.S. companies may in factstem from a lac! of precisely this !ind of system design. :ven companieswith able heavyweight product managers tend to +ump directly from productconcept to the technical details of engineering design. They bypass, withoutgoing through, the very di9cult but important tas! of designing the overallvehicle system# planning how all the parts will wor! together as a cohesivewhole before sweating the 'ne details. (t Toyota, the chief engineer providesthe glue that binds the whole process together.

Standard Skills

:very company depends on highly s!illed engineers, designers, andtechnicians to bring a product to mar!et. $rgani)ations can coordinate theiractivities by giving each person within a specialty the same set of s!ills toaccomplish his or her tas!s. 6hen we !now what to e1pect of others becausethey are trained in a certain way, we can request speci'c services withrelatively little e3ort in coordination. 4n engineering, most U.S. companiesrely heavily on universities or speciali)ed training companies to provide theirpeople with the s!ills needed to do their +obs.

Toyota, by contrast, relies primarily on training within the company. 4t viewstraining as a !ey competency, worth developing internally rather thanoutsourcing. :ngineers receive most of their training through the intensivementoring involved in direct supervision, although the company also runs atraining center with instructors who are e1perienced Toyota engineers. Theprocess not only develops e1cellent engineers but also teaches new hires

Toyota%s distinct approach to developing the body, chassis, or other systemsin a vehicle.

(dditionally, Toyota rotates most of its engineers within only one function,unli!e U.S. companies, which tend to rotate their people among functions.

ody engineers, for e1ample, will wor! on di3erent auto-body subsystems/for e1ample, door hardware or outer panels2 for most, if not all, of theircareers. ecause most engineers rotate primarily within their engineeringfunction, they gain the e1perience that encourages standard wor!, ma!ingthe outputs of each functional group predictable to other functions. 4naddition, rotations generally occur at longer intervals than the typical



product cycle so that engineers can see and learn from the results of theirwor!.

That consistency over time means that the company%s engineers in themanufacturing division, for e1ample, need to spend less time and energy

communicating and coordinating with their counterparts in design becausethey learn what to e1pect from them. 4ndeed, Toyota 'rmly believes thatdeep e1pertise in engineering specialties is essential to its product-development system. 6e often heard such comments as, 4t ta!es ten yearsto ma!e a body engineerD in our conversations with the company%smanagers. 4n short, the widely held notion that "apanese companies rotatetheir personnel broadly and frequently simply does not apply to Toyota.

Twist #1: ?otating locally and building functional e1pertise would seem tocreate rigid functional boundaries, or chimneys, in which engineers wor! onlyto be the best in their function. (n electrical engineer, for e1ample, might

aim to develop the most elaborate electrical design possible, withoutthin!ing about how that design will wor! with the rest of the vehicle. ut wehave found that the so-called chimney e3ect is not the result of youngengineers being too loyal to their functions or too narrow-minded about whatcars need. ?ather, it is usually the result of e1perienced engineers andmanagers hoarding their !nowledge, which becomes the basis of their powerin an organi)ation rooted in functions.

To prevent the chimney e ect %s political con icts, engineers atthe bucho level are regularly rotated to areas outside their e1pertise.

To avoid such political con ict, Toyota ta!es care to rotate most of its seniorpeople broadly. :ngineers at the bucho level&which usually means the headof a functional division /for e1ample, power-train engineering for front-wheel-drive passenger cars2 with at least E years% e1perience&typically rotatewidely across the company to areas outside their e1pertise. Such movesforce buchos to rely heavily on the e1perts in their new area, building broadnetwor!s of mutual obligation. (t the same time, buchos bring their owne1perience, e1pertise, and networ! of contacts that they can use to facilitateintegration.

Twist # : uchos /and chief engineers2 encourage their people to see the

needs of the product as a whole, but Toyota also !eeps design engineersaware of the rami'cations of their decisions throughout the developmentprocess. These engineers retain responsibility for their parts of the car fromthe concept stage to the start of full production. ( door-systems engineer, fore1ample, wor!s with stylists to determine the concept of the door and thendevelops the detailed design by wor!ing with production engineers andoutside suppliers. The engineer also goes to the factory to be part of thelaunch team as the vehicle ramps up to full production.



Flexible Work Standards

The stereotypical bureaucratic way of coordinating wor! processes is tospecify in detail the content of each step in the process. Tas!s arepreprogrammed so that one group !nows what to e1pect from another andwhen to e1pect it, with little or no communication required. ;actories use this!ind of coordination e1tensively, standardi)ing the tas!s at each wor!stationto ensure that the wor! is done consistently and in a set amount of time. (llthe wor!stations can then be easily coordinated by a schedule.

5any U.S. companies have tried to apply this concept to productdevelopment, notably Feneral 5otors with its four-phase process. ( specialteam at F5 de'nes the process in great detail, telling each department whatit needs to do when, whom to send results to, what format the informationshould ta!e, and so on. The plan for the styling function alone covers thelength of one wall in a si)able conference room. The four-phase process isalmost never followed as its authors envisioned, however, because theprocess is so detailed that every vehicle program has e1ceptions that forcedesigners to deviate from the prescribed process&the real world resists suchintensive planning. 4n addition, a separate group develops and maintains thedetails of the standard process* as a result, the people who must follow theprocess do not have ownership of it, and the prescribed processes are notli!ely to be truly representative of the actual one. 4ndeed, the four-phaseprocess seems to do little to shorten cycle times or to bring other bene'tsthat such thorough planning aims to produce. Companies such as Feneral5otors face a dilemma# the more they attempt to de'ne the process ofproduct development, the less the organi)ation is able to carry out thatprocess properly.

Toyota, by contrast, has successfully standardi)ed much of its developmentprocess. Aroduct-engineering departments follow highly consistent processesfor developing subsystems within a vehicle. ?outine wor! procedures&suchas design blueprints, (< reports, and feedbac! forms for design reviews&arealso highly standardi)ed. The overall process of developing a vehicle followsregular milestones. 4ndeed, the suppliers we visited in "apan could describefrom memory Toyota%s vehicle-development process because it is soconsistent from model to model. :very model has a concept, stylingapproval, one or two prototype vehicles, two trial production runs, and 'nallya launch* and suppliers !now the appro1imate timing of each event. /;ormore on how Toyota uses standards to coordinate its wor! with suppliers, see

( Second @oo! at "apanese Aroduct 7evelopment,D by ?a+an ?. Gamath and "e3rey G. @i!er, 0 ? 8ovemberH7ecember I.2

Twist #1: 0ow does Toyota avoid the pitfalls that other companies havee1perienced with wor! standardsJ 6hen you tal! speci'cs with Toyota



engineers&such as how many prototypes are built and tested, when designsare 'nali)ed, or how long a particular phase ta!es&the response is typicallythat it varies case by case. The actual standardi)ed wor! plans are !ept to aminimum* they often 't on a single sheet of paper. The basic process in theeyes of the participants is very consistent from model to model, but the

implementation of the concept is individually designed for each vehicleprogram. 4ntense sociali)ation of engineers through on-the-+ob trainingcreates a deep understanding of every step, as well as a broadunderstanding of the e1pectations at milestones and 'nal deadlines. Thesimpli'ed plans allow e1ibility, common understanding, and continuousimprovement, while hard deadlines !eep the pro+ect on trac!. The companythus gains the e9ciencies o3ered by standards without sti ing its engineers.

The standards also save product developers the trouble of reinventing a newprocess for each individual pro+ect.

Twist # : (nother di3erence is that the standard wor! procedures are

maintained by the people and departments that use them, not by acentrali)ed sta3 that may be tempted to standardi)e for the sa!e ofstandardi)ation. (s a result, standards are more li!ely to be simple and tothe point, relevant and up-to-date. They are therefore more li!ely to befollowed. 4n addition, the people who use the standards understand theirintent, so deviations are perfectly permissible as long as consistency /andthus predictability for other functions2 is maintained. (t Toyota, developingthe product and designing standard development processes are consideredto be inseparable tas!s.

Living Design Standards

4n the past, product developers often used standardi)ed product rules toguide their wor!. 5any companies, however, seem to have shied away fromdesign standards in recent years. :ngineers at automa!ers in the UnitedStates have told us time and again that design standards are largely ignoredat their companies. (rguing that technology is changing too fast forstandards to be valuable, they boast about starting from a clean sheet ofpaperD in new product-development pro+ects. /Test engineers, of course, relyon standards to ensure that the 'nal product meets government regulationsand other requirements, but those guidelines concern the product%s functioninstead of providing information for the product%s design.2 7esign standardsappear to be archaic or sti ing to companies that depend on innovation forsuccess.

Toyota, however, still maintains voluminous boo!s of engineering chec!liststo guide design wor!. These chec!lists act as the 'rst cut at designingmanufacturable products that use common parts across platforms.:ngineering chec!lists contain detailed information concerning any number



of aspects, including functionality, manufacturability, governmentregulations, and reliability. The styling department, for e1ample, has achec!list for the license-plate well that contains plate dimensions, bolt holelocations, regulations on tilt angles and illumination for various worldmar!ets, and restrictions on curvature radii. (nd every part of the car body

has a separate manufacturing chec!list that shows what angles will producea good part, what !inds of interfaces avoid problems in assembly, and otherguidelines.

:ngineers use the chec!lists to guide the design throughout thedevelopment process. The chec!lists are particularly important for theintensive design reviews that every vehicle program undergoes. 0undreds ofengineers come together to study a vehicle or prototype at !ey +unctures,loo!ing for problems and opportunities for improvement. 6hat !eeps thesee1tremely large meetings from becoming chaotic is that all engineers comewith a list of all the items they need to verify from their perspective. 4f the

design conforms to the chec!list, the part is highly li!ely to meet a certainlevel of functionality, manufacturability, quality, and reliability. 4f it does not,discrepancies between the chec!lists and the design become the focal pointsof discussion among the divisions. The design review chec!lists are anothere1ample of using written forms of communication to improve face-to-facemeetings.

$nce in place, design standards add predictability across vehiclesubsystems, and between product design engineers and manufacturingengineers. The engineer responsible for audio spea!ers, for e1ample, canta!e advantage of e1isting speci'cations for door si)es and door components

and can begin designing spea!ers without coordinating directly with theother engineers wor!ing on door components. (s a result, Toyota is able tobring new products to mar!et quic!ly&as it demonstrated with the ?(KImini-sport-utility vehicle, which was brought to mar!et in EI months, carvedout a new product niche in "apan, but still drew on e1isting design standardsfor L M of its ma!eup.

:ngineering chec!lists also facilitate organi)ational learning acrossgenerations of vehicles. Toyota trains its engineers not only to record producthistories but also to abstract from that e1perience in order to update e1istingcapabilities. 6hen an engineer learns something new, the !nowledge can be

incorporated into the chec!list and then applied across the company to everysubsequent vehicle. Those lessons reside with the organi)ation, not in oneperson%s head. 4f an engineer leaves, the !nowledge he or she has gained iscaptured in the chec!lists and remains with the company. "ust asstandardi)ation is the !ey to continuous improvement on the factory oor,standards are the basis for continuous improvement in engineering design.



6hen an engineer learns something new, the !nowledge is incorporated intoa chec!list and applied to all the company%s vehicles.

Twist #1: (gain, such standardi)ation smac!s of the !ind of bureaucraticapproach that U.S. companies seem bent on avoiding. ut rather than

presenting design rules that have been imposed by a central sta3, thechec!lists e1plicitly de'ne current capabilities as understood by theresponsible designers. They are living documents# product andmanufacturing engineers update the standards with every vehicle program.8ew information is quic!ly and e9ciently disseminated throughout theorgani)ation and into interfacing divisions, without any meetings ta!ingplace.

Twist # : Toyota%s continuous and overlapping product cycles also help !eepstandards fresh. The company launches new vehicles on a regular basis,several times every year. 4t also has annual product renewals, and a ma+or

model change every three to four years, unli!e other companies that stretchout their product cycles. (ccordingly, standards are revisited every couple ofmonths /as opposed to being used once and then put away for a couple ofyears2* they never become outdated. The frequent changes to the chec!listsalso give engineers continual opportunities to develop and hone their s!ills.

Managing Product Development as a System

Together, these si1 mechanisms ma!e up a whole system, each partsupporting the others. 5entoring supervision serves mainly to buildfunctional e1pertise, but it also teaches young engineers how to write andinterpret reports, wor! with chief engineers, and understand and usestandards. The chief engineer%s prestige reinforces the importance ofe1pertise while it also balances out the functional bent of the otherengineers. The chief engineer also promotes mutual ad+ustment by providingthe wor!ing instructions for each vehicle program and by resolving cross-functional disagreements.

;or their part, the three types of standards interact and support one anotherto boost the pace of development* at the same time, they allow e1ibilityand build Toyota%s base of !nowledge. 6ithout the other mechanismsproviding reinforcement, each mechanism would not be nearly as e3ective./See the e1hibit 0ow the Coordinating 5echanisms 6or! Together.D2



0ow the Coordinating 5echanisms 6or! Together

4ndeed, the two halves of Toyota%s system&social processes and standards&interact in powerful ways. The functional organi)ation, with its intensivementoring, trains and sociali)es engineers in ways that foster in-depthtechnical !nowledge and e9cient communication. 6ithout deep tacit!nowledge about how to develop products, standardi)ation would become abureaucratic nightmare. 4n turn, the common use of the di3erent standardsma!es all functions automatically aware of the constraints imposed byinterfacing groups and gives focus to reports and meetings. Toyota showsthat companies do not need to choose between functional depth and cross-



functional coordination&each can facilitate the other within the rightenvironment.

Toyota%s balanced approach also bene'ts from basic company policies thatprovide a foundation for the whole system. 6ith a stable and long-term

wor!force, the company can a3ord to invest heavily in training andsociali)ing its engineers* it !nows that the investment will pay o3 for manyyears. The company also places great emphasis on satisfying customers.5ost of its engineers in "apan, for e1ample, are required to sell cars door todoor for a few wee!s in their 'rst year of hire. oth factors help discouragethe functional loyalties that might otherwise aNict a company with Toyota%sstructure.

These synergistic interactions give Toyota%s system its stability and power. They enable the auto-ma!er to integrate across pro+ects as well as withinthem. 7esign standards, for e1ample, facilitate integration across functions

while promoting the use of common components in simultaneous pro+ects,and provide a ready base of !nowledge for the ne1t generation of products.

Implications or !t"er Companies

Toyota%s mi1 of practices may not be right for other industries, or even forother companies in the auto industry. 7i3erent environments, di3erentcorporate cultures, and di3erent circumstances mean that a company%sproduct-development system must be uniquely designed to suit its distinctneeds. 4ndeed, Toyota%s system is not necessarily perfect even for Toyota.(lthough the company has succeeded mightily with its new products inmass-mar!et sedans and lu1ury cars&two well-de'ned segments of themar!etplace&it has reacted late to the recent ma+or shifts in consumerdemand# 'rst to mini-vans and then to sport-utility vehicles. So designstandards and internal sociali)ation, for e1ample, may ma!e for nimble andinnovative product development, but perhaps at the cost of discouragingsome big leaps in thin!ing.

8evertheless, we believe that Toyota%s system has important implications forother companies. ;irst, integrated product-development processes should bedeveloped and implemented as coherent systems. 4ndividual best practicesand tools are helpful, but their potential can be fully reali)ed only if they areintegrated into and reinforce the overall system. Toyota was fortunate in thatit was able to develop its system over decades through an incremental,almost unconscious, process of ta!ing good ideas and adapting them to thee1isting structure. $ther companies that conclude they are going down thewrong trac! and need a ma+or overhaul of their product-developmentsystems do not have the lu1ury of developing their system gradually over



time. They will need to be much more conscious of designing a coherentsystem.

Second, well-designed systems should balance the demands of functionale1pertise and cross-functional coordination. The chart 0ow Toyota (voids

:1tremesD describes features of the two opposing sides# the chimneye!treme, characteri)ed by strong functional divisions, and the committeee!treme, characteri)ed by broad-based decision ma!ing and wea! functionale1pertise. Toyota, for e1ample, uses both written forms of communicationand face-to-face contact to the e1tent that each is useful and e9cient.





0ow Toyota (voids :1tremes

(chieving the proper balance, however, is no easy tas!. 5any of Toyota%scurrent practices&such as an emphasis on written communication, designstandards, and the chief engineer&seem to have been standard practice in

the United States in the B s and earlier. ut in the O s and > s, asU.S. automa!ers neglected their development processes, systems that wereonce sound and innovative gave way to bureaucracy, internal distrust, andother distractions that brought the companies close to the chimney e1treme.4n reaction, those companies seem to have swung toward the other end ofthe spectrum. ?esults in the short term have been encouraging, but thede'ciencies of the committee e1treme may well appear soon. Somecompanies are discovering them already.

The !ey is to stri!e the appropriate balance for one%s situation. 4t may beperfectly appropriate in some circumstances to rely almost solely on

meetings for communication and problem solving or to abandon standardprocedures completely. ut such practices are not good for all organi)ationsat all times. They are not panaceas, and they do have signi'cant drawbac!s.$ne must weigh the bene'ts and drawbac!s of a particular practice,including how it contributes to all aspects of integration /includingintegration across pro+ects2 and how it a3ects other parts of the system.

;inally, the success of Toyota%s system rides squarely on the shoulders of itspeople. Successful product development requires highly competent, highlys!illed people with a lot of hands-on e1perience, deep technical !nowledge,and an eye for the overall system. 6hen we loo! at all the things that Toyota

does well, we 'nd two foundations of its product-development system# chiefengineers using their e1pertise to gain leadership, and functional engineersusing their e1pertise to reduce the amount of communication, supervision,trial and error, and confusion in the process. (ll the other coordinatingmechanisms and practices serve to help highly s!illed designers do their +obe3ectively. y contrast, many other companies seem to aspire to developsystems designed by geniuses to be run by idiots.D Toyota prefers todevelop and rely on the s!ill of its personnel, and it shapes its product-development process around this central idea# people, not systems, designcars.

Documents

Another Look at How Toyota Integrates Product Development