文档资料库>>Toward a theory of competencies for the management of product complexity Six case studies > 正文

Toward a theory of competencies for the management of product complexity Six case studies

Toward a theory of competencies for the management of product complexity  Six case studies

Available online at www.sciencedirect.com

Journal of Operations Management 26 (2008) 590–610 www.elsevier.com/locate/jom

Toward a theory of competencies for the management of product complexity: Six case studies
David J. Closs y, Mark A. Jacobs *, Morgan Swink, G. Scott Webb
Department of Supply Chain Management, Eli Broad Graduate School of Management, N370 North Business Complex, Michigan State University, East Lansing, MI 48824, United States Received 7 June 2007; received in revised form 19 September 2007; accepted 5 October 2007 Available online 17 October 2007

Abstract Business units in six Fortune 500 companies were studied to develop better understanding regarding drivers of product portfolio complexity and the means to manage them. Our research focuses on identifying important competencies for managing product portfolio complexity and on the development of appropriate theoretical explanations. We found three important competencies: product/technology portfolio strategy, organization and governance regarding complexity decisions, and product design and decision support systems. We explicate these competencies using a socio-technical systems theoretical perspective. Our ?ndings provide the basis for a model describing the impact of complexity and complexity management on business unit pro?tability. # 2007 Elsevier B.V. All rights reserved.
Keywords: Marketing–operations interface; Design–operations interface; Complexity; Product development; Socio-technical systems theory; Case study

1. Introduction Managers must regularly balance requirements for sales growth through increased product complexity (i.e., more features and variants) against requirements for enhanced operational ef?ciency through product rationalization (Salvador et al., 2002). Fisher and Ittner (1999) state that optimal levels of product complexity are dif?cult to determine in the face of con?icting cost and revenue implications because related decisions are neither simple nor singular. Typically, the complexity of a ?rm’s product portfolio is in?uenced by myriad

* Corresponding author. Tel.: +1 517 432 6467x288. E-mail addresses: closs@msu.edu (D.J. Closs), jacobsm@bus.msu.edu (M.A. Jacobs), swink@bus.msu.edu (M. Swink), webb@bus.msu.edu (G.S. Webb). y Authors listed alphabetically. 0272-6963/$ – see front matter # 2007 Elsevier B.V. All rights reserved. doi:10.1016/j.jom.2007.10.003

management decisions made in many functional areas over extended time periods. Many factors need to be considered when making these decisions, and trade-offs among various complexity-related outcomes are not always clear. Thus, managing product complexity effectively can be a daunting organizational task. In many ?rms the potential implications of having overly complex or overly simple product lines are not fully understood, nor widely recognized. This situation exists in part because little research has been done on the subject (Bayus and Putsis, 1999; Lancaster, 1990; Ratchford, 1990). Furthermore, theoretical underpinnings of product complexity management have not been well described. Investigation into the environmental and organizational factors in?uencing complexity decisions is needed to describe the evolution of product complexity. In addition, study of organizational and operational processes in?uencing product complexity is necessary to provide a foundation for an explanatory theory.

D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610


This paper examines product complexity management through rigorous case analyses (Eisenhardt, 1989; Glaser and Strauss, 1967; McDonald, 1985) of six global manufacturers of durable goods. The study is motivated by several questions: (1) What factors drive managerial decisions toward more or less complex product portfolios? (2) How do ?rms manage product complexity decisions to optimize their product portfolios? (3) What organizational structures, decision processes, and control systems are relevant and effective? and (4) What theories describe how organizations cope with product portfolio complexity? This research uses both literature and case study data to explore the signi?cant dimensions of product portfolio complexity, to identify factors in?uencing it, and to propose effective management competencies. Our ?ndings offer insights leading to a number of theoretical propositions, as well as a model describing the effects of product portfolio complexity and its management on business unit pro?tability. The paper begins with de?nitions and a brief discussion of product portfolio complexity bene?ts and detriments. Second, we describe the case study research strategy applied, including company selection, data gathering protocols, and analytical techniques. Third, we review the case study ?ndings, considering variations in qualitative data both within and between cases. This discussion leads to the development of the model and theoretical propositions, making use of a socio-technical systems perspective. The paper concludes with a discussion of limitations and future research opportunities. 2. Product portfolio complexity and its management This research focuses on product portfolio complexity of business units which design and manufacture tangible, discrete, assembled products. A product portfolio is de?ned as the complete set of possible product con?gurations offered by a business unit at a given point in time (McGrath, 2001; Meyer and Lehnerd, 1997). In general, complexity is a multifaceted concept. Webster (1964) de?nes complexity as: ‘‘1a: the quality or state of being composed of two or more separate or analyzable items, parts, constituents, or symbols 2a: having many varied parts, patterns or elements, and consequently hard to understand fully 2b: marked by an involvement of many parts, aspects, details, notions, and necessitating earnest study or examination to understand or cope with.’’

This de?nition indicates that the complexity of an item stems from a multiplicity of elements, as well as from relationships among the elements. Further, the combination of multiplicity and relational aspects creates dif?culties requiring resources be expended to process the item in question. These aspects are re?ected in complexity de?nitions from many different ?elds of research including organization design (Blau and Shoenherr, 1971; Flood and Carson, 1988; Price and Mueller, 1986), chemistry (Kotz and Treichel, 1996; Whitten and Gailey, 1984), physics, and biology, (Dooley and Van de Ven, 1999). Applying these conceptual aspects to product portfolios, we de?ne complexity as a state of processing dif?culty that results from a multiplicity of, and relatedness among, product architectural design elements. This de?nition is consistent with less formalized statements in the product design and development literatures (Baldwin and Clark, 2000; Gupta and Krishnan, 1999; Novak and Eppinger, 2001; Rutenberg, 1971; Grif?n, 1997; Randall and Ulrich, 2001). Product portfolio complexity creates dif?culties in supply chain process execution related to product development, supply, manufacture, delivery, and support. On the other hand, complexity can also increase sales through greater product differentiation (Kekre and Srinivasan, 1990; Lancaster, 1979; Quelch and Kenny, 1994). At some point, increased cost associated with added complexity will dominate the revenue bene?t (Lancaster, 1979; Moorthy, 1984; Quelch et al., 1994; Robertson and Ulrich, 1998; Sievanen et al., 2004; Thompson et al., 2005). The combination of diminishing sales returns and increasing costs due to complexity create the potential for an optimal level of complexity in a product portfolio. Given the multiple potential implications of complexity, ?nding and maintaining near optimal levels of product portfolio complexity are critical management decisions involving many ?rm functions. This task, product portfolio complexity management, is the domain of this study. We de?ne product portfolio complexity management as the collective set of decisions, supporting processes, value systems, and initiatives pertaining to determining and implementing the most effective product portfolio (i.e., mix of product variants, feature sets, and component choices). Researchers have addressed product complexity somewhat myopically, and often with the perspective that less complexity is always better. For example, some have focused on the inventory and risk pooling bene?ts from component commonality (Fisher et al., 1999; Hillier, 2000). Others have focused on reductions in


D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610

