>Working Papers
 
1998 Working Papers
 

A report prepared at the 1997 International Executive Forum 
Managing International Research and Development 
of the Carnegie Bosch Institute 

Pittsburgh, October 1997 
Managing International R&D 
for Global Platforms 
and Local Adaptations 
Working Paper 98-1 

by 
Dr. Michael Bolle, Robert Bosch GmbH, Germany 
Michael A. DiFlora, Tecumseh Products Co., USA 
Dr. Gerhard Felten, Robert Bosch GmbH, Germany 
Dr. Kunihiko Hara, Denso Corp., Japan 
Thomas L. Holt, Caterpillar France S.A, France 
Stephen A. Hyland, Caterpillar Inc., USA 
Kenneth L. Klaer, Scientific Atlanta, Inc., USA  Dr. Jacques G. Lemoine, Corning Inc., USA 
Walter Meyer, Siemens AG, Germany 
Tommy J-E Persson, Volvo Car Corp., Sweden 
Wolfgang. O. Rein, MAHLE, Inc., USA 
Dr. Heinz Schulte, Carnegie Bosch Institute, USA 
Dr. Wolfgang Simon, Robert Bosch GmbH, Germany

Edited by John L. Naman, Kristina Dahlin and Michele A. Krohn 
Carnegie Mellon University 

Table of Contents

Introduction 1 
R&D Strategy, Structure, and Management 2 
The R&D strategy process 2 
The globalization of R&D 3 
Managing short-term development and long-term research 4 
Prioritizing resources for R&D projects 4 
Integrating functional and R&D strategies 5 
International Cross-functional Teams for Product Development 6 
Cross-functional teams in the product development cycle 7 
Design of cross-functional teams 9 
Individual rewards 9 
Corporate priorities 10 
Projecting future needs 10 
"Dynamic reallocation" of functional personnel 11 
Technological competence - gaining and keeping 11 
Managing Collaboration 12 
Conclusion 13 
Appendix 1 - Quality Function Deployment (QFD) 15 

Introduction  
This report is the result of a week-long International Executive Forum for R&D executives sponsored by the Carnegie Bosch Institute at Carnegie Mellon University in Pittsburgh, Oc-tober 1997. The report describes current issues and challenges that the forum participants considered important in improving the performance of international R&D organizations. 

The forum participants focused on the R&D activities of large multinational corporations with operations in countries with open markets, producing state-of-the art products. Each participant's firm has production sites in multiple countries and decentralized research and development activities in several countries. A typical example, a blend of several firms, is illustrated in figure 1. Not all products or components are necessarily developed or manu-factured in all locations. Most firms strive for a global platform product that can be locally adapted (at least at the national level) to customer requirements, regulatory requirements, and distribution channels. In the report, current issues concerning the strategy, organizational structure, and human resources required for continuing success in these R&D intensive or-ganizations are discussed. 

Key:  R = Research Lab;  D = Development Lab;  M = Manufacturing Plant 
Figure 1  Multinational R&D Facilities Example 

The ground rules of the forum include a strict policy of non-attribution of individuals or companies. Consistent with this policy, pseudonyms such as Company X are used in this re-port in all references to real organizations, whether or not participating in the forum. The ob-servations and discussion about these companies have not been altered nor fabricated.

R&D Strategy, Structure, and Management  

This section of the report provides details about the strategy, organization, and management of research and development activities drawn from the 1997 forum participants. It is asserted that the success of an organization's technology strategy critically depends on research and development people doing the right things (effectiveness) and doing things right (efficiency).  Much of the discussion concerned problems and tradeoffs in improving effectiveness and ef-ficiency. 

This report discusses the process in which R&D strategy is developed, the importance of in-tegrating corporate and R&D strategies, and the complications involved in implementing strategy. Strategy currently is being developed in a context of high complexity that is mani-fest in three key areas: product-market diversity, rapidity of change, and density of organiza-tional relationships or communications linkages. Diversity encompasses the range of prod-ucts and services, breadth of geographic markets, and distribution of production and R&D fa-cilities. Rapidity of change includes changing industry prices, speed of technological change, and velocity of new product introductions. Density of linkages includes external relations with customers and suppliers as well as internal linkages among R&D, production, and busi-ness units. Understanding these background conditions is important to understanding the pro-cess by which R&D strategy is developed. 

