Managing New Product Development Teams

By Schilling, M.A.

Edited by Paul Ducham

TEAM SIZE

New Product Development teams may range from a few members to hundreds of members. For example, the development team that created the IBM personal computer had 19 members, but the average team size for development projects at IBM is close to 200. The Yahoo! Internet portal was developed by 13 software developers, split into several small teams of one to three members. By combining the efforts and expertise of multiple individuals, groups can often outperform individuals on many problemsolving tasks, implying that the size of the development team might be related to its potential for success.

 Bigger, however, is not always better. Large teams can create more administrative costs and communication problems, leading to costly delays. Additionally, the larger the team, the harder it can be to foster a shared sense of identity among team members. Further, as the size of the team increases, the potential for social loafing also increases. Social loafing occurs when, as the size of the team increases, individuals perceive that they will not receive full credit (or blame) for their contribution to the group effort and so their effort and commitment decrease. The average team size used by U.S. organizations is 11 members, but there is considerable variance in the size of teams used by organizations, and each team may vary in size over the course of a new product development project.

TEAM COMPOSITION

A lack of communication among the marketing, R&D, and manufacturing functions of a company can be extremely detrimental to new product development. A lack of crossfunctional communication can lead to a poor fit between Product Attributes and customer requirements. R&D cannot design products that fit customer requirements unless it receives and attends to input from marketing regarding those requirements. The manufacturing/R&D interface is also of critical importance because of manufacturing’s role in determining two key attributes of a product—quality and price. By working closely with R&D, manufacturing can ensure that R&D designs products that are relatively easy to manufacture. Designing for ease of manufacturing can lower both unit costs and product defects, which translates into a lower final price and higher quality. Similarly, a lack of cross-functional communication between functions can lead to longer cycle times as a product iterates back and forth between different stages in the process.

 Firms can rectify this problem by building cross-functional product development teams. Cross-functional teams include members drawn from more than one functional area, such as engineering, manufacturing, or marketing. For instance, in Chrysler’s “vehicle deployment platform teams,” team members are drawn from design, engineering, purchasing, manufacturing, product planning, finance, and marketing. Firms around the world rely heavily on Cross-Functional Teams for their new product development efforts. In 2000, 77 percent of U.S. firms, 67 percent of European firms, and 54 percent of Japanese firms reported using cross-functional teams.

 Teams that are composed of people from diverse backgrounds have several advantages over teams that are drawn from only one or a few functional areas. A greater variety of specialists provides a broader knowledge base and increases the crossfertilization of ideas. Having specialists from different areas also allows the project to draw on a wider mix of information sources in the environment through scanning activities (for richer detail on this, see the accompanying Research Brief on boundaryspanning activities). Functional experts often actively read journals and are involved in associations that directly affect their trade. These activities can lead to the creation and improvement of innovative ideas, as well as provide solutions to product development problems. By combining members of different functional areas into one project team, a wide variety of information sources can be ensured.

 A number of arguments also support other types of diversity. Individuals who enter the organization at different times (organizational tenure diversity) are likely to have different contacts outside of the team, enabling the team to draw from a wider mix of resources. Teams that incorporate cultural diversity should show better problem solving by incorporating multiple viewpoints, and teams composed of members who are diverse in terms of gender or age will also ensure a variety of viewpoints are considered and external resources are tapped. Studies have demonstrated that demographic diversity in teams can increase innovative outcomes and overall performance.

 Diversity of team members, however, can also raise coordination and communication costs. Individuals tend to interact more frequently and more intensely with other individuals whom they perceive as being similar to them on one or more dimensions. This phenomenon is known as homophily. Research on homophily suggests that individuals prefer to communicate with others they perceive as similar to them because it is easier and more comfortable to communicate with those who have similar dialects, mental models, and belief systems. The perception of similarity can also be self-reinforcing—as individuals interact with frequency and intensity, they can develop a common dialect, greater trust, and greater familiarity with the knowledge each possesses. The common dialect, trust, and familiarity, in turn, make the individuals both more willing and more able to exchange information effectively in future interactions. When individuals perceive others as being very different from them, they may be less willing to interact frequently or intensely, and it may be more difficult for them to develop a shared understanding. Heterogeneous teams often have greater difficulty integrating objectives and views, leading to conflict and lower group cohesion. Research has also indicated, however, that the communication and coordination differences between heterogeneous or homogeneous teams diminish if the groups maintain long-term contact. Presumably, through extensive interaction, heterogeneous teams learn to manage their group processes better.

 In sum, heterogeneous teams should possess more information, on average, than homogeneous groups. The heterogeneity of a team can also increase the creativity and variance in decision making, leading to more innovative outcomes and higher overall performance. However, to realize this potential performance advantage, heterogeneous teams may require long-term contact and incentives to foster communication and cooperation.

 The ability of team members to communicate and cooperate effectively is also a function of the personalities of the individuals on the team. A study by Susan Kichuk and Willi Wiesner explored whether five personality factors (conscientiousness, extroversion, neuroticism, agreeableness, and openness to experience) influenced the likelihood of success in new product development teams. Kichuk and Wiesner found that the personality characteristics that enhanced the success of a new product development team were high extroversion, high agreeableness, and low neuroticism.

 Research Brief Boundary-Spanning Activities in New Product Development Teams