procurement cost resulting from reducing unique parts (Meyer and Mugge (2001). Another research stream focuses on the in?uence of product architecture on the ?rm’s ability to communicate effectively and coordinate design activities (Galvin and Morkel, 2001; Meyer et al., 2001; Sanchez and Mahoney, 1996; Ulrich and Tung, 1991). Yet another line of research relates to measures of research and development (R&D) effectiveness and the degree of modularity within a production process (Meyer et al., 1997; Qiang et al., 2004). Several studies examine how design architecture facilitates ?exibility (Baldwin and Clark, 1997; Chang and Ward, 1995; Galvin and Morkel, 2001; Sanchez and Mahoney, 1996; Ulrich and Tung, 1991). Lastly, researchers have examined the effects of complexity on product development cost (Clark and Fujimoto, 1991). These studies identify design strategies including component standardization and reuse schemes, modular product architectures, and platform-based design by which the operational cost of supporting a complex product portfolio can be reduced. However, the literature lacks research that address the comprehensive management of product portfolio complexity. It is important to study complexity management from a broader perspective to develop principles that can guide the integrated application of the strategies identi?ed in the previous studies. 3. Case study methodology Several researchers discuss the rigor and bene?ts of the case study research method (Eisenhardt, 1989; Ellram, 1996; Meredith, 1998; Voss et al., 2002; Yin, 2003). Consistent with these arguments, we employed a case study research approach. Theory describing product portfolio complexity management is immature, overly simplistic and in need of richness. Case research enables the study of complexity management within its ‘‘natural’’ setting, thereby yielding richer insights through observing actual practice in context (Weick, 2007). Before embarking upon the research, the research team created a case study research protocol (available from the authors upon request). This protocol was used to guide the overall study design and execution. 3.1. Case selection Case study literature dictates theoretical selection of cases as a prerequisite for rigorous case study research (Eisenhardt, 1989; Glaser and Strauss, 1967; McDonald, 1985; Meredith, 1998). We used the selection

methodology suggested by Miles and Huberman (1984). First, we established the boundaries for the study to ensure that selection criteria connected directly to the research questions. We began by selecting complexity management factors and in?uences discussed in the literature. The important factors were ?eshed-out in interviews conducted at the initial case study company, Computer Server Company (CSC). CSC was chosen because it had a reputation for well managed product lines, and it had actively engaged in initiatives to manage its portfolio complexity. Using the information gleaned from the CSC interviews, the research team developed a summary of the basic constructs underlying product complexity management, as suggested by Miles and Huberman (1984). We then used this framework to categorize a number of ?rms in an attempt to select ideal case candidates that were polar types, representing extreme situations in which complexity was observable (Eisenhardt, 1989). The research team brainstormed a list of candidate ?rms by ?rst identifying products and industries within the assembled, durable goods category that exempli?ed extremes along the dimensions identi?ed in Table 1. We then listed strategic business units (SBUs) from each targeted industry. We contacted companies in each of three selected industries. After speaking with representatives in seven companies, we selected and obtained participation from three SBUs in addition to the CSC. These ?rms were deemed to be different enough to experience signi?cant and varied complexity issues. In order to increase the likelihood of cooperation from the ?rms, we also limited the sample to exclude ?rms which might compete against each other. Later, as subsequent interviews at the four ?rms identi?ed additional complexity dimensions, we added two more case study ?rms to ensure a comprehensive analysis. It was determined that the cases had reached a point of theoretical saturation once these additional cases failed to contribute signi?cant new information about complexity management (Glaser and Strauss, 1967; McCutcheon and Meredith, 1993; Yin, 2003). Similarly, management interviews within each ?rm continued until the point of saturation was reached. The ?nal sample includes a SBU from each of six ?rms; all members of the Fortune 500. Table 1 compares the six SBUs across the complexity factor selection dimensions, along with other relevant company statistics. The ?rm names have been replaced by descriptive monikers. The sample ?rms are in the computer, aircraft, automotive, heavy equipment, telecommunications, and imaging equipment industries. They do not directly compete for the same market,

D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610 Table 1 Sample company characteristics Technological and commercial factors Industry clock speed (the pace of product introductions) Post sales support requirements (the duration and involvement of service and help required after the sale) In-house control of technology (the degree to which technological advances were promulgated by the business unit in contrast to external sources) Product functional complexity (the number of different types of systems incorporated within the product and the degree to which they were interconnected) Market diversity/demand variety (the number of market segments and degree of demand differences between them) Production volume (per line) Revenue (billions) Employees (thousands) Number of global markets served R&D expenditures/sales (%) a CSC H M L LAC L H M–H GAC M M H AEC L H H TEC H M L















M 91 330 160 5.9

L 10 37 120 6.9

H 180 390 200 4.0

L 4 9 160 3.5

H 37 69 73 10.0

M–H 16 56 130 4.8

CSC: Computer Server Company; AEC: Agricultural Equipment Company; LAC: Luxury Aircraft Company; TEC: Telecommunications Equipment Company; GAC: Global Automotive Company; IEC: Imaging Equipment Company. a Percentages are given at the ?rm level where business unit level data were not available. L: low; M: medium; H: high.

nor were they in alliances with each other to compete for complementary markets. The qualitative evaluations (high, medium, low) shown in Table 1 were set through discussions, clari?cation of complexity factor de?nitions, and eventual unanimous consent of the research team. The ?rms are all headquartered in the United States. All the ?rms serve global markets with the United States as their largest market. As indicated in Table 1, the variety of industries selected maximized differences in product types and breadth, lifecycles, production volumes, and product support requirements, thereby enhancing the external validity (generalizability) of the ?ndings. At the same time, we maintained environmental comparability across the cases by including only producers of durable assembled products. Additionally, all the ?rms design and manufacture products for end users, though these users may include both commercial and individual consumers. The variety represented within this group of ?rms increases the sample’s overall usefulness for theory building. 3.2. Data One of the distinguishing characteristics of case study research is that it utilizes multiple sources of evidence for evaluation (Eisenhardt, 1989; Patton and Appelbaum, 2003; Yin, 2003). The three data sources for this study include structured interviews, printed materials and quantitative data, and a research ?ndings

conference. Each type of data strengthened the analysis by allowing triangulation on important issues to crossverify insights and ?ndings. 3.2.1. Structured interviews Case interviews were conducted to gather structured interview data throughout 2005, and follow-up interviews carried on into early 2006. To represent the variety of perspectives that exist about portfolio complexity, multiple interviews were conducted at multiple ?rm locations throughout the US. Additionally, one US headquartered company had personnel of interest located in the UK. The interviews for these personnel were conducted by telephone with the research team assembled together in the US. Between 5 and 14 interviews were conducted at each ?rm, with an average of 10.5 interviews per ?rm. Structured interviews were carried out by personal visits by two or more researchers at each company location. Interviews were also sometimes conducted by telephone when schedules con?icted or when follow-up or clari?cation was needed. The duration of interviews ranged from 30 to 90 min. Different combinations of researchers from the team participated in different interviews in order to minimize bias. The interviews were guided by a structured instrument (available from authors upon request), though certain areas of the instrument were given more or less emphasis depending on the knowledge of a given interviewee. An introductory letter and the interview guide were provided to each


D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610

interviewee prior to the interview. New concept discovery was facilitated by encouraging deviation from the structured interview when the team uncovered novel or seemingly meaningful concepts revealed by interviewees. The interviewees included employees from multiple management levels and functions including marketing, production, engineering, R&D, procurement, and support services. Examples of speci?c roles within functions include brand manager, production manager, development engineer, product planner, Vice President (VP) procurement, and VP support services. Interviewees ranged from marketing technical staff to VP of Marketing, from production manager to plant manager, from product development engineer to VP of R&D, from commodity manager to VP procurement, and customer support executives. Interviewees had varied educational backgrounds, training, and career progressions. Interviewing at each ?rm continued until the research team concluded that information had become repetitive (Eisenhardt, 1989; Glaser and Strauss, 1967). In addition to the structured interviews, each interviewing team was provided a plant tour. Observations were made during plant tours for consistency with the spoken word and written policy. The overall result was a fairly full view of complexity management processes at each ?rm. 3.2.2. Printed and quantitative data At each ?rm, documents and other data were gathered to complement the interview process. These included con?dential policy and procedure manuals, presentation slide decks, marketing and promotional materials, and publicly available information. Examples of con?dential information include product development strategies and targets, technology roadmaps, revenue per product, and production rates. Examples of public information include information gathered from annual statements, 10K ?lings, and other data offered on public websites. In addition, several published articles describing some of the ?rms’ product management policies were drawn from the literature. Data from all of these sources were compared with other data in both within ?rm and between ?rm comparisons. 3.2.3. Conference As a ?nal measure to ensure our research had arrived at reliable and valid results, we invited each participating ?rm to send representatives to a one day conference where the research ?ndings were reviewed. Five of the six ?rms sent a total of twelve representatives.

Representatives from each ?rm made a presentation on programs and policies they had installed in an area of strength discovered by the research team. The research team presented brie?ngs on each of the competency areas, the ?rms’ strengths and weaknesses, and areas requiring additional research. Ellram (1996) states that in case studies, reliability addresses whether a replication of the study would create similar results. Conference participants agreed that the analysis had indeed captured the most salient points of managing complexity, thus supporting the conclusion that future researchers studying the same phenomena would generate similar results. External validity was also addressed through this one day seminar. Each participant found the conclusions reached by the research team to be meaningful and related to their industries and markets. These con?rmations support the conclusion that the research results are reliable, valid, and generalizable to other similar ?rms. 4. Analysis and discussion Consistent with standards for rigor in case study research, our analysis focused on ?nding patterns of management practice within and between ?rms (Adler, 1995). We desired to identify and understand differences in practice between ?rms and to determine the signi?cance of contextual in?uences on these practices (Poole and Van de Ven, 1989). Following the procedure recommended by Miles and Huberman (1984) and Eisenhardt (1989), multiple case interviews were ?rst conducted to identify the explicit and implicit management practices deployed by each business unit. Once the within-case analyses were completed, between case analyses were undertaken to compare and contrast the complexity management practices of the units, along with managers’ perceptions regarding their effectiveness. 4.1. Case descriptions The ?rst analysis level examined each SBU individually. The speci?c focus was to determine: (1) how managers within the ?rms tended to conceptualize complexity and its drivers; (2) what challenges are faced in the management of complexity; (3) what approaches are used to balance competing forces driving complexity. Following the interview guide, the research team gathered information describing each business unit’s industry and market characteristics, product and organizational management processes addressing com-

Table 2 Case descriptions
Computer Server Company Industry Dominant ?rm amongst several Limited control over technology advances Transitioning from high to moderate growth Luxury Aircraft Company Dominant ?rm amongst few Cyclical Global Automotive Company Mid-level player Mature Agricultural Equipment Company Major player among a few Mature Telecommunications Equipment Company One of ?ve ?rms Rapid growth globally Imaging Equipment Company Mature Highly competitive


Signi?cant cost pressures


Innovations also come from suppliers and service providers

Technology paced by new entrants EU hazardous substances act forcing updates

D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610

Heavily regulated Avionics NPD cycle shorter than production lead time Market Characteristics Average product life cycle ranging 2–5 years Customers accustomed to working directly with manufacturer Distinct categories: corporate buyers, individuals, and ?eets High levels of customization with many change orders

Technology paced by suppliers

High control of design elements Innovations also come from suppliers Premium placed on reliability, durability, and increasing users’ productivity Product life cycle estimated at 15 years Style and technological novelty are the key differentiators Relationship with customer is controlled by service providers who may value different attributes than the consumer e.g. cost and compatibility with existing infrastructure Product life cycle about 12–18 months

Global with regional distinctions requiring accommodation within the product Presence of meaningful niches

Price focused consumers that express a decreasing appreciation for variety Increasingly customers are expressing interest in a solution not a product

Global market with relatively consistent requirements across regions

Sensitivity to excess weight inhibiting competitiveness of a standard con?guration

Requires high level of reliability, durability, and performance

Independent dealers are point of customer interaction

Product reliability, productivity enhancing characteristics, and cost are the attributes most valued by the market

Product lifecycles 15–30 years Portfolio Management Focus is on managing customer options Options dropped and added in the same proportion over the product’s life cycle Platform product with variations to extend the useful life of the design Offer a product in each segment of the private aviation market

Relationship with customer is through increasingly powerful dealer networks Differentiated products to dominate speci?c niches Extensive use of roadmaps to guide the complexion of the portfolio

Multinational design and manufacturing create inconsistent products Focus is on providing feature packages tailored to speci?c applications Cover the full breadth of each market segment in which product competes Rapid introduction of new styles based upon a common platform Identify and incorporate ‘ hot’ features into new and existing products to maintain market excitement Services are an increasingly important part Products for the ‘intensive use’ distinct from ‘casual use’



Table 2 (Continued )
Computer Server Company Increasing focus on design reuse through ‘‘common building blocks’’ initiative Organization Portfolio Management Team (PMT)—functional heads in each division. PMT’s allocate resources to new opportunities, and focus on markets, competition, and revenue growth Integrated Product Management Team—sales personnel, systems architects, and supply chain managers. Reports to PMT, reviews plans for NPD, feature/product withdrawal, approves NPD concepts and controls funding. Product Development Team (PDT)—marketers, engineers, operations personnel. PDT’s guide a speci?c NPD project and report to the PMT High level teams to foster interdivisional collaboration including:  Development Executive Council—R&D executives from all divisions chartered to improve commonality  Design Councils—to commonize subsystem architecture across lines  Commodity Councils— engineering and procurement managers develop and manage preferred parts process No coordinated approach to managing complexity Luxury Aircraft Company Global Automotive Company Reliance upon suppliers for feature development Agricultural Equipment Company Telecommunications Equipment Company Imaging Equipment Company Refreshes of existing products with few new introductions Product Deployment Process representing engineering, marketing, supply management, and accounting Centralized procurement Only design for ‘intensive use’ products is fully internalized. High reliance on outsourced engineering and packaged solutions (badge engineering) Technology development is integrated with NPD

Integrated information system to promote opportunities to reduce component complexity

D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610

Employee suggestion system targeting manufacturing process improvements

Centralized control of additions to the database

Primarily responsible for market research, de?ning the business environment, and setting performance, cost and commonality objectives

Standard, global purchasing standards and processes

Commodity teams have been assembled to seek opportunities for component reuse

Development divided between two groups. Advanced engineering is forward looking and working at the conceptual level. The second group is located several miles away and takes the output from advanced engineering and creates both an embodiment of the concept and the detail design work

Core technology development independent of product development which together are independent of feature development Numerous teams at multiple levels often incorporating multiple functions to coordinate development. For example, engineering, procurement and ?nance collaborate to make decisions on new components. Another example is the leaders of the three development groups meeting several times per year to ensure efforts are harmonized

Teams accountable for cost and schedule of the project

Extensive use of strategic roadmaps

Commodity teams tasked by CEO to reduce complexity at three levels; parts, modules, and architectures Limited information system infrastructure hampering the effectiveness of these teams

Program Management Team composed of mid and senior level managers from marketing, sales, design, quality and supply management drive design for business impact initiatives

Formally connects technology, decision support, and knowledge management

There is no formal system for managing product complexity. There is a complete reliance upon ‘tribal knowledge’

Lean staf?ng levels in engineering to encourage design reuse

Strategic sourcing teams, composed of buyers, coordinate complexity reduction programs with suppliers

Eleven strategic commodity teams reporting to the CTO

Matrix of approximately 500 attributes used to drive standardization across lines Design reviews in NPD include comparison of lifecycle costs for new verses reused components Additional revenue per additional feature Percent reuse and degree of commonality No formal commonality targets

Usually consist of engineering, procurement, product teams, consumer experience, and software Metrics Revenue impact Percentage of feature reuse Con?icting measures of success Con?icting rewards Complexity targets Percent reuse targets for each design area Parts per platform Parts per model New product/total Number of model variants/total model sales Swappable component types/total component types

D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610

Marketing ! market share Production ! cost Engineering ! patents Primary Principles Separation of planning and development activities for component technologies from ultimate products Use of teams to improve decisions Customer observable features and attributes should be differentiated and opportunities for complexity reduction elsewhere should be pursued Commonality and differentiation are not incompatible

Model variants/ model sales

Commonality should be planned and incorporated through the organization

Strategic planning of technology using roadmaps

Customer focus and market driven

Use of teams to guide decision making

Strong commitment to voice of customer and embodying it in the ?nal manifestation of the product

Single global design with consistent global manufacturing

Disciplined introduction of new features

Use highly structured management approaches

Drivers of the business should determine how to implement supply chain processes Suppliers and dealers are key team members

Strong market segmentation principles

Centralized purchasing Strategic partnering with service providers


Progress due mainly to imposition of new controls and metrics, integrated decision making processes, and cross functional involvement

Employee input system will save 7–8 million dollars

Reduced product development times

Extensive supplier rationalization and involvement

$600 million dollar cost savings realized from using common components and standardizing supplier relations

None reported



Table 2 (Continued )
Computer Server Company Limited application of data base and decision applications Luxury Aircraft Company Target costing resulted in faster product development with lower certi?cation costs Global Automotive Company Agricultural Equipment Company Reduced number of platforms from 4 to 1, lower end products gained greater reliability but total portfolio cost reduced Moved from MTS to MTO on a highly seasonal product Cultural resistance to information system Funding for component development still tied to product development Credibility of core technology teams not yet established Opportunities to ‘manage the shelf’ not fully identi?ed Communicating the global impact of product design choices Aligning reward systems Lack of a technology implementation strategy Cyclical markets No formal cost bene?t analyses Lack of clear rules for the addition of features Telecommunications Equipment Company Imaging Equipment Company

D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610


Feature cost estimation capabilities inadequate and not credible Poor understanding of market responses to option withdrawals

Failure to communicate and consider life cycle and supply chain costs of options

Impending retirements will decimate ‘tribal knowledge’ system Lack of cross functional information ?ows will impair the ability to harmonize business processes and implement complexity reduction initiatives globally Culture of customization impairs ability to offer more standardization

Rapid growth in underdeveloped nations

Strengthening governance initiatives to increase reuse Include cost of spares inventory in decision support models Considering overall life cycle and supply chain costs


Easier to design new than to reuse

Constant technological change of market

Failure to capture lessons learned Dominance of marketing and culture of adopting voice of customer

D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610 Table 3 Cross company comparison CSC Environmental drivers of complexity Technology dynamism Control over technology Product durability (support requirements) Number of product functions Market/use diversity Value of product performance increments Regulation (certi?cation requirements) Industry standards Retro?t (backward compatibility) requirements Product reliability requirements Size of capable supply base Recurring/non-recurring life cycle costs Time to market pressure Price sensitivity of demand (pricing power) Economics of product development CSC Complexity management competencies Product/technology portfolio strategy Organization and governance Design and decision support systems 2 1 2 2 2 3 6 4 1 2 6 4 3 2 3 5 3 5 AEC 6 6 5 2 5 5 3 2 6 5 5 5 2 2 2 AEC 2 4 4 GAC 4 5 4 3 1 4 5 3 2 4 1 4 3 4 3 GAC 3 1 1 IEC 3 3 2 4 3 3 1 1 3 2 3 2 4 5 6 IEC 4 4 5 LAC 5 4 6 1 6 6 6 4 5 6 6 6 1 1 1 LAC 5 6 6 TEC 1 1 1 5 2 2 4 5 1 1 4 1 6 6 4 Smaller ranking ! more complexity


1 = more dynamism 1 = less control 1 = less support requirements 1 = more functions 1 = more diversity 1 = more value attached to smaller performance increments 1 = less regulation 1 = less industry standards 1 = less retro?t requirements 1 = less reliability requirements 1 = larger supply base 1 = higher recurring/non-recurring ratio 1 = less pressure on time to market 1 = less price sensitive (more pricing power) 1 = lower ability to leverage designs TEC 1 3 3 Smaller ranking= higher competency 1 = Best of six companies 1 = Best of six companies 1 = Best of six companies

CSC: Computer Server Company; AEC: Agricultural Equipment Company; GAC: Global Automotive Company; IEC: Imaging Equipment Company; LAC: Luxury Aircraft Company; TEC: Telecommunications Equipment Company.

plexity throughout product life, metrics and guiding principles, recent results and perceived challenges related to product complexity management. A seven to eight page case description was written for each of the six SBUs studied. For brevity, this information for each business unit is summarized in Table 2. The table reveals interesting ?rm differences regarding how managers tend to perceive and operationalize complexity in their product portfolios. Differences in operating environments also pointed out a wide array of external drivers and constraints on complexity-related decisions faced by the ?rms. Notions of complexity within product de?nitions varied greatly across the ?rms. Organizational structures and decision processes related to product and technology management also varied in terms of degrees of centralization, formalization, and division of labor. These important differences are discussed more fully in the following sections. 4.2. External environmental drivers of complexity While increases and decreases in product complexity are often planned, there are a number of external environmental factors that motivate or constrain the

managerial complexity-related choices. Table 3 lists and compares environmental complexity drivers uncovered across cases. Through joint discussions supported by our notes and company documentation, the research team ranked each company on each factor. An important driver of portfolio complexity encountered in the case studies is technological change created by suppliers or other agents outside the ?rm’s control. Managers in the Luxury Aircraft Company (LAC) pointed out that certain technologies such as avionics dramatically and rapidly evolve. LAC’s challenge is to offer new products exploiting these technological improvements, while at the same time maintaining the ability to support or replace existing avionics suites that have been in use for as long as ?fty years. Additionally, ?rms like LAC and CSC have little direct control over core technologies embedded in their products. They are forced to increase product complexity because new products have limited potential to capitalize upon the previous version’s architecture. Market diversity drives greater complexity. At Imaging Equipment Company (IEC), we observed that product lines targeting multiple operating environments required more variants to meet market requirements. For example, IEC produced multiple power supply


D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610

variants in order to meet US and EU requirements, multiple interfaces to account for cultural and application differences, or choices of light or heavy duty engines to account for usage differences. Similarly, companies producing ‘‘fashion-driven’’ products are driven to increase complexity in order to capture additional sales. For example, managers at Telephone Equipment Company (TEC) and Global Automobile Company (GAC) attached a much greater market value to trendy or stylish features than did managers in companies such as the Agricultural Equipment Company (AEC). LAC provided an extreme example of market driven complexity. They were willing to change any non-airframe feature for every customer. As a result, no two aircraft are con?gured identically. Our study also uncovered a number of external factors that constrain increased product portfolio complexity. Regulation or other mandated standardization clearly drives ?rms towards reduced portfolio complexity. The need for compliance, compatibility, and product reliability tends to motivate design reuse as well. Managers in LAC, CSC, and AEC felt most constrained by external requirements, whereas the IEC and TEC felt the least constrained. Interviews identi?ed reduced complexity is also motivated by industry structure, economic structure, and market pressures. For example, at TEC, the life of iconic features is short, thus requiring managers to launch new products faster. This situation tends to drive design reuse (and lower complexity) in both the overall product architecture and at the component level. The economics of new product development was found to be a strong driver of portfolio complexity (Krishnan and Gupta, 2001). For example, high product development and certi?cation costs signi?cantly curtail the product offerings of LAC. At CSC, the ease of designing new features combined with a heavy bias placed on revenue growth over pro?t growth resulted in unpro?table feature proliferation. Product life and the lifetime support cost were also identi?ed as complexity drivers. For example, AEC’s commitment to long-term customer satisfaction coupled with spare parts support for decades old equipment models required them to maintain signi?cant levels of spare parts inventory. A company’s market power also in?uences complexity. The IEC has experienced signi?cant margin squeeze from the loss of pricing power and felt the need to differentiate its products accordingly. Similarly, TEC found that a loss in market power forced them to focus on iconic and differentiating features built on common platforms.

4.3. A socio-technical view of product portfolio complexity management competencies Our observations indicated that effective complexity management requires developing mechanisms for coping with external complexity drivers, as well as developing remedies for internal organizational weaknesses and de?ciencies in product lifecycle management. These infrastructural weaknesses often create ‘‘unintended’’ complexity in the product portfolio, generally owing to a lack of disciplined and comprehensive decision-making processes or systems. For example, in all of the companies we studied, the unavailability of total cost data resulted in a lack of understanding regarding the cost to create and maintain a new part number. Managers consistently felt that this led to poor decisions regarding the creation of new parts. Similarly, many managers noted that due to the inaccessibility of product design data, design engineers often found it easier to create a new part than to re-use an existing one, leading them to increase product portfolio complexity unnecessarily. Organizational barriers also inhibit effective decision-making regarding complexity. Managers stated that decisions were commonly made without full representation of concerned stakeholders. Moreover, our conversations with these stakeholders revealed their widely varying perspectives on complexity. It was clear that different stakeholders held differing values, operated under differing norms, and often had con?icting goals. The observations and the resulting propositions are consistent with a variety of theories. For example, the advantages regarding effective use of information and the limitations arising from ineffective information management are consistent with information processing theory (Galbraith, 1973, 1977) as well as the knowledge based view of the ?rm (Grant, 1996). However, these theories are incomplete in that they do not fully explain the interdependencies between managerial and technical issues. The dynamic capabilities perspective (Teece et al., 1997) is useful in that it addresses the con?guration of resources enabling successful complexity management in an environment of change. However, not all of the study ?rms are in dynamic markets and path dependency was not pronounced as an issue. After careful consideration, we realized that the SBU’s ability to make effective complexity-related decisions is limited by both technical and social factors. This led us to adopt socio-technical systems (STS) theory (Avgerou et al., 2004; Cherns, 1976, 1987;

D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610 Table 4 Socio-technical systems design principles Socio-technical systems theory design principles (Cherns, 1976, 1987) (1) Compatibility: the way that the design of a work system is done should be compatible with the design objectives


Applications to product portfolio complexity management Compatibility: product design and life cycle management processes should be compatible with a guiding product/ technology portfolio strategy that is itself compatible with the business strategy Minimal criteria speci?cation: important points of product differentiation should be clearly identi?ed. Product features that are transparent to customers should not be differentiated Variance control: social norms, values and rewards should be oriented toward controlling variances between actual and desired levels of product complexity. Exporting undesirable complexity from one product generation or product line to another should be minimized Boundary location: differences in status across functional groups should be eliminated. Boundary spanning teams should be created to jointly make complexity related decisions Information ?ow: information systems should provide reliable market information, product speci?cations and component information quickly and easily to designers and other decision makers Power and authority: cross-functional decision-making teams within the complexity management work system should have primary responsibility for tracking and achieving portfolio complexity goals. They also should have the authority required to enforce related policies The multifunctional principle: mechanisms such as job rotations and training should be used to increase decision-maker awareness of both the objectives and constraints of stakeholders in changes to the product portfolio Support congruence: metrics and incentives should motivate appropriate decisions regarding complexity. Product complexity delivery processes such as marketing and manufacturing should be aligned with and supportive of the outputs of the product complexity management system Transitional organization: transitions in the product technology portfolio structure should be planned and managed, not simply ‘‘realized’’ as an outcome of independent product development and retirement efforts Incompletion: markets, technologies, and products are constantly changing. Complexity management systems should be continually updated to re?ect current realities

(2) Minimal criteria speci?cation: no more should be speci?ed than absolutely essential, that which is essential must be identi?ed

(3) Variance control: variances should not be exported. The social subsystem is the most effective system at controlling variance

(4) Boundary location: social and technical boundaries should not be drawn to impede sharing of information, knowledge or learning (5) Information ?ow: information should be provided to those who require it when they require it. Information for action must be directed ?rst at those who immediately need the information (6) Power and authority: Those with a need to carry out responsibilities should have access to resources, materials and authority to carry out the responsibility. Those with the resources must act prudently and ef?ciently (7) The multifunctional principle: systems that expand people’s roles to accommodate change create organic systems. Systems that hire a specialist to accommodate change confuse the organization (8) Support congruence: supporting systems and sub-systems need to be congruent

(9) Transitional organization: ?rms are constantly in transition from old to new. Transitional technology and society must be designed just as new organizations are designed

(10) Incompletion: no state of equilibrium exists. Design teams must be consistently prepared for continual change

Clegg, 2000; Trist and Bamforth, 1951) as a potentially useful perspective for interpreting our ?ndings. STS has been primarily applied to long-linked, production-like operational environments (Pava, 1986; Thompson, 1967). However, a few researchers have started to employ STS to examine the nonlinear, problem-solving oriented work systems involved in product development

and life cycle management (Hirschhorn et al., 2001; Kaghan and Bowker, 2001; Purser, 1991, 1992; Taxen and Svensson, 2005). To our knowledge, we are the ?rst to apply STS to the domain of product portfolio complexity management. STS offers a process-oriented view of work systems combining the social system (people, their values, roles,


D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610

and inter-relationships), and the technical system (techniques, tools, and procedures) (Trist and Bamforth, 1951). Two central tenets of STS provide important considerations for our analysis. First, STS argues that there should be ‘‘congruence’’ between the technical and social systems of a process. Social and technical systems must be jointly optimized so that all aspects address and support relevant outcomes. Inconsistencies must be harmonized. Second, STS takes an ‘‘open systems’’ view of organizations. Thus, it maintains that the socio-technical work design should meet the demands of the external environment. In an effort to explain how an organization achieves synergy between its technical and social systems, Cherns (1976, 1987) articulated ten work-system design principles. Table 4 lists these STS principles, along with our applications of the principles to the product portfolio complexity management context. In the following sections we draw upon these principles in our development of propositions regarding the effects of speci?c management practices on complexity and pro?tability. Though we uncovered many potentially interesting similarities and differences across the case ?rms, we limit our discussion to propositions that emerged from repeated observations across the cases. From our analysis there emerged a number of competencies that seem to demonstrate varying abilities to manage product portfolio complexity. Through multiple discussions with managers and between the research team, we determined that the competencies could be grouped into three primary domains. Accordingly, we posit that a SBU’s product portfolio complexity is largely results from its competencies in three key areas: (1) product/technology portfolio strategy, (2) organization and governance of complexity decision processes, and (3) design and decision support. 4.4. Competence area 1: product/technology portfolio strategy Product/technology portfolio strategy relates to product de?nitions, objectives, and other means by which a ?rm guides decisions regarding the products it offers and the technologies applied. We noted a high degree of variance in both the discipline and scope that different ?rms applied in the articulation of their portfolio strategies. Interviewees at multiple ?rms noted that unintended complexity often results from the lack of clearly de?ned strategies for product features. STS theory maintains that highly equivocal and controversial issues should be resolved through deliberation and consensus building

(Pava, 1986). The product strategy, including the creation and deletion of product variants and features, is highly controversial. Thus, dedicated, cross-functional efforts toward clarifying plans for the development and application of core technologies and clarifying the rationale for a given product architecture should increase the organization’s ability to maximize performance. The ?rms we studied differed widely in this important area of competence. TEC used technology roadmaps to identify disruptive technologies and to quickly incorporate them into its portfolio. The GAC’s effective use of feature and technology roadmaps enabled it to develop vehicles more rapidly, and to explicate emerging styling and performance trends. In the parlance of STS, the use of such roadmaps improves the alignment between the technical subsystem and the environment, and prevents the exportation of ‘‘variances’’ from one organizational department to another (Table 4, Principle 3). Technology roadmaps and clearly articulated product strategies help to prevent and correct variances between actual and desired product portfolio states. Also in keeping with STS principles, ?rms that develop a more fully articulated strategy for product features and technologies specify the support system transitions required throughout the ?rm to accommodate product changes. In accordance with these expected bene?ts, we forward our ?rst proposition. P1: Business units that more clearly articulate and communicate product technology strategies achieve more pro?table levels of product portfolio complexity. An important corollary competency to the articulation of product technology strategy relates to product feature de?nitions. For example, our interviews with GAC revealed that they had clearly distinguished between features that were customer ‘‘discernable’’ and those that were not. Kim and Chhajed (2001) argue that too much commonality in discernable features can lead to cannibalization. GAC’s ability to make this distinction allowed them to focus research and development resources on differentiating discernable features while using common components elsewhere; thus increasing alignment between the product design and environmental requirements (e.g., customer needs and production constraints). In contrast, LAC made few such distinctions among product features or components. As a result, LAC struggled with where to place its innovation emphasis. The minimal criteria speci?cation in STS indicates that objectives and methods for obtaining them should be speci?ed parsimoniously (Table 4, Principle 2). In terms of product design, such a

D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610


speci?cation applies to clearly de?ned points of differentiation, as well as making clear distinctions between product features that serve as customer touch points and those that are transparent to customers. STS theory would suggest that business units which make strict choices on a minimal number of product differentiating features should outperform their counterparts. P2: Business units that establish clearly de?ned, minimal numbers of product differentiating features achieve more pro?table levels of product portfolio complexity. Our interviews revealed that both strategic choices and functional inter-relationships can in?uence realized levels of product portfolio complexity. Ceterus paribus, a business unit that chooses a product differentiation strategy will likely create a product portfolio that is more complex than one which follows a price leadership strategy. Strategic choices such as these are sometimes dominated by a particular functional group, which inevitably creates a social structure reinforcing its preferred strategy. For example, in both LAC and IEC, marketing functions tended to dominate strategy development processes, with an orientation favoring more product line complexity. In the opinions of some managers at these ?rms, this strategy represented a mis?t with the market environment. At IEC, for example, the product portfolio was geared toward differentiation when the market favored commoditization. Similarly, managers in several ?rms described circumstances in which a myopic focus on certain performance measures, e.g., revenue growth or cost reduction, stimulates increases or decreases in product complexity which may not have been pro?table. The STS principle of compatibility suggests that the way a design activity is performed should be compatible with the design’s objectives (Cherns, 1987) (Table 4, Principle 1). The system for product portfolio complexity management should ensure that both the product portfolio and its delivery systems are congruent with each other and with the external environment. This necessity implies that the portfolio strategy and related complexity decisions must be jointly established by stakeholders who have relevant knowledge of environmental demands and constraints. STS theory maintains that social and technical boundaries should not impede such joint work, nor should it impede associated knowledge sharing and learning (Table 4, Principle 4). Thus, differences in strategy-making power or social status across functional groups should be eliminated. Likewise, performance incentives which create mis-

alignments among various functional objectives should be minimized (Table 4, Principle 8). Our case observations suggest that strategy development processes which promote a greater balance of various functional objectives will produce product portfolios with greater alignment both internally and with the external environment. In a related way, the STS principle of support congruence states that all organizations should work together with the focal work system toward the same objective (Table 4, Principle 8). In the product complexity management context, this alignment should include all value chain functions involved in promoting and delivering the product portfolio to customers. Value chain functions including marketing, manufacturing, logistics, and supply management are both stakeholders and supporting systems for the product complexity management work system. AEC provided a strong example of such alignment. For a given product line, AEC had earlier offered four different product platforms with so many diverse options that the sales force could not explain the differences to prospective buyers; thus customers were left unaware of the options available. AEC redesigned the product around a single platform for a ‘‘core’’ market segment; the design addressed adjacent market segments through the use of feature con?gurations and option packages. Marketing promotion and sales plans followed this platform strategy, with core and tailored elements. AEC further leveraged this platform architecture by redesigning the supply network and manufacturing processes. For example, they moved from three engine suppliers to a single supplier who provided an engine that could be tuned or modi?ed by exchanging one sub-assembly to yield four different horsepower levels. Similarly, the manufacturing plant layout was changed to consolidate production lines and shift from a make-to-stock orientation to a make-toorder orientation. These changes improved scale economies and freed signi?cant amounts of ?nancial capital. The other ?rms sought similar examples of product rationalization. However, the full bene?ts of these programs were seldom achieved, because supporting complexity delivery systems were not changed enough to fully leverage the new platform concepts. The AEC example illustrates the potential bene?ts of strategic alignment. STS theory suggests that both social and technical alignments are necessary to make individual work sub-systems with the value chain more ef?cient. In our next proposition, we express this total alignment in terms of strategy.


D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610

P3: Business units that align their product/technology strategy with product complexity delivery strategies (i.e., marketing, supply, manufacturing, and logistics) will achieve more pro?table levels of product portfolio complexity. 4.5. Competence area 2: organization and governance Organization and governance competency are re?ected in the structures that ?rms use to monitor and control portfolio complexity decisions throughout all stages of product development, delivery, and withdrawal. Practices related to organization and governance include the use of managerial tools such as decision models, development process documentation, metrics, and associated goals. Also included are organizational practices for designing functional relationships, developing policy, and directing decisions made throughout the product life cycle. While others have explored such practices within the bounds of the development organization (Cooper et al., 1997), this research explores the whole of the business. The ?rms demonstrated salient differences in the degrees to which they organizationally separated feature and technology development activities from speci?c new product development activities. For example, GAC created a separate organization to develop and maintain strategies and speci?cation databases for eleven core product technologies. These ‘‘technologies’’ included everything from preferred components and vendors to ‘‘best practice’’ design architectures for subsystems. In addition, GAC created a parallel group that developed strategies for new product features. This marketing oriented group had the task of studying competitor moves and consumer tastes to identify customer utilities for certain product features, and to determine the sales potential of new feature offerings. IEC had similar, though less well established, organizational structures. CSC offers another example of managing technology and product development activities independently. They created a separate organization tasked with building upgrade paths into product development strategies. This approach effectively decoupled product or feature release dates from technology release dates. CSC was then able to capitalize on its ability to rapidly offer new features or products. It was also able to overcome customer perceptions of rapid technological obsolescence, thereby improving its value proposition. In each of these cases, the ?rms recognized the need to closely manage the interdependencies among

activities in the feature management, technology management, and new product development organizations. Such interdependencies are described in the STS literature as mutual dependencies (Majchrzak, 1997). When detriments from one function of an organization impact another organizational function, a mutual dependency occurs. Managers we interviewed felt strongly that the coupling of technology and feature development with new product development projects created dependencies which led to localized optimization for each individual new product development (NPD) project, at the expense of globally optimal levels of product complexity for the business unit. In other words, if an individual new product development (NPD) project team is tasked with independently developing feature de?nitions and technology solutions, it will most certainly choose design solutions which maximize the potential returns given that project’s targeted market and competitive environment. If many NPD projects are managed in this way, then many different and unique design solutions are likely to be created, thus adding to overall portfolio complexity. By designing organizational structures that decouple feature and technology development from NPD, some of the companies we studied were able to more effectively limit the creation of new features and technologies. In the parlance of STS theory, this decoupling of product, features, and technology development efforts, accompanied by tight management of their interdependencies, creates a transitory organizational structure (Cherns, 1987) (Table 4, Principle 9). Such a structure creates easier transitions as disruptive technologies are encountered, and it minimizes redundancies and outliers in product design. The result is more ?uid technology transitions and greater ability to ensure congruence with the environment using minimal product portfolio speci?cations. Accordingly, we suggest that this type of approach will maximize performance. P4: Business units that organizationally separate product feature and core technology planning activities from speci?c product development projects achieve more pro?table levels of product portfolio complexity. Earlier, we discussed the process of product technology strategy development relative to the STS principle that organizational boundaries should facilitate information sharing, knowledge, and learning (Cherns, 1987). The same principle applies at the level of individual product design processes. STS theory advocates that design projects should employ a crossfunctionally cooperative and matrixed approach (Susman and Chase, 1986).

D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610


We observed examples of this organizational approach at LAC and TEC. Both ?rms made use of cross-functional commodity teams during product development so that the supply chain implications of design alternatives could be evaluated. These teams included members of the procurement, engineering, and manufacturing functions. The cross-functional aspects of the teams proved to be effective for identifying and legitimizing savings opportunities. Each ?rm with active commodity teams has seen signi?cant reductions in materials acquisition costs. Other ?rms extended cross-functional decisionmaking beyond the initial product development phase of the product life cycle. Managers at CSC discussed how product feature additions were better managed after they instituted cross-functional review boards to approve feature additions and deletions for existing products. GAC and AEC also discussed similar approaches, and managers at IEC expressed a desire to put such practices in place. At CSC, GAC, and AEC, the implementation of cross-functional review boards and stricter feature approval processes created a social governance system which controlled key ‘‘variances’’ with the organization. Again, this re?ects an important STS principle (Cherns, 1987) (Table 4, Principle 3). In addition, by centralizing the decision making task, these ?rms clearly established and located the primary responsibility for achieving overall portfolio complexity goals. This approach is consistent with the STS principle of power and authority (Cherns, 1987) (Table 4, Principle 6). P5: Business units that employ more rigorous, crossfunctional review processes throughout product development and lifecycle management achieve more pro?table levels of product portfolio complexity. An important aspect of the STS principle of power and authority is that organization members given authority must accept responsibility for the prudent and ef?cient use of resources (Cherns, 1987) (Table 4, Principle 6). An interesting practice used at CSC was the establishment of a ‘‘feature owner’’ for each of the ?rm’s ?ve major product brands. Each owner was given ?nal responsibility for tracking the total number of product features, and for working together with review boards to establish and achieve feature budgets. The creation of total feature budgets also brought complexity to the fore as a primary decision criterion. Without such explicit targets, each feature proposal is likely to be evaluated on an isolated cost/bene?t basis. An additional bene?t of explicit complexity targets and related approval processes is heightened awareness

among the design community of the importance of managing total product portfolio complexity. Explicit targets serve to shape decision makers’ attitudes and normative views toward product complexity. For example, marketing managers and design engineers are normally driven to increase product variety by the presence of extrinsic ?nancial incentives (e.g., sales growth targets for marketing personnel) and intrinsic rewards (e.g., engineers’ desire to be seen as creative). Consistent with the STS principle of support congruence (Table 4, Principle 8), the presence of explicit product complexity targets provides motivation for a more balanced decision making processes in these functional areas. Managers at LAC, though not possessing or using a formal set of decision criteria, reported signi?cant reductions in certi?cation, design, and component costs when a soft design reuse target was employed. This example illustrates the important linkage between the social (awareness and response) and technical (review processes and targets) systems; neither can exist in isolation (Emery and Trist, 1971). Almost all the managers at the SBUs studied expressed a desire for more design reuse, and most had technical systems such as computerized catalogs to facilitate this end. Yet those units which created greater support congruence between explicit company goals and the employees’ social norms appeared to be more successful in ?nding effective levels of complexity. P6: Business units that establish explicit complexity targets achieve more pro?table levels of product portfolio complexity. 4.6. Competence area 3: design and decision support systems The information ?ow principle of STS speci?es that when information is given to the correct people in a timely manner (Cherns, 1987) (Table 4, Principle 5), the organization functions more ef?ciently. This principle also suggests that actionable information should be targeted towards those people who need it. In our case studies, it became evident that a critical decision maker requirement was an information system that both enables better decision making and also saves time. Almost all ?rms indicated that it took their design engineers less time to design a new part than it did to ?nd a suitable existing one in their information databases. This is especially important given that all of the ?rms felt pressured to develop more new products faster using fewer design resources.


D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610

Of the six ?rms we studied, GAC and AEC had the best information systems allowing users access to timely and relevant product data. As a result, decision makers in these ?rms had a greater awareness of areas of excessive complexity. In contrast, managers at LAC indicated that they were heavily reliant on ‘‘tribal knowledge,’’ or localized experience. If one designer didn’t happen to know that another designer had previously designed a similar product or component, then the opportunity to reuse that design was lost. Thus, improved availability of pertinent design data enables greater design reuse. GAC’s product data management information system was an internally developed searchable database that contained product component design speci?cations, sourcing information, and identi?cation of the usage of the component in various product programs. In addition to providing excellent access to the design data, the system also served as a tool for enforcing product design policies. Managers commonly referred to the system as ‘‘the design shelf’’ connoting that the system contained the approved inventory of acceptable component designs and design ‘‘practices.’’ For design engineers on a given product development project to obtain approval for a new component design, they had to ?rst demonstrate that no suitable part or design existed in the design database. Severe departures from design templates had to be approved by a top level manager. By controlling the inventory of designs made available on the ‘‘shelf,’’ component proliferation could be controlled and managers could implement a given product technology strategy across all product development programs. Viewed from the STS perspective, a product data management system can be seen as a tool that increases the alignment of social and technical subsystems, strategies, and technology. In each of the studied ?rms, managers expressed a strong desire to reduce complexity. The lack of adequate information system capabilities posed a technological barrier which stymied the realization of this social desire. Conversely, the presence of a user-friendly information system enabled designers to make better decisions affecting product complexity, and provided a means by which managers could ensure better alignment of decisions made on individual product development programs with overall business unit strategies. This leads to our seventh proposition. P7: Business units that extensively use comprehensive product data management systems achieve more pro?table levels of product portfolio complexity.

Along with product data management systems, useful design decision models enable managers to apply high ?delity data and credible (understandable) decision rules to complexity tradeoffs. Almost all of the managers we interviewed felt that they had very limited ability to determine ‘‘true’’ and ‘‘complete’’ sales and cost implications for a given product design decision. All expressed the need for better decision models to help in this regard. Though none of the ?rms demonstrated well developed competence in this area, those that had begun to develop models (often spreadsheet based) appeared to be gaining substantially improved insights. IEC demonstrated the greatest level of maturity in this area. They had commissioned a dedicated crossfunctional team to develop a cost estimation model to help them estimate life cycle cost impacts for alternative product design scenarios. Other ?rms such as TEC had established simple heuristics to guide decisions regarding introduction of a new, non-standard product features. For example, in order to justify addition of a new feature, CSC required a projected sales increase of at least $2 million. However, managers generally did not convey a high level of con?dence in these types of decision rules. STS theory suggests that the accumulation and synthesis of tacit knowledge plays an important role in a work system’s ability to respond to the environment (Kaghan and Bowker, 2001). One manager noted that he believed that all the requisite knowledge to make good decisions existed in various pockets of the company, yet there was no mechanism for synthesizing it. Decision support model development could make explicit the tacit or undeveloped knowledge of the market, as well as making plain the implications of supply chain, complexity-related decisions. In order for such a system to be embraced by decision makers, however, it must be viewed as both credible and comprehensive. Several managers at IEC said that wide-spread usage of their decision model was hampered by users’ suspicions regarding the systems’ accuracy. The users’ lack of understanding of the algorithms inside the ‘‘black box’’ led them to question the validity of the model’s conclusions, especially when that conclusion con?icted with a user’s personal desires or reward structure. Skeptics typically attacked the model results by claiming that the analysis had omitted important variables or considerations. These ?ndings re?ect STS principles in that the design and implementation of decision support models needs to consider both the technical and social aspects of the system’s use. Decision support systems that can integrate compre-

D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610


Fig. 1. Complexity management framework.

hensive technical knowledge into credible, usercompatible formats are more likely to experience higher levels of usage, thus producing better complexity-related decisions. Hence we offer proposition eight. P8: Business units that develop decision analysis models tailored to the needs of internal decision makers achieve more pro?table levels of product portfolio complexity. 4.7. Towards a model of complexity management competencies This research identi?es and synthesizes a model of product complexity management. We uncovered a number of environmental drivers of product portfolio complexity and identi?ed product life cycle management activities that comprise a complexity management work system. Furthermore, the research suggests propositions that relate the performance effects of management competencies grouped in three main areas of practice. The most important competence area has to do with the clear articulation and continuous updating of a product/technology strategy that is aligned with supporting complexity delivery functional strategies. Aspects of governance and organizational structure for product complexity management were identi?ed as important means for ensuring that social and technical subsystems are congruent with each other and with the operating environment. It is through these work system design elements that principles of STS relating to variance control, power, boundary location, and multifunctionality can be enforced, and thereby improve the overall quality of complexity related decisions made throughout the product lifecycle. Finally, the study identi?ed attributes of design information and decision

support systems that should improve the quality and timeliness of complexity related decisions. Fig. 1 illustrates a model summarizing our ?ndings and establishing the functional form for our propositions. The model shows that product portfolio complexity mediates the relationship between environmental drivers and business unit performance. We posit that the management competencies identi?ed in our research moderate these relationships. Note that the competencies can be considered as means for coping with external complexity drivers. We also view the competencies as important mechanisms for ensuring that complexity management processes are ef?cient, making maximal use of innovative design solutions such as platform strategies. 5. Conclusions This research makes several contributions to the study of product complexity management. First, we have offered a clear and succinct de?nition of complexity. Use of this de?nition should provide greater comparability across future research studies (Wacker, 2004). Future research can extend this de?nition as it explores sub-dimensions of multiplicity and relatedness in product architectures. A second contribution is the application of sociotechnical systems theory as an appropriate theoretical lens for studying product portfolio complexity management. The ten principles of STS (Cherns, 1987; Emery and Trist, 1971) offer helpful guidance in the evaluation of product complexity management processes. This approach should be used as a basis for design of future research studies which evaluate key competencies for the management of complexity. Our application of the principles also has immediate relevance for managers.


D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610 Avgerou, C., Ciborra, C., Land, F., 2004. The Social Study of Information and Communication Technology: Innovation Actors and Contexts. Oxford University Press, Oxford, New York, p. 290. Baldwin, C.Y., Clark, K.B., 1997. Managing in an age of modularity. Harvard Business Review 75 (5), 84–94. Baldwin, C.Y., Clark, K.B., 2000. Design Rules. MIT Press, Cambridge, p. 471. Bayus, B.L., Putsis, W.P., 1999. Product proliferation: an empirical analysis of product line determinants and market outcomes. Marketing Science 18 (2), 137–153. Blau, P.M., Shoenherr, R.N., 1971. The Structure of Organizations. Basic Books, New York. Chang, T.S., Ward, A.C., 1995. Design-in-modularity with conceptual robustness. In: Proceedings of the 1995 ASME Design Engineering Technical Conferences—21st International Conference on Advances in Design Automation, Boston, MA. Cherns, A., 1987. Principles of sociotechnical design revisited. Human Relations 40 (3), 153–161. Cherns, A.B., 1976. The principles of sociotechnical design. Human Relations 29 (8), 783–792. Clark, K.B., Fujimoto, T., 1991. Product Development Performance: Strategy, Organization, and Management in the World Auto Industry. Harvard Business School Press, Boston, Mass, pp. 409. Clegg, C.W., 2000. Sociotechnical principles for system design. Applied Ergonomics 31 (5), 463–477. Cooper, R.G., Edgett, S.J., Kleinschmidt, E.J., 1997. Portfolio management in new product development: lessons from the leaders. I. Research Technology Management 40 (5), 16. Dooley, K.J., Van de Ven, A.H., 1999. Explaining complex organizational dynamics. Organization Science 10 (3), 358. Eisenhardt, K.M., 1989. Building theories from case study research. The Academy of Management Review 14 (4), 532–550. Ellram, L.M., 1996. The use of the case study method in logistics research. Journal of Business Logistics 17 (2), 93–138. Emery, F.E., Trist, E.L., 1971. Analytical model for sociotechnical system. In: Hill, P. (Ed.), Towards a New Philosophy of Management. Gower, London, pp. 230–243. Fisher, M., Ramdas, K., Ulrich, K., 1999. Component sharing in the management of product variety: a study of automotive braking systems. Management Science 45 (3), 297–315. Fisher, M.L., Ittner, C.D., 1999. The impact of product variety on automobile assembly operations: empirical evidence and simulation analysis. Management Science 45 (6), 771–786. Flood, R.L., Carson, E., 1988. Dealing with Complexity: An Introduction to the Theory and Application of Systems Science. Plenum Press, New York, p. 289. Galbraith, J.R., 1973. Designing Complex Organizations. AddisonWesley, Reading, MA, p. 150. Galbraith, J.R., 1977. Organizational Design. Addison-Wessley, Reading, MA, p. 426. Galvin, P., Morkel, A., 2001. The effect of product modularity on industry structure: the case of the world bicycle industry. Industry and Innovation 8 (1), 31–48. Glaser, B.G., Strauss, A.L., 1967. The Discovery of Grounded Theory: Strategies for Qualitative Research. Aldine, Chicago, p. 271. Grant, R.M., 1996. Toward a knowledge-based theory of the ?rm. Strategic Management Journal 17, 109. Grif?n, A., 1997. The effect of project and process characteristics on product development cycle time. Journal of Marketing Research 34 (1), 24–35.

In our execution of the case studies, we have uncovered signi?cant knowledge gaps in both the academic and practitioner communities. For example, even the more advanced ?rms we interviewed tended to conceptualize complexity mainly in terms of numbers of unique components in the product portfolio. It appears that few ?rms have gone beyond this level of conceptualization to consider higher order aspects of complexity. There is a glaring need to develop complexity metrics that measure the relational and combinatorial dimensions of complexity and that are predictive of various performance outcomes. While using measures such as the number of products in the portfolio should yield some insight, there are other measures that may compliment or supplant total count as the best measure of portfolio complexity; measures such as the ratio of products that are simple refreshes to those that are wholly new, the average age of a product in the portfolio, or how concentrated the revenue the portfolio generates is within one or a few products. We suggest that this is an important area of research, as more precise conceptualizations and measures of complexity will enable tests of more re?ned theories. A second research need is development of insights into the interactive dynamics between the different elements of the complexity management model and how these relationships might be conditioned by industry and product technology factors. As with any case study research, there are limits to the ?ndings and conclusions generated in this study. We limited our study to large ?rms that produce durable, assembled products. While our theoretical sampling approach should aid generalizability within this domain (Rosenthal and Rosnow, 1991), our ?ndings may not be applicable to the management of complexity for other product and service types. Another important limitation of this research is its emphasis on product portfolio complexity and its neglect of complexity in the value chain elements. It is likely that marketing and supply chain design characteristics interact with product portfolio complexity factors to affect business unit performance. While we discussed the importance of aligning product technology and value chain functional strategies, we did not study marketing or supply chain factors directly. The study of such interactions is a rich research area that remains largely unexplored. References
Adler, P.S., 1995. Interdepartmental interdependence and coordination: the case of the design/manufacturing interface. Organization Science 6 (2), 147–168.

D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610 Gupta, S., Krishnan, V., 1999. Integrated component and supplier selection for a product family. Production and Operations Management 8 (2), 163–182. Hillier, M.S., 2000. Component commonality in multiple-period, assemble-to-order systems. IIE Transactions 32 (8), 755. Hirschhorn, L., Noble, P., Rankin, T., 2001. Sociotechnical systems in an age of mass customization. Journal of Engineering and Technology Management 18 (3/4), 241–252. Kaghan, W.N., Bowker, G.C., 2001. Out of machine age? Complexity, sociotechnical systems and actor network theory. Journal of Engineering and Technology Management 18 (3/4), 253–269. Kekre, S., Srinivasan, K., 1990. Broader product line: a necessity to achieve success? Management Science 36 (10), 1216–1231. Kim, K., Chhajed, D., 2001. An experimental investigation of valuation change due to commonality in vertical product line extension. The Journal of Product Innovation Management 18 (4), 219. Kotz, J., Treichel, P.J., 1996. Chemistry and Chemical Reactivity, 3rd ed. Saunders, Toronto, p. 952. Krishnan, V., Gupta, S., 2001. Appropriateness and impact of platform-based product development. Management Science 47 (1), 52. Lancaster, K., 1979. Variety, Equity and Ef?ciency: Product Variety in an Industrial Society. Columbia University Press, New York, p. 373. Lancaster, K., 1990. The economics of product variety: a survey. Marketing Science 9 (3), 189–206. Majchrzak, A., 1997. What to do when you can’t have it all: toward a theory of sociotechnical dependencies. Human Relations 50 (5), 535–565. McCutcheon, D.M., Meredith, J.R., 1993. Conducting case study research in operations management. Journal of Operations Management 11 (3), 239–256. McDonald, M.H.B., 1985. Methodological problems associated with qualitative research: Some observations and a case analysis of international marketing planning. International Studies of Management & Organization 15 (2), 19–40. McGrath, M.E., 2001. Product Strategy for High Technology Companies, 2nd ed. McGraw-Hill, New York, p. 378. Meredith, J., 1998. Building operations management theory through case and ?eld research. Journal of Operations Management 16 (4), 441–454. Meyer, M.H., Lehnerd, A.P., 1997. The Power of Product Platforms: Building Value and Cost Leadership. Free Press, New York, p. 267. Meyer, M.H., Mugge, P.C., 2001. Make platform innovation drive enterprise growth. Research-Technology Management 44 (1), 25– 39. Meyer, M.H., Tertzakian, P., Utterback, J.M., 1997. Metrics for managing research and development in the context of the product family. Management Science 43 (1), 88–111. Miles, M.B., Huberman, A.M., 1984. Qualitative Data Analysis: A Sourcebook of New Methods. Sage Publications, Beverly Hills, p. 263. Moorthy, K.S., 1984. Market segmentation, self-selection, and product line design. Marketing Science 3 (4), 288–307. Novak, S., Eppinger, S.D., 2001. Sourcing by design: Product complexity and the supply chain. Management Science 47 (1), 189– 204. Patton, E., Appelbaum, S.H., 2003. The case for case studies in management research. Management Research News 26 (5), 60–71.


Pava, C., 1986. Redesigning sociotechnical systems design: Concepts and methods for the 1990’s. The Journal of Applied Behavioral Science 22 (3), 201–221. Poole, M.S., Van de Ven, A.H., 1989. Using a paradox to build management and organization theory. The Academy of Management Review 14 (4), 562–578. Price, J.L., Mueller, C.W., 1986. Complexity: Handbook of Organizational Measurement. Pitman Publishing, Marsh?eld, MA. Purser, R.E., 1991. Redesigning the knowledge-based product development organization: a case study of sociotechnical systems change. Technovation 11 (7), 403–415. Purser, R.E., 1992. Sociotechnical systems design principles for computer-aided engineering. Technovation 12 (6), 379–386. Qiang, T., Mark, A.V., Ragu-Nathan, T.S., Bhanu, R.-N., 2004. Measuring modularity-based manufacturing practices and their impact on mass customization capability: a customer-driven perspective. Decision Sciences 35 (2), 147–168. Quelch, J.A., Kenny, D., 1994. Extend pro?ts, not product lines. Harvard Business Review 72 (5), 153–160. Randall, T., Ulrich, K., 2001. Product variety, supply chain structure, and ?rm performance: analysis of the US bicycle industry. Management Science 47 (12), 1588–1604. Ratchford, B.T., 1990. Commentary marketing applications of the economics of product variety. Marketing Science 9 (3), 207–211. Robertson, D., Ulrich, K., 1998. Planning for product platforms. Sloan Management Review 39 (4), 19–31. Rosenthal, R., Rosnow, R.L., 1991. Essentials of Behavioral Research: Methods and Data Analysis, second ed. McGraw Hill, New York, NY, pp. 692. Rutenberg, D., 1971. Design commonality to reduce multi-item inventory: optimal depth of a product line. Operations Research 19 (2), 491–509. Salvador, F., Forza, C., Rungtusanatham, M., 2002. Modularity, product variety, production volume, and component sourcing: theorizing beyond generic prescriptions. Journal of Operations Management 20 (5), 549–575. Sanchez, R., Mahoney, J.T., 1996. Modularity, ?exibility, and knowledge management in product and organization design. Strategic Management Journal 17, 63–76. Sievanen, M., Suomala, P., Paranko, J., 2004. Product pro?tability: causes and effects. Industrial Marketing Management 33 (5), 393– 401. Susman, G.I., Chase, R.B., 1986. A sociotechnical analysis of the integrated factory. The Journal of Applied Behavioral Science 22 (3), 257–270. Taxen, L., Svensson, D., 2005. Towards an alternative foundation for managing product life-cycles in turbulent environments. International Journal of Product Development 2 (1/2), 24–46. Teece, D.J., Pisano, G., Shuen, A., 1997. Dynamic capabilities and strategic management. Strategic Management Journal 18 (7), 509– 533. Thompson, D.V., Hamilton, R.W., Rust, R.T., 2005. Feature fatigue: when product capabilities become too much of a good thing. Journal Of Marketing Research 42 (4), 431–442. Thompson, J.D., 1967. Organizations in Action. McGraw-Hill, New York, p. 192. Trist, E., Bamforth, K., 1951. Some social and psychological consequences of the longwall method of coal getting. Human Relations 4 (1), 3–38. Ulrich, K., Tung, K., 1991. Fundamentals of product modularity. In: Proceedings of the 1991 ASME Design Engineering Technical


D.J. Closs et al. / Journal of Operations Management 26 (2008) 590–610 Webster, 1964. Webster’s Third new International Dictionary of the English Language. G.&C. Merriam, Spring?eld, MA. Weick, K.E., 2007. The generative properties of richness. Academy of Management Journal 50 (1), 14–19. Whitten, K., Gailey, K., 1984. General Chemistry, 2nd ed. Saunders, Toronto, p. 974. Yin, R.K., 2003. Case Study Research: Design and Methods, Third ed. Sage, Newbury Park, p. 166.

Conferences—Conference on Design/Manufacture Integration, Miami, FL, pp. 73–79. Voss, C., Tsikriktsis, N., Frohlich, M., 2002. Case research in operations management. International Journal of Operations & Production Management 22 (2), 195–219. Wacker, J.G., 2004. A theory of formal conceptual de?nitions: developing theory-building measurement instruments. Journal of Operations Management 22 (6), 629–650.

点击搜索更多“Toward a theory of competencies for the management of product complexity Six case studies”相关的内容
更多“Toward a theory of competencies for the management of product complexity Six case studies”图文资料
下载《Toward a theory of competencies for the management of product complexity Six case studies》