The R&D strategy process

The 1997 forum discussed the best strategy-making practices and processes drawn from a number of organizations. An example of a "best practices" approach to strategy is Company X, discussed below.

Example 1  
The corporation board and executives of Company X have a global view of R&D that is translated into a well-defined corporate R&D strategy. X uses a three-part model to motivate and focus R&D activities: Vision, Mission and Strategy. The R&D strategy contains five key sub-strategies: 1) people, 2) maintaining a creative climate that helps ensure quality (defined as effectiveness and efficiency); 3) globalization, 4) a focus on core technologies and competencies (research), with a time frame greater than two years; and 5) a policy of transferring to divisions any business technology (development) projects with a time frame of less than two years. 

The strategy-building process was very comprehensive. A small group of managers spent six months developing a set of factors and then presented a draft to all R&D per-sonnel. The company held four meetings with all R&D employees. Outsiders (academic and consultants) were brought in to comment on the plan. Management sincerely wanted all of the organization's members to buy into the model and plan. It took one year of in-tensive selling to the R&D group for them to fully accept the new strategy. 

This strategy process helped to create an identity for corporate R&D. The R&D center now uses tools such as portfolio management and project management and can rational-ize in a consistent manner why some projects are killed and others funded. Each project is evaluated in terms of (probability of success) x (size of impact). Major projects are re-viewed and revised periodically, as often as every 3 months. At that time, the relative priorities of projects are also reviewed and revised. Communication with employees is considered to be a key to the on-going success of this process and is felt to be a critical success factor for the corporation as a whole.

The globalization of R&D

Globalization of R&D is an important strategy issue. In national or multinational R&D, re-search centers are staffed with personnel of one nationality and work more or less independ-ently of other groups. Globalization involves the multinational personnel and often collabo-ration among diverse research centers. Participants pointed out that globalization sometimes develops unintentionally or may be an intentional strategy. 

Intentional strategies for globalizing R&D emphasize access to expertise, best use of re-sources, enhancing creativity, and mixing of nationalities. The differences in training and perspectives not only make nationally diverse groups of researchers generate more project ideas but also helps them come up with more solutions per project. Several firms report ac-celerated product development cycle-times, partly due to work distributed to more than one location. 

Globalization develops unintentionally by acquisition of a company for other reasons than R&D, e.g., market access. When the acquired company has its own R&D unit, the acquirer must decide whether to keep part of the R&D group, all of it, or close it entirely. Several factors influence whether a R&D unit may be closed down or not: 1) government interven-tion may require keeping the unit, 2) the firm may want to maintain competence in the tech-nology, and 3) having a local R&D unit may be important to customers. Even if the R&D unit is closed down, the personnel may be absorbed by other centers. After one or more ac-quisitions, the company may begin developing an intentionally global R&D strategy. 

Globalization of R&D is affected by the markets that the company serves. Product technol-ogy is sometimes lagged for different geographical markets due to the technological level of the countries. This is especially the case when comparing western markets with developing economies. Recently there has been a trend toward customers in developing countries want-ing the latest technology and being uninterested in older product generations. Because of this closing of the technology gap, many forum participants see the world as becoming one mar-ket, especially with regard to technology and research. Globalization may be limited to re-search, as the development of many products continues to be highly dependent on national and cultural factors. 

The previous discussion about strategy development and globalization highlights many of the areas of complications involved in implementing strategy. In particular, forum participants brought out issues involving managing trade-offs between short-term development and long-term research, different approaches to prioritizing resources for R&D projects, and complica-tions integrating corporate, functional, and R&D strategies. Each of these issues is reviewed in turn. 

Managing short-term development and long-term research  

Most forum participants believed it is important for long-term R&D to be close to customers and product designers in order to understand what technologies to develop. This intent can be hindered by a general propensity to allow too much attention to be spent on short term devel-opment projects and too little attention on long-term research programs. Several solutions were examined and critiqued.

For one firm, this is an organizational structure problem, as they feel that they cannot expect long-term research when placing research engineers too close to day-to-day operations. Such structural isolation would seem to work best when researchers and engineers are working on a small set of projects and when the company is deeply committed to a long-term research strategy and its resource requirements. 

