Strategic Alliances Research Paper

Scope of the Study

Most research has dealt with bilateral development alliances or those between two organizations. Through an analysis of the various costs and benefits, the next section discusses when a company should opt for development with a partner versus going it alone. In addition to considering tangible factors, it is necessary to weigh contracting and coordination costs versus learning and flexibility benefits. The third section examines the design of a bilateral development alliance, including whether or not the partners should form a company that they would jointly own, the appropriate scope of the alliance’s activities, and the uses of alliance experience. This section also looks into supplier involvement in development in terms of the extent of participation and the quality of the relationship between customer and supplier. The fourth section, which covers development when more than two companies work together, examines the special problems, opportunities, and organization of this complex arrangement. The section also looks at how a company’s network of alliances influences—and in turn, is influenced by—the company’s development alliances. Finally, this section examines the mutual relationship between a company’s development alliances and its position in the industry’s network of alliances.

Research projects, which are not examined here, aim at the general advancement of knowledge by discovering new technologies, while development projects, the subject of this research-paper, use specific technologies to come up with new products or services. For example, pharmaceutical biotechnology, manipulating the genetic structure of cells to have them create specific therapeutic proteins, is a technology used to develop a specific new product such as insulin. In practice, however, distinguishing between research and development is not always simple, which is perhaps the reason that the two terms are sometimes used interchangeably.

Development is a process that usually starts with knowledge of technological or market opportunities. Strategic choices defining what is to be developed are made in the upstream phase of the process, while the downstream phase, which absorbs the bulk of committed resources, involves detailed design and testing. The process ends with a new product, service, or some combination, ready for full-scale operations and marketing. It may be used as part of a higher-level system such as an aircraft, it may be sold to customers, or it may serve both purposes.

Without forgetting the importance of resources such as skills, finances, and equipment, the development process essentially transforms existing knowledge resources into new knowledge. Some of this knowledge is tangible, such as design documents, but other aspects are tacit, meaning hard to articulate and write down. At each step of the process, participants receive information from previous steps and, using their own and the organization’s knowledge (the latter based in information technology and standard operating procedures), create new information that is passed on to succeeding steps. Knowledge creation also occurs when steps have to be redone. Ultimately, the new knowledge resources reside in the product or service, the participants, and the organization.

A development alliance is a collaborative effort—based on a legally enforceable agreement—between two or more independent organizations that contribute resources for the purpose of commercializing a product or service. Most research concentrates on bilateral relationships between business firms. The two companies may decide to share profits and decision making. On the other hand, one company may reap all of the profits and have the final say, while the partner company obtains a fee for its contributions and has some influence in decisions. For a product, the partners usually involve their design, manufacturing, and marketing departments, while for a service, the relevant departments might be technology, operations, and marketing.

Some development alliances also may involve other tasks, such as full-scale operations and marketing. In one approach, the partners share each of the tasks, while in another approach, one company is responsible for development and the other for operations and marketing. In the latter approach, development is still a joint effort as long as the firm in charge of development needs interaction with the partner to accomplish its task.

There are two main types of development alliances. Contractual arrangements depend solely on written agreements and verbal understandings. Equity relationships involve, as well as contracts, an operating entity in which the partners have a controlling stock investment. The operating entity might be a new joint venture organization formed by the partners, or it might be one of the partner organizations in which the other partner has taken a minority interest. A licensing arrangement, which involves the transfer of previously developed products or services from one firm to another, is not a development alliance.

Another way of classifying development alliances is by business relationships. Sometimes the partners are in a vertical alliance between a customer and a supplier. A bank and a telecommunications network provider might collaborate on providing Internet financial services for the bank’s customers. Other times, the partners are in a horizontal alliance between competitors. Two manufacturers of telecommunications equipment might work together to develop a new switch.

Characteristics of Development Alliances

Hagedoorn (2002) reported on aggregate instances of new research, development, and licensing alliances on a yearly basis for 1960 through 1998. No comparable data exists just for development alliances. First, there has been a clear pattern of growth, in terms of number of alliances, over the period. Second, companies have increasingly preferred contractual relationships to joint ventures. Third, high tech’s (mainly pharmaceuticals, computers, telecommunications, and semiconductors) share of these relationships has steadily increased; by 1998, it was 80%. Fourth, international arrangements between partners from different countries, which tend to concentrate in medium-tech industries such as automotive, consumer electronics, and chemicals, have exhibited a somewhat irregular and slightly downward trend. Fifth, nearly one third of all of the relationships initiated since 1960 have occurred in North America (overwhelmingly in the United States), while another 36% have transpired between North America and other regions.

