Putting It Together: How to Succeed in Distributed Product Development

Companies have traditionally been protective of the innovation activities they use in product and process development, seeing the activities as part of their crown jewels. That thinking, however, is starting to change. The increase in outsourcing, offshoring and alliance building has resulted in innovation efforts that often require the orchestration of multiple organizations separated by cultural, geographic and legal boundaries.1 At one extreme are centralized arrangements, with a clear lead organization and subsidiary “supplier” organizations. At the other are innovation efforts performed by decentralized “open-source” networks.2 In between is the realm of outsourcing and offshoring — the key building blocks in a trend called distributed product development or DPD, whose success factors are still not widely understood.

This article is an attempt to remedy that. Outsourcing complex product development work subjects companies to significant uncertainty. Companies can make perfectly reasonable decisions and still find themselves needing to make expensive changes, ranging into the millions or even billions of dollars. Our contention is that, by anticipating some of these changes, managers can reduce risk and, ultimately, cost.

We start by explaining why some seemingly well-conceived DPD strategies have failed to deliver the expected financial or performance benefits — information that may be useful to senior executives starting to put their faith in DPD and invest in it.3 Our central focus, however, is providing guidance to middle managers — who, after all, must make DPD work. Our recommendations have been developed over more than a decade’s worth of research and consulting.

The Trouble That Arises Around “Boundaries” — Two Cautionary Tales

We will start by acknowledging that DPD is no panacea. Two illustrations make the point. Example one: A multibillion-dollar computer server company concluded that it could exploit the benefits of reusability by developing one subassembly that it could use in a number of products. That was certainly feasible. However, the working prototypes the manufacturer developed demonstrated significant unwanted electromagnetic, mechanical and thermal interactions, which degraded the performance of the derivative products.

As the company turned its attention to studying the various performance impacts, the development of the derivative products got put on hold. Valuable time elapsed. Ultimately, the company realized that there was too much performance degradation by mixing and matching subsystems, and the idea of using the initial product as a platform was scrapped. Several million dollars in development expenses went down the drain.

Example two: A maker of medical imaging technology decided to switch the supplier it used to manufacture the high-performance processing boards that went into its flagship product. The incoming supplier was already a known quantity, having previously made circuit boards, quite reliably, for the manufacturer. However, the new assignment involved a much higher level of product complexity and performance. It also involved an expanded scope: The new supplier would have to design the boards in addition to manufacturing them. Somewhere in this handoff and amid the expanded requirements, things went wrong. When prototype testing began, the new boards exhibited significant unexpected and unwanted electromagnetic interactions with the rest of the system, causing a six-month delay in product launch.

To get the project back on track, the manufacturer and supplier were forced to take several difficult steps. First, the manufacturer pulled key engineers off other projects and added them to the imperiled one. Second, the supplier hired additional engineers to work with the manufacturer’s designers and improve coordination. And after the immediate problem was solved, the manufacturer took the extreme step of “re-insourcing” — that is, it acquired a regional design/manufacturing company to avoid similar issues in the future.

In both examples, problems arose across corporate boundaries. Boundaries are the places where different organizations that must work together are separated by being in different companies, industries, geographic locations, time zones or business cultures. Boundaries aren’t exclusive to DPD projects — they exist even at companies that design, test and manufacture every widget themselves. But boundaries are far more challenging when multiple organizations, in multiple places, are working together to develop complex products.

Defining and Spanning Boundaries: The Two Main Challenges of DPD

Defining the Boundary DPD requires that managers distribute work across various organizations. The key questions are, “Who does what — should we insource or outsource?” and “Where should we do it — onshore or offshore?”

To answer these questions, project teams must analyze processes at the level of activities, by which we mean a set of related tasks, performable by a single entity, resulting in specific deliverables. Activities tend to be constant across development programs and over time, as opposed to tasks, which are often situation dependent and harder to anticipate.