A dynamic solution is to have people move between being at a corporate R&D center, away from the short-term thinking, for periods of time and cycle them back into development proj-ects. The idea is to keep rotating R&D engineers between these two locations. This scheme is best suited to a firm having a large number of projects available for people to rotate among. Separation of facilities also helps to ensure the continuance of long term R&D programs. 

Looking to very successful R&D organizations, it seems to be a best practice to analyze how the developers spend their time. It is especially important to ascertain what "fire fighting" activities they undertake and identify underlying problems that make fire-fighting necessary. Thus, one useful performance measure in development projects is the share of total time on each project spent on fire fighting. 

Prioritizing resources for R&D projects

Long-term versus short-term issues arise when resource allocations become constrained. Two different methods of managing the resource allocations are discussed in the examples below. 

Example 2 
For example, one firm experienced a period of poor profitability, which led to the cutting of R&D budgets. The board of directors was aware that this would create problems for the future. To alleviate the negative effects of long-term projects being cut, twenty top projects were defined. Their scope was structured and they were allocated a special budget. Such a policy keeps all resources from being consumed by immediate needs and keeps key research personnel working on appropriate assignments. Thus, one way to ensure long term R&D, is to define such major projects. 

Defining and prioritizing projects in a top-down approach can lead to other problems. Some forum participants were concerned that in rapidly changing fields, who would better know than the people close to the technology what the next project should be? Many researchers are skeptical about the quality of decisions about technology projects made by non-scientists

Example 3 
In contrast to Example 2, one firm uses a prioritization model where the R&D manager regularly meets with his technology project leaders to establish priorities. Together, they develop a list of important projects and the list order is prioritized. There are always more projects than money, so there is often reprioritization to accommodate new projects. Changes can occur monthly, bimonthly or quarterly, which provides the firm with a competitive advantage over slower acting competitors. 

The priority changes in the example typically do not involve massive shifts in resources. Changes involve moving a person to an area of higher need, changing the schedule for access to certain equipment, or modifying a list of features to be incorporated in a new product. Clearly the most significant changes occur at the product development end and there is less change in long-term research programs. However, the cumulative effect of incremental changes in long-term research can help adapt the research to evolutionary changes in markets and technology. 

Integrating functional and R&D strategies 

A key concern was raised that long term seedling research projects are at stake when research resources are allocated to functional managers. It is often difficult for functional managers to put a value on research projects and therefore there is a risk that long-term projects will be stopped. Experience suggests that the risk is very real and all too common. Many forum managers emphasized the need for support from top-management to maintain longer-term re-search  projects. Some favor keeping the research people in a site separate from development and having a separate prioritization for the research-only budget. As in Example 2, funding for long-term research needs to be protected. 

The method by which R&D project priorities are determined is important when integrating corporate strategy and R&D strategy. Some in the forum advocated prioritizing research  projects by looking at their long-term impact on the company. The key question to ask is: If this project works out, what would be the resulting economic value of the successful re-search? Participants also discussed best practices that would help keep R&D priorities aligned with corporate objectives. 

Example 4  
In one example discussed, a firm has approximately twenty R&D projects per year. Once a project is started there is a commitment to the customer and the project must be com-pleted. There is at the same time a high technical uncertainty about how long and how costly each project will be. Also, there is a fear of "ivory-tower research" that it will go off on its own. To help ensure closure, the firm assigns a local researcher for no more than two years at a time in the corporate research center. 

International Cross-functional Teams for Product Development  
The 1997 Forum participants focused considerable attention on a variety of issues concerning international cross-functional teams for product development. All participating organizations currently employ some form of cross-functional teams in product development. Using cross-functional teams helps communication between departments. When using cross-functional teams, development proceeds faster, often by a factor of two or more, and the quality of the resulting product is almost universally perceived as being better. 

This section reports on discussions related to evaluating and improving on the current success of cross-functional teams in product development. It focuses on the range of complexity of teams, employing cross-functional teams in the product development cycle, and best prac-tices in the design and management of cross-functional teams. Many of the issues discussed consequently complicate implementing strategy and create conflicts integrating corporate, functional, and R&D strategies. 

