Creating high-performance product design teams

Creating High-Performance Product Design Teams

NATIONAL PRODUCTIVITY REVIEW / Summer 2000

47


© 2000 John Wiley & Sons, Inc.

by Bob Carroll

A consultant based in Scottsdale, Arizona, Bob Carroll has an extensive background in manufacturing and project management. He is a graduateof Harvard University and has published over 25 papers and book chapters and given numerous lectures on technology and self-managed workteams. He is a member of the New York Academy of Sciences. As a professional sculptor, he is also a member of the Copley Society of Bostonand the Arizona Artist Guild. His email address is [email protected].

* * *

The success that many companies have had using high-per-formance self-managed production work teams to improveproductivity has led a number of organizations to try to ap-ply this process to knowledge teams. Assuming that knowl-edge teams were essentially the same as production teams,they attempted to develop these knowledge teams by usingthe standard production self-management model. But usingthe production empowerment model to create high-perfor-mance knowledge teams did not work because knowledgeteams are significantly different from production teams. Theyare different in the nature of the tasks they handle and in theskill requirements of the individuals who must accomplishthose tasks. These differences mandate that a unique high-performance knowledge team model be developed for eachtype of knowledge team. At one specialized electronic equip-ment manufacturer, an operations project leader managedto turn a product design team into a high-performance prod-uct design team by tailoring concepts that he had previouslyused in developing high-performance production teams tofit a product design team.

47

The manufacturer employed about 5,500 people, includ-ing approximately 3,000 software, electrical, mechanical,manufacturing, and quality engineers. The company wasorganized into three main functional departments: engineer-ing, operations, and business (program management), alongwith various support departments, such as financial, humanresources, and facilities. Work was organized into projectsof ten to 100 members. If the project was in the productdesign phase, the engineering department had oversight andthe project leader was one of the design engineers. If theproduct was in the production phase, operations had over-sight and the project leader was a manufacturing engineer.When the operations project leader was first hired and as-signed to his first product design team, all teams were orga-nized in a very traditional way.

TRADITIONAL DESIGN TEAMS PROVE INEFFICIENT

The engineering department completely dominated theteam. Responsible for the total product design, the engi-

C REATING HIGH-PERFORMANCE PRODUCTDESIGN TEAMSBecause of the success of self-managed production work teams, a number of companieshave tried to extend these concepts to the development of high-performance knowledgeteams. They have not been successful, however, because knowledge teams are not thesame as production teams; each knowledge team requires its own unique high-perfor-mance model. This article, which shows how a knowledge team model was developed forand successfully applied to a product design team, describes a process that can be used toguide the development of any high-performance knowledge team. © 2000 John Wiley &Sons, Inc.

K N O W L E D G E W O R K E R S


48 Bob Carroll

neering project leader was aided by an assistance engineer-ing project leader, various engineering task leaders, and theother design disciplines. Each engineer accomplished hisor her assigned task in relative isolation. The task leadersintegrated the efforts of the engineers assigned to them andthe task leader’s integration was integrated again by the en-gineering project leader to produce the total design. Thequality of the output of this design team was determined byhow well the project leader could integrate those individualefforts into a coherent single design. Only the project leadercould feel totally responsible for the whole design, sincethe other members of the design team only contributed theirparticular effort. Although all the engineers on the productdesign team wanted to see their effort result in a superiorfinal design, it was difficult for them to feel responsible fora final design they had no control over or, in many cases,access to. This meant that the quality and success of thetotal design depended on the ability of a single or, at most, afew individuals.

The sequential processing of the design compoundedthe minimal interaction between the various segments ofthe traditional design team. Each engineering discipline wastime-phased to come on the design team when its expertisewas needed. This meant that as one group of engineers startedto complete their work, they would be working with the nextgroup of engineers who were just starting to intensify theireffort. For example, after the electrical design engineers haddeveloped the overall electrical design, selected their com-ponents, and had drawn up the schematic, they would workwith the packaging engineers to figure how the design wouldbe mechanically packaged: what size box, how many cir-cuit cards and connectors, and how it should be wired to-gether. Although there was some interaction between theelectrical engineers and the packaging engineers, the pack-aging engineers were essentially handed an electrical de-sign and told to package it. By the time the manufacturingengineer came on the design team full-time, most of theother engineers had already left the team.

This time-phasing of each of the design disciplines re-sulted in each group of engineers accepting what was givento them with little or no input. They could not change thedesign unless they could show it was wrong or show that achange would result in a major improvement in cost or per-formance. Any change that did not result in a major im-provement was ignored because it would delay the