Theoretically, teams could analyze every activity across all development business processes, but in reality not every permutation is realistic or feasible. The general locations of organizational boundaries are often mandated by senior executives based on their strategic analyses, or on technology, market and cost factors.

When companies start DPD projects, we counsel them to focus on the potential boundary areas. There are, in particular, three interrelated issues that implementation managers must address:

1. Combining versus separating activities
2. Insourcing versus outsourcing and
3. Onshoring versus offshoring.4

Combining vs. separating activities Combining activities offers two potential benefits. If activities are highly interdependent, or coupled, combining them within a single organization can simplify trade-offs, ease contingency planning and eliminate the overhead associated with managing boundaries. The second benefit occurs if the output quality of the upstream activity is important but difficult to measure. In these cases, combining the activities improves accountability and motivates higher levels of performance.

Separating activities can also generate benefits. Let’s say the activities require different competencies. For example, one company we have worked with is expert at designing oil-well monitoring equipment but does not have the internal capability to design the specialized circuit boards needed to make the equipment work. In such a case, specialized organizations can more easily get the work done. It is also easier to monitor activities that have been separated, facilitating accountability and avoiding opportunistic behaviors.

Insourcing vs. outsourcing In any DPD initiative, there are two main reasons to keep activities internal. First, performing the activity may require unique physical, intellectual or human assets; that creates the possibility that a supplier with these assets could extract concessions, or could become a direct competitor. Second, if future uncertainty is high, contracting may be costly to negotiate initially and may require renegotiation.

On the flip side, there can be good reasons to outsource an activity. One is to get the best possible price in situations where there are multiple suppliers and low switching costs. The second is that suppliers may possess essential capabilities that are not available internally.

Onshoring vs. offshoring In most product development projects, the default preference is to keep activities onshore. There are two main reasons. First, it reduces “linkage” costs — which include tangible costs like travel, telecommunications and secure data transfer, and less tangible costs like late-night teleconferences, manager burnout and the potential for miscommunications.

Second, it minimizes employee turnover to keep activities onshore. Employee continuity during product development is important, and many widely used offshore locations have a reputation for churning through workers.5 In addition to the recruitment headaches it creates, this exodus exposes employers to a loss of proprietary information.

Offshoring occurs for multiple reasons. The main one is to gain access to sufficient talent and capacity at a favorable cost. Another important reason is to satisfy local content regulations to gain access to markets. A third reason can be to develop access to local market insights. For instance, in the smaller apartments that typically exist in Japan, there is a preference for smaller form-factor printers and display devices. A research and development executive might never make this connection if her operation was based entirely in the United States, for example, and was focused on performance regardless of the “footprint” implications.

Turning the factor analysis into recommendations After drawing process maps for the potential boundary areas, project teams should evaluate activities according to the above three interrelated factors. For adjacent activities, there will be a net recommendation of combine versus separate. For each activity, there will be a net recommendation of in versus out and on versus off. In most cases, the individual recommendations will not conflict with one another. Where they do, of course, the differences must be reconciled.

Spanning the Boundary Once the boundary has been defined, it will need to be spanned so that parties on both sides of the boundary can coordinate their work in an effective manner. (See “Crossing Boundaries.”) To do so effectively requires five supporting mechanisms:

• Appropriate incentives to align the organizations’ objectives;
• Clear specifications to describe how interactions should occur across the boundary;
• Shared information systems to collaborate with partners and to synchronize data;
• Human value chain integrators to cope with the inevitable gaps in specifications and to resolve minor disputes; and
• Appropriate governance structures to end disputes that the value chain integrators cannot resolve.

Incentives Organizational alignment is notoriously hard to achieve and requires the proper balance of financial and nonfinancial incentives.6 Financial incentives — as Einstein might have put it — should be made as simple as possible, but no simpler. Long, complex incentive schedules end up in the file cabinets of the lawyers, not posted above the desks of the project managers and engineers. Incentives should take account of what clients truly value, and should therefore help service providers make the appropriate trade-offs. At the same time, unintended consequences occur if incentives relate to things that are hard to measure, or are misaligned, ambiguous or biased.