Simple cross-functional team:  

Project leader- Engineering -Marketing- Manufacturing 

Complex cross-functional teams:  

Range of Complexity of Cross-functional Teams  
The simplest form of a cross-functional team consists of a project leader and representatives from departments such as engineering, marketing, and manufacturing. On the other end of the spectrum, there are large teams working in parallel. Examples of this range are shown in fig-ure 2. In the complex situation, multiple product development projects are associated with cross-functional project teams composed of members from facilities around the world. Local sub-teams manage local adaptations to the "global platform" design. Note that the complex case often includes more functions, such as accounting and after-sales product support. 

Cross-functional teams in the product development cycle  

Example 5 

Company Y has been employing complex cross-functional teams for over five years. Since Y started using the team structure, product development time has been cut in half. For each new product under development, a team of twenty is composed of functional leaders from sites in four countries (similar to that shown in figure 2). The team meets bi-monthly, rotating through all sites during a year. Rotating the meeting location serves to distribute the travel requirements equitably, ensures that each country team has a chance to learn first-hand about innovations and constraints in other locations, and reinforces a sense of global mission with the employees of each facility. 

Note that different teams work on several development products at the same time. Some team members may belong to more than one team - for example, accounting. Projects are usually staggered in order to (theoretically) level the work load for engineering de-velopment and operations. 

In Company Y, a typical product development cycle consists of four phases: concept, development, pilot, and production. In the first phase, the cross-functional team consid-ers a number of factors. They make a customer needs analysis (end-users, their compa-nies, and distribution channel), determine regulatory requirements for product (noise, environmental, safety), assess the competition; select a market position; decide pricing; incorporate the financial goals of company; adhere to capital constraints; and adapt available technology (such as new component advances). During the concept phase, the team decides the functional specification. The process includes "extremely rigorous Q.F.D. ". 

The concept team also decides where major components will be manufactured. Compo-nents may be out-sourced or manufactured in company factories in one or several coun-tries. Not all components are manufactured in all plant locations, depending on econo-mies of scale, shipping costs, existing plant schedules, etc. The manufacturing decision is complicated by considerations of local adaptations for regulatory or customer re-quirements. Project management includes critical path (time) and definitions of activity-based tasks, which links to an activity-based cost system. 

After a formal approval by senior management, the functional specification is frozen. The development phase includes development of product and process designs, analysis, simulation, refinement and procurement. Expertise from corporate centers is drawn on and not duplicated by the team. After a review, several (2-3) prototypes are built and evaluated. 

In the pilot phase, manufacturing tools up and builds 10-15 products for verification and beta-testing by key customers. Orders from customers will not begin before the pilot. After a final formal approval by senior management, the product enters the full manu-facturing phase. 

From a human resources perspective, there are two key points to be noted about Company Y's use of cross-functional teams in the product development cycle. First, team members are evaluated and rewarded by the project manager(s) and not by functional management. Y views this to be one critical factor in their success with cross-functional teams. Second, dur-ing some product development cycles, turnover (promotions out of) the cross-functional teams can be so high that few of the original team members are present at the end (approxi-mately 30 months from concept to the start of manufacturing). Because of this dynamic par-ticipation, Y views Q.F.D.1 and well-defined team processes to be of critical importance. 

Why does Company Y have such high turnover in teams? Apparently (see figure 2), at least some project members have begun to specialize in different phases of the product develop-ment cycle. Although full verification has not been obtained, it appears that a concept phase engineer moves on to the next concept phase project when that phase ends, as illustrated in figure 3, below. Staggering projects over time efficiently utilizes expertise across projects, dramatically increasing the productivity of expert managers. One staffing implication is that the number of staggered projects can be increased or decreased slightly with hiring, firing, or transferring team members with high expertise. An implication for competing on the basis of time is that innovations in one development project rapidly diffuse to staggered projects, in contrast to having to wait until projects are completed. 

To better understand cross-functional teams, the forum examined a second company's practices, briefly described in the example below. 

