Please read the attached case Medisys Corp: The IntensCare Product Development Team and answer the following questions. Organizing and Leading “Heavyweight” Development Teams - Read article attach

29 Organizing and Leading “Heavyweight"

Development Teams

KIM B. CLARK STEVEN C. WHEELWRIGHT

Effective product and process development requires the integration of specialized capabilities. Integrating is difficult in most circumstances, but is particularly challenging in large, mature firms with strong func tional groups, extensive specialization, large numbers of people, and multiple, ongoing operating pressures. In such firms, development projects are the exception rather than the primary focus of attention. Even for people working on development projects, years of ex perience and the established systems covering every thing from career paths to performance evaluation, and from reporting relationships to breadth of job defini tions-create both physical and organizational dis- tance from other people in the organization. The func tions themselves are organized in a way that creates further complications: the marketing organization is based on product families and market segments; engi neering around functional disciplines and technical fo cus; and manufacturing on a mix between functional and product market structures. The result is that in large, mature firms, organizing and leading an effec tive development effort is a major undertaking. This is especially true for organizations whose traditionally stable markets and competitive environments are threatened by new entrants, new technologies, and rap idly changing customer demands.

This article zeros in on one type of team struc ture"heavyweight” project teams—that seems par ticularly promising in today's fast-paced world yet is strikingly absent in many mature companies. Our re search shows that when managed effectively, heavy weight teams offer improved communication, stronger identification with and commitment to a project, and a focus on cross-functional problem solving. Our re search also reveals, however, that these teams are not so easily managed and contain unique issues and challenges.

Heavyweight project teams are one of four types of team structures. We begin by describing each of them briefly. We then explore heavyweight teams in detail, compare them with the alternative forms, and point out specific challenges and their solutions in managing the heavyweight team organization. We con clude with an example of the changes necessary in in dividual behavior for heavyweight teams to be effec tive. Although heavyweight teams are a different way of organizing, they are more than å new structure; they represent a fundamentally different way of working. To the extent that both the team members and the surrounding organization reorganize that phenome non, the heavyweight team begins to realize its full potential.

Reprinted with the permission of The Free Press, a Division of Simon & Schuster Adult Publishing Group, from Revolutionizing Prod uct Development: Quantum Leaps to Speed, Efficiency and Quality, by Steven C. Wheelwright and Kim B. Clark. Copyright © 1992 by Steven C. Wheelwright and Kim B. Clark.

419

420

MANAGING STRATEGIC INNOVATION AND CHANGE

TYPES OF DEVELOPMENT PROJECT TEAMS

Figure 29.1 illustrates the four dominant team struc tures we have observed in our studies of development projects: functional, lightweight, heavyweight, and au tonomous (or tiger). These forms are described below, along with their associated project leadership roles, strengths, and weaknesses. Heavyweight teams are ex amined in detail in the subsequent section.

Functional Team Structure In the traditional functional organization found in larg er, more mature firms, people are grouped principally by discipline, each working under the direction of a specialized subfunction manager and a senior function al manager. The different subfunctions and functions coordinate ideas through detailed specifications all parties agree to at the outset, and through occasional meetings where issues that cut across groups are dis

1. Functional Team Structure

2. Lightweight Team Structure

FMI FM I FM

Function FM I FMI 1x Manager

(FM) ENG MEGMKG

ENG MFG7MKG

Project Manager (PM)

Working Level

Area of Strong PM Influence

Liaison (L)

3. Heavyweight Team Structure

4. Autonomous Team Structure

EMI FM

FMI FML FM

Market

ENG MFG MGA

ENG MEGT MKG

Concept

Market

---

-ENE

Concept

Figure 29.1. Types of development teams.

MANAGING LINKAGES

421

tated by the unique market the development effort aims

for.

cussed. Over time, primary responsibility for the proj ect passes sequentially-although often not smooth ly-from one function to the next, a transfer frequently termed “throwing it over the wall."

The functional team structure has several advan tages and associated disadvantages. One strength is that those managers who control the project's re sources also control task performance in their func tional area; thus, responsibility and authority are usual ly aligned. However, tasks must be subdivided at the project's outset, i.e., the entire development process is decomposed into separable, somewhat independent ac tivities. But on most development efforts, not all re quired tasks are known at the outset, nor can they all be easily and realistically subdivided. Coordination and integration can suffer as a result.

Another major strength of this approach is that, because most career paths are functional in nature un til a general management level is reached, the work done on a project is judged, evaluated, and rewarded by the same subfunction and functional managers who make the decisions about career paths. The associated disadvantage is that individual contributions to a de velopment project tend to be judged largely indepen dently of overall project success. The traditional tenet cited is that individuals cannot be evaluated fairly on outcomes over which they have little or no control. But as a practical matter, that often means that no one di rectly involved in the details of the project is responsi- ble for the results finally achieved.