Choosing A Development Alliance

If a company intends to develop a new product or service, there are two main alternatives: (a) going it alone or (b) entering an alliance.2 For all of the different components of a large, complex system such as an aircraft or auto, the company may utilize both of these alternatives, as well as nondevelopmental alternatives including open market purchases, licensing, and acquisition of another firm that has already developed a component. One way to analyze the two basic alternatives is to examine their costs and benefits of developing the exact same offering. This type of analysis assumes that a company is attractive enough to have willing partners and that there is at least one attractive partner among them. An attractive firm typically has resources that other companies want, such as innovative technologies or operations and marketing capabilities.

There are at least two other issues to keep in mind. First, while the cost-benefit analysis presented here concentrates on just the alliance alternative, going it alone may involve some of the same kinds of costs and benefits, which also must be considered in making a choice. Second, when a company already has an existing set of alliances, any decision on whether or not to enter a new development alliance is not completely independent of these past choices (Gulati, 1998). The sub sections “Leveraging Alliance Experience” and “Networks of Alliances” explain some of these connections.

Tangible Costs and Benefits

If a company works alone, it will have the new offering’s entire future revenue stream, but the tangible cost stream might reflect a need to acquire development resources. In an alliance, the company only receives a share of the potential revenue stream, although a larger market may exist if the company, say, has a strong presence in North America and the partner in Europe. The company’s tangible cost stream would be influenced by the level of the partner’s technical capabilities and would not have to include acquisitions of any needed resources that the partner already had.

An alliance makes sense (the present value of the company’s net returns tend to be higher) when the resources needing to be acquired are expensive and the partner already has them (Shan, 1990). Allying is even more likely if, in addition, it takes a long time to get the resources up to speed or if the new offering will have a short life span. Biotechnology start-ups, for example, want access to the costly manufacturing and marketing resources possessed by pharmaceutical firms in an industry where being first to market is crucial. A telecommunications firm planning to develop a new customized mobile phone chip destined to last just a few years will want to use costly manufacturing capabilities available from a semiconductor firm. These arguments, however, do not consider significant intangibles such as the costs of contracting and coordination, and the benefits of learning and flexibility.

Contracting Costs

Contracting (explicit transaction) costs are the direct and indirect expenses of negotiating, monitoring, and enforcing the written agreements that protect a company from being taken advantage of by its partner (opportunism).3 We can add the costs of finding a suitable partner and the lost sales revenue from missing the project’s market window due to disputes between the partners over issues lying on the critical path.

According to Williamson (1985), contracting costs should increase with the degree of specialization of the resources used in development (asset specificity). When a company’s specialized technology has little use outside of the current alliance, or when the company has few alternatives outside of the alliance to using its partner’s specialized technology, the partner’s bargaining power on contractual issues grows, making it harder for the company to reach a satisfactory agreement. To illustrate, by building a learning curve advantage over its competitors through specialized technical knowledge gained during prior joint development efforts with a company, a supplier can then seek more profits and decision-making control in the negotiations for the current development effort (Monteverde & Teece, 1982). Thus, due to these contracting costs, a firm’s willingness to enter an alliance decreases as development involves more specialized resources.

Another factor, the level of technological uncertainty, refers to the likelihood of unexpected events occurring in the future concerning a technology’s characteristics and consequences, including whether it eventually becomes obsolete. This type of uncertainty helps to augment contracting costs by triggering numerous occasions for having to renegotiate the written agreements. If, for example, a company’s technology turns out to be less cost effective than anticipated, the partner may want to revise the contract. Just for a development alliance, however, technological uncertainty is also associated with offsetting flexibility benefits, to be discussed later.

Contracts are an expensive way to protect firms from two important problems of development alliances arising from specialized technology and technological uncertainty. First, opportunities exist for confidential knowledge about a company’s technology to leak to the partner. The partner may then develop its own competing products or inform the company’s competitors. This leakage hampers the company from obtaining enough financial returns to make its investment in the technology worthwhile (reduces appropriability). Second—initially, at least—a company may be at a disadvantage in knowing about the partner’s technology (information asymmetry or impactedness). The partner may use this situation to misrepresent the technology’s worth (adverse selection).

Coordination Costs

In a development alliance, coordination must occur both within and between the partner organizations. It takes place largely through informal working level communication using the exchange of design, operations, and marketing information. The costs of this coordination are the day-to-day expenses of reaching mainly verbal agreements that achieve unity of effort among the participants in the development project (organization costs or implicit transaction costs). These costs are salient when one party takes advantage of superior bargaining power by, say, delaying its share of the work to gain concessions, and when the partners interpret and react differently to the same information (Gulati, Lawrence, & Puranam, 2005).