Example 6  
Company Z utilizes a variation of the complex cross-functional team for its product development. Cross-functional teams are composed of project leaders from one country, then development teams are drawn from all over the world. As with Company Y in the previous example, several projects may be in progress at one time and the projects are staggered by several months to level the load on R&D.

 
Important differences from the Company Y example include: 1) Project leaders make many site visits; 2)There are some problems coordinating development workers; and 3) A world-wide definitions team generates very complex requirements (accommodating many local ad-aptations). Z's product market is high technology and changes rapidly, which causes "dy-namic goal shifting", that is, the product requirements are a moving target. As a result, man-agement monitors product development efficiency in part by comparing with historical data for "similar" projects at different points in past project life cycles. In contrast to Y's team members being evaluated and rewarded solely by the project manager(s), Z's people are evaluated and rewarded both individually (line manager) and by team, that is two separate bonuses. 

 

Further analysis of the dual evaluation and bonuses in the Company Z is informative. The state-of-the-art technological level required for Z's product markets requires that employees stay at the forefront in their functional specialty. Evaluation and bonus by a functional man-ager helps to insure that employees are motivated and rewarded for continual learning, as well as evaluated by an appropriately knowledgeable manager. On the other hand, the high uncertainty associated with Z's projects suggests that team members not be evaluated exclu-sively on the success or failure of innovative projects. It seems inevitable that some projects will fare better than others for reasons such as marketplace acceptance, unanticipated techni-cal "bugs", and timing of competitors' product innovations. Thus, management may find it difficult to unambiguously allocate responsibility, hence rewards, for the team's effort. The double evaluation seems to ensure equitable treatment and consistency with the corporate technology strategy. 

Design of cross-functional teams  

The performance and success of cross-functional product development teams are critically dependent on differences in the design and implementation of the teams. This section of the report provides detail about the organization and management of cross-functional teams drawn from the forum participants. Participants identified six currently important manage-ment problems and a variety of solution alternatives. Each is discussed in turn. 

Individual rewards 
The first problem is how to align individual rewards with project goals and signal the strate-gic importance of the project to team members. One solution is for the project leader to evaluate and distribute bonuses to functional team members. This would seem to work best when members work on one project (perhaps a few) at a time and when the company is deeply committed to a strategy of cross-functional team product development. 

A second alternative is for the project leader to evaluate the performance of the functional members, but have the functional manager determine the bonus. This procedure is perhaps better than the previous one if the functional manager is responsible for allocating effort across a large number of equal priority projects. However, most R&D managers feel that functional managers still have too much responsibility for allocating resources such as bo-nuses, personnel, equipment, facilities, and scheduling.

Some companies currently have the functional managers evaluate and distribute bonuses to function members. This policy is best for a limited engagement "strike force" assignment and is inconsistent with the goals of cross-functional team product development. Otherwise, it is often counter-productive and dysfunctional. The presence of this policy may be a symptom of functional managers resisting giving up power over resources or a lack of top management commitment to cross-functional teams. Transferring power from line managers to cross-function team leaders can be "painful" and take up to seven years to "convert". 

Corporate priorities  
The second problem identified is that of corporate priorities for product development and signaling the importance of product development projects to other (non-R&D) corporate units. All participants seemed to agree that the best policy is overt CEO support for cross-functional teams. It is also important that there be high level sponsorship of projects, in terms of involvement and commitment. The commitment and involvement of executives signals the importance of projects to corporate units that are not directly involved in product develop-ment, particularly other company projects that might draw off resources and the timely re-sponse of bureaucracies. Furthermore, it is important that there be "strong" project managers, that is, with the power to allocate resources and reward performance. In all cases, it is a good policy to make sure there is a clear project ownership. Lastly, project sponsors need to be kept fully and quickly informed of any emerging problems in a product development project. A best practice in which this policy is implemented is to have a small core group responsible for each project and a fringe group of executives who are fully informed and able to attend meetings and react when they think the project is veering off course. 

Projecting future needs 
A vexing problem is that marketing and sales people often have difficulty projecting the fu-ture needs of customers, particularly where products require higher technical knowledge than the marketers have. Yet many feel that marketing and sales should be involved in project de-sign to ensure proper price and features. This conundrum is particularly a problem with state-of-the-art products, where perhaps only a few people truly understand the technology. Most agree that it is important to have involvement of key (knowledgeable) customers early in the product development. This involvement is elicited to some extent by most cross-functional product development teams, but participants explicitly desired that it be done even better and more effectively.