Generally speaking, fixed-price contracts are best when the scope of the work is well understood upfront and there are unlikely to be any surprises during the execution of the contract. Cost-plus contracts work best for projects that are not well understood upfront, either because of the novelty of the project, because of uncertainty surrounding the implementation challenge or both.7

Of course, there is room for hybrid approaches. For example, in one case, Toyota Motor Corp. covered 70% of the overrun incurred by a plastics supplier after an unexpected surge in the cost of oil feedstock, a crucial input.8

It is also important to keep in mind, given the delays between actions (engineering work) and results (product sales), that there is a significant risk that activities whose output is obvious and immediate will be emphasized at the expense of activities whose impact is more subtle, and that won’t become visible until later.9 Put another way, the difficulty of inspecting most aspects of a service inevitably means that considerable weight is placed on those few remaining aspects that can be inspected. That can lead to problems unless there are nonfinancial incentives, too — such as the chance of repeat work and an implicit promise of a positive recommendation when the supplier needs it to secure other business. As every service provider knows, the best marketing is a delighted client.

While it may be tempting to push for low fees, working toward fair fees is probably smarter. Design services tend to be less “transactional” than, say, manufacturing services. Therefore, providers that feel like they’re being nickel-and-dimed can protect their margins in subtle ways that may not violate the letter of the contract but could lead to unsatisfactory outcomes. For instance, a provider might transition its best — and most expensive — engineers off a project. Or the provider might slip in extra service charges and fees as soon as a change request appears. Fair compensation combined with nonfinancial incentives can avoid this, and may result in better organizational alignment.

Project Specifications Providing clear requirements to partner organizations is among the most important activities when working across company boundaries. Nearly every manager we’ve met who has been involved in a DPD initiative has emphasized this point. A high-level manager in a large aerospace company summed up the issue as follows:

The Boeing Co. is an excellent aerospace company. Yet when we work [on a product] with them, we find that we speak different languages. We have different words for the same thing. And we have different ways of doing the same thing, such as qualifying parts. Most of our procedures don’t even correspond cleanly to theirs. But we know that both our companies are good at what they do. Sorting this out is difficult.

Cultural issues can make specifications even more problematic. An American supplier of capital equipment who participated in our research was asked by an engineer from an oil-services company in Asia whether the supplier’s equipment was “monkey-proof.” You bet, said the supplier, who had worked hard to provide user-friendly computer screens and had gone to the additional trouble of color-coding the equipment’s buttons. Six months later, when the manager visited the installation, he was brought to a jungle where, of course, his machinery was overrun by flesh-and-blood monkeys, happily gnawing through the wires that connected various pieces of equipment.

That is an extreme (and comic) example, but the import is clear: When dealing with specifications across cultures, it is best to “double confirm” a mutual understanding of intent and interpretation. (See “Mind the Gap.”) Nonnative speakers of a language can seem fluent but miss important subtleties or meanings. It is also true that we tend to underestimate the difficulty that other people have in understanding what we are trying to communicate. In other words, the curse of knowledge — the fact that once we know something, we can no longer imagine not knowing it10 — extends to the writing of specifications. When there are communications gaps, it isn’t necessarily because the person on the other side is not paying attention, is not trying, is not motivated or is not smart. The problem may lie with us, in our lack of clarity or patience.

The communication of specifications depends on how expert the service provider is. If the provider has limited expertise, it is useful to think in terms of a development plan. The best practice is usually to specify what needs to be done, and perhaps how not to do it (based on experience), without being overly prescriptive in terms of how it should be done. There are a lot of points on the continuum between tightly controlling the development process and simply throwing the completed work over the wall, as the engineers like to say. It is up to the company leading the product development effort to find the right balance. Managers can always transfer additional activities as the service provider develops expertise and proves it is up to the job. For that matter, managers can switch providers (or simply slow down and/or reduce the scope) if things go wrong.