Coordination costs in a development alliance increase with coordination needs and decrease with coordination ability and willingness (Gerwin, 2004). The need to coordinate goes up with technological interdependence, the extent to which the work in one development activity affects the work in another. Technological uncertainty also raises needs because an unexpected event typically requires an integrated effort to deal with it.

Especially when time pressures exist, the ability to coordinate in an alliance suffers from the lack of a completely unitary chain of command. At least at the uppermost hierarchical levels, representatives of both companies usually make joint decisions. Willingness to coordinate varies inversely with concerns about knowledge leakage; the greater this concern is, the less a company wants to communicate with its partner. In spite of these problems, there are certain situations in which the coordination costs of joint development can be smaller than costs are when a company develops something on its own.

Learning Benefits

In a development alliance, a company learns not only technical knowledge about developing products and services, but also managerial knowledge about how to choose partners and participate in alliances. This learning occurs through contacts with the partner and by gaining experience in performing alliance activities (learning by doing).

Within the alliance, learning helps enlarge the profit pie. At the same time, by obtaining knowledge for which it was previously dependent on the partner, a company can increase its own bargaining power and thereby take a bigger slice of the pie. This opportunity to redistribute profits may create a “race to learn” everything that is useful from the other party and then exit the alliance (Hamel, 1991). There are also benefits for a company outside of the alliance if the company can transfer the learning to development projects undertaken on its own or with other partners.

A number of factors determine how much a company learns from the partner (Hamel, 1991). First, there must be some motivation such as a desire to fill knowledge gaps. Not every alliance, however, offers a suitable match between a company’s gaps and what the partner does best. When a financial institution and a telecom provider collaborate to provide Internet financial services, they may not have much interest in moving into each other’s business. Assuming a match does exist, the company must transmit its intent to learn to those of its employees who are in good positions to absorb knowledge from the partner.

Second, there is the partner’s willingness and ability to transfer knowledge. Willingness depends on the partner’s relative speed of innovation. A partner that innovates very rapidly, as compared to its ally, can afford to disseminate information about its recent technological advances. By the time the collaborator has utilized the information, the partner will have jumped another step ahead. Ability decreases to the extent that knowledge is tacit. Transferring tacit knowledge requires costly personal contact and experiential approaches such as working together in a joint team.

Third, a company must have absorptive capacity, an ability to recognize, incorporate, and utilize the partner’s knowledge (Cohen & Levinthal, 1990). This ability may be helpful only up to a certain point, because as the two companies’ existing basic knowledge becomes more similar, the less there is to learn from each other. Creating absorptive capacity is not an easy task. Suppose a company learns from its partner about the benefits of using heavyweight project managers for development projects. These are individuals with superior expertise and influence, yet their expertise takes a long time to evolve, and their influence depends upon the balance of power between the company’s technical managers and project managers (Takeishi, 2001).

Flexibility Benefits

When biotechnology start-ups entered the pharmaceutical industry, they had radically new technologies that incumbent pharmaceutical firms knew little about. Although the new technologies threatened to make an incumbent’s traditional chemical approach obsolete, the technologies had unproven market potential. A typical incumbent could have tried to compete with the start-ups by acquiring one of them and then developing products by itself. Instead, many adopted a transitional approach to acquisition by forming alliances with start-ups.

When alliances act as transitions, they have flexibility benefits in terms of various options for dealing with technological uncertainty (Folta, 1998). They offer a company—at less cost and risk—the possibilities of eventually acquiring the partner’s technology if it turns out to be a success, continuing the arrangement if the uncertainty persists, or ending the arrangement if the technology eventually does not live up to its promise. This approach reduces the company’s losses when the technology does not work out, but allows it to take full advantage of the technology’s success. In addition, by having the time to learn more about the technology, a company can block any attempts by the partner to misrepresent the technology’s value, make a more informed acquisition decision, and more smoothly incorporate the acquisition into its operations. It is easy to see why—at one time—Nortel had alliances with firms representing each of the three main competing mobile phone alternatives.

All of these flexibility and learning benefits may outweigh the high contracting costs associated with specialized technology and technological uncertainty. In fact, due to these benefits, a company seeking new technology may prefer a transitional alliance even when technological uncertainty is high (Folta, 1998). On the other hand, an alliance does not protect a company as well as an acquisition does from a switch by the partner with the technology to working with another company. As a result, having a lot of competitors discourages a company from entering a transitional equity alliance (Folta, 1998). The company must also have resources—in operations and marketing, for example—to entice the partner into an alliance.