It is also desirable that R&D staff have direct contact with key customers when sales and marketing do not understand or can not communicate state-of-the-art technical issues. However, in some countries, such as Germany, "it is still not common for developers to talk di-rectly with customers," noted one forum member. Also, some R&D managers report that salespeople want "Gee Whiz!" products, even if that is not exactly what customers are re-questing. Thus, it is important to clarify both what is possible and what is needed by the mar-ket. When it is possible to hire sales people with adequate technical knowledge, there is a long-term problem keeping their knowledge up-to-date and at what cost. 

From a policy perspective, it may be beneficial to change the compensation of salespeople from being based on quarterly sales to include a component of future profitability. Such a policy is widely desired or wished for by R&D management, but is currently reported as not yet widely implemented. On the other hand, managers feel that it is desirable that the sales force focus on selling existing products that need to be shipped today and not try to sell prod-ucts that are not out of development yet. R&D managers are poignantly aware that profits on existing products fund R&D and that premature selling creates unnecessary pressure on de-velopment teams. 

On a related matter, R&D managers would like to see more incentives to discourage market-ing and sales from pushing a different product variation for each customer. The concerns are that profitability should be more important than sales revenue targets and that product varia-tions burden R&D and manufacturing with extra costs in time, assigning personnel, loss of economies of scale, and expenses. Theoretically, prices should be raised sufficiently to re-coup the extra costs, but competitive pressure and imperfect accounting systems seem to pre-clude fully capturing the revenues. Also, this selling tactic is tantamount to switch from a mass production strategy to custom work, which should require completely restructuring the organization and R&D strategy. 

 "Dynamic reallocation" of functional personnel 
In resource constrained environments, there can be a problem assigning functional people (engineers, marketers) to project teams when needed. In particular, unanticipated problems in product development almost always require "dynamic reallocation" of functional personnel from other projects. Also, resource scheduling never perfectly matches evolving project pri-orities. One firm has a senior manager attend monthly reallocation meetings as a 'referee'. This practice provides immediate resource allocation decisions, which is a major advantage in addressing problems promptly. Another firm has a staff person responsible for ensuring cross-functional members attend meetings, which can sometimes be a problem, and prodding functional managers to fulfill their resource committments. This approach is important for keeping team members apprised of emergent resource needs and preventing unnecessary de-lays. Some suggest that it may help to have functional managers evaluated by development teams on their success in allocating resources when and as needed. This seems to be the heart of the widely held concern about functional managers' power over resources. 

The importance of the reallocation problem is growing. Many organizations are loading en-gineers 100%, leaving little slack for reallocations. Also, training for functional personnel is becoming more important, while demands for the time taken for training are increasing. Fu-ture solutions need to incorporate the training issue. (In a previous section, it was noted that there is a related long-term problem keeping the knowledge of salespeople up-to-date and at what cost.) 

Technological competence - gaining and keeping  
All R&D organizations are concerned about gaining and keeping technological competence. This concern is manifest in policies for staffing R&D, that is, hiring versus subcontracting. In the forum, several policy solutions were offered for building and maintaining competence. For new technologies, it was suggested that the company pay technical consultants to jump start development, then management should act to build the competence inside. The key issue is time to train people internally, because short development cycles mean that there is not suf-ficient time to (re)educate existing personnel, forcing managers to hire additional personnel. However, labor laws in most European countries make it very difficult to layoff or fire employees, which promotes the practice of using consultants rather than hiring full-time em-ployees. A second issue involves difficulty finding good (future) product developers in a pool of technically competent new hires, such as out of a university. One participant aptly stated the employee search problem, "Product development is different from science on the bench." 

A topic of keen concern to most R&D managers is the maximum amount of subcontracting that can be utilized without changing the nature of the R&D organization itself. They fear that too much subcontracting can cost dearly in the long-term due to a loss of competence. A policy restricting subcontracting to less than 15% of R&D was agreed necessary to keep competence inside the company. All agreed that 50% of R&D workers as subcontractors would be unacceptable. Most agreed that 40% would be too high. A range of 10-25% was re-ported as currently practiced, with some concern that some organizations are already ex-ceeding desirable limits. Another subcontractor issue raised was a report that French co-employment laws have criminal and civil penalties for talking directly to subcontract em-ployees. By French law, communication must go through supervisors, which slows and dis-torts communication. Thus, policies should be adjusted for differential cultural and regulatory effects. 