Finally, the functional project organization brings specialized expertise to bear on the key technical is sues. The same person or small group of people may be responsible for the design of a particular component or subsystem over a wide range of development ef forts. Thus the functions and subfunctions capture the benefits of prior experience and become the keepers of the organization's depth of knowledge while ensuring that it is systematically applied over time and across projects. The disadvantage is that every development project differs in its objective and performance re quirements, and it is unlikely that specialists develop ing a single component will do so very differently on one project than on another. The "best" component or subsystem is defined by technical parameters in the ar eas of their expertise rather than by overall system characteristics or specific customer requirements dic-

Lightweight Team Structure Like the functional structure, those assigned to the lightweight team reside physically in their functional areas, but each functional organization designates a li aison person to “represent” it on a project coordinating committee. These liaison representatives work with a "lightweight project manager,” usually a design engi neer or product marketing manager, who coordinates different functions' activities. This approach usually figures as an add-on to a traditional functional organi zation, with the functional liaison person having that role added to his or her other duties. The overall coor dination assignment of lightweight project manager, however, tends not to be present in the traditional func tional team structure.

The project manager is a "lightweight” in two im portant respects. First, he or she is generally a middle or junior-level person who, despite considerable exper tise, usually has little status or influence in the organi zation. Such people have spent a handful of years in a function, and this assignment is seen as a "broadening experience," a chance for them to move out of that function. Second, although they are responsible for in forming and coordinating the activities of the function al organizations, the key resources (including engi neers on the project) remain under the control of their respective functional managers. The lightweight proj ect manager does not have power to reassign people or reallocate resources, and instead confirms schedules, updates time lines, and expedites across groups. Typi cally, such project leaders spend no more than 25% of their time on a single project.

The primary strengths and weaknesses of the lightweight project team are those of the functional project structure. But now at least one person over the course of the project looks across functions and seeks to ensure that individual tasks-especially those on the critical path-get done in a timely fashion and that everyone is kept aware of potential cross-functional is sues and what is going on elsewhere on this particular project.

Thus, improved communication and coordination are what an organization expects when moving from a functional to a lightweight team structure. Yet, because

422

MANAGING STRATEGIC INNOVATION AND CHANGE

power still resides with the subfunction and functional managers, hopes for improved efficiency, speed, and project quality are seldom realized. Moreover, light weight project leaders find themselves tolerated at best, and often ignored and even preempted. This can easily become a “no-win" situation for the individual thus assigned

Heavyweight Team Structure In contrast to the lightweight setup, the heavyweight project manager has direct access to and responsibility for the work of all those involved in the project. Such leaders are “heavyweights” in two respects. First, they are senior managers within the organization; they may even outrank the functional managers. Hence, in addi tion to having expertise and experience, they also wield significant organizational clout. Second, heavy weight leaders have primary influence over the people working on the development effort and supervise their work directly through key functional people on the core teams. Often, the core group of people are dedi cated and physically co-located with the heavyweight project leader. However, the longer-term career devel opment of individual contributors continues to rest not with the project leader—although that heavyweight leaders makes significant input to individual perfor mance evaluations-but with the functional manager, because members are not assigned to a project team on a permanent basis.

The heavyweight team structure has a number of advantages and strengths, along with associated weak nesses. Because this team structure is observed much less frequently in practice and yet seems to have tremendous potential for a wide range of organiza tions, it will be discussed in detail in the next section.

sheet of paper"; it is not required to follow existing or ganizational practices and procedures, but allowed to create its own. This includes establishing incentives and rewards as well as norms for behavior. However, the team will be held fully accountable for the final re sults of the project: success or failure is its responsibil ity and no one else's.

The fundamental strength of the autonomous team structure is focus. Everything the individual team members and team leader do is concentrated on mak ing the project successful. Thus, tiger teams can excel at rapid, efficient new product and new process devel opment. They handle cross-functional integration in a particularly effective manner, possibly because they at tract and select team participants much more freely than the other project structures.

Tiger teams, however, take little or nothing as "given”; they are likely to expand the bounds of their project definition and tackle redesign of the entire product, its components, and subassemblies, rather than looking for opportunities to utilize existing mate rials, designs, and organizational relationships. Their solution may be unique, making it more difficult to fold the resulting product and process—and, in many cases, the team members themselves—back into the traditional organization upon project completion. As a consequence, tiger teams often become the birthplace of new business units, or they experience unusually high turnover following project completion.

Senior managers often become nervous at the prospects of a tiger team because they are asked to del egate much more responsibility and control to the team and its project leader than under any of the other orga nization structures. Unless clear guidelines have been established in advance, it is extremely difficult during the project for senior managers to make midcourse corrections or exercise substantial influence without destroying the team. More than one team has “gotten away” from senior management and created major problems.