Designing A Development Alliance

Managers can increase the benefits and reduce the costs of a development alliance by properly designing it. If both partners—instead of just one partner—invest in specialized resources, each is unlikely to take advantage of the other due to their mutual dependence. A good illustration of mutual dependence occurs in the joint development of custom integrated circuits. Suppliers need their customers’ plans for new end products to guide the development of future process technologies, and customers require knowledge of suppliers’ future process technologies to plan their new end products. Each party protects the other’s knowledge to encourage similar treatment.

Equity Alliances and Alliance Scope

Equity alliances have better features than contractual relationships for limiting contracting and coordinating costs. A company will be less likely to take advantage of its partner in order not to jeopardize its up-front financial investment and because the organizational structure provides some help in resolving disputes. To illustrate, the partners can sidestep the issue of which one owns technical knowledge created during the alliance, because the knowledge will belong to the joint venture (Gulati, 1995). It is also easier for a company to monitor the partner’s actions when they jointly own a single organization than it is when the company has a contract with a separate partner organization (Kogut, 1988). With the exception of the highest levels, the chain of command in a joint venture typically is more unitary than it is in a contractual alliance. Accordingly, there is less opportunity for time-wasting disputes.

Due to their specialized resources, technological uncertainty, technological interdependence, and potential for knowledge leakage, development alliances tend to have larger contracting and coordination costs than other types of alliances have. When an alliance includes development combined with full-scale operations and marketing, there tends to be even more of these costs. Alliances in which development is at least one of the tasks are therefore more likely to be equity based than contractual (e.g., Gulati, 1995). The downside is that due to the existence of an operating organization, equity alliances are more costly to initiate and to terminate, and have greater administrative costs, than contractual relationships.

Equity alliances are also better vehicles than contractual arrangements are for learning from the partner. Tacit knowledge transfer benefits from the greater face-to-face contact in the single organization of an equity arrangement. Simultaneously, it suffers from having to cross the organizational boundaries of a contractual alliance because this knowledge is difficult to separate from the rest of an organization (Kogut, 1988). On the other hand, for the same reasons that they facilitate learning from the partner, equity alliances should also exhibit a greater tendency for the leakage of tacit knowledge.

Another way to limit joint development’s contracting and coordinating costs is to restrict an alliance’s scope (Oxley & Sampson, 2004). Managers can reduce the amount of contracting and coordinating problems by narrowing the range of tasks to, say, just development as opposed to development, operations, and marketing. Restricting scope also seems to do a good job of limiting knowledge leakage. In fact, the closer partners are to being competitors—and thus, the more they are concerned about leakage—the more likely it is that their alliance involves just development as opposed to development and other tasks. Limiting scope and using an equity alliance seem to be substitute design alternatives. There is evidence that when scope is narrow, there is less need to use a joint venture, and that use of a joint venture broadens an alliance’s scope.

Leveraging Alliance Experience

A firm’s alliance experience, based on the number of its prior alliances, influences the costs and benefits of a current development alliance in at least three different ways (see Table 1). First, technical experience augments current technical learning and flexibility benefits (although it may also increase contracting costs by providing a bargaining advantage). Second, managerial experience about how to effectively choose partners and collaborate with them reduces current contracting and coordination costs, and improves current learning opportunities.

Third, trust—one party’s confidence in the good behavior of the other party—may have developed between the current partners as the result of repeated prior contacts. Gulati (1995) distinguished between knowledge-based trust, which is based on social norms such as equity and reciprocity, and deterrence-based trust, which is derived from calculations that taking advantage of the partner will lead to penalties such as loss of reputation or repeat business. Mutual trust reduces all the costs and increases all the benefits, yet a company with bargaining power may be tempted to take advantage of its partner when the partner trusts the company. Being trustful should be backed up by some countervailing power as well.

A company’s levels of technical experience, managerial experience, and trust depend upon the type of prior alliances in which it has participated. In the upper left cell of Table 1, prior development alliances with the current partner— such as a long-term relationship between a customer and a supplier—foster all three experience-based characteristics in the most meaningful ways. The buildup of managerial learning and trust, for example, represents an investment by both companies in intangible, specialized resources that help create mutual dependence.

Table 1  Effects of Alliance Experience

In the upper right cell, prior development alliances with firms other than the current partner supply somewhat less relevant technical learning and managerial learning, as well as hardly any trust. Nondevelopment alliances with the current partner (the lower left cell) contribute somewhat less useful managerial learning and trust than the upper left cell can because they involve other business functions and individuals from the two companies. These alliances should also provide little, if any, technical knowledge useful for development. Finally, nondevelopment alliances with companies other than the current partner (the lower right cell) have somewhat less beneficial managerial learning to offer than those in the upper left cell do, and they offer virtually no technical knowledge and trust.