Managing Collaboration  

The last of the currently important management problems relates to managing collaboration between firms. On the topic of technical competence, most participants believe that technical exchanges between firms can be good for both firms, in terms of gaining and keeping com-petence. However, the presence of a "Not invented here" syndrome will impede creation of some joint ventures. Participants also note how disastrous joint ventures can be, suggesting that the means of exchange be very carefully considered. For example, it was reported that the collaborative decision making process can be quite complex in Europe, often leading to "advising" rather than "deciding". With some flexibility on the part of the parent managers, the collaborative effort can succeed. 

After discussion about a wide range of present and past collaborative arrangements, several conclusions were drawn. First, mutual trust is critical for collaboration, particularly if there is any tension between confidentiality and sharing information/teaming. Second, collaboration requires good communication, especially of the logic underlying a decision. Insuring full un-derstanding of the basis of decisions is reported to be particularly important across national cultures. Third, collaboration can be strengthened by historical links between the companies, building on a solid foundation of a shared "mindset" and friendships between personnel. It is suggested that collaborative success breeds excellent future collaboration as well. 

One way in which collaboration can be better managed is illustrated by the following example. 

Example 7 

A company used "third party" international management professors to interview the managers and employees involved in a collaborative project. Using the information from the interviews, they returned and explained how different cultures work. The result was much better collaboration and some small changes in team membership to accommodate local culture. For example, to accommodate the national culture at one location, a functional manager was brought into the cross-functional team decision making loop. This example confirms the value of judicious policy adjustments to deal with different cultures. 

 

Conclusion  

This report highlights the critical role that the R&D organization plays in the very complex task of implementing company strategy. Based on discussion, best practices, and examples drawn from a number of organizations, the first section examined key issues involving man-aging trade-offs between short-term development and long-term research, different ap-proaches to prioritizing resources for R&D projects, and complications integrating corporate, functional, and R&D strategies. The second section addresses a variety of issues concerning international cross-functional teams for product development. Most of the issues evaluated link directly back to complications in implementing strategy and conflicts integrating corpo-rate, functional, and R&D strategies. 

One theme that threaded its way through the week of discussions was the need to balance competing demands on R&D management. Resource needs for long-term research compete with the immediate needs of short term development projects and day-to-day operations. In collaborative work, there is often some tension between confidentiality and sharing informa-tion/teaming. The economies of scale of global products compete with customers' demands for product variations and adaptations. The need to sell existing products, in part to fund R&D, competes with customer desires for state-of-the-art products that are not out of devel-opment yet. Early in the product development cycle, marketing and sales people often have difficulty projecting the future needs of customers, particularly where products require higher technical knowledge than the marketers have. Yet marketing and sales must be involved early in project design to ensure competitive price and features. 

R&D organizations have found a variety of innovative ways to balance these competing demands. International cross-functional teams are employed for product development, bringing much of the decision making and inevitable trade-offs out of corporate offices and as close as possible to the product. Within companies, multiple product development projects are associ-ated with cross-functional project teams composed of members from facilities around the world. Local sub-teams manage local adaptations (national standards, regulations, and key customer specifications) to the "global platform" design. 

Another theme in the discussions was the increasing complexity of the task of R&D management. In recent years, production and R&D facilities have become more decentralized and geographically dispersed. Cross-functional teams now include more functions, such as ac-counting and after-sales product support. The involvement of customers and collaborations with other companies create a complex network of communications linkages. Changing in-dustry prices, acceleration of technological change, and faster product introductions have complicated management of R&D. Terms such as "dynamic goal shifting" have been in-vented to describe how product requirements have become a moving target and unanticipated problems in product development almost always require "dynamic reallocation" of functional personnel among projects. 