When a service provider has significant expertise, it is more useful to treat the relationship as a partnership. Specify what needs to be done and explicitly define the major uncertainties and contingencies. That will force the service provider to consider carefully whether she can achieve the project objectives. (It will also, of course, keep the provider from claiming later on that the scope of the job increased and so the company is entitled to additional compensation.)

Shared Information Systems Product development requires companies to synchronize and exchange data across organizations — a requirement that is inherently challenging with a multipart, distributed project. For most of the 2000s, the most frequent solutions were on the low end of the technology spectrum — e-mail, Web conferencing, plain old telephone service — or did not use technology at all (such as face-to-face communications). Poor image quality undercut the claims surrounding video-conferencing systems and discouraged their use.

In more recent years, however, technology has been making more of a contribution to DPD. Product development partners can turn to some increasingly valuable technology, from collaborative software to far superior teleconferencing to shared enterprise resource planning systems.11 If the relationship between the partners is tight and both sides feel confident about the future, it is common for there to be joint databases or jointly run computer-aided design systems. And with recent improvements in bandwidth and computing power, virtual meeting technologies are finally starting to fulfill their potential. Several companies now offer “telepresence” systems, in which high-definition video and identical furniture are used to give individuals the sense that they are sitting in the same room, and can practically reach across and touch one another, even if they are separated by thousands of miles and a dozen time zones.

Value Chain Integrators Even with smart incentive schemes, precise specifications and leading-edge technology, there are many gaps that can create problems across the boundary.12 To address this, many companies employ personnel explicitly to face and manage the boundary. These value chain integrators, as we call them, are much more than simply program managers or relationship managers. Their job is to coordinate and negotiate across the supply chain interface to maintain the integrity of the product vision from initial concept to customer delivery. They do this by marshaling an exacting mix of technical and business skills. (See “Value Chain Integrator Skills.”)13

One communication skill is especially critical for the integrator, and that is the ability to clarify ambiguous specifications. There is something we call the 50:1 Specification Multiplier; it asserts that, for every word in a contract or specification, another 50 words are needed to clarify intentions, explain meanings and correct misunderstandings. (As an aside: We use 50-to-1 because that is the ratio of pages [500] in the Federalist Papers to the U.S. Constitution [10], the seminal document the papers were created to explain. Product specifications are rarely crafted as brilliantly as the Constitution and so typically require at least as much interpretation.) Without clarity of communications, a tremendous amount of time gets wasted on irrelevant tasks, and important tasks are left undone.

Value Chain Integrator Skills >>

Another critical skill is that of persuasion. The difficulty in many outsourced or offshored relationships is that the people on the other side of the boundary (the supplier side) do not directly report to the value chain integrator. In fact, the first level of common management may be many levels up in offshoring relationships and may not exist at all in outsourcing. In either case, the integrator lacks the power to compel the supplier to do something his way. The delays that occur when such issues get “escalated” — that is, when higher-level managers must step in and resolve them — can impede progress and hurt morale. That makes the skill of persuasion critical. “It’s all in the soft stuff,” one manager who has worked with value chain integrators told us. “It’s very hard to put in a job description. You must be able to play nice with others and you must be able to get things done just by the force of communication.”

There are several problems associated with using value chain integrators. The biggest is finding people who are qualified to do the work. The initial wave of integrators were middle managers who had deep and wide experience in manufacturing, design and other support functions within their once vertically integrated companies. As organizations’ product development efforts have become increasingly distributed, it has become harder to find people who have the requisite combination of skills and experience. Today, potential value chain integrators can occasionally be recruited from specialized education programs (like MIT’s Leaders for Global Operations), from the ranks of large management consulting businesses, from industries that remain vertically oriented in their product development efforts and from end-user companies.