Supplier Involvement in Development

Vertical alliance design has been influenced by the aims of long-term customer-supplier relations in the Japanese auto industry (Bensaou & Venkatraman, 1995). A typical auto contains 30,000 components, with suppliers accounting for as much as 70% of manufacturing costs and 50% of development costs. Consequently, the way in which an auto company works with its component suppliers has an important influence on its competitiveness (Takeishi, 2001).

In the Japanese approach, both customer and supplier make specialized investments in equipment and knowledge. Their collaborative activities include supplier involvement in the development process from the early stages. In “black box” development, for example, the customer provides general product requirements and then monitors the supplier, which is responsible for the rest of the work. Extensive knowledge exchange occurs through a customer development team that includes representatives of the supplier and uses the latest information technology.

We can look at supplier involvement as occurring during the development of an entire product that has a number of components or during the development of one of these components. Either way, supplier involvement refers to both the extent of the supplier’s participation, in terms of how much of the development work it does, and the quality of the relationship with the customer, in terms of the supplier’s influence in decision making (Primo & Amundson, 2002).

Supplier involvement has some important effects on the performance of a development project. Increasing the extent of supplier involvement in developing auto components (in combination with using more “off-the-shelf” parts) leads to a performance trade-off for an entire new car project. There is lower development time and cost, but also lower product quality (Clark & Fujimoto, 1991). To the extent that lower quality is due to suppliers’ inadequate proficiency, customers should work closely with them and invest in improving their capabilities. A high-quality relationship, on the other hand, improves the product’s quality and notably reduces the negative effect of the extent of involvement on product quality (Swink, 1999).

Factors Determining Supplier Involvement

In spite of the risks, both customer and supplier must want to participate in joint development. Suppliers risk dependence on the customer, technical knowledge leakage, and higher fixed costs. A need for economies of scale conflicts with the uncertainties and low volumes associated with development (Helper, 1996). Customers risk lower product quality, dependence on the supplier, knowledge leakage, and delays that might imperil meeting the target date for releasing the new product or service.

Customers also risk deterioration of their technical knowledge about a component. This increases the difficulty in understanding the technological interdependencies between the component and other components and in evaluating the component when the supplier uses new technology (Takeishi, 2001). Maintaining technical knowledge is also necessary to build trust with the supplier, to avoid the supplier’s gaining more bargaining power, and to perform development alone in the future, if necessary.

Not surprisingly, the extent of supplier involvement in a component’s development increases when the supplier can protect its design knowledge from leakage and when customers use incentives such as technical assistance and promises of future business (Helper, 1996). Novelty is another consideration. If both a mobile phone network and a new service component such as games or ring tones have novel features, developing the service requires a great deal of interaction with the network. Then, the network operator can best accomplish the development on its own without a service supplier’s help. If both the network and the new service have familiar features, the supplier can readily develop the service on its own. A degree of supplier participation with the network operator is appropriate when the network is novel and the service is familiar or vice versa (van den Ende, Jaspers, & Gerwin, 2006).

Supplier involvement in a component’s development, in terms of the quality of the relationship, depends on effective internal customer coordination (Takeishi, 2001). Otherwise, the supplier may, for example, receive conflicting signals from different departments in the customer organization. When a customer uses heavyweight project managers and engineers that rotate from the design of one component to another, it has better internal coordination. The relationship’s quality also improves with a number of other factors including the supplier’s dependency on the customer for sales.

Multilateral Alliances And Networks Of Alliances

Multilateral development alliances have more than two partners.4 These arrangements, which may include suppliers, customers, and potential competitors, can have vertical and horizontal dimensions simultaneously. They often occur where the knowledge needed for development bridges different industries. As one example, the first personal digital assistants were brought to market almost exclusively by multilateral alliances because development required knowledge of computer hardware and software, telecommunications, and consumer electronics (Gomes-Casseres, 1996).

Multilateral Alliance Basics

A system is a complex product or service containing a hierarchy of subsystems. New automobiles, for example, have major subsystems such as the body, engine, and transmission. Each major subsystem also contains subsystems; the engine includes the cylinder block and cylinder head, among others. Some of these subsystems, in turn, may involve minor subsystems which, in their turn, consist of individual parts. When the subsystems depend on very different technologies, it may be necessary for a number of firms from different industries to engage in joint development.