completion of the design and increase design cost. So ev-eryone accepted what he or she was given, making the bestof it. This was particularly true for the manufacturing engi-neers, who essentially had the design thrown over the wallto them from design engineering and told to build it. Thisresulted in products that were difficult and, therefore, costlyto build. After working on a number of product design teams,the operations project leader got himself assigned to beingthe project leader on projects that were in the productionphase. This was more rewarding, since he was managingthe project and had a chance to improve how the work wasaccomplished.

DEVELOPING SELF-MANAGED PRODUCTION TEAMS

Although the operations project leader got more satis-faction from his work, he was still frustrated by having tobuild products that were designed to be state-of-the-art en-gineering products with very little attention to producibility.The very restrictive traditional manufacturing structure hehad to operate within added to the difficulty of buildingthese products. With this structure in place, there was littleor no room for the operators to make any improvements inhow the work was accomplished.

In this traditional structure the operations projectleader’s primary tasks were customer interface and overallproject planning and responsibility. He had a production taskleader (a manufacturing engineer) to manage the produc-tion effort and solve the technical problems on the line. Therewas a supervisor who took direction from the project leaderand the production task leader on project issues and tookinstructions from his or her general supervisor on disciplineand personnel issues. Group leaders under the supervisordirected the operators and informed their supervisor of anydisciplinary problems. There was a strong emphasis on mak-ing sure the operators followed all the rules—to be at theirworkstation and ready to start work at 7:30, to take no morethan 30 minutes for lunch and 10 minutes for break, and tonot question what they were told to do. If they found a prob-lem, they told their group leader, who told the manufactur-ing engineer so he or she could correct the problem. Thiswas the full extent of the operator’s involvement in the prob-lem-solving process

The operations project leader recognized early on thatthis traditional organizational structure was not conduciveto continuous improvement. It was bad enough that the prod-uct was usually difficult to build without an organizationalstructure that did not permit the operators to continuouslyimprove how the work was accomplished. He spent the nextseven years, with the approval and support of his sectionmanager, turning his projects into self-managed teams. Theseteams were so successful that the operations project leaderkept thinking of ways that these concepts could be used toimprove the way the product design teams operated. If the

The sequential processing of the design com-pounded the minimal interaction between the

various segments of the traditionaldesign team.



49

product design team could be made to function as effec-tively as the self-managed production teams, they could pro-duce a highly producible product. This would result in aproduct that was designed for maximum producibility be-ing built by a self-managed production team in the mostefficient manner. The importance of developing this high-performance product design team model significantly in-creased for the operations project leader when, after sevenyears, he was again assigned to a product design team.

SWITCHING TO CONCURRENT TEAMS

During the seven years that the operations project leaderhad worked on production teams, significant changes oc-curred in the company’s concept of how a product designteam should operate. During this period the company startedto lose more and more contracts. When the company inves-tigated why it was no longer cost-competitive, it found thatits major competitors had significantly reduced their pro-duction costs by designing products that could be built withautomated manufacturing equipment.

To meet this competition the company heavily investedin automated manufacturing equipment, believing that itwould help the company become cost-competitive veryquickly. But the company soon learned that it could not usethis equipment to build the existing designs. The automatedequipment required that all products be designed to veryprecise design rules. All the components selected and theway circuit boards were designed had to be compatible withthe automated parts placement and solder reflow equipment.Up to this point, there were no companywide design rules;each design team tended to produce a unique product de-sign. Since everything had been hand-assembled, almost anydesign could be built, albeit at a high cost. But if designedto fully utilize the automated production equipment, a cir-cuit board could be to built and preliminarily tested, in quan-tities of a hundred or more in less than an hour instead ofthe three to four days required with hand assembly.

Once the company realized that all products had to bedesigned to these very precise rules, it establishedcompanywide standardized design rules. This was notenough; the design engineers did not like their creativitybeing restricted by rules that made their tasks difficult. Theycontinued to use components that accomplished what theywanted, but were not compatible with the automated equip-ment. This meant that those components had to be hand-soldered. If they did not lay out the circuit board accordingto the rules, which was often the case, the whole circuit boardhad to be hand-soldered.

Realizing that the rules were not enough, the companymandated that all product design teams would be concur-rent product design teams. On a concurrent product designteam the manufacturing engineer is on the team full-timefrom the start of the design to ensure that the product is

designed to use advanced manufacturing technologies. Inaddition, the company established a formal design method-ology that detailed what must be accomplished during eachof the design phases and concluded each design phase witha review by the chief engineers and a checklist that had tobe filled out. This checklist required inputs on producibilityfrom the manufacturing members of the concurrent team ateach phase of that design.