Once integration personnel are in place, they need time to develop. Our research shows a significant learning curve for boundary-spanning effectiveness. There is also a high incidence of burnout, particularly with offshoring.14 If the integrators are located overseas, they need to be rotated back to the home country of the lead company within, at most, a few years. Otherwise, they will lose touch with the home market and with the company and lose effectiveness. If they are based in the home country, the meetings at odd hours (many offshoring partners are 10 to 14 time zones away from the lead company) and the need to travel across those time zones mean that organizations should rotate integrators out of their positions within a few years, lest they leave for an “easier” job with fewer time demands and less stress.

Providing appropriate compensation is also a challenge. Integrators can look like individual contributors even when managing a large “virtual” team; if that is the case, it may initially be hard to justify attractive salaries. Executives who were at Hewlett-Packard when it set up its value chain integration program in the 1990s found a way around this, explicitly compensating managers based on their span of control both internally and externally.

Governance Incentives, specifications and integration personnel sometimes will not be enough — they can fail. Some typical signs of failure are the appearance of ad hoc processes, heated arguments, strained relationships and runaway costs. At one company in our research, a development problem spiraled out of control, and there was so much mistrust and animosity between the project teams that it destroyed their working relationship. Senior executives at both companies tried to intervene, but it was too late: They could not salvage the program.

Setting up governance arrangements before initiating joint operations is key to heading off problems. By governance, we mean speedy and inexpensive procedures for dealing with the most likely issues and events — preventing and resolving disputes, and dealing with change. In the early 1990s, Mazda Motor Corp. and Ford Motor Co. established defined escalation paths as part of their partnership, analogous to the “red telephones” that linked Washington to Moscow during the Cold War and that ensured an avenue of negotiation before misunderstanding became catastrophe. That may sound like an exaggerated comparison to make, but if you have been part of a DPD effort gone wrong, you know that the analogy is not far off. When these things explode, it can be incredibly messy.

Conclusion: The Three Rules for Successful Distributed Innovation

Large-scale product development comes with risks that cannot be eliminated. The risks are even higher when different parts of the endeavor are distributed among different companies. However, there are three things that companies can do to take advantage of opportunities when they arise, and to avoid pitfalls.

Rule #1: Analyze your DPD ecosystem Product development is often seen — wrongly — as being a monolithic function. In fact, it comprises hundreds, even thousands, of interrelated and parallel activities. Product development managers need to have a clear sense of which activities create and sustain shareholder value, and which do not. Activities deemed to be noncore can often be safely outsourced. The trick is distinguishing between these and the core activities; the latter should be the organization’s focus. And if a decision is made to hand the work off, there should be specific recommendations about how the handoffs will work across internal and external organizational boundaries.

Rule #2: Have a plan for spanning boundaries The academic and popular press have at times banged the drum of modularity — the notion that it is possible to achieve a clean decomposition of work into parallel development efforts that can be seamlessly merged later on.15 Modularity does in fact have its applications. It usually makes more sense for a company to buy standard screws as opposed to making its own. However, most DPD efforts have too many interdependencies across the various subassemblies to rely purely on a modular approach.

Instead of attempting to assemble some idealized product from perfectly fitting components, managers should figure out ways to span organizational boundaries through appropriate incentives, specifications, information systems, people and governance. That is an especially important point as companies new to DPD routinely underinvest in their boundary-spanning capabilities.

Rule #3: Cultivate a readiness to adapt DPD is not a plan you set and forget. On the contrary, it is an ongoing process that should evolve in response to macroeconomic issues, industry dynamics and technological innovation. In just about every one of the examples of DPD that we have seen, something that was being done one way at the beginning was being done another way by the end.

Indeed, the only thing you can be sure of is that changes will be necessary. If you are going to use DPD, you need to create mechanisms to review, redefine and respan organizational boundaries. To do anything else is to put at risk the friendships and partnerships that allow DPD to create, rather than destroy, shareholder value.