Autonomous Team Structure With the autonomous team structure, often called the "tiger team,” individuals from the different functional areas are formally assigned, dedicated, and co-located to the project team. The project leader, a “heavy weight" in the organization, is given full control over the resources contributed by the different functional groups. Furthermore, that project leader becomes the sole evaluator of the contribution made by individual team members.

In essence, the autonomous team is given a "clean

THE HEAVYWEIGHT TEAM STRUCTURE

The best way to begin understanding the potential of heavyweight teams is to consider an example of their success, in this case, Motorola's experience in devel o ping its Bandit line of pagers.

MANAGING LINKAGES

423

The Bandit Pager Heavyweight Team This development team within the Motorola Commu nications Sector was given a project charter to develop an automated, on-shore, profitable production opera tion for its high-volume Bravo pager line. (This is the belt-worn pager that Motorola sold from the mid 1980s into the early 1990s.) The core team consisted of a heavyweight project leader and a handful of dedi cated and co-located individuals, who represented in dustrial engineering, robotics, process engineering, procurement, and product design/CIM. The need for these functions was dictated by the Bandit platform automation project and its focus on manufacturing technology with a minimal change in product technol ogy. In addition, human resource and accounting/fi nance representatives were part of the core team. The human resource person was particularly active early on as subteam positions were defined and jobs posted throughout Motorola's Communications Sector, and played an important subsequent role in training and development of operating support people. The ac counting/finance person was invaluable in “costing out” different options and performing detailed analy ses of options and choices identified during the course of the project.

An eighth member of the core team was a Hewlett Packard employee. Hewlett Packard was chosen as the vendor for the “software backplane," providing an HP 3000 computer and the integrated software communi cation network that linked individual automated work- stations, downloaded controls and instructions during production operations, and captured quality and other operating performance data. Because HP support was vital to the project's success, it was felt essential they be represented on the core team.

The core team was housed in a corner of the Mo torola Telecommunications engineering/manufactur ing facility. The team chose to enclose in glass the area where the automated production line was to be set up so that others in the factory could track the progress, offer suggestions, and adopt the lessons learned from it in their own production and engineering environments. The team called their project Bandit to indicate a will ingness to "take" ideas from literally anywhere.

The heavyweight project leader, Scott Shamlin, who was described by team members as "a crusader," "a renegade," and "a workaholic,” became the champi on for the Bandit effort. A hands-on manager who

played a major role in stimulating and facilitating communication across functions, he helped to articu late a vision of the Bandit line and to infuse it into the detailed work of the project team. His goal was to make sure the new manufacturing process worked for the pager line, but would provide real insight for many other production lines in Motorola's Communications Sector.

The Bandit core team started by creating a con tract book that established the blueprint and work plan for the team's efforts and its performance expectations; all core team members and senior management signed on to the document. Initially, the team's executive sponsor-although not formally identified as such was George Fisher, the Sector Executive. He made the original investment proposal to the Board of Directors and was an early champion and supporter, as well as direct supervisor in selecting the project leader and helping get the team underway. Subsequently, the vice president and general manager of the Paging Products division filled the role of executive sponsor.

Throughout the project, the heavyweight team took responsibility for the substance of its work, the means by which it was accomplished, and its results. The project was completed in 18 months as per the contract book, which represented about half the time of a normal project of such magnitude. Further, the au tomated production operation was up and running with process tolerances of five stigma (i.e., the degree of precision achieved by the manufacturing processes) at the end of 18 months. Ongoing production verified that the cost objectives (substantially reduced direct costs and improved profit margins) had indeed been met, and product reliability was even higher than the stan dards already achieved on the off-shore versions of the Bravo product. Finally, a variety of lessons were suc cessfully transferred to other parts of the Sector's oper ations, and additional heavyweight teams have proven the viability and robustness of the approach in Motoro la's business and further refined its effectiveness throughout the corporation.

The Challenge of Heavyweight Teams Motorola's experience underscores heavyweight teams' potential power, but it also makes clear that cre ating an effective heavyweight team capability is more than merely selecting a leader and forming a team. By their very nature-being product (or process) focused,

424

MANAGING STRATEGIC INNOVATION AND CHANGE

and needing strong, independent leadership, broad skills and cross-functional perspective, and clear mis sions--heavyweight teams may conflict with the func- tional organization and raise questions about senior management's influence and control. And even the ad vantages of the team approach bring with them poten tial disadvantages that may hurt development perfor mance if not recognized, and averted.

Take, for example, the advantages of ownership and commitment, one of the most striking advantages of the heavyweight team. Identifying with the product and creating a sense of esprit de corps motivate core team members to extend themselves and do what needs to be done to help the team succeed. But such teams sometimes expand the definition of their role and the scope of the project, and they get carried away with themselves and their abilities. We have seen heavyweight teams turn into autonomous tiger teams and go off on a tangent because senior executives gave insufficient direction and the bounds of the team were only vaguely specified at the outset. And even if the team stays focused, the rest of the organization may see themselves as “second class.” Although the core team may not make that distinction explicit, it happens because the team has responsibilities and authority be yond those commonly given to functional team mem bers. Thus, such projects inadvertently can become the “haves" and other, smaller projects the “have nots” with regard to key resources and management attention.