Although the intention of these changes was good, thegoal was never achieved. The problem was that the cost toproduce a concurrent design was significantly higher thanthat of a traditional design. The reason the traditional de-sign teams only brought on engineers as they needed themwas to minimize design costs. Concurrent teams were veryexpensive; the manufacturing engineers had to be paid for afull week at the early stages of the design process when theyonly had a day or two worth of tasks. What was true formanufacturing was true for the other support engineers. Thisextra design cost should not have been a problem becausethe total cost to design and then manufacture a product withautomated equipment was significantly lower than the totalcost to design without concurrent design teams and use handassembly.

Knowing that it would be less expensive to produceproducts that were designed to utilize the automated equip-ment, the company reduced all its manufacturing bids, butit did not add in the additional design time required to pro-duce these designs. It used historical design times for thedesign bids that were based on traditional design teams. Noone wanted to admit that concurrent design teams cost more.Because of this, the engineering project leader had to con-tinually try to balance the management directive to have aconcurrent product design team with a budget that only al-lowed for a traditional team. Since the project leader wasmeasured each month on how well he or she was doing rela-tive to the budget and not on how concurrent the designteam was, he or she would tend to budget only the manufac-turing members and other support departments for the ac-tual tasks that were required of them. This meant that themanufacturing people would be budgeted for one or, at mosttwo, days a week. Because of this, the manufacturing engi-neer would have to be on three or four product design teamsto be fully budgeted. This often did not allow him to bearound the design engineers when they were making criti-cal design decisions. As a result, the design engineers

Once the company realized that all productshad to be designed to these very precise rules, it

established companywide standardizeddesign rules.


50 Bob Carroll

repeatedly would design in components that could not beinserted by the automated equipment. Unfortunately for themanufacturing engineer, when this occurred he or she wasblamed for not telling the design engineer that he was se-lecting the wrong component or laying out the circuit boardincorrectly. If this occurred a number of times, it adverselyaffected the manufacturing engineer’s career.

The operations project leader found this out the hardway. He was on three product design teams at once, whichdid not allow him enough time to really know what the en-gineers were designing. All he had time for was to attendteam meetings. When the first product from one of theseteams went to the automated factory he was in serioustrouble. Most of the circuit cards could not be built with theautomated equipment and had to be hand-assembled. Heknew at that point that he had better find a way to be on asingle product design team if he wanted to continue to moveforward in his career. Having developed a theoretical modelfor a high-performance product design team when he wasworking at developing high-performance production teams,he decided to make this model, at least the part that relatedto manufacturing, work.

WORKING TOWARD A HIGH-PERFORMANCE PRODUCTDESIGN TEAM MODEL

When the operations project leader reviewed how adesign team operated, he realized that the high-performanceself-managed production team model would not work for adesign team. A self-managed production team solves theproblem of ensuring that everyone on the team always haswork by cross-training the entire the team so each teammember can perform all the tasks required to produce thatproduct. That way if an operator completes a task, he or shecan start whatever task is next required to complete that seg-ment of work.

Cross-training is not possible on a product design team.Each design task must be accomplished by an engineer whohas spent many years acquiring the specialized educationand skills required to accomplish that task. It is difficult toimagine a digital electrical engineer designing a complexpiece of mechanical hardware or a chemical engineer de-signing a digital circuit. When the operations project leaderreflected on this inherent limitation to eliminating special-ization, he realized there was still the potential of using aform of task sharing to significantly improve the design pro-cess. The team could take the collective responsibility forthe final design and support each other by sharing the tasksthat were common to all engineers.

Probably 60 percent of an engineer’s time is consumedin doing tasks that are common to all engineers: research-ing information, contacting outside suppliers, ordering ma-terial required for the design, setting up design reviews, orhandling such business as generating budgets and sched-

ules. On a high-performance concurrent product designteam, as each discipline hit its peak activities the other mem-bers of the team, who were not fully engaged, could pitch into do these common tasks. This would enable the engineerswho had too much to do to spend most of their time doingthe portion of their tasks that only they could do.

This would eliminate the need for each function to staffthe project with part-timers and would fully utilize the othermembers of the team. As a result, the concurrent productdesign team would be able to produce an improved designat less cost than a traditional product design team.

Believing that he could not convince the engineeringdepartment to try this model since it went against traditionalwisdom, the operations project leader developed a smallerversion of it, just for manufacturing. In this model the op-erations project leader would become the assistant projectleader and the manufacturing engineer would support thedesign engineers by sharing common tasks.