The system architecture, determined in the upstream phase of development, identifies the major subsystems and the technological interdependencies between them. Subsequent detailed development of each subsystem occurs within this framework. With a modular architecture, detailed development of the subsystems can proceed more or less independently because there are limited interdependencies between them. In an integral architecture, however, there are extensive interdependencies that lead to considerable information sharing among subsystem developers, often involving tacit knowledge.

Trade-offs frequently exist when choosing between a modular and an integral architecture, so that developers usually fix a system’s architecture somewhere between these two extremes (Ulrich & Eppinger, 2003). A more modular approach facilitates high subsystem performance, improvement of a subsystem without affecting the rest of the system, and use of the same subsystem in different systems, while a less modular approach offers high overall system performance. A Formula One race car has less modularity than a subcompact passenger car does.

Multilateral alliances often compete against each other or against individual firms on the basis of different architectures for the same system. The introduction of reduced instruction-set computing (RISC) workstations pitted multilateral alliances led by Sun, Mips, IBM, and other firms against each other (Gomes-Casseres, 1996). A particular architecture becomes the industry standard when most or all of the companies agree to follow it. Thus, another reason for a multilateral alliance is to include firms having enough customers and complementary offerings for the rest of the industry to accept its architecture.

Building a customer base is particularly important when purchases of a system by new customers increase the value to an existing customer (direct network externalities). The more new customers there are for Skype’s Internet phone calls, the more use existing customers can make of the service. Not charging for SkypeIn phone calls helps expand the customer base. Insuring a wide range of complementary offerings is critical when they increase the value of a system to customers (indirect network externalities). For example, if more movie studios adopt the Blu-ray optical disc format for their DVDs, as opposed to HD-DVD, the accompanying DVD players will become more attractive to customers.

Organizational Issues

There are two alternative theoretical structural models for a multilateral alliance (Gomes-Casseres, 1996). At one extreme, a centralized structure exists in which a firm, usually a system company, determines the architecture, perhaps using information from other organizations, and then plays the central role in coordinating subsystem suppliers or customers. Typically, the company has a bilateral alliance with each of its allies and it develops a number of key subsystems itself in order to reduce the number of collaborators. These allies have just a limited number of alliances among themselves. The development of a new car model often has important aspects of this approach.

At the other extreme, in a decentralized structure, a number of subsystem firms jointly determine the system architecture, perhaps using information from other organizations, and then may ally with more firms. Here, a firm’s bargaining power—connected to the importance of the resources it brings to the alliance—permits it to influence the formulation of the architecture. Each firm more or less develops one subsystem, so that there are almost as many companies as subsystems. The member firms adhere to a common overall agreement administered by a separate managing body funded and staffed by the members (a consortium). The architecture of the World Wide Web is the responsibility of the World Wide Web Consortium (W3C) representing over 400 governmental and private organizations.

In practice, a multilateral alliance’s structure depends on its system’s degree of modularity. The structure lies in a range between the decentralized end for a highly modular system and the centralized end for a slightly modular system. As modularity decreases, the managing body gives way to a web of bilateral alliances that spring up where technological interdependencies become strong. Each company will have an alliance with at least one of the others, and a small number of companies will be in locally central positions. As modularity decreases further, one company gravitates to the center as it gains bargaining power by internalizing key subsystems with particularly strong inter-dependencies. This shift from decentralization to centralization is due to mounting contracting and coordination costs as technological interdependence increases (Chesbrough & Teece, 1996).

Coordination becomes a particularly important issue as the number of firms and technological interdependencies increase. It is even more of a problem when a company not only provides a subsystem in a multilateral alliance developing a system, but also is the center of a multilateral alliance developing components of its own subsystem. The company must then act as a linking pin between the two alliances, particularly if the technical knowledge for its subsystem is rapidly changing.

Computer-integrated information technology is often used to try to reduce coordination problems. Argyres (1999), in studying the development of the B-2 Stealth bomber by four defense contractors, found that the information technology’s highly standardized rules for preparing and transmitting information reduced the central firm’s coordination needs. For example, it facilitated a more modular design of the aircraft sections entrusted to different companies. On the other hand, there were problems in selecting a common information technology because the companies had previously invested in their own different approaches. Similarly, adopting a common new product development process facilitates coordination, but achieving agreement on the steps in the process is not always easy.

Problems and Opportunities

