October 2013 Download this article as a PDFAbstract

Twenty years ago, most companies developed their own products in a single location and brought them to market themselves. Today, original equipment manufacturers (OEMs) are enlisting partners on a global scale as subsystem designers and producers in order to create and deliver new products into the market more rapidly and more frequently. This is especially true for large, complex products from the aerospace, telecommunications, electronics, and software industries. To assure the delivery of information across organizational boundaries, new coordination mechanisms need to be adopted (boundary management). In this article, best practices are described on how OEMs and partners self-organize and use agile, cooperative techniques to maintain daily communication among numerous internal and partner engineers to better coordinate product design and system integration. This article focuses on examples from the aerospace industry; however; these tactics can be applied in any organization to innovate at faster rates, to make delivery times more predictable, and to realize shorter product development timelines.

Introduction

Competition in business is nothing new, and building a better product than your competitor has long been a key competitive edge. Over the past couple of decades, to achieve better competitiveness, product developers have put more focus on time, in particular, on rapid product development and timeliness. If developers can achieve rapid development, they can minimize cost risk, and when priority is given to timeliness, developers minimize the risk associated with the poor timing of entry to market. To realize both of these goals, large amounts of resources need to be managed over short periods of time. As development cycles have become even shorter, most original equipment manufacturers (OEMs) cannot physically amass the required resources or cannot justify the cost risk; so, OEMs have been seeking partners for every aspect of creating and bringing a product to market: technology, design, manufacturing, and marketing. Thus, partnering is being used to respond to the pressures of time, and also, to the complexity of amassing the required skills for product development (Littler and Leverick, 1995).

In 2004, the market demanded a new generation of regional jet aircraft with lower operating cost and with a seating capacity of 100–150 people. Bombardier Aerospace saw an opportunity and realized that due to lower-cost competitors in Russia and Brazil, the time to respond to the demand was short (Pritchard, 2006). However, following a corporate restructuring in 2003 and the need to develop two new business aircraft models, Bombardier lacked the resources to launch a new product line (Hébert and Taleb, 2009). Therefore, Bombardier chose to adopt partners who could completely design and build systems for its CSeries aircraft. Doing so allowed the company to share the financial risk with its partners (Pritchard, 2006). Without partnering, Bombardier would not have been able deliver the CSeries aircraft while simultaneously developing two other aircraft.

About the same time, Apple Inc. chose partnering for both the design and manufacture of the iPod, but this was for strategic and not financial reasons (Aboulafia, 2005). Not even President Barack Obama could coax Apple’s then CEO, Steve Jobs, to repatriate the manufacturing jobs from China back to the USA (Rawson, 2012). The reason that Apple chose their Chinese manufacturing partner, Foxconn, was based on who could build the greatest number of Apple products (e.g., iPhones, iPads, iPods) within the shortest period of time, while remaining flexible and adaptable to Apple's needs. Foxconn had the resources and could manufacture with a greater speed and on a larger scale than any US manufacturer (Rawson, 2012). Foxconn proved its ability to adapt quickly to Apple’s requests by needing only 15 days to hire 8700 industrial engineers to oversee the manufacturing of Apple’s products. By contrast, Rawson (2012) observes that it would have taken months to find that many qualified people in the United States.

In this article, we adopt the view of collaborative product development as suggested by Lawton Smith, Dickson, and Smith (1991): a collaborative relationship between firms aimed at innovation and the development of new products. In a review of literature on the topic of collaborative product development, Büyüközkan and Arsenyan (2012) list many characteristics: motivation, risks, and team infrastructure, as well as success factors. In terms of success factors for product development, there are: partner selection, relationships, leadership, trust, communication, etc. In this article, we focus on the daily procedures that are needed to make product development successful when working with partners. We focus on inter-team relationships and communication, in short, boundary management. Communication among design team members is supported by a large set of information-technology tools that include product-lifecycle management, project management, and databases, which we assume that companies use, but are not part of the discussion here. Our information and examples are drawn from the field of aircraft development due to our experience in this area; however, the concepts can be generalized to any industry that features technology innovation and product development.

Boundary Management

Boundary management is the use of coordination mechanisms to assure the delivery of material and information across organizational boundaries (Holland et al., 2000; Ancona and Caldwell, 2007). For product development, this is the assurance of information transfers between knowledge workers in terms of quality and timeliness. Ancona and Caldwell (2007) indicate that much research shows that delay in product development comes from the difficulty in coordinating the various groups involved. They also conclude that “the importance of boundary management… should not be underestimated” and that “high performing product development teams generally carry out more external activity than low performing teams”.