The design project leader had two primary tasks: thetechnical and business management of the project. The tech-nical management relates to ensuring that all design require-ments are met. To accomplish this, the design project leadercontinously monitors and reviews the progress of his or herengineers to help solve or resolve any technical issue orconflicts. The business management of the design relates togenerating and then maintaining the schedules and budgetsneeded to ensure that the project is on schedule and on orunder budget. Since the design project leader’s workloadwas usually too much for a single person, he or she had anassistant project leader to help. Traditionally, the projectleader handled the technical management of the project andthe assistant project leader, who was an electrical engineer(as was the project leader), handled the business side. Theoperations project leader felt that he should manage thebusiness side of the project. This would eliminate the needfor an assistant project leader from the electrical engineer-ing department and allow the operations project leader tobe on the project full-time. This would save money, result ina better design, and would ease the transition from the de-sign phase to the production phase. At that time the opera-tions project leader would become the project leader andthe design engineering project leader would become the as-sistant project leader and support the technical problemsduring the early phases of production.

The problem was finding a project that would allowthis model to be tested. The operations project leader knewthe engineering department would be dead set against it.

Cross-training is not possible on a productdesign team.



51

But although the engineering department had a lot of say onhow a product design team must operate, the program man-ager had the final word. He or she came from the businessoffice and was responsible for ensuring that each disciplinework together and for defining its role on the team.

As luck would have it, the next product design teamthat the operations project leader was assigned to was idealfor implementing his model. The program manager had pre-viously worked for the operations project leader as his pro-duction task leader and had helped him develop theself-managed production teams. Moreover, the new projectrequired a lot of management attention. Five separate com-panies were partnered to develop a complex system for aspecial application. The operation project leader’s companywas to design and produce a customized computer to oper-ate the system. Since it was a joint effort, managing andcoordinating the project were critical.

The customer had imposed on each of the partners acommon budget and scheduling software package to man-age the effort. The customer also required that the entireproject be completely scheduled and budgeted the firstmonth after receipt of contract and that the budget/schedulebe updated by each partner monthly thereafter. Very fewpeople at the operations project leader’s company knew howto use this software package. Knowing that the project leaderwas buried in technical issues, the operations project leaderspent the time to master this budgeting/scheduling system.Then he proposed to the program manager that he be as-signed the assistant project leader’s position and do all thescheduling, budgeting, and other business activities. Theoperations project leader told the program manager that ifhe took on that roll he could be on the project full-time toensure that the design was producible and able to be built inthe automated production factory. This would eliminate theneed for engineering to assign an assistant project leaderand it would facilitate, upon completion of the design, thetransition of the project to production. Since the programmanager had worked with self-managed teams, he under-stood and concurred with what the operations project man-ager was trying to accomplish.

The operations project leader now had to find an activ-ity to employ his manufacturing engineer full-time on theteam. One of an electrical design engineer’s tasks is to re-search each of the components or categories of componentsto be used in the design to ensure that it meets all the oper-ating requirements of the design, is compatible with theautomated production equipment, and meets the design-to-cost goals. If the component meets these requirements, it isselected and entered into the design database. One of thedesign engineers is then assigned the task of maintainingthe overall project component list to ensure that commoncomponents are used wherever possible.

The design engineers hated this task; it was tedious andtook time away from the work they loved, designing elec-

tronic circuits. So the operations project leader assigned thistask to his manufacturing engineer. She also found it te-dious and, at first, did not like the idea of doing what sheconsidered to be someone else’s job. The operations projectleader explained his model of sharing common tasks andhow this task would allow her to monitor the design at theconception phase to ensure that all the designers were usingthe components required for automated assembly. It wouldalso give her an excellent knowledge of the physical char-acteristics of components, something that most of her fel-low manufacturing engineers did not possess. If she did agood job, she would probably be accepted as a member ofthis and future design teams.

In the past the manufacturing and other support peoplewere viewed by the design community as noncontributors,people who sat back and continually threw roadblocks inthe designers’ path by telling them what was not acceptable.If the designer asked them what was acceptable, they wouldsay that it was not their job to design. They were there tomake sure the design was done right. As the manufacturingengineer pitched in and completely took over the compo-nent research activities, the design engineers started to de-pend on her. Most of the design engineers were young, aswas the manufacturing engineer. This made it easier for themto accept her as one of them. Over time all the members ofthe design team viewed both the operations project leaderand his manufacturing engineer as essential members of thedesign team.

