Q

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 protability.
# 2007 Elsevier B.V. All rights reserved.
Keywords: Marketingoperations interface; Designoperations 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 efciency through product ratio-
nalization (Salvador et al., 2002). Fisher and Ittner
(1999) state that optimal levels of product complexity
are difcult to determine in the face of conicting cost
and revenue implications because related decisions are
neither simple nor singular. Typically, the complexity of
a rms product portfolio is inuenced by myriad
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 underpin-
nings of product complexity management have not been
well described. Investigation into the environmental and
organizational factors inuencing complexity decisions
is neededtodescribe the evolutionof product complexity.
In addition, study of organizational and operational
processes inuencing product complexity is necessary to
provide a foundation for an explanatory theory.
www.elsevier.com/locate/jom
Available online at www.sciencedirect.com
Journal of Operations Management 26 (2008) 590610
* 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
This paper examines product complexity manage-
ment 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) Howdo 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 signicant dimensions of
product portfolio complexity, to identify factors inuen-
cing it, and to propose effective management compe-
tencies. 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 manage-
ment on business unit protability.
The paper begins with denitions and a brief
discussion of product portfolio complexity benets
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 con-
cludes with a discussion of limitations and future
research opportunities.
2. Product portfolio complexity and its
management
This research focuses on product portfolio complex-
ity of business units which design and manufacture
tangible, discrete, assembled products. A product
portfolio is dened as the complete set of possible
product congurations 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) denes complexity as:
1a: the quality or state of being composed of two or
more separate or analyzable items, parts, constitu-
ents, 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 necessitat-
ing earnest study or examination to understand or
cope with.
This denition 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 difculties requiring resources be expended to
process the item in question. These aspects are reected
in complexity denitions 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 dene
complexity as a state of processing difculty that results
from a multiplicity of, and relatedness among, product
architectural design elements. This denition 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; Grifn, 1997;
Randall and Ulrich, 2001).
Product portfolio complexity creates difculties in
supply chain process execution related to product
development, supply, manufacture, delivery, and sup-
port. 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 benet
(Lancaster, 1979; Moorthy, 1984; Quelch et al., 1994;
Robertson and Ulrich, 1998; Sievanen et al., 2004;
Thompson et al., 2005). The combination of diminish-
ing 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 com-
plexity, 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 dene 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 benets
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) 590610 591
procurement cost resulting from reducing unique parts
(Meyer and Mugge (2001). Another research stream
focuses on the inuence of product architecture on the
rms 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) effec-
tiveness 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 includ-
ing 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 identied in
the previous studies.
3. Case study methodology
Several researchers discuss the rigor and benets 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; McDo-
nald, 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 inuences dis-
cussed 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 (Eisen-
hardt, 1989). The research team brainstormed a list of
candidate rms by rst identifying products and
industries within the assembled, durable goods category
that exemplied extremes along the dimensions
identied 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 signicant 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
identied 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 signicant 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 complex-
ity 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 indus-
tries. They do not directly compete for the same market,
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, clarication of complexity factor deni-
tions, 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 environ-
mental 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 samples 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 cross-
verify insights and ndings.
3.2.1. Structured interviews
Case interviews were conducted to gather structured
interview data throughout 2005, and follow-up inter-
views carried on into early 2006. To represent the
variety of perspectives that exist about portfolio
complexity, multiple interviews were conducted at
multiple rmlocations 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 conicted or when follow-up or clarication
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
Table 1
Sample company characteristics
Technological and commercial factors CSC LAC GAC AEC TEC IEC
Industry clock speed (the pace of product introductions) H L M L H M
Post sales support requirements (the duration and
involvement of service and help required after the sale)
M H M H M M
In-house control of technology (the degree to which
technological advances were promulgated by the
business unit in contrast to external sources)
L MH H H L M
Product functional complexity (the number of
different types of systems incorporated within
the product and the degree to which they
were interconnected)
L H H H L M
Market diversity/demand variety (the number of
market segments and degree of demand
differences between them)
L L H L M M
Production volume (per line) M L H L H MH
Revenue (billions) 91 10 180 4 37 16
Employees (thousands) 330 37 390 9 69 56
Number of global markets served 160 120 200 160 73 130
R&D expenditures/sales (%)
a
5.9 6.9 4.0 3.5 10.0 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.
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 specic roles within
functions include brand manager, production manager,
development engineer, product planner, Vice President
(VP) procurement, and VP support services. Inter-
viewees 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 progres-
sions.
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 inter-
viewing 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 condential policy and procedure manuals,
presentation slide decks, marketing and promotional
materials, and publicly available information. Examples
of condential information include product develop-
ment 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 fromall 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 participat-
ing 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 briengs 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 replica-
tion 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 conrma-
tions 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 differ-
ences in practice between rms and to determine the
signicance of contextual inuences 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 manage-
ment 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 effective-
ness.
4.1. Case descriptions
The rst analysis level examined each SBU
individually. The specic 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 units
industry and market characteristics, product and
organizational management processes addressing com-
D
.
J
.
C
l
o
s
s
e
t
a
l
.
/
J
o
u
r
n
a
l
o
f
O
p
e
r
a
t
i
o
n
s
M
a
n
a
g
e
m
e
n
t
2
6
(
2
0
0
8
)
5
9
0
6
1
0
5
9
5
Table 2
Case descriptions
Computer Server
Company
Luxury Aircraft Company Global Automotive
Company
Agricultural Equipment
Company
Telecommunications
Equipment Company
Imaging Equipment
Company
Industry Dominant rm
amongst several
Dominant rm amongst few Mid-level player Major player among
a few
One of ve rms Mature
Limited control
over technology
advances
Cyclical Mature Mature Rapid growth globally Highly competitive
Transitioning from
high to moderate
growth
Mature Signicant cost pressures Cyclical Innovations also come
from suppliers and
service providers
Technology paced by
new entrants
Heavily regulated Technology paced
by suppliers
High control of design
elements
EU hazardous substances
act forcing updates
Avionics NPD cycle shorter
than production lead time
Innovations also come
from suppliers
Market
Characteristics
Average product life
cycle ranging
25 years
Distinct categories:
corporate buyers,
individuals, and eets
Global with regional
distinctions requiring
accommodation within
the product
Premium placed on
reliability, durability,
and increasing users
productivity
Style and technological
novelty are the key
differentiators
Price focused consumers
that express a decreasing
appreciation for variety
Customers accustomed to
working directly with
manufacturer
High levels of customization
with many change orders
Presence of meaningful
niches
Product life cycle
estimated at 15 years
Relationship with customer
is controlled by service
providers who may value
different attributes than
the consumer e.g. cost
and compatibility with
existing infrastructure
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 conguration
Requires high level of
reliability, durability,
and performance
Independent dealers are
point of customer
interaction
Product life cycle about
1218 months
Product reliability,
productivity enhancing
characteristics, and cost
are the attributes most
valued by the market
Product lifecycles
1530 years
Relationship with customer
is through increasingly
powerful dealer networks
Multinational design and
manufacturing create
inconsistent products
Portfolio
Management
Focus is on managing
customer options
Platform product with
variations to extend the
useful life of the design
Differentiated products to
dominate specic niches
Focus is on providing
feature packages tailored
to specic applications
Rapid introduction
of new styles based
upon a common platform
Services are an
increasingly
important part
Options dropped and
added in the same
proportion over the
products life cycle
Offer a product in each
segment of the private
aviation market
Extensive use of roadmaps
to guide the complexion
of the portfolio
Cover the full breadth
of each market segment
in which product
competes
Identify and incorporate
hot features into new
and existing products to
maintain market excitement
Products for the
intensive use distinct
from casual use
D
.
J
.
C
l
o
s
s
e
t
a
l
.
/
J
o
u
r
n
a
l
o
f
O
p
e
r
a
t
i
o
n
s
M
a
n
a
g
e
m
e
n
t
2
6
(
2
0
0
8
)
5
9
0
6
1
0
5
9
6 Table 2 (Continued )
Computer Server
Company
Company
Company
Telecommunications
Equipment Company
Imaging Equipment
Company
Increasing focus on
design reuse through
common building
blocks initiative
Reliance upon suppliers
for feature development
Refreshes of existing
products with few new
introductions
Organization Portfolio Management
Team (PMT)functional
heads in each division.
PMTs allocate resources
to new opportunities, and
focus on markets,
competition, and revenue
growth
No coordinated approach
to managing complexity
Integrated information
system to promote
opportunities to reduce
component complexity
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)
Integrated Product
Management Teamsales
personnel, systems
architects, and supply chain
managers. Reports to PMT,
reviews plans for NPD,
feature/product withdrawal,
approves NPD concepts
and controls funding.
Employee suggestion
system targeting
manufacturing process
improvements
Centralized control of
additions to the database
Primarily responsible
for market research,
dening the business
environment, and setting
performance, cost and
commonality objectives
Standard, global
purchasing standards
and processes
Technology development
is integrated with NPD
Product Development Team
(PDT)marketers, engineers,
operations personnel. PDTs
guide a specic NPD project
and report to the PMT
Commodity teams have
been assembled to seek
opportunities for
component reuse
Core technology
development independent
of product development
which together are
independent of feature
development
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
High level teams to foster
interdivisional collaboration
including:
Development Executive
CouncilR&D executives
from all divisions chartered
to improve commonality
Design Councilsto
commonize subsystem
architecture across lines
Commodity Councils
engineering and procurement
managers develop and
manage preferred parts
process
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
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
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
Limited information
system infrastructure
hampering the
effectiveness of
these teams
D
.
J
.
C
l
o
s
s
e
t
a
l
.
/
J
o
u
r
n
a
l
o
f
O
p
e
r
a
t
i
o
n
s
M
a
n
a
g
e
m
e
n
t
2
6
(
2
0
0
8
)
5
9
0
6
1
0
5
9
7
There is no formal system
for managing product
complexity. There is a
complete reliance upon
tribal knowledge
Lean stafng 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
Usually consist of
engineering, procurement,
product teams, consumer
experience, and software
Design reviews in NPD
include comparison of
lifecycle costs for new
verses reused components
Metrics Revenue impact Conicting measures of
success
Complexity targets Parts per platform New product/total Additional revenue per
additional feature
Percentage of feature reuse Conicting rewards Percent reuse targets
for each design area
Parts per model Number of model
variants/total model
sales
Percent reuse and degree
of commonality
Marketing ! market
share
Model variants/
model sales
Swappable component
types/total component
types
No formal commonality
targets
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 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
Commonality and
differentiation are
not incompatible
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
Strong market
segmentation principles
Suppliers and dealers are
key team members
Centralized purchasing
Strategic partnering
with service providers
Results Progress due mainly to
imposition of new controls
and metrics, integrated
decision making processes,
and cross functional
involvement
Employee input system
will save 78 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
D
.
J
.
C
l
o
s
s
e
t
a
l
.
/
J
o
u
r
n
a
l
o
f
O
p
e
r
a
t
i
o
n
s
M
a
n
a
g
e
m
e
n
t
2
6
(
2
0
0
8
)
5
9
0
6
1
0
5
9
8 Table 2 (Continued )
Computer Server
Company
Company
Company
Telecommunications
Equipment Company
Imaging Equipment
Company
Limited application of
data base and decision
applications
Target costing resulted in
faster product development
with lower certication
costs
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
Challenges Feature cost estimation
capabilities inadequate
and not credible
Impending retirements will
decimate tribal knowledge
system
Cultural resistance to
information system
Aligning reward
systems
Cyclical markets No formal cost benet
analyses
Poor understanding of
market responses to
option withdrawals
Lack of cross functional
information ows will
impair the ability to
harmonize business
processes and implement
complexity reduction
initiatives globally
Funding for component
development still tied to
product development
Credibility of core
technology teams
not yet established
Lack of a technology
implementation strategy
Rapid growth in
underdeveloped nations
Lack of clear rules for
the addition of features
Failure to communicate
and consider life cycle
and supply chain costs
of options
Culture of customization
impairs ability to offer
more standardization
Opportunities to
manage the shelf
not fully identied
Strengthening
governance
initiatives to
increase reuse
Regulation Easier to design new
than to reuse
Communicating the
global impact of product
design choices
Include cost of spares
inventory in decision
support models
Constant technological
change of market
Failure to capture
lessons learned
Considering overall life
cycle and supply chain
costs
Dominance of marketing
and culture of adopting
voice of customer
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 oper-
ationalize 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 denitions
varied greatly across the rms. Organizational struc-
tures 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 uncov-
ered 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 encoun-
tered in the case studies is technological change created
by suppliers or other agents outside the rms control.
Managers in the Luxury Aircraft Company (LAC)
pointed out that certain technologies such as avionics
dramatically and rapidly evolve. LACs 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 complex-
ity because new products have limited potential to
capitalize upon the previous versions 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
Table 3
Cross company comparison
CSC AEC GAC IEC LAC TEC Smaller ranking ! more complexity
Environmental drivers of complexity
Technology dynamism 2 6 4 3 5 1 1 = more dynamism
Control over technology 2 6 5 3 4 1 1 = less control
Product durability (support requirements) 3 5 4 2 6 1 1 = less support requirements
Number of product functions 6 2 3 4 1 5 1 = more functions
Market/use diversity 4 5 1 3 6 2 1 = more diversity
Value of product performance increments 1 5 4 3 6 2 1 = more value attached to smaller
performance increments
Regulation (certication requirements) 2 3 5 1 6 4 1 = less regulation
Industry standards 6 2 3 1 4 5 1 = less industry standards
Retrot (backward compatibility) requirements 4 6 2 3 5 1 1 = less retrot requirements
Product reliability requirements 3 5 4 2 6 1 1 = less reliability requirements
Size of capable supply base 2 5 1 3 6 4 1 = larger supply base
Recurring/non-recurring life cycle costs 3 5 4 2 6 1 1 = higher recurring/non-recurring ratio
Time to market pressure 5 2 3 4 1 6 1 = less pressure on time to market
Price sensitivity of demand (pricing power) 3 2 4 5 1 6 1 = less price sensitive (more pricing power)
Economics of product development 5 2 3 6 1 4 1 = lower ability to leverage designs
CSC AEC GAC IEC LAC TEC Smaller ranking= higher competency
Complexity management competencies
Product/technology portfolio strategy 2 2 3 4 5 1 1 = Best of six companies
Organization and governance 1 4 1 4 6 3 1 = Best of six companies
Design and decision support systems 2 4 1 5 6 3 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.
variants in order to meet US and EU requirements,
multiple interfaces to account for cultural and applica-
tion 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 Com-
pany (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 congured identically.
Our study also uncovered a number of external
factors that constrain increased product portfolio
complexity. Regulation or other mandated standardiza-
tion 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 identied
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 certication 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 prot
growth resulted in unprotable feature proliferation.
Product life and the lifetime support cost were also
identied as complexity drivers. For example, AECs
commitment to long-term customer satisfaction
coupled with spare parts support for decades old
equipment models required them to maintain sig-
nicant levels of spare parts inventory.
A companys market power also inuences complex-
ity. The IEC has experienced signicant 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 weak-
nesses and deciencies in product lifecycle manage-
ment. These infrastructural weaknesses often create
unintended complexity in the product portfolio,
generally owing to a lack of disciplined and compre-
hensive 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 deci-
sion-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
conicting 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 techni-
cal issues. The dynamic capabilities perspective (Teece
et al., 1997) is useful in that it addresses the
conguration of resources enabling successful com-
plexity 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
SBUs 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;
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,
Table 4
Socio-technical systems design principles
Socio-technical systems theory design principles (Cherns, 1976, 1987) Applications to product portfolio complexity management
(1) Compatibility: the way that the design of a work system is
done should be compatible with the design objectives
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
(2) Minimal criteria specication: no more should be specied
than absolutely essential, that which is essential must be identied
Minimal criteria specication: important points
of product differentiation should be clearly identied.
Product features that are transparent to customers
should not be differentiated
(3) Variance control: variances should not be exported. The social
subsystem is the most effective system at controlling variance
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
(4) Boundary location: social and technical boundaries should
not be drawn to impede sharing of information,
knowledge or learning
Boundary location: differences in status across
functional groups should be eliminated. Boundary
spanning teams should be created to jointly make
complexity related decisions
(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
Information ow: information systems should provide
reliable market information, product specications and
component information quickly and easily to designers
and other decision makers
(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 efciently
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
(7) The multifunctional principle: systems that expand
peoples roles to accommodate change create organic
systems. Systems that hire a specialist to accommodate
change confuse the organization
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
(8) Support congruence: supporting systems and
sub-systems need to be congruent
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
(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
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
(10) Incompletion: no state of equilibrium exists. Design teams
must be consistently prepared for continual change
Incompletion: markets, technologies, and products are
constantly changing. Complexity management systems
should be continually updated to reect current realities
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-systemdesign
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
specic management practices on complexity and
protability. 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. Accord-
ingly, we posit that a SBUs 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 denitions, 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 dened
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-func-
tional efforts toward clarifying plans for the develop-
ment and application of core technologies and
clarifying the rationale for a given product architecture
should increase the organizations 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 GACs
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 var-
iances 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 accommo-
date product changes. In accordance with these
expected benets, we forward our rst proposition.
P1: Business units that more clearly articulate and
communicate product technology strategies achieve
more protable levels of product portfolio complexity.
An important corollary competency to the articula-
tion of product technology strategy relates to product
feature denitions. 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. GACs ability to make this distinc-
tion 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 environ-
mental requirements (e.g., customer needs and produc-
tion 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 specication
in STS indicates that objectives and methods for
obtaining them should be specied parsimoniously
(Table 4, Principle 2). In terms of product design, such a
specication applies to clearly dened 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 coun-
terparts.
P2: Business units that establish clearly dened,
minimal numbers of product differentiating features
achieve more protable levels of product portfolio
complexity.
Our interviews revealed that both strategic choices
and functional inter-relationships can inuence 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
mist with the market environment. At IEC, for
example, the product portfolio was geared toward
differentiation when the market favored commoditiza-
tion. 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 protable.
The STS principle of compatibility suggests that the
way a design activity is performed should be compatible
with the designs objectives (Cherns, 1987) (Table 4,
Principle 1). The system for product portfolio complex-
ity 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 environ-
mental 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 pro-
cesses 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 congurations and
option packages. Marketing promotion and sales plans
followed this platform strategy, with core and tailored
elements. AEC further leveraged this platform archi-
tecture 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 modied 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-to-
order orientation. These changes improved scale
economies and freed signicant amounts of nancial
capital. The other rms sought similar examples of
product rationalization. However, the full benets 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 benets 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
efcient. In our next proposition, we express this total
alignment in terms of strategy.
P3: Business units that align their product/technology
strategy with product complexity delivery strategies
(i.e., marketing, supply, manufacturing, and logistics)
will achieve more protable levels of product portfolio
complexity.
4.5. Competence area 2: organization and
governance
Organization and governance competency are
reected 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 documenta-
tion, metrics, and associated goals. Also included are
organizational practices for designing functional rela-
tionships, 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
specic new product development activities. For
example, GAC created a separate organization to
develop and maintain strategies and specication
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.
CSCoffers 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 obsoles-
cence, 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 organiza-
tions. 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 optimiza-
tion 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 newproduct development (NPD)
project team is tasked with independently developing
feature denitions and technology solutions, it will most
certainly choose design solutions which maximize the
potential returns given that projects 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 fromNPD, some of
the companies we studied were able to more effectively
limit the creation of newfeatures and technologies. In the
parlance of STS theory, this decoupling of product,
features, and technology development efforts, accom-
panied 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 encoun-
tered, 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
specications. Accordingly, we suggest that this type
of approach will maximize performance.
P4: Business units that organizationally separate pro-
duct feature and core technology planning activities
from specic product development projects achieve
more protable levels of product portfolio complexity.
Earlier, we discussed the process of product
technology strategy development relative to the STS
principle that organizational boundaries should facil-
itate 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 cross-
functionally cooperative and matrixed approach (Sus-
man and Chase, 1986).
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 signicant reductions
in materials acquisition costs.
Other rms extended cross-functional decision-
making 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 reects 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 complex-
ity 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, cross-
functional review processes throughout product devel-
opment and lifecycle management achieve more prot-
able 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 efcient 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
rms 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/benet basis.
An additional benet 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 con-
gruence (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 signicant
reductions in certication, 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 protable levels of product port-
folio complexity.
4.6. Competence area 3: design and decision
support systems
The information ow principle of STS species that
when information is given to the correct people in a
timely manner (Cherns, 1987) (Table 4, Principle 5), the
organization functions more efciently. 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 newproducts
faster using fewer design resources.
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
didnt 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.
GACs product data management information
system was an internally developed searchable database
that contained product component design specica-
tions, sourcing information, and identication 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 devel-
opment 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 complex-
ity. The lack of adequate information system capabil-
ities 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 prot-
able 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 cross-
functional team to develop a cost estimation model to
help themestimate 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 condence in these types of
decision rules.
STS theory suggests that the accumulation and
synthesis of tacit knowledge plays an important role in a
work systems 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 models conclusions, especially when
that conclusion conicted with a users personal desires
or reward structure. Skeptics typically attacked the
model results by claiming that the analysis had omitted
important variables or considerations. These ndings
reect STS principles in that the design and imple-
mentation of decision support models needs to consider
both the technical and social aspects of the systems use.
Decision support systems that can integrate compre-
hensive technical knowledge into credible, user-
compatible formats are more likely to experience
higher levels of usage, thus producing better complex-
ity-related decisions. Hence we offer proposition eight.
P8: Business units that develop decision analysis mod-
els tailored to the needs of internal decision makers
achieve more protable levels of product portfolio
complexity.
4.7. Towards a model of complexity management
competencies
This research identies and synthesizes a model of
product complexity management. We uncovered a
number of environmental drivers of product portfolio
complexity and identied product life cycle manage-
ment 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 identied 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 multi-
functionality can be enforced, and thereby improve the
overall quality of complexity related decisions made
throughout the product lifecycle. Finally, the study
identied 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 proposi-
tions. The model shows that product portfolio complex-
ity mediates the relationship between environmental
drivers and business unit performance. We posit that the
management competencies identied in our research
moderate these relationships. Note that the competen-
cies can be considered as means for coping with
external complexity drivers. We also view the compe-
tencies as important mechanisms for ensuring that
complexity management processes are efcient, mak-
ing 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 denition of
complexity. Use of this denition should provide
greater comparability across future research studies
(Wacker, 2004). Future research can extend this
denition as it explores sub-dimensions of multiplicity
and relatedness in product architectures.
A second contribution is the application of socio-
technical systems theory as an appropriate theoretical
lens for studying product portfolio complexity manage-
ment. 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.
Fig. 1. Complexity management framework.
In our execution of the case studies, we have
uncovered signicant 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 rened 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 coordina-
tion: the case of the design/manufacturing interface. Organization
Science 6 (2), 147168.
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), 8494.
Baldwin, C.Y., Clark, K.B., 2000. Design Rules. MIT Press, Cam-
bridge, 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), 137153.
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 Engineer-
ing Technical Conferences21st International Conference on
Advances in Design Automation, Boston, MA.
Cherns, A., 1987. Principles of sociotechnical design revisited.
Human Relations 40 (3), 153161.
Cherns, A.B., 1976. The principles of sociotechnical design. Human
Relations 29 (8), 783792.
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), 463477.
Cooper, R.G., Edgett, S.J., Kleinschmidt, E.J., 1997. Portfolio man-
agement 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 organiza-
tional dynamics. Organization Science 10 (3), 358.
Eisenhardt, K.M., 1989. Building theories from case study research.
The Academy of Management Review 14 (4), 532550.
Ellram, L.M., 1996. The use of the case study method in logistics
research. Journal of Business Logistics 17 (2), 93138.
Emery, F.E., Trist, E.L., 1971. Analytical model for sociotechnical
system. In: Hill, P. (Ed.), Towards a New Philosophy of Manage-
ment. Gower, London, pp. 230243.
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), 297315.
Fisher, M.L., Ittner, C.D., 1999. The impact of product variety on
automobile assembly operations: empirical evidence and simula-
tion analysis. Management Science 45 (6), 771786.
Flood, R.L., Carson, E., 1988. Dealing with Complexity: An Intro-
duction to the Theory and Application of Systems Science.
Plenum Press, New York, p. 289.
Galbraith, J.R., 1973. Designing Complex Organizations. Addison-
Wesley, 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), 3148.
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.
Grifn, A., 1997. The effect of project and process characteristics on
product development cycle time. Journal of Marketing Research
34 (1), 2435.
Gupta, S., Krishnan, V., 1999. Integrated component and supplier
selection for a product family. Production and Operations Man-
agement 8 (2), 163182.
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 Tech-
nology Management 18 (3/4), 241252.
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), 253269.
Kekre, S., Srinivasan, K., 1990. Broader product line: a necessity to
achieve success? Management Science 36 (10), 12161231.
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 Efciency: 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), 189206.
Majchrzak, A., 1997. What to do when you cant have it all: toward a
theory of sociotechnical dependencies. Human Relations 50 (5),
535565.
McCutcheon, D.M., Meredith, J.R., 1993. Conducting case study
research in operations management. Journal of Operations Man-
agement 11 (3), 239256.
McDonald, M.H.B., 1985. Methodological problems associated with
qualitative research: Some observations and a case analysis of
international marketing planning. International Studies of Man-
agement & Organization 15 (2), 1940.
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),
441454.
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), 88111.
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 pro-
duct line design. Marketing Science 3 (4), 288307.
Novak, S., Eppinger, S.D., 2001. Sourcing by design: Product com-
plexity 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),
6071.
Pava, C., 1986. Redesigning sociotechnical systems design: Concepts
and methods for the 1990s. The Journal of Applied Behavioral
Science 22 (3), 201221.
Poole, M.S., Van de Ven, A.H., 1989. Using a paradox to build
management and organization theory. The Academy of Manage-
ment Review 14 (4), 562578.
Price, J.L., Mueller, C.W., 1986. Complexity: Handbook of Organiza-
tional Measurement. Pitman Publishing, Marsheld, MA.
Purser, R.E., 1991. Redesigning the knowledge-based product devel-
opment organization: a case study of sociotechnical systems
change. Technovation 11 (7), 403415.
Purser, R.E., 1992. Sociotechnical systems design principles for
computer-aided engineering. Technovation 12 (6), 379386.
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 per-
spective. Decision Sciences 35 (2), 147168.
Quelch, J.A., Kenny, D., 1994. Extend prots, not product lines.
Harvard Business Review 72 (5), 153160.
Randall, T., Ulrich, K., 2001. Product variety, supply chain structure,
and rm performance: analysis of the US bicycle industry. Man-
agement Science 47 (12), 15881604.
Ratchford, B.T., 1990. Commentary marketing applications of
the economics of product variety. Marketing Science 9 (3),
207211.
Robertson, D., Ulrich, K., 1998. Planning for product platforms. Sloan
Management Review 39 (4), 1931.
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), 491509.
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), 549575.
Sanchez, R., Mahoney, J.T., 1996. Modularity, exibility, and knowl-
edge management in product and organization design. Strategic
Management Journal 17, 6376.
Sievanen, M., Suomala, P., Paranko, J., 2004. Product protability:
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), 257270.
Taxen, L., Svensson, D., 2005. Towards an alternative foundation for
managing product life-cycles in turbulent environments. Interna-
tional Journal of Product Development 2 (1/2), 2446.
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), 431442.
Thompson, J.D., 1967. Organizations in Action. McGraw-Hill, New
York, p. 192.
Trist, E., Bamforth, K., 1951. Some social and psychological con-
sequences of the longwall method of coal getting. Human Rela-
tions 4 (1), 338.
Ulrich, K., Tung, K., 1991. Fundamentals of product modularity. In:
Proceedings of the 1991 ASME Design Engineering Technical
ConferencesConference on Design/Manufacture Integration,
Miami, FL, pp. 7379.
Voss, C., Tsikriktsis, N., Frohlich, M., 2002. Case research in opera-
tions management. International Journal of Operations & Produc-
tion Management 22 (2), 195219.
Wacker, J.G., 2004. A theory of formal conceptual denitions: devel-
oping theory-building measurement instruments. Journal of
Operations Management 22 (6), 629650.
Webster, 1964. Websters Third new International Dictionary of the
English Language. G.&C. Merriam, Springeld, MA.
Weick, K.E., 2007. The generative properties of richness. Academy of
Management Journal 50 (1), 1419.
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.

Q

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Q

Transféré par

Droits d'auteur :

Formats disponibles

Toward a theory of competencies for the management of

product complexity: Six case studies

Vous aimerez peut-être aussi