Organizations create structures to execute and support activities, where differentiated activities and structures are a result of the division of labour paradigm. Given the tendency to have highly differentiated structures and large physical distances between development teams due to globalization and partnering, timely and extensive communication across boundaries is imperative in order to have successful product development. This assertion is underlined by many authors (e.g., Sosa et al., 2002; Clark and Fujimoto, 1991; Wheelwright and Clark, 1992; Ulrich and Eppinger, 1995; Antaki et al., 2010).

Some of the research literature on collaborative product management discusses conflict management (e.g., Lam and Chin, 2005). However, we disagree with the use of the term “conflict management” when applied to design activities. When designers collaborate, designs are not created instantly, but are the result of a refining process in which many decisions are made with respect to geometry, quality, manufacturing methods, etc., by many participants who have intersecting interests in the design of a particular system component. This refining process is not a set of incompatibilities or confrontations that need to be settled, but rather requires a large number of communications and cooperative decisions. Boundary management provides mechanisms to identify and facilitate these communications and decisions, while minimizing negative impacts on designers such as schedule disruptions and high levels of interruption for consultation.

Conventional Versus Collaborative Models of Product Development

With the adoption of partners and collaborative product development processes, boundary management becomes very important for successful outcomes. Nevertheless, most organizations do not have the correct culture to perform boundary management well.

Figure 1 shows a schematic of a conventional design process. Starting at the top, engineers develop design models and produce drawings and reports using various forms of analysis. The models and analyses are passed to integrators who ensure that interdependencies among parts are harmonized so that subsystems work well together. Once designs are approved, production planning is done, and then, parts are made or purchased. When the parts are ready, the products are assembled. In this model, integrators are responsible for assuring timeliness and the level of quality. There are usually no formal processes for the required communication; the integrator relies on personal relationships with engineering and other groups, and each integrator decides on the form and frequency of communication.

Figure 2 shows a schematic of a typical process for product development that uses partners. In this case, Companies A, B, and C do the engineering and analyses for product development and their integrators make sure that subsystems will perform as required. Partner integrators forward documents during each design stage to OEM integrators, who give these documents to OEM engineers to review and approve the designs and analyses, confirming that designs meet requirements and that subsystems are harmonized. When designs are finished, it is usually the partner who makes the subsystems and delivers them to the OEM for assembly, or sometimes, the final product is assembled by a contract manufacturer. The supply chain makes sure that parts and subsystems are produced on time at the correct quality for assembly.

Figure 1

Figure 1. A conventional design process for product development

 

Figure 2

Figure 2. Product development with partners

The main differences between conventional and partnering product development are summarized in Table 1. In the past, most companies have used a conventional process similar to that shown in Figure 1 for product development, where coordination of activities is done on an informal basis. With a conventional process, there is no culture to deal with interactions with collaborators, no formal recognition of boundaries, and no formal mechanisms for managing the flow of information. When moving to product development with partners using a collaborative process, these informal communication mechanisms do not adequately address the needed coordination across more complex boundaries. A culture of boundary management is missing and is often not developed when moving to higher levels of partnering and collaboration.

Table 1. Major differences for OEMs when using conventional and partnering product development

 

Conventional

Partnering

Resources

In-house

Outside companies

Control

Internal supervision

Contractual partnerships

Activity

Create drawings and parts

Review drawings and documents that specify parts

Focus

Product development

Product development

The Review-Approve Process

An integral part of the process of developing complex products with partners is the review-approve process. On a macro-level, the OEM creates the ideas for a new product, contracts the design and building of the product to its partners, and then approves the subsystems built by the partners prior to their assembly into a final product. On a micro-level, for each item, the OEM gives the partner a description of the required appearance, materials, and functionality, then, the partner submits the finished design, and company integrators review and approve it. OEM and company integrators are responsible for moving the design forward between all the development stages: conceptual, preliminary, detailed, production, subsystem test, and assembly, where reviews occur at each stage of the process. Figure 3 shows the exchange between company and OEM integrators where, throughout each stage, many documents are exchanged as the design progresses. For aircraft development, this process involves tens of thousands of documents. Without formal processes for boundary management, the timely creation, delivery, and review of design documents is very difficult to achieve.

Figure 3

Figure 3. Processing documents in the review-approve process

Boundary Management Issues

Partnering results in several new issues facing both the OEM and its partners. To find the best partner, an OEM must be prepared to search globally, which requires it to create new types of relationships. This change in relationships due to global partnering leads to greater complexity in managing ever more diverse supply chains. The following subsections discuss some of the major boundary-management issues faced during product development.

1. New models for collaborative work

As discussed, OEMs are shifting from being designers and manufacturers to being work reviewers and approvers. In order to assure the seamless integration of subsystems developed by several partners, there must be continuous interaction among developers for the planning and execution of design tasks. Formal processes or procedures are necessary to ensure universal use of effective work scheduling and communication techniques with partners.