This made a significant difference in the quality of thefinal design. Since the manufacturing people were fully in-volved during the early conception stages, a very produc-ible design was created that was fully compatible with theautomated equipment. In addition, as the manufacturingengineer was entering the components into the design data-base, the operations project leader was receiving the com-ponent cost information that he needed for his design-to-costcalculations. With this information early on, he was able toinfluence the design engineers to make two major changesin the basic design approach. The first change resulted in anestimated 56 percent reduction in cost to produce the cus-tomized computer in quantities of 5,000; the second changeresulted in another 28 percent estimated cost reduction. Thiscould not have occurred if the manufacturing people hadnot been full-time members of the product design team.

Since the manufacturing people were fullyinvolved during the early conception stages, avery producible design was created that was

fully compatible with the automatedequipment.


52 Bob Carroll

Although this task-sharing experiment was very suc-cessful, the operations project leader felt it would have beengreatly enhanced if all the design disciplines had pitched into help in a similar manner. If he could accomplish this onhis next assignment, he felt there would be significant im-provements derived from task sharing.

Among the improvements to result from effective shar-ing of tasks:

Cost reductions: In traditional product design teams,as each discipline hits its peak activity, more people fromthe particular functional area are added. When a functionrequires only a portion of some person’s time to meet thatfunction’s peak activities, the individual is paid to be on theteam full-time or the team suffers delays while it waits forthat person’s time. Either way, any time people are added toa process it increases confusion, creates delays, and addscost. With all the engineers sharing common tasks, all thepart-time personnel could be eliminated, creating muchsmaller, tightly knit teams. This significantly reduces thecost to design a new product.

Reduced design cycle times: These smaller cohesivedesign teams, where all the members are engaged in all as-pects of the design, eliminate most of the delays associatedwith functional hand-offs. The elimination of these delaysmeans the product design cycle can be reduced. Reducedcycle time equals reduced cost and quicker time-to-marketwith new products.

Continuous learning and improving: When all theteam members are engaged in all aspects of the design, theyincrease their knowledge of the design itself, the total de-sign process, and each other’s activity. This results in indi-viduals who are continually expanding their individualknowledge, and who are continuously improving the designprocess. As future high-performance concurrent productdesign teams are staffed with individuals who have gonethrough this process, design cycle times will continue to bereduced.

Team building: The intensity of team cohesion is di-rectly proportional to the feeling of each of the membersthat all the other members are equally committed to the teamsuccess and are willing to do whatever is required to makethe team successful. Nothing demonstrates this better thanwhen everyone is willing to help each other accomplish theirtasks.

Improved designs: In both the traditional and con-current product design teams, the quality of the final de-sign depends on the ability of a single or, at most, a fewindividuals. In a high-performance product design team,

the final design is the result of an empowered design team.If the entire team is involved in the process, it brings acollective seeing and knowing that far exceeds that of anyindividual. This collective seeing and knowing should re-sult in a superior final design. When an expert works inisolation, there is a tendency to optimize his or her portionof the design, but the sum of these optimizations may notequal the best design. In some cases, it does the opposite.By working as a team, the team members learn how tooptimize their portion of the design in a fashion that opti-mizes the total design.

This process of seeing the design through someone else’seyes is sometimes quite subtle. When an expert is review-ing his or her area of expertise in a design, he sees it in aparticular way that reflects his education and experience.He knows the limits and the constraints that are part of hisexpertise. His teammates, who do not have this educationor experience, see it in a different way; they see it from theirperspective. They do not know what the expert’s limits andconstraints are. They only know how it affects their abilityto optimize their portion of the design. They then ask ques-tions that may seem naive to the expert, but that cause theexpert to look at the design in a way never thought of be-fore. Each starts to see the design through the eyes of eachof the other team members and, through those eyes, starts tosee what is required to create a superior design. The qualityof the output of this collective effort has to exceed the effortof a single design leader integrating the output of a numberof individual designers working in relative isolation fromeach other. Moreover, people working together as a team toaccomplish a whole task is more rewarding and, therefore,more motivating than working as an individual in relativeisolation to complete a portion of a task.

Although this high-performance model for product de-sign teams has many of the attributes of the high-perfor-mance model for self-managed production teams, it isdifferent in some essential features. It is different becausethe product design process is different. These differencesmandate that a different empowerment model be devel-oped—a model that is unique to this type of team, butwhose process for developing that model will be the samefor all knowledge teams. Organizational leaders who wantto take this approach must decide if empowerment willimprove the knowledge work group. If so, they must thendetermine the difference between the knowledge workgroup and the standard production empowerment model.Finally, they can develop an empowerment model specifi-cally for that work group. ■

Documents

Creating high-performance product design teams