From the increasing complexity, some trends are emerging for ways to cope with the load. In cross functional teams, it seems that project members have begun to specialize in different phases of the product development cycle. As they cycle in and out of teams, other functional knowledge workers are entering and exiting the teams as needed in the increasingly resource-constrained environment. Many organizations are loading permanent employees to 100%, leaving little slack for reallocations. Increasingly, more team members are contract employ-ees. Managers have found ways to begin dealing with this changed nature of the teams them-selves. In response to increasing cultural diversity and changing teams, mangers are attempt-ing to improve communication and full understanding of the basis of decisions. None feel that they have found the perfect solution and set of tools. All seriously self-evaluate and try to improve on their current successes in the process of product development. 

The two threads of balancing demands and increasing complexity knot together to create a great challenge for tomorrow's R&D managers. All R&D organizations are concerned about building technological competence over time rather than simply exploiting them. They must allocate the time and other costs to maintain competitiveness. While continual learning and skills training are becoming more important, demands for the time taken for training are in-creasing as well. Yet, R&D projects must be completed at minimum time and cost, relative to competitors, and the results must be perceived as "state of the art" by customers. Ever shorter development cycles mean there will be even less time to (re)educate in the future, but the knowledge of salespeople, functional workers, and even customers must be kept up-to-date. Good solutions to this challenge will be judged by the extent to which they increase the value that R&D contributes to the firm and its competitive position in the marketplace. 

This report has drawn on the experience of participating executives to provide documentation of some of the better alternatives for designing and managing an international R&D organi-zation. The forum participants have shared their collective current knowledge of the key is-sues and challenges considered to be  important in improving the performance of interna-tional R&D. The report includes many examples of "best practices" and variations with which they are familiar. For completeness, also written up are various caveats and limitations that emerged in discussions of those practices. For those who read this seeking some guid-ance, know that it is most important that each company's management team decide what is most appropriate for their own context. As for the future, these complex and changing times require us all to continually learn from each other to ensure continuing success in R&D in-tensive organizations. 

Appendix 1 - Quality Function Deployment (QFD
Overview  
Quality Function Deployment is a team-based technique that provides a means of identifying and translating customer requirements into technical specifications for product planning, de-sign, process, and production. The term Quality Function Deployment is a loose translation from the Japanese name for this methodology, hin shitsu (quality), ki nou (function), ten kai (deployment) [1]. The methodology consists of a structured procedure that starts with the qualities desired by the customer, leads through the functions required to provide these prod-ucts and/or services, and identifies the means for deploying the available resources to best provide these products and/or services. Research has found that QFD can provide some short-term benefits such as reducing the cross-functional barriers associated with product develop-ment teams and aiding changes in corporate culture. However, over the long-term, QFD has been shown to address the more tangible benefits of reduced cycle time, reduced develop-ment cost, and increased productivity [1]. An important benefit of QFD has been its effec-tiveness in capturing, prioritizing and stabilizing customer requirements. As with many busi-ness practices, the manner in which QFD is implemented will likely have a significant impact on the benefits derived [2]. Team commitment to the methodology is an important success factor [2]. 

Background 
QFD has its roots in Japan of the late 60's and early 70's [1]. The Japanese created a method-ology to support the development process for complex products, such as supertankers, by linking the planning elements of the design and construction processes to specific customer requirements. By employing this methodology, numerous Japanese companies enabled their product development efforts to more effectively focus on meeting customer needs, thus building a distinct competitive advantage. The successes in Japan helped lead to the adoption of QFD by companies in the United States starting in the early 80's. Since then, with appli-cations across many different manufacturing and service based companies in the US, QFD has led to some dramatic success stories: reductions in overall project costs (for example, by 50%), reductions in project cycle time (for example, by 33%), and major increases in pro-ductivity (for example, by 200%) [1]. 

References: 
1. Guinta, L. R. and Praizler, N. C. The QFD Book, The Team Approach to Solving Prob-lems and Satisfying Customers Through Quality Function Deployment. AMACOM Books. 1993. 
2. Griffin, A. "Evaluating QFD's Use in US Firms as a Process for Developing Products.", 
Journal of Product Innovation Management, 9:171-187, 1992. 

 

 

 



About Us Executive Education Programs CBI Home Page Conferences Globalview Newsletter Contact Us Research and Working Papers