The adoption of agile methods for aircraft development has proven successful; weekly schedules are set for intermediate deliverables and daily scrums expose roadblocks. The immediate surfacing of problems that hinder work is absolutely necessary in order to overcome the high interdependencies among the design characteristics of various subsystems. The use of highly specific instructions from the OEM and the quick resolution of common issues assure that subsystems integrate seamlessly. The intent of boundary management in product development is to move relationships from being a contract-deliverable model to that of cooperative work, where appropriate mechanisms greatly enhance coordination for both the scheduling and pace of work.

2. New skills for partners and OEMs

When product development with partners is adopted, there is a significant shift in the roles of engineers for both the OEM and the partners. Partners are now doing the design and production of parts, and the OEM is using a review-approve process to ensure intended functionality and quality. The skills of both partners and OEMs must be upgraded. The partners need people who can lead design teams and the OEMs need people who can review the work of others, where reviewers need to have technical skills superior to designers, for they need to be able to resolve integration issues, which designers do not do well or for which they are not responsible.

Boundary-management skills are required by both the OEM and partners. It should be obvious that integrators on both sides need to be great communicators. Engineers and integrators need to resolve problems with regard to misunderstood design requirements and any uneven pace of work. So, both partners and OEMs must concur on and adopt coordination mechanisms (e.g., schedules, daily meetings, issue-escalation processes) that set an agreed pace of work as well as identify and resolve roadblocks quickly.

3. Partner agreements

Choosing the right partners is crucial. OEMs must create a new type of agreement that is based on cooperative work rather than a specify-and-deliver relationship. Are present suppliers willing to move to this type of relationship? Do they have the required skillsets? What conditions need to be negotiated to ensure success in the new arrangement, where success depends on higher competency, a new attitude towards collaboration, and new procedures to ensure good cooperation?

4. Project management

As mentioned, collaborative development requires new coordination mechanisms to deliver on time with requisite quality. More emphasis needs to be given to the ongoing management of process activities for timeliness and quality rather than wait for surprises at delivery. Project management of product development needs to move from a specify-and-deliver relationship where lateness and defects on delivery can be expected to one that emphasizes on-time delivery and first-time quality. Staff on both sides of the boundaries in the design process must adopt new skills for managing information flow.

Selecting a Partner

Once an OEM has decided on collaborative product development, the selection of partners becomes crucial. For now, both the OEM and partner are responsible for innovation, timeliness, and management of the increased pace of delivering to the marketplace. A well-chosen partner can drive a company to market leadership and long-term profitability, whereas a badly chosen partner can lead the OEM to disaster.

Below are some key considerations for selecting a partner with an eye on boundary management.

1. Direct evidence of the ability to use boundary management

A partner’s ability to use boundary management can be discerned directly by the degree to which their organization has been structured to allow for communication:

  • Dedicated personnel: Is there one or more individuals within the organization dedicated to ensuring communication among design teams?
  • Collaborative systems: Are systems in place that assist collaboration?

2. Indirect evidence of the ability to use boundary management

A partner’s ability to use boundary management can be discerned indirectly by looking at other factors:

  • Success of past projects: How well or poorly has a partner fared in collaborative product development with other OEMs? Have they demonstrated that they can support the complexity of designing products similar to yours?
  • Supply chain management: Supply chain management must move beyond purchasing to cooperation for mutual benefit as well as use boundary management to coordinate schedules and pace of delivery. How well do potential partners perform?
  • Training in boundary management: Does the partner’s training program include boundary management?

3. Selecting a partner to manage risk

One way of evaluating a potential partner is to consider how that partner helps the OEM to manage risk both strategically and operationally. The two main risks discussed in this article are cost and time to market, which are helped by good boundary management:

  • Cost risk: Which partners have proven their ability to create accurately designed products in a short time?
  • Time-to-market risk: Do partners have the competency and, especially, the attitude to manage development processes in order to deliver on time? Look at the past performance of potential partners to manage timeliness well.

Conclusion

OEMs are working more and more with partners to manage the risks of product development. Collaboration helps an OEM to better handle risk, but it requires better management skills, especially for the complex interactions between OEM and partner design teams. One of the key success factors for collaborative product development is the use of formal procedures for boundary management. OEMs and partners must use boundary management on a daily basis in order to enhance coordination for both the scheduling and pace of work. The successful use of boundary management depends on choosing the correct partners who will enthusiastically develop good working relationships and who will embrace boundary-management practices. Boundary-management tactics can be applied in any organization to innovate at faster rates, to make delivery times more predictable, and to realize shorter product development timelines.

Share this article:

Cite this article:

Rate This Content: 
No votes have been cast yet. Have your say!

Keywords: boundary management, collaborative product development, outsourcing, partnering, product development, review-approve process

Breadbasket