Support activities are particularly vulnerable to an excess of ownership and commitment. Often the heavyweight team will want the same control over sec ondary support activities as it has over the primary tasks performed by dedicated team members. When waiting for prototypes to be constructed, analytical tests to be performed, or quality assurance procedures to be conducted, the team's natural response is to "de mand” top priority from the support organization or to be allowed to go outside and subcontract to indepen dent groups. While these may sometimes be the appro priate choices, senior management should establish make-buy guidelines and clear priorities applicable to all projects—perhaps changing service levels provided by support groups (rather than maintaining the tradi tional emphasis on resource utilization)---or have sup port groups provide capacity and advisory technical services but let team members do more of the actual

task work in those support areas. Whatever actions the organization takes, the challenge is to achieve a bal ance between the needs of the individual project and the needs of the broader organization.

Another advantage the heavyweight team brings is the integration and integrity it provides through a system solution to a set of customer needs. Getting all of the components and subsystems to complement one another and to address effectively the fundamental re quirements of the core customer segment can result in a winning platform product and/or process. The team achieves an effective system design by using generalist skills applied by broadly trained team members, with fewer-specialists and, on occasion, less depth in indi vidual component solutions and technical problem solving.

The extent of these implications is aptly illustrat ed by the nature of the teams Clark and Fujimoto stud ied in the auto industry. They found that for U.S. auto firms in the mid-1980s, typical platform projects-or ganized under a traditional functional or lightweight team structure—entailed full-time work for several months by approximately 1,500 engineers. In contrast, a handful of Japanese platform projects-carried out by heavyweight teams.--utilized only 250 engineers working full-time for several months. The implications of 250 versus 1500 full-time equivalents (FTES) with regard to breadth of tasks, degree of specialization, and need for coordination are significant and help explain the differences in project results as measured by prod uct integrity, development cycle time, and engineering resource utilization.

But that lack of depth may disclose a disadvan tage. Some individual components or subassemblies may not attain the same level of technical excellence they would under a more traditional functional team structure. For instance, generalists may develop a windshield wiper system that is complementary with and integrated into the total car system and its core concept. But they also may embed in their design some potential weaknesses or flaws that might have been caught by a functional team of specialists who had de signed a long series of windshield wipers. To counter this potential disadvantage, many organizations order more testing of completed units to discover such possi ble flaws and have components and subassemblies re viewed by expert specialists. In some cases, the quality assurance function has expanded its role to make sure

MANAGING LINKAGES

425

sufficient technical specialists review designs at ap propriate points so that such weaknesses can be minimized.

likely to be very successful over the next three to five years, Industries and settings where such a charter might be found would include a microprocessor being developed for a new computer system, a diesel engine for the heavy equipment industry, or a certain type of slitting and folding piece of equipment for the newspa per printing press industry. Even in a medical diagnos tics business with hundreds of customers, a goal of "capturing 30% of market purchases in the second 12 months during which the product is offered” sets a clear charter for the team.

Managing the Challenges of

Heavyweight Teams Problems with depth in technical solutions and alloca tions of support resources suggest the tension that ex ists between heavyweight teams and the functional groups where much of the work gets done. The prob lem with the teams exceeding their bounds reflects, in part, how teams manage themselves, in part, how boundaries are set, and, in part, the ongoing relation ship between the team and senior management. Deal ing with these issues requires mechanisms and prac tices that reinforce the team's basic thrust--ownership, focus, system architecture, integrity and yet improve its ability to take advantage of the strengths of the sup- porting functional organization-technical depth, con sistency across projects, senior management direction. We have grouped the mechanisms and problems into six categories of management action: the project char ter, the contract, staffing, leadership, team responsibil ity, and the executive sponsor.

THE CONTRACT BOOK Whereas a charter lays out the mission in broad terms, the contract book defines, in detail, the basic plan to achieve the stated goal. A contract book is created as soon as the core team and heavyweight project leader have been designated and given the charter by senior management. Basically, the team develops its own de tailed work plan for conducting the project, estimates the resources required, and outlines the results to be achieved and against which it is willing to be evaluat ed. (The table of contents of a typical heavyweight team contract book are shown in Table 29.1.) Such documents range from 25 to 100 pages, depending on the complexity of the project and level of detail desired by the team and senior management before proceed ing. A common practice following negotiation and ac ceptance of this contract is for the individuals from the team and senior management to sign the contract book as an indication of their commitment to honor the plan and achieve those results.

The core team may take anywhere from a long week to a few months to create and complete the con

THE PROJECT CHARTER A heavyweight project team needs a clear mission. A way to capture that mission concisely is in an explicit, measurable project charter that sets broad performance objectives and usually is articulated even before the core team is selected. Thus, joining the core team in cludes accepting the charter established by senior management. A typical charter for a heavyweight proj ect would be the following:

The resulting product will be selected and ramped by Company X during Quarter 4 of calendar year 1991, at a minimum of a 20% gross margin.

Table 29.1. Heavyweight Team, Contract Book Major Sections

This charter is representative of an industrial products firm whose product goes into a system sold by its customers. Company X is the leading customer for a certain family of products, and this project is ded icated to developing the next generation platform of fering in that family. If the heavyweight program re sults in that platform product being chosen by the leading customer in the segment by a certain date and at a certain gross margin, it will have demonstrated that the next generation platform is not only viable, but

Executive summary Business plan and purposes Development plan

Schedule Materials

Resources Produce design plan Quality plan Manufacturing plan Project deliverables Performance measurement and incentives

426

MANAGING STRATEGIC INNOVATION AND CHANGE

tract book; Motorola, for example, after several years of experience, has decided that a maximum of seven days should be allowed for this activity. Having watched other heavyweight teams--particularly in or ganizations with no prior experience in using such a structure—take up to several months, we can appreci ate why Motorola has nicknamed this the “blitz phase” and decided that the time allowed should be kept to a minimum.

STAFFING As suggested in Figure 29.1, a heavyweight team in cludes a group of core cross-functional team members who are dedicated (and usually physically co-located) for the duration of the development effort. Typically there is one core team member from each primary function of the organization; for instance, in several electronics firms we have observed core teams consist ing of six functional participantsmdesign engineering, marketing, quality assurance, manufacturing, finance, and human resources. (Occasionally, design will be represented by two core team members, one each for hardware and software engineering.) Individually, core team members represent their functions and provide leadership for their function's inputs to the project. Collectively, they constitute a management team that works under the direction of the heavyweight project manager and takes responsibility for managing the overall development effort.

While other participants--especially from design engineering early on and manufacturing later on—may frequently be dedicated to a heavyweight team for sev eral months, they usually are not made part of the core team though they may well be co-located and, over time, develop the same level of ownership and com mitment to the project as core team members. The pri mary difference is that the core team manages the total project and the coordination and integration of individ ual functional efforts, whereas other dedicated team members work primarily within a single function or subfunction.

Whether these temporarily dedicated team mem bers are actually part of the core team is an issue firms handle in different ways, but those with considerable experience tend to distinguish between core and other dedicated (and often co-located) team members. The difference is one of management responsibility for the core group that is not shared equally by the others.

Also, it is primarily the half a dozen members of the core group who will be dedicated throughout the proj ect, with other contributors having a portion of their time reassigned before this heavyweight project is completed.

Whether physical colocation is essential is like wise questioned in such teams. We have seen it work both ways. Given the complexity of development proj ects, and especially the uncertainty and ambiguity of ten associated with those assigned to heavyweight teams, physical colocation is preferable to even the best of on-line communication approaches. Problems that arise in real time are much more likely to be ad dressed effectively with all of the functions represent ed and present than when they are separate and must either wait for a periodic meeting or use remote communication links to open up cross-functional discussions.

A final issue is whether an individual can be a core team member on more than one heavyweight team simultaneously. If the rule for a core team mem ber is that 70% or more of their time must be spent on the heavyweight project, then the answer to this ques tion is no. Frequently, however, a choice must be made between someone being on two core teams-for exam ple, from the finance or human resource function-or putting a different individual on one of those teams who has neither the experience nor stature to be a full peer with the other core team members. Most experi enced organizations we have seen opt to put the same person on two teams to ensure the peer relationship and level of contribution required, even though it means having one person on two teams and with two desks. They then work diligently to develop other peo ple in the function so that multiple team assignments will not be necessary in the future.

Sometimes multiple assignments will also be jus tified on the basis that a-function such as finance does not need a full-time person on a project. In most in stances, however, a variety of potential value-adding tasks exist that are broader than finance's traditional contribution. A person largely dedicated to the core team will search for those opportunities and the project will be better because of it. The risk of allowing core team members to be assigned to multiple projects is that they are neither available when their inputs are most needed nor as committed to project success as their peers. They become secondary core team mem

MANAGING LINKAGES

427

bers, and the full potential of the heavyweight team structure fails to be realized.

PROJECT LEADERSHIP Heavyweight teams require a distinctive style of lead ership. A number of differences between lightweight and heavyweight project managers are highlighted in Figure 29.2. Three of those are particularly distinctive. First, a heavyweight leader managers, leads, and eval uates other members of the core team, and is also the person to whom the core team reports throughout the project's duration. Another characteristic is that rather than being either neutral or a facilitator with regard to problem solving and conflict resolution, these leaders see themselves as championing the basic concept around which the platform product and/or process is being shaped. They make sure that those who work on subtasks of the project understand that concept. Thus they play a central role in ensuring the system integrity of the final product and/or process.

Finally, the heavyweight project manager carries out his or her role in a very different fashion than the lightweight project manager. Most lightweights spend the bulk of their time working at a desk, with paper. They revise schedules, get frequent updates, and en courage people to meet previously agreed upon dead lines. The heavyweight project manager spends little time at a desk, is out talking to project contributors,

and makes sure that decisions are made and imple mented whenever and wherever needed. Some of the ways in which the heavyweight project manager achieves project results are highlighted by the five roles illustrated in Table 29.2 for a heavyweight proj ect manager on a platform development project in the auto industry.

The first role of the heavyweight project man ager is to provide for the team a direct interpretation of the market and customer needs. This involves gathering market data directly from customers, dealers, and in dustry shows, as well as through systematic study and contact with the firm's marketing organization. A sec ond role is to become a multilingual translator, not just taking marketing information to the various functions involved in the project, but being fluent in the language of each of those functions and making sure the transla tion and communication going on among the func tions--particularly between customer needs and prod uct specifications--are done effectively,

A third role is the direct engineering manager, or chestrating, directing, and coordinating the various en gineering subfunctions. Given the size of many devel opment programs and the number of types of engineering disciplines involved, the project manager must be able to work directly with each engineering subfunction on a day-to-day basis and ensure that their work will indeed integrate and support that of others,

Lightweight (Limited)

Heavyweight (extensive)

Span of coordination responsibilities Duration of Responsibilities Responsible for specs, cost, layout, components Working level contact with engineers Direct contact with customers Multilingual/multi-disciplined skills Role in conflict resolution Marketing imagination/concept champion Influence in: engineering

marketing

manufacturing Figure 29.2. Project manager profile.

I TT TT TTT

428

MANAGING STRATEGIC INNOVATION AND CHANGE

Table 29.2. The Heavyweight Project Manager

Role

Description

Direct market interpreter

Multilingual translator

"Direct" engineering manager

Firsthand information, dealer visits, auto shows, has own marketing budget, market study team,

direct contact and discussions with customers Fluency in language of customers, engineers, marketers, stylists; translator between customer

experience/requirements and engineering specifications Direct contact, orchestra conductor, evangelist of Direct contact, orchestra conductor, evangelist of conceptual integrity and coordinator of

component development; direct eye-to-eye discussions with working level engineers; shows up

in drafting room, looks over engineers’ shoulders Out of the office, not too many meetings, not too much paperwork, face-to-face communication,

conflict resolution manager Concept guardian, confronts conflicts, not only reacts but implements own philosophy, ultimate

decision maker, coordination of details and creation of harmony

Program manager in motion"

Concept infuser

so the chosen product concept can be effectively executed.

A fourth role is best described as staying in mo tion: out of the office conducting face-to-face sessions and highlighting and resolving potential conflicts as soon as possible. Part of this role entails energizing and pacing the overall effort and its key subparts. A fi nal role is that of concept champion. Here the heavy weight project manager becomes the guardian of the concept and not only reacts and responds to the inter ests of others, but also sees that the choices made are consistent and in harmony with the basic concept. This requires a careful blend of communication and teach ing skills so that individual contributors and their groups understand the core concept, and sufficient conflict resolution skills to ensure that any tough is sues are addressed in a timely fashion.

It should be apparent from this description that heavyweight project managers earn the respect and right to carry out these roles based on prior experience, carefully developed skills, and status earned over time, rather than simply being designated “leader” by senior management. A qualified heavyweight project manag er is a prerequisite to an effective heavyweight team structure.

marketing is responsible for ensuring that appropriate marketing expertise is brought to the project, that a marketing perspective is provided on all key issues, that project sub-objectives dependent on the marketing function are met in a timely fashion, and that market ing issues that impact other functions are raised proac tively within the team.

But each core team member also wears a team hat. In addition to representing a function, each mem ber shares responsibility with the heavyweight project manager for the procedures followed by the team, and for the overall results that those procedures deliver. The core team is accountable for the success of the

Table 29.3. Responsibilities of Heavyweight Core Team Members

Functional Hat Accountabilities

Ensuring functional expertise on the project Representing the functional perspective on the project Ensuring that subobjectives are met that depend on their

function Ensuring that functional issues impacting the team are raised

proactively within the team, Team Hat Accountabilities

Sharing responsibility for team results Reconstituting tasks and content Establishing reporting and other organizational relationships Participating in monitoring and improving team performance Sharing responsibility for ensuring effective team processes Examining issues from an executive point of view

(Answering the question, “Is this the appropriate

business response for the company?") Understanding, recognizing, and responsibly challenging the

boundaries of the project and team process

TEAM MEMBER RESPONSIBILITIES Heavyweight team members have responsibilities be yond their usual functional assignment. As illustrated in Table 29.3, these are of two primary types. Func tional hat responsibilities are those accepted by the in dividual core team member as a representative of his or her function. For example, the core team member from

MANAGING LINKAGES

429

the executive sponsor expects to provide oversight and be consulted; these areas are of great concern to the en tire executive staff and team actions may well raise policy issues for the larger organization. In this firm, the executive staff wants to maintain some control over:

project, and it can blame no one but itself if it fails to manage the project, execute the tasks, and deliver the performance agreed upon at the outset.

Finally, beyond being accountable for tasks in their own function, core team members are responsible for how those tasks are subdivided, organized, and ac complished. Unlike the traditional functional develop ment structure, which takes as given the subdivision of tasks and the means by which those tasks will be con ducted and completed, the core heavyweight team is given the power and responsibility to change the sub stance of those tasks to improve the performance of the project. Since this is a role that core team members do not play under a lightweight or functional team struc ture, it is often the most difficult for them to accept ful ly and learn to apply. It is essential, however, if the heavyweight team is to realize its full potential. .

resource commitment-head count, fixed costs, and major expenses outside the approved contract book

plan; pricing for major customers and major accounts; potential slips in major milestone dates (the execu tive sponsor wants early warning and recovery plans); plans for transitioning from development project to operating status; thorough reviews at major milestones or every three months, whichever occurs sooner;

review of incentive rewards that have company-wide implications for consistency and equity; and cross-project issues such as resource optimization, prioritization, and balance.

Identifying such areas at the outset can help the executive sponsor and the core team better carry out their assigned responsibilities. It also helps other exec utives feel more comfortable working through the ex ecutive sponsor, since they know these “boundary is sues” have been articulated and are jointly understood.

THE EXECUTIVE SPONSOR With so much more accountability delegated to the project team, establishing effective relationships with senior management requires special mechanisms. Se nior management needs to retain the ability to guide the project and its leader while empowering the team to lead and act, a responsibility usually taken by an execu tive sponsor--typically the vice president of engineer ing, marketing, or manufacturing for the business unit. This sponsor becomes the coach and mentor for the heavyweight project leader and core team, and seeks to maintain close, ongoing contact with the team's efforts. In addition, the executive sponsor serves as a liaison. If other members of senior management- including the functional heads have concerns or inputs to voice, or need current information on project status, these are communicated through the executive sponsor. This re duces the number of mixed signals received by the team and clarifies for the organization the reporting and eval uation relationship between the team and senior man agement. It also encourages the executive sponsor to set appropriate limits and bounds on the team so that orga nizational surprises are avoided.

Often the executive sponsor and core team identi fy those areas where the team clearly has decision making power and control, and they distinguish them

from areas requiring review. An electronics firm that has used heavyweight teams for some time dedicates one meeting early on between the executive sponsor and the core team to generating a list of areas where

THE NECESSITY OF FUNDAMENTAL CHANGE

Compared to a traditional functional organization, cre ating a team that is "heavy one with effective lead ership, strong problem-solving skills and the ability to integrate across functions—requires basic changes in the way development works. But it also requires change in the fundamental behavior of engineers, de signers, manufacturers, and marketers in their day-to day work. An episode in a computer company with no previous experience with heavyweight teams illus trates the depth of change required to realize fully these teams' power.?

Two teams, A and B, were charged with develop ment of a small computer system and had market intro duction targets within the next 12 months. While each

430

MANAGING STRATEGIC INNOVATION AND CHANGE

core team was co-located and held regular meetings, there was one overlapping core team member (from fi nance/accounting). Each team was charged with devel oping a new computer system for their individual tar get markets but by chance, both products were to use an identical, custom-designed microprocessor chip in addition to other unique and standard chips.

The challenge of changing behavior in creating an effective heavyweight team structure was highlight ed when each team sent this identical, custom designed chip—the "supercontroller”--to the vendor for pilot production. The vendor quoted a 20-week turnaround to both teams. At that time, the supercon troller chip was already on the critical path for Team B, with a planned turnaround of 11 weeks. Thus, every week saved on that chip would save one week in the overall project schedule, and Team B already suspect ed that it would be late in meeting its initial market in troduction target date. When the 20-week vendor lead time issue first came up in a Team B meeting, Jim, the core team member from engineering, responded very much as he had on prior, functionally structured devel opment efforts: because initial prototypes were engi neering's responsibility, he reported that they were working on accelerating the delivery date, but that the vendor was a large company, with whom the computer manufacturer did substantial business, and known for its slowness. Suggestions from other core team mem bers on how to accelerate the delivery were politely re buffed, including one to have a senior executive con tact their counterpart at the vendor. Jim knew the traditional approach to such issues and did not per ceive a need, responsibility, or authority to alter it sig nificantly.

For Team A, the original quote of 20-week turn around still left a little slack, and thus initially the su percontroller chip was not on the critical path. Within a couple of weeks, however, it was, given other changes in the activities and schedule, and the issue was imme diately raised at the team's weekly meeting. Fred, the core team member from manufacturing (who histori cally would not have been involved in an early engi neering prototype), stated that he thought the turn around time quoted was too long and that he would try to reduce it. At the next meeting, Fred brought some good news: through discussions with the vendor, he had been able to get a commitment that pulled in the delivery of the supercontroller chip by 11 weeks! Fur

thermore, Fred thought that the quote might be re duced even further by a phone call from one of the computer manufacturer's senior executives to a contact of his at the vendor.

Two days later, at a regular Team B meeting, the supercontroller chip again came up during the status review, and no change from the original schedule was identified. Since the finance person, Ann, served on both teams and had been present at Team A's meeting, she described Team A's success in reducing the cycle time. Jim responded that he was aware that Team A had made such efforts, but that the information was not correct, and the original 20-week delivery date still held. Furthermore, Jim indicated that Fred's efforts (from Team A) had caused some uncertainty and dis ruption internally, and in the future it was important that Team A not take such initiatives before coordinat ing with Team B. Jim stated that this was particularly true when an outside vendor was involved, and he closed the topic by saying that a meeting to clear up the situation would be held that afternoon with Fred from Team A and Team B’s engineering and purchas ing people.

The next afternoon, at his Team A meeting, Fred confirmed the accelerated delivery schedule for the su percontroller chip. Eleven weeks had indeed been clipped out of the schedule to the benefit of both Teams A and B. Subsequently, Jim confirmed the re vised schedule would apply to his team as well, al though he was displeased that Fred had abrogated "standard operating procedure” to achieve it. Curious about the differences in perspective, Ann decided to learn more about why Team A had identified an ob stacle and removed it from its path, yet Team B had identified an identical obstacle and failed to move it at all.

As Fred pointed out, Jim was the engineering manager responsible for development of the supercon troller chip; he knew the chip's technical requirements, but had little experience dealing with chip vendors and their production processes. (He had long been a spe cialist.) Without that experience, he had a hard time pushing back against the vendor's “standard line." But Fred's manufacturing experience with several chip vendors enabled him to calibrate the vendor's dates against his best-case experience and understand what the vendor needed to do to meet a substantially earlier commitment.

MANAGING LINKAGES

431

Moreover, because Fred had bought into a clear team charter, whose path the delayed chip would block, and because he had relevant experience, it did not make sense to live with the vendor's initial com mitment, and thus he sought to change it. In contrast, Jim--who had worked in the traditional functional or ganization for many years--saw vendor relations on a pilot build as part of his functional job, but did not be lieve that contravening standard practices to get the vendor to shorten the cycle time was his responsibility, within the range of his authority, or even in the best long-term interest of his function. He was more con- cerned with avoiding conflict and not roiling the water than with achieving the overarching goal of the team.

It is interesting to note that in Team B, engineer ing raised the issue, and, while unwilling to take ag gressive steps to resolve it, also blocked others' at tempts. In Team A, however, while the issue came up initially through engineering, Fred in manufacturing proactively went after it. In the case of Team B, getting a prototype chip returned from a vendor was still being treated as an "engineering responsibility," whereas in the case of Team A, it was treated as a “team responsi bility." Since Fred was the person best qualified to at tack that issue, he did so.

Both Team A and Team B had a charter, a con tract, a co-located core team staffed with generalists, a project leader, articulated responsibilities, and an exec utive sponsor. Yet Jim's and Fred's understanding of what these things meant for them personally and for

the team at the detailed, working level was quite differ ent. While the teams had been through similar training and team startup processes, Jim apparently saw the new approach as a different organizational framework within which work would get done as before. In con trast, Fred seemed to see it as an opportunity to work in a different way-to take responsibility for reconfig uring tasks, drawing on new skills, and reallocating re sources, where required, for getting the job done in the best way possible.

Although both teams were “heavyweight" in the ory, Fred's team was much "heavier" in its operation and impact. Our research suggests that heaviness is not just a matter of structure and mechanism, but of atti tudes and behavior. Firms that try to create heavy weight teams without making the deep changes needed to realize the power in the team's structure will find this team approach problematic. Those intent on using teams for platform projects and willing to make the ba sic changes we have discussed here, can enjoy substan tial advantages of focus, integration, and effectiveness.

NOTES

1. See Kim B. Clark and Takahiro Fujimoto, Prod uct Development Performance (Boston, MA: Harvard Business School Press, 1991).

2. Adapted from a description provided by Dr. Christopher Meyer, Strategic Alignment Group, Los Al tos, CA.