A more centralized structure is well suited for improving the overall performance of a system with relatively low modularity. One central firm can readily coordinate changes to the rest of the system due to an improvement in a subsystem and can readily align all the subsystems into an integrated whole. The performance of RISC workstations from the group led by Hewlett-Packard benefited from a relatively centralized approach. This company, by developing and manufacturing chips and workstations in-house, achieved high alignment between them. The relatively decentralized group led by Sun relied more for chip development on allied semiconductor firms that had other customers’ needs to also bear in mind. The Sun group, with less alignment between chips and workstations, had a lower performing product (Gomes-Casseres, 1996).

A more decentralized structure does an excellent job of maintaining high subsystem performance in a relatively modular system. The subsystem firms can do development work more or less in parallel and independently. Specialization by each company in a particular subsystem, as well as competition among companies developing the same subsystem, facilitates the improvements. Having to conform to the existing architecture, however, sets limits on subsystem performance improvement.

The central firm or managing body must attend to a number of problems (Dhanaraj & Parkhe, 2006; Hwang & Burgers, 1997). First, a company may withhold high quality individuals and knowledge from the joint effort and still gain all the benefits (free riding). Second, overseeing the transfer of knowledge is critical so that the knowledge gets to where it is needed without leaking to nonalliance organizations. Third, there needs to be some control over the firms entering and exiting the alliance. If, for example, different companies insist that their architecture be adopted, the alliance may break apart. This happened to the ACE alliance, which wanted to establish a RISC architecture in personal computers. Another example is an alliance formed to defeat a common enemy that may not hold together if the threat disappears. The COSE group of UNIX firms, formed to compete against Windows NT, had trouble cooperating after the latter’s threat turned out to be overblown.

A multilateral alliance with a high percentage of competitors, versus suppliers or customers, also poses problems (Rindfleisch & Moorman, 2001). As this percentage increases, the degree of close relationships decreases and the extent of overlapping knowledge increases, both of which reduce technical learning. The overlapping knowledge, however, does provide a base of common understanding that leads to creative new products and fast development times. On the other hand, as the percentage of suppliers or customers increase, closer relationships and more distinct knowledge bases augment technical learning. The closer relationships also stimulate creative new products and fast development times.

Networks of Alliances

A company’s network of alliances typically includes all of those in which it participates, regardless of their objectives and tasks. Viewing a development alliance as embedded in this network offers some useful insights (Gulati, 1998; Powell et al., 1996). First, the company’s internal and joint development projects are complementary. A firm’s value as a partner depends on its internal development resources, and collaboration further enhances these resources.

Second, a company should manage its development alliances in an integrated manner rather than as separate endeavors. There is a need for example to transfer learning across the alliances. In another example, having too many development alliances can overextend a company’s limited resources (Doz & Hamel, 1998). To mitigate this problem, the company should try to create synergies by sticking to related applications (economies of scope). Concurrently, it is useful to extend the alliances across different industries to reduce conflicts among partners that compete with each other.

Third, any new development alliance that a company enters is significantly influenced by the company’s existing network. The network reduces potential contracting and coordination costs for the new endeavor because the company can choose a partner from among firms that it already trusts or can obtain information from them about partners it is considering. This, in turn, may allow the new alliance’s designers to avoid an equity arrangement in favor of a less costly contractual relationship. The existing network also contributes to a company’s technical experience, managerial experience, and trust, factors that should positively influence the new alliance’s performance.

Finally, while a company’s existing network influences a new development alliance, its existing development alliances are the driving force in evolving the network. Having a large number of existing development alliances is a prerequisite for later having a large number of new nondevelopment alliances, such as in operations and marketing. Apparently, the network evolves by exploiting the new product and services created by development alliances.

An industry’s network of alliances includes all the different types of alliances entered into by its companies. There is a mutual relationship between a company’s development alliances and its position in this network (Powell et al., 1996). First, the more existing development alliances that a company has, the more central it subsequently becomes in the network; in other words, it will have alliances with a larger number of other firms in the industry. This is because having existing development alliances leads to ideas for more joint development and to opportunities for other types of alliances that exploit the new products or services.

Second, the greater is a company’s centrality in the industry network, in terms of its greater access to other firms, the more development alliances it subsequently has. A central firm is in a better position to absorb the diverse technical knowledge needed for successful future development. Central firms are also likely to have more alliance experience and better reputations. Thus, there is a virtuous cycle in which development alliances lead to a company having a more central role in an industry’s alliances, which, in turn, stimulates more development alliances for the company.

Acknowledgments

This research was supported by a strategic grant from the Social Sciences and Humanities Research Council of Canada (SSHRC) and from two Canadian companies. I appreciate the helpful comments of Glenn Hoetker, Alan O’Sullivan, and Jan van den Ende.

References:

1. Argyres, N. S. (1999). The impact of information technology on coordination: Evidence from the B-2 “Stealth” bomber. Organization Science, 10, 162-180.
2. Bensaou, M., & Venkatraman, N. (1995). Configurations of interorganizational relationships: A comparison between U.S. and Japanese automakers. Management Science, 41, 14711492.
3. Chesbrough, H. W., & Teece, D. J. (1996). When is virtual virtuous? Harvard Business Review, 74, 65-73.
4. Clark, K. B., & Fujimoto, T. (1991). Product development performance: Strategy, organization, and management in the world auto industry. Boston: Harvard Business School Press.
5. Cohen, W. M., & Levinthal, D. A. (1990). Absorptive capacity: A new perspective on learning and innovation. Administrative Science Quarterly, 35, 128-152.
6. Dhanaraj, C., & Parkhe, A. (2006). Orchestrating innovation networks. Academy of Management Review 31, 659-669.
7. Doz, Y. L., & Hamel, G. (1998). Alliance advantage: The art of creating value through partnering. Boston: Harvard Business School Press.
8. Folta, T. B. (1998). Governance and uncertainty: The trade-off between administrative control and commitment. Strategic Management Journal, 19, 1007-1028.
9. Gerwin, D. (2004). Coordinating new product development in strategic alliances. Academy of Management Review, 29, 241-257.
10. Gomes-Casseres, B. (1996). The alliance revolution: The new shape of business rivalry. Cambridge, MA: Harvard University Press.
11. Gulati, R. (1995). Does familiarity breed trust? The implications of repeated ties for contractual choice in alliances. Academy of Management Journal, 38, 85-112.
12. Gulati, R. (1998). Alliances and networks. Strategic Management Journal, 19, 293-317.
13. Gulati, R., Lawrence, P. R., & Puranam, P. (2005). Adaptation in vertical relationships: Beyond incentive conflict. Administrative Science Quarterly, 26, 415-440.
14. Hagedoorn, J. (2002). Inter-firm R&D partnerships: An overview of major trends and patterns since 1960. Research Policy, 31, 477-492.
15. Hamel, G. (1991). Competition for competence and inter-partner learning within international strategic alliances. Strategic Management Journal, 12, 83-103.
16. Helper, S. (1996). Incentives for supplier participation in product development: Evidence from the U.S. automobile industry. In T. Nishiguchi (Ed.), Managing product development (pp. 165-188). New York: Oxford University Press.
17. Hwang, P., & Burgers, W. P. (1997). The many faces of multi-firm alliances. California Management Review, 39, 101-117.
18. Kogut, B. (1988). Joint ventures: Theoretical and empirical perspectives. Strategic Management Journal, 9, 319-332.
19. Monteverde, K., & Teece, D. J. (1982). Supplier switching costs and vertical integration in the automobile industry. The Bell Journal of Economics, 13, 206-213.
20. Oxley, J. E., & Sampson, R. C. (2004). The scope and governance of international R&D alliances. Strategic Management Journal, 25, 723-749.
21. Powell, W. W., Koput, K. W., & Smith-Doerr, L. (1996). Interorganizational collaboration and the locus of innovation: Networks of learning in biotechnology. Administrative Science Quarterly, 41, 116-145.
22. Primo, M. A. M., & Amundson, S. D. (2002). An exploratory study of the effects of supplier relationships on new product development outcomes. Journal of Operations Management, 20, 33-52.
23. Rindfleisch, A., & Moorman, C. (2001). The acquisition and utilization of information in new product alliances: A strength-of-ties perspective. Journal of Marketing, 65, 1-18.
24. Shan, W. (1990). An empirical analysis of organizational strategies by entrepreneurial high-technology firms. Strategic Management Journal, 11, 129-139.
25. Stuart, T. E. (2000). Interorganizational alliances and the performance of firms: A study of growth and innovation rates in a high-technology industry. Strategic Management Journal, 21, 791-811.
26. Swink, M. (1999). Threats to new product manufacturability and the effects of development team integration processes. Journal of Operations Management, 17, 691-709.
27. Takeishi, A. (2001). Bridging inter- and intra-firm boundaries: Management of supplier involvement in automobile product development. Strategic Management Journal, 22, 403-433.
28. Ulrich, K., & Eppinger, S. D. (2003). Product design and development. New York: McGraw-Hill.
29. van den Ende, J., Jaspers, F., & Gerwin, D. (2006). Organizing the development of complementary products: The influence of novelty. Best Paper Proceedings of the Academy of Management, Atlanta, GA.
30. Williamson, O. E. (1985). The economic institutions of capitalism. New York: The Free Press.