To be successful, new product development teams must be able to manage relationships with groups that are beyond the team’s boundaries. Teams need to be able to collect information and resources both within and outside of their organizations, and they also need to represent the team to other groups in the organization to ensure that the team continues to receive support and that team members are not overloaded with nonteam- related activities. The most successful new product development teams have gatekeepers who provide important links to the environment.

 Deborah Ancona and David Caldwell conducted a study to explore the full range of boundary-spanning activities in which teams engage and to identify which of these activities enhanced team performance. They interviewed 38 experienced product development team managers and collected data from 45 product development teams in five high-technology companies in the computer, analytic instruments, and photographic equipment industries. Ancona and Caldwell found that teams engaged in three primary types of boundary-spanning activity:

          Ambassador activities—These activities were directed at representing the team to others and protecting the team from interference. For example, an ambassador might convince other individuals in the organization that the team’s activities are important.

          Task coordination activities—These activities emphasized coordinating and negotiating the team’s activities with other groups. For instance, task coordination activities might include negotiating delivery deadlines with other divisions of the firm or obtaining feedback about the team’s performance.

           Scouting activities—These activities were directed at scanning for ideas and information that might be useful to the team, enhancing its knowledge base. For example, scouting activities could include collecting data about what competitors were doing on similar projects or finding technical information that might be useful in the development project.

 Ancona and Caldwell found that boundaryspanning activities affected the performance of the new product development team, and their impact depended on the timing of the activities. In particular, they found that scouting and ambassador activities were more beneficial if conducted early in the development project cycle, while task coordination activities were beneficial throughout the life of the team.

FUNCTIONAL TEAMS

In functional teams, members remain in their functional departments (e.g., R&D, marketing, manufacturing, etc.), and report to their regular functional manager (see Figure 12.1, panel a); however, they may meet periodically to discuss the project. Such teams are usually temporary, and individuals may spend less than 10 percent of their time working on team-related activities. Functional teams also typically do not have a project manager or dedicated liaison personnel. While this team structure is straightforward to implement because it requires little (if any) deviation from the firm’s normal operations, this structure provides little opportunity for cross-functional coordination. Further, since individuals are still evaluated and rewarded almost exclusively based on their functional performance, the team members may have little commitment to the development project. Functional teams are more likely to be appropriate for derivative projects that primarily affect only a single function of the firm.

Fig 12.1

LIGHTWEIGHT TEAMS

In lightweight teams, members still reside in their functional departments, and functional supervisors retain authority over evaluation and rewards (see Figure 12.1, panel b). Like functional teams, lightweight teams are typically temporary, and members spend the majority of their time on their normal functional responsibilities (up to 25 percent of their time might be spent on team-related activities). However, lightweight teams have a project manager and dedicated liaison personnel who facilitate communication and coordination among functions. Managers of lightweight teams are normally junior or middle management employees, who are not able to exert significant influence or authority over team members. As a result of these factors, lightweight teams offer a small improvement in team coordination and likelihood of success over functional teams. Such a team structure might be appropriate for derivative projects where high levels of coordination and communication are not required.

HEAVYWEIGHT TEAMS

In heavyweight teams, members are removed from their functional departments so that they may be collocated with the project manager (see Figure 12.1, panel c). Project managers of heavyweight teams are typically senior managers who outrank functional managers, and have significant authority to command resources, and evaluate and reward team members. The core group of team members in the heavyweight team is often dedicated full-time to the project. This combination of factors helps ensure that the team has strong cross-functional coordination and communication, and that team members are significantly committed to the development project. However, heavyweight teams are still often temporary; thus, the long-term career development of individual members continues to rest with their functional managers rather than the project manager. This type of team structure offers a significant improvement in communication and coordination over functional teams, and it is typically considered appropriate for platform projects.

AUTONOMOUS TEAMS

In autonomous teams, members are removed from their functional departments and dedicated full-time (and often permanently) to the development team (see Figure 12.1, panel d). Team members are collocated with the project manager, who is a very senior person in the organization. The project manager of an autonomous team is given full control over resources contributed from different functional departments, and the project manager has exclusive authority over the evaluation and reward of team members. Autonomous teams often do not conform to the operating procedures of the rest of the organization; instead they are permitted to create their own policies, procedures, and reward systems. Autonomous teams are also held fully accountable for the success of the project; in many ways, autonomous teams act like independent divisions of the firm. Autonomous teams typically excel at rapid and efficient new product development, particularly when such development requires breaking away from the organization’s existing technologies and routines. Thus, autonomous teams are typically considered to be appropriate for breakthrough projects and some major platform projects. They can be the birthplace of new business units. However, the independence of the autonomous teams can cause them to underutilize the resources of the parent organization. Furthermore, autonomous teams are often hard to fold back into the organization if the project is completed or terminated. For an example of the use of autonomous teams, see the accompanying Theory in Action on Chrysler’s “platform teams.”

 Figure 12.2 summarizes key dimensions across which the four teams vary, including a number of points that have not yet been dealt with in the text. The potential for conflict between the functions and the team, particularly the project manager, rises with the move from functional teams to autonomous teams. The independence of heavyweight and autonomous teams may prompt them to pursue goals that run counter to the interests of the functions. Senior managers should keep such conflict in check.

Fig 12.2

TEAM LEADERSHIP

The team leader is responsible for directing the team’s activities, maintaining the team’s alignment with project goals, and serving as a communicator between the team and senior management. In heavyweight and autonomous teams, the team leader may also be the person who is primarily responsible for the evaluation, compensation, and promotion of individual team members. Effective team leaders are often much more directly related to the team’s success than senior management or project champions. This may be because team leaders interact much more frequently with the team and more directly influence the team’s behavior.

 As described in the team type and structure section above, different types of teams have different leadership needs. For instance, while lightweight teams might have a junior or middle-management leader who provides basic coordination between the functional groups, heavyweight and autonomous teams require senior managers with significant experience and organizational influence. In heavyweight and autonomous teams, the project manager must be someone who can lead and evaluate the team members, champion the development project both within the team and to the wider organization, and act as a translator between the various functions. In particular, project managers in heavyweight and autonomous teams must have high status within the organization, act as a concept champion for the team within the organization, be good at conflict resolution, have multilingual skills (i.e., they must be able to talk the language of marketing, engineering, and manufacturing), and be able to exert influence upon the engineering, manufacturing, and marketing functions. Other things being equal, teams whose project managers are deficient on one or more of these dimensions will have a lower probability of success.

TEAM ADMINISTRATION

To ensure that members have a clear focus and commitment to the development project, many organizations now have heavyweight and autonomous teams develop a project charter and contract book. The project charter encapsulates the project’s mission and articulates exact and measurable goals for the project. It might include a vision statement for the project (e.g., “Dell laptops will be the market standard for performance and value”) and a background statement for why this project is important for the organization. The charter may describe who is on the team, the length of time members will spend on the team, and the percentage of their time that will be spent on team activities. It may also stipulate the team’s budget, its reporting timeline, and the key success criteria of the project (e.g., meeting a particular time-to-market goal, exceeding customer satisfaction criteria established for the project, capturing a target amount of market share within a defined period of time, etc.). Establishing an explicit set of goals for the project helps ensure that the team members have a common understanding of the project’s overall purpose and priorities. Goals also help to structure the New Product Development Process and can facilitate cooperation by keeping team members oriented toward a common outcome.

 Once the team charter is established, core team members and senior managers must negotiate a contract book. The contract book defines in detail the basic plan to achieve the goal laid out in the project charter. Typically, the contract book will estimate the resources required, the development time schedule, and the results that will be achieved. The contract book provides a tool for monitoring and evaluating the team’s performance in meeting objectives by providing a set of performance benchmarks and deadlines to which the team’s performance can be compared. More important, however, the contract book is an important mechanism for establishing team commitment to the project and a sense of ownership over the project. After negotiation and acceptance of this contract, all parties often sign the contract book as an indication of their intention to honor the plan and achieve the results. Team members who sign the contract book typically feel a greater sense of duty to work toward the project’s goals. Furthermore, signing the contract book can give team members a sense of ownership over the project and empowerment to make decisions about the project. This ownership and empowerment can help team members identify with a project’s outcome and can encourage them to exert extra effort to ensure its success.

MANAGING VIRTUAL TEAMS

Recent advances in information technology have enabled companies to make greater use of Virtual Teams. Virtual teams are teams in which members may be a great distance from each other, but are still able to collaborate intensively via advanced information technologies such as videoconferencing, Groupware, and e-mail or Internet chat programs. Virtual teaming can enable individuals with unique skills to work on a project, regardless of their location. By meeting virtually, individuals who live at great distances can collaborate without incurring travel costs or disruption to their lives. This is especially valuable for a company whose operations are highly global. For example, when IBM began deploying more of its products globally, it increased its use of virtual teams. About one-third of IBM’s employees will participate in virtual teams at some point in their career. When IBM needs to staff a project, it gives a list of the needed skills to the human resource division, which identifies an appropriate pool of people. If the skills and talent of the people are more important than their ability to meet face-to-face, a virtual team is formed.

 Virtual teams pose a distinct set of management challenges, however. Much of the work on the structure of new product development teams has emphasized the importance of collocation. Collocation facilitates communication and collaboration by giving team members opportunities for rich face-to-face communication and informal interaction. Proximity and frequent interaction help teams to develop shared norms and a dialect for communicating about the project. Virtual teams, by contrast, must often rely on communication channels that are much less rich than face-to-face contact and face significant hurdles in establishing norms and dialects.

 In the forming of virtual teams, it is important to select personnel who are both comfortable with the technologies being used to facilitate collaboration and who have strong interpersonal skills. Team members must be able to work independently and have a strong work ethic. Since distance makes it easy for team members to deflect opportunities for interaction, it is important to choose individuals who tend to seek interaction rather than avoid it. It is important that members of the team establish standards for how quickly they will respond to messages, and how often they will be available for synchronous communications (communications where the involved parties must participate at the same time, such as telephone calls, videoconferencing, and instant messaging). Furthermore, because many of the opportunities for informal interaction may be lost in a virtual environment, more types of interaction may have to be incorporated into the ground rules of the team. For example, the team leader might schedule daily or weekly unstructured “chat” times where team members are required to participate in a group conference call or online conference to share ideas that may not be uncovered in the team’s more formal interactions.

 Virtual teams also face challenges in developing trust, resolving conflict, and exchanging tacit knowledge, as discussed in the accompanying Research Brief about virtual international R&D teams.

Research Brief Virtual International R&D Teams

Gassman and von Zedtwitz build on the transnational corporation model by examining how such firms coordinate their international innovation efforts via virtual teams. As in some of the arguments about loosely coupled R&D activities, virtual international R&D teams may jointly work on a single development project, utilizing information technologies (rather than geographical proximity) to achieve coordination. However, while information technology decreases the need to collocate R&D activities, it does not readily solve problems related to Building Trust and transferring tacit knowledge. The type of innovation project being undertaken and the type of knowledge that must be shared should influence the degree to which firms rely on decentralized, virtual coordination processes.

 Gassman and von Zedtwitz studied 37 technology-intensive multinationals and identified four patterns of teams: (1) decentralized selfcoordination, (2) system integrator as coordinator, (3) core team as system architect, and (4) centralized venture team. In the decentralized selfcoordinating teams, there was no single source of power or authority over the teams. Teams communicated primarily through telephone, the Internet, shared databases, and groupware. Coordination was relatively weak and relied largely on a strong corporate culture. Decentralized self-coordination was more likely to arise if there were well-developed standard interfaces between components being developed in different locales; thus, it tended to be suited to modular innovation as opposed to architectural innovation.

 In teams with a system integrator as R&D coordinator, a single individual or office takes responsibility for helping different divisions coordinate. The system integrator helps to build a common understanding of the project among each of the divisions, translates knowledge from one division to another, and tracks progress and contributions. While the overall project is decentralized, the system integrator enables some centralized coordination.

 In the core team as system architect model, a core team of key decision makers from all of the decentralized R&D groups meets regularly to coordinate the otherwise decentralized groups. The core team often includes a strong project manager, leaders from each of the decentralized groups, and occasionally external customers or consultants. The core team constructs the overall architecture of the development project and maintains its coherence throughout its development. Because the core team has more direct authority over the individual divisions than the system integrator described above, the core team is better able to resolve conflict and enforce standards across the divisions. Because core teams can provide a significant level of integration across the divisions, core teams are often able to conduct architectural innovation. In the centralized venture team, R&D personnel and resources are relocated to one central location to enable maximum integration and coordination. The team is likely to have a very powerful senior project manager with significant authority to allocate resources and define the responsibilities of individual team members. Gassman and von Zedtwitz describe two examples of centralized venture teams—Asea Brown’s “High Impact Projects” and Sharp’s “Golden Badge” projects. Because of their high expense, such teams are likely to be used only for strategic innovations of the utmost importance.

 Gassman and von Zedtwitz’s model is summarized in Figure 12.3. Overall, Gassman and von Zedtwitz argue that innovations that are radical, are architectural, or require the intensive transfer of complex or tacit knowledge will require greater centralization. Innovations that are incremental, are modular, and do not require the frequent transfer of complex or tacit knowledge can be more decentralized.

Fig 12.3