A Framework for Organizing Lean Product Development
Joern Hoppmann, ETH Zurich
Eric Rebentisch, Massachusetts Institute of Technology
Uwe Dombrowski, Technische Universität Braunschweig
Thimo Zahn, Technische Universität Braunschweig
Abstract: While in the last 20 years a large number of frameworks
have been presented in literature, currently there is no consensus
on how to define Lean Product Development (PD). We used
content analysis to investigate existing approaches and integrated
them into a single, coherent framework consisting of 11 Lean
PD components. To better understand the nature of the novel
definition of Lean PD, we conducted a theoretical investigation
of the component interdependencies. We hypothesize that Lean
PD needs to be understood as a system of highly interwoven
components that only in their concurrency lead to high
performance in PD.
Keywords: Lean Product Development, Lean Engineering,
Lean Innovation, Product Development System, Lean Thinking,
Innovation Management
EMJ Focus Areas: Innovation & New Product Development,
Operations Management, Program and Project Management,
Systems Engineering
S
ince the publication of The Machine that Changed the World
by Womack et al. (1990), the concept of Lean Thinking
has attracted increasing attention from practitioners and
scholars around the world. Lean Thinking propagates taking a
close look at an organization’s value streams, eliminating all nonvalue adding activities, and consistently aligning all required
activities to the external and internal customers. The results—and
particular characteristics of any Lean system—are short leadtimes, reduced requirements for human and financial resources,
as well as products that are particularly suited to fulfill customer
requirements (Womack and Jones, 1996).
It has long been argued that Lean Thinking has to be applied
to the entire value stream rather than to distinct subsystems
within a company (Murman et al., 2002; Womack and Jones,
1996). Despite this notion, which is reflected in the ultimate goal
of the “Lean Enterprise”, up to this point the application of Lean
principles has strongly focused on the domain of production.
While there is abundant experience with introducing Lean on the
manufacturing shop floor, concepts on how to employ Lean in
up- or downstream processes and supporting functions remain
to be investigated in nearly as much detail.
Arguably, an area with a particularly high potential for
realizing the benefits of Lean principles is the field of product
development. Product development by definition plays a key part
in defining customer value. It determines the physical appearance
of the product, defines the materials to be used and, thus, largely
constrains the set of production processes that can be employed
to manufacture the product. Consequently, the impact on cost,
quality, and manufacturing lead-times is usually much bigger
in the phase of product development than during production
(Kennedy, 2003; Morgan and Liker, 2006).
Current market trends put increasing pressure on companies
to optimize their product development processes in three major
dimensions: time, cost, and quality. First and foremost, increasing
speed of innovation requires companies to drastically reduce their
development cycles and minimize time-to-market. “In automotive
product development, since the 1980s the average time to develop
a car from styling to freeze has decreased by about one-third—to
24 months in 2006” (Morgan and Liker, 2006). In automotive
product development, since the 1980s the average time to develop
a car from styling to freeze has decreased by about one-third—to
24 months in 2006. Second, lower sales volumes per product with
a simultaneous increase in product complexity have resulted in
an increased cost pressure. If one seeks to avoid an increase in the
development cost per unit produced, total development costs for
a product with a smaller sales volume have to be much lower than
for a product with a larger sales volume. Third and last, shortening
product life-cycles comes with a decreased tolerance for quality
issues. High rates of early failures after market introduction,
causing lengthy efforts of rework, are even less acceptable for a
product with a short life-span than they are for long-lived ones
(Morgan and Liker, 2006).
Lean Product Development (PD) as a domain addresses
these major challenges. It discusses how the general idea
of Lean Thinking can be applied to the field of product
development to achieve a value-oriented, resource-efficient,
and fast product innovation process. To this end, several
authors have studied instances of product development systems,
particularly the Toyota Product Development System. During
these studies a number of components were identified that are
supposed to contribute to the previously mentioned objectives
and distinguish a high-performing Lean PD system from
traditional PD. Up to this point, however, the exact number
and nature of the elements that make up a Lean PD system
remain controversial.
With this article we contribute to the theory base of Lean
PD in order to enable further productive empirical research in
this area. We give an overview of existing frameworks for Lean
PD and combine them into a single, clearly structured theory
framework. We begin with a review of existing approaches to
Lean PD, following with a description of the method we used
to derive a novel, coherent definition of a Lean PD system
consisting of eleven Lean PD components. We then analyze
the interdependencies among the system elements. The
components of the framework are described in more detail
in the subsequent section. Next we summarize the insights
generated through the theoretical analysis of the component
relationships. Finally, we conclude by discussing the implications
of our research for the theory of Lean PD and point to potential
future research.
Refereed research manuscript. Accepted by Special Issue Editor Geert Letens.
Engineering Management Journal
Vol. 23 No. 1
March 2011
3
A Historical Perspective on Approaches to Lean Product
Development
The basis for understanding Lean PD, although not yet termed
this way, was laid through a series of detailed studies of product
development systems by Clark, Chew, Fujimoto, and Sheriff even
before The Machine that Changed the World was published. In their
study Product Development in the World Auto Industry (1987),
Clark et al. compared the product development performance of
22 projects of international automotive manufacturers and found
that Japanese companies outperformed North American and
European competitors, particularly with regard to engineering
hours and lead time. European and American development
projects required on average about 3.5 million engineering
hours and took about 62 months. Projects of Japanese car
manufacturers—despite including a higher number of unique
parts—were completed on average with 1.155 million engineering
hours within 42.6 months (Clark etl al., 1987). Based on a
number of statistical tests, Clark et al. attributed this difference in
productivity to the strong involvement of suppliers in the design
process and the role of a “heavy-weight project manager” with
extensive authority who lead the multifunctional teams through
the problem-solving cycles. In addition, Clark et al. found that
Japanese product development projects made use of overlapping
development stages to a larger extent than projects of European or
American car manufacturers (Clark etl al., 1987). The hypothesis
that this overlap could contribute to the significantly shorter
lead times was subsequently confirmed by follow-up analyses
conducted by Fujimoto, Clark, and Sheriff (Clark and Fujimoto,
1989; Cusumano and Nobeoka, 1990; Fujimoto, 1989).
In The Machine that Changed the World, Womack et al.
(1990) took on the detailed findings of Clark, Chew, Fujimoto,
and Sheriff and elaborated on the potential explanations for the
tremendous difference in product development performance
between Japanese and western automobile manufacturers.
While the major impact of their book has been in the area of
manufacturing, more than 30 pages of The Machine that Changed
the World were dedicated to the idea of Lean Design and Lean
PD. Under the title of “techniques for lean design” Womack et al.
identified four major design methods that differentiated a mass
from a lean producer: a powerful project leader with a strong
authority, teamwork, early and controlled communication, and
simultaneous development (Womack et al., 1990).
In the following years, the idea of overlapping phases and
simultaneous development was the one that attracted the most
interest of researchers and practitioners. In their effort to find
methods to shorten lead times, a number of authors studied crossfunctional integration, team structures, and communication and
coordination techniques (Liker et al., 1996). The new findings
resulted in expansions of the four characteristics of Womack. As
an example, Karlsson and Ahlstrom (1996), studying the product
development system of a manufacturer of mechanical and
electrical office equipment, developed their own interpretation of
Lean PD. According to their definition, Lean PD is comprised of
six techniques: supplier involvement, simultaneous engineering,
cross-functional teams, integration of activities, a heavy-weight
team structure, and strategic management of projects.
The strong focus on simultaneous development as the reason
for the superior performance of Japanese car manufacturers in
product development was in part questioned by the findings of
Ward et al. (1995) and Liker et al. (1996) who pointed out that the
best in class, Toyota, neither collocated its teams nor intensively
communicated with its suppliers. Building on experiments with
4
design automation conducted by Ward and Seering (1989a,
1989b) and intensive studies of practices at Toyota, Ward et al.
developed what they called set-based concurrent engineering.
In essence, they found that paradoxically, in the case of Toyota,
delaying decisions and following a large number of alternatives
for the same product module contributed to better and faster
product development (Liker et al, 1996; Ward et al., 1995).
The theory of set-based concurrent engineering, particularly
attractive due to its counter-intuitive nature, was a strong impulse
for the revision and expansion of existing Lean PD concepts. In
a manuscript from 2001, published posthumously in 2007, Ward
describes a Lean PD system consisting of five major principles:
“value focus,” “entrepreneur system designer, “set-based concurrent
engineering,” “cadence, flow and pull,” and a “team of responsible
experts” (Ward et al., 2007). Kennedy, referring to work with Ward
during a study at the National Center for Manufacturing Sciences,
names set-based concurrent engineering as one of the four critical
elements of Lean PD next to “system designer entrepreneurial
leadership,” “responsibility-based planning and control,” and an
“expert engineering workforce” (Kennedy, 2003).
To further explore the particularities of Toyota’s approach,
Morgan conducted a two-and-a-half year, in-depth study of
Toyota’s product development system. Through more than 1,000
hours of interviews held with Toyota and supplier representatives
at different sites in the U.S. and Japan, Morgan tried to answer
the fundamental question what underlying characteristics made
Toyota’s approach to product development so successful. Together
with Liker, who had been strongly involved in the investigation
of set-based engineering, Morgan published his findings in The
Toyota Product Development System, in which the authors identify
13 Lean PD principles they group into the three broad categories:
process, people, and technology (Morgan and Liker, 2006).
The comprehensive and detailed description of Toyota
practices given by Morgan and Liker has induced researchers
to test whether or not the principles described as the reasons
for Toyota’s success could be found to foster better product
development performance in other companies as well. To
this end, in two independent studies Brown (2007) and Schuh
et al. (2007) surveyed 400 and 143 manufacturing firms
respectively and linked the use of particular Lean PD practices
to performance indicators. Both found that the use of particular
practices is correlated with the success of product development
projects as measured by the adherence to schedule, product
and product development costs, product quality, revenues,
and market share. Interestingly, these practices show strong
overlap with the principles of Lean PD defined by Morgan and
Liker. Schuh et al. (2008), based on their findings, describe 10
key principles: motivation, value system, design sets, product
architecture, product line optimization, value stream definition,
capacity planning, synchronization, perfection, and derivation.
Brown (2007) lists 13 components he identifies to have the
largest impact on improving performance: product development
using design sets, value stream mapping, standardized work
methods, concurrent design, lean change/process improvement
enabled at all organizational levels, information flow aligned with
process flow, centralized/documented engineering knowledge,
advanced search technologies, knowledge based engineering,
digital manufacturing, specialty tools for lean, product portfolio
management, and product development results measured with
timely metrics.
In summary, over the last 20 years a number of publications
on Lean PD have emerged; however, our review of literature on
Engineering Management Journal
Vol. 23 No. 1
March 2011
Lean PD revealed two major problems. First, so far, the empirical
base for Lean PD remains rather weak. Much of what has been
published on Lean PD is based on insights generated through
the early studies of Clark et al., theoretical investigations by
Ward and Seering, as well as the comprehensive case studies
conducted by Morgan, Liker, and Sobek. The latter, however,
have strongly focused on practices at Toyota. Up to this point
there are few studies that have tried to collect empirical data on
Lean PD from sources other than Toyota. Second, there is a clear
lack of a consistent theory base for Lean PD. Existing descriptive
frameworks for Lean PD, despite showing apparent overlaps, differ
considerably regarding the focus and the number of components
they comprise. So far, none of the approaches discussed above has
found wide-spread acceptance. Hence, to date it remains largely
unclear what particular elements make up a Lean PD system.
It seems likely that much of the first problem, the lack of
empirical data on Lean PD, is due in part to the second one, i.e. the
lack of a consistent guiding theory basis. The current ambiguity
in the understanding of Lean PD represents a major obstacle to
progress in this nascent area of research. As a basis for future
empirical studies on Lean PD, we therefore took a closer look
at the existing approaches, examined the overlaps between the
different definitions, and integrated them into a single, coherent,
and robust framework for Lean PD.
Study Approach
The goal of our research was not to present a review of Lean PD
literature in its classical sense. A rigorous review of the literature
published in this field using the well-established procedure was
conducted by Baines et al. (2006). Our study focused on a different
objective—namely to further a common understanding by distilling
and integrating the essential elements of existing approaches
toward Lean PD. Our analysis does not address the underlying
Lean philosophy or logic that prompted the development of these
elements, but rather focuses on understanding the artifacts and
their role as part of a system. This approach might, therefore, not
directly result in the development of a theory of Lean PD systems,
but is an essential step in developing a coherent empirical basis
for that theory development.
For this study we used content analysis and applied it to a
large number of publications in the field. Content analysis, which
has its origin in social sciences, provides a systematic way of
filtering and clustering data from recorded human information
(Holsti, 1969; Neuendorf, 2005). Using coding procedures,
texts are scanned for specific patterns that are used to generate
condensed insights on the content. In literature, depending on
the purpose of the analysis, different procedures for conducting
content analysis have been described. Since in our case the analysis
aimed to extend the theory base of Lean PD, we borrowed on an
approach described in grounded theory (Charmaz, 2006; Glaser
and Strauss, 1967; Strauss and Corbin, 1990). Grounded theory
suggests deriving research theory in a systematic way by gathering
and analyzing large amounts of data up-front. In the course of
the data analysis process the collected data is coded, divided
into concepts, grouped into categories, and finally translated
into a theory that intends to explain the phenomenon (Corbin
and Strauss, 1990). Data, in the original definition by Glaser and
Strauss, are “all statements about events pertaining to the area
under study” that explicitly include writings of other researchers
in the field (Glaser and Strauss, 1967).
For our analysis, we used a sample of 27 publications that are
listed in Exhibit 1. To identify this sample, we conducted a web
Engineering Management Journal
Vol. 23 No. 1
search on “Lean Product Development”, “Lean Development”
and “Lean Innovation” using the search engines Google scholar
and Google. Limiting our scope to journal articles, books, and
benchmarking reports, this resulted in 21 retrievable publications
being identified (similar searches using the Social Sciences Citation
Index and ABI/Inform Global yielded fewer but redundant
citations). We checked these publications for whether or not they
explicitly mentioned any of the three key words and provided a
description of at least one component of a Lean PD system. This
resulted in 13 publications that met our criteria for the sample (see
column “Explicitly mentions Lean PD/Innovation?” in Exhibit 1).
In a second step, we scanned the references in these publications
for additional original sources that provided empirical evidence
or further detail for the components listed in the 13 articles. This
procedure, which explicitly included conference proceedings as
research outlets, resulted in 14 publications that were added to
our sample.
After selecting the 27 sources for our analysis the publications
were coded in two major steps. In the first step, we scanned the
publications for quotes describing elements of a Lean PD system.
A total number of 316 quotes each consisting of one to four
sentences were extracted from the publications on Lean PD and
documented in a long list. Subsequently, we used a procedure called
“open coding” to label the quotes regarding underlying concepts
(Strauss and Corbin, 1990). In an iterative process, the resulting
concepts were subsequently checked for overarching themes and
clustered into 11 categories. When deriving the 11 categories,
care was taken that the category names did not represent general
principles or goals, such as “value orientation”, but rather processes,
technology, or functional roles that could be implemented in an
organizational setting. Furthermore, a main goal when defining
the categories was to avoid redundancy. Hence, the categories—
in the following called Lean PD components—were chosen such
that they were mutually exclusive and collectively exhaustive.
In the second major step, we used another round of coding
to extract interdependencies between the components we had
identified in the first step. Literature was scanned for quotes
describing positive or negative effects that the Lean PD components
have on each other. The relationships between the components
were extracted from the quotes and entered into a cause-effect
matrix of 121 fields spanned by the eleven components. Since
not all pairs of components’ cause-effect relationships had been
described in literature, we continued our theoretical investigation
of Lean PD by phrasing hypothetical interdependencies for those
that had not been explicitly discussed. For this purpose, we drew
on our comprehensive analysis of the components in the first step
of our analysis and formulated potential links to describe how a
particular component required the use of another.
Overall, our analysis of the literature on Lean PD revealed
that our list of 27 publications could be broadly separated into
two general categories. While the majority of publications focus
on describing a smaller number of Lean PD elements in greater
detail, we identified some that take on a systems perspective
and make suggestions on how to integrate the components into
an overarching framework. The latter publications, that are
somewhat identical to the ones discussed in the previous section,
are marked in the right column of Exhibit 1.
The results of our content analysis will be discussed in the
following sections. In accordance with the methods we used, we
will first describe the eleven Lean PD components we identified to
constitute a Lean PD system. Building upon this, the cause-effect
matrix we derived in the second part of the analysis is presented.
March 2011
5
Exhibit 1. References Used in the Content Analysis
Sort of Source
Explicitly mentions Lean
PD/Innovation?
Ballée and Ballée, 2005
Journal article
X
Brown, 2007
Benchmarking report
X
3.
Clark et al., 1987
Journal article
4.
Clark and Fujimoto,1989
Journal article
5.
Cusumano and Nobeoka, 1990
Working paper
6.
Cusumano and Nobeoka, 1998
Book
7.
Fiore, 2004
Book
8.
Fujimoto, 1989
Thesis
9.
Fujimoto, 1999
Book
10.
Haque and James-Moore, 2004
Journal article
X
11.
Karlsson and Ahlstrom, 1996
Journal article
X
X
12.
Kennedy, 2003
Book
X
X
13.
Liker et al., 1995
Book
14.
Liker et al., 1996
Journal article
15.
MacDuffie et al., 1996
Journal article
X
16.
Mascitelli, 2007
Book
X
17.
Morgan and Liker, 2006
Book
X
18.
Oppenheim, 2004
Journal article
X
19.
Schuh et al., 2007
Benchmarking report
X
X
20.
Schuh et al., 2008
Conference proceeding
21.
Sobek et al., 1998
Journal article
22.
Sobek et al., 1999
Journal article
23.
Thomke and Fujimoto, 2000
Journal article
24.
Ward et al., 1995
Journal article
25.
Ward and Seering, 1989a
Conference proceeding
26.
Ward et al., 2007
Book
X
X
27.
Womack et al., 1991
Book
X
X
No.
Reference
1.
2.
Eleven Components of Lean Product Development
Exhibit 2 summarizes the results of the first step of the content
analysis described in the previous section. The left column lists
the 11 Lean PD components that were identified as categories for
the elements of Lean PD described in the literature. The columns
to the right detail to what extent each category is covered by the
Lean PD literature identified as primary framework sources. It
should be noted that, due to the approach used to derive the
categories, the number of components listed for a particular
author in Exhibit 2 naturally differs from the one described later
in the article. As an example, Karlsson and Ahlstrom (1996) list
simultaneous engineering and cross-functional teams as separate
parts of a Lean PD system. In the framework derived in this
research these two concepts were, since related, subsumed under
the common heading of “simultaneous engineering”.
As Exhibit 2 shows, most authors, when describing key
principles of Lean PD, focus on a rather small number of
elements. The only approach that comprises all eleven Lean PD
components building the framework of this article is the one
by Morgan and Liker (2006). Their framework was found to be
6
Primary Framework
Source?
X
X
X
X
very comprehensive; however, the 13 general Lean PD principles
Morgan and Liker describe are broad and sometimes not mutually
exclusive. To give an example, Morgan and Liker list “Utilize
Rigorous Standardization to Reduce Variation, and Create
Flexibility and Predictable Outcomes” as one of the principles
for their “process” dimension. This principle shows considerable
overlap with “Use Powerful Tools for Standardization and
Organizational Learning” which is part of the “tools & technology”
dimension of their framework.
In what follows, the 11 Lean PD components of the novel
framework are described in greater detail. We explain the
background of the components listed in Exhibit 2 and point out
why their use has been found to contribute to a stream-lined and
cost-efficient product development process.
Strong Project Manager
The concept of the Strong Project Manager, also known as the
“Heavyweight Project Manager” or the “Chief Engineer”, has its
origins in the U.S. aerospace industry and was adopted by the
Japanese aerospace industry as it began licensing and building
U.S. aircraft in the 1950s (Hall and Johnson, 1970). Its basic
Engineering Management Journal
Vol. 23 No. 1
March 2011
Exhibit 2. Coverage of the Eleven Lean PD Components by Selected Authors
Lean PD Component
Clark et al. 1987
Womack et
al. 1991
Karlsson
and
Ahlstrom
1996
Ward et al.
2007
Kennedy
2003
X
X
X
X
X
X
X
X
X
1. Strong Project
Manager
2. Specialist Career Path
3. Workload Leveling
X
4. Responsibility-based
Planning and Control
X
X
Morgan and
Brown 2007
Liker 2006
X
7. Supplier Integration
X
X
X
X
X
X
X
X
X
X
X
X
X
8. Product Variety
Management
X
X
9. Rapid Prototyping,
Simulation and Testing
10. Process
Standardization
11. Set-based
Engineering
X
idea is to establish the role of an experienced project manager
who leads the development projects from concept definition to
market, and is ultimately responsible for delivering value to the
customer (Morgan and Liker, 2006).
The use of project managers in product development is not
unusual (Armstrong, 2001). The tasks of a strong project manager,
however, go beyond the sole management and integration of
functions which are the main responsibilities of a traditional PD
project manager (Womack et al., 1990). At Toyota, at the beginning
of a project, the Chief Engineer conducts extensive research
and analyzes competitor products in order to understand what
the customer values (Ballé and Ballé, 2005; Morgan and Liker,
2006). After the customer requirements have been documented,
it is the role of the Chief Engineer as the “voice of the customer”
to translate the product definition into well-aligned goals for the
different functions involved (Haque and James-Moore, 2004;
Ward et al., 2007). This includes not only the definition of project
milestones and the negotiation of deadlines with development
engineers, but also the derivation of clear cost and performance
targets for particular components.
The adherence to the project schedule, cost, and performance
targets set at the beginning of the project is continuously checked
Engineering Management Journal
X
X
5. Cross-project
Knowledge Transfer
6. Simultaneous
Engineering
Vol. 23 No. 1
X
Schuh et al.
2008
X
X
X
X
X
X
X
X
X
by the strong project manager during the actual design phase
(Schuh et al., 2007). Moreover, the strong project manager is
strongly involved in the development of the technical details.
Ideally, he is the most experienced and knowledgeable engineer
on the project, makes major component choices, and chooses the
technology used for the product (Karlsson and Ahlstrom, 1996;
Kennedy, 2003; Morgan and Liker, 2006; Oppenheim, 2004;
Sobek et al., 1999; Ward et al., 2007).
Specialist Career Path
Considering the complexity of problems that have to be solved
in the course of a PD project, it is indispensable to make use of
technical specialists with dedicated expertise in a particular field.
To develop this expertise and foster the exchange of knowledge
among specialists of the same domain, engineers are traditionally
assigned to functional divisions. The functions serve as schools
that continuously gather knowledge and best practices and teach
it to their members (Haque and James-Moore, 2004; Ward et al.,
2007; Womack and Jones, 1994).
In traditional organizations, engineers often do not spend
a long period of time in the same functional division. Career
paths are built in a way that with promotions, technical focus
March 2011
7
gets increasingly substituted by general management and
administrative tasks. It has been observed that engineers in Lean
companies tend to stay within their technical position for a much
longer period of time than engineers in traditional companies
(Ward et al., 2007). Furthermore, to give engineers the possibility
to gather more experience in their particular functional domain,
many Lean companies have introduced designated specialist
career paths that promote the development of technical expertise
in a field (Schuh et al., 2007). In the literature on human resource
management, this concept has become know as the “dual
career ladder” (Allen and Katz, 1986), although in practice the
dual career ladder concept has shown uneven application and
inconsistent results.
One of the companies making strong use of a specialist
career path is Toyota. It usually requires a Toyota engineer a
minimum of 10 to 12 years before he or she becomes eligible
for promotion to a first-level management position (Morgan
and Liker, 2006). After a rigorous hiring process, engineers go
through a period of intensive on-the-job training that aims to
promote technical expertise and a standardized skill set among
its engineers. During this time, they are closely supervised by a
designated mentor (Ward et al., 2007). Performance and potential
areas for improvement are discussed in feedback interviews
that are held on a regular basis for six to eight years (Sobek et
al., 1998). Based on the level of demonstrated skills and their
adherence to standard procedures, engineers then slowly climb
up the career ladder (Morgan and Liker, 2006; Ward et al., 2007).
These practices help them build the required knowledge base for
the system-level problem-solving and continuous improvement
activities that are a key part of a Lean PD system.
Workload Leveling
An unleveled workflow is tightly connected with overburdening
of employees, a decrease in the quality of PD activities, an increase
in lead times, and higher product development costs (Fiore, 2004;
Morgan and Liker, 2006; Ward et al., 2007). In the literature on
Lean PD a number of practices have been described that focus on
leveling the workload of engineers through measures of resource
planning and control.
First, it is important to note that different product development
projects with timely overlap compete for the same financial,
technical, and human resources. When trying to maximize the
overall product development performance of an enterprise, it is,
therefore, of major importance that their resources be planned on
a cross-project basis—a methodology Cusumano and Nobeoka
(1998) refer to as multi-project management. To achieve a
leveled workload and generate a smooth flow of PD projects, it
is generally recommended to stagger projects and launch them
in constant intervals (Ward et al., 2007). When determining the
exact scheduling of projects, the availability of different functional
specialists and their capabilities has to be taken into account. In
this context, a particular challenge lies in avoiding inefficiencies
through multitasking (Fiore, 2004; Mascitelli, 2007; Smith and
Reinertsen, 1997; Ward et al., 2007).
A reliable planning of shared resources is not possible if the
duration and resource demand of the single projects are highly
unpredictable. Hence, the practices of multi-project management
described in the previous paragraph need to be supported by
detailed scheduling and capacity planning on the project level.
The tasks to be solved by the participating functions need to
be clearly prioritized, synchronized, and consistently executed.
In order to establish an even flow of the activities within the
8
project, some authors suggest replicating the cadence of project
launches of the multi-project level and establishing rhythmic
cycles within the projects (Haque and James-Moore, 2004;
Oppenheim, 2004; Ward et al., 2007). Since unforeseen events
and iterations can cause deviations from schedule, actual and
planned capacity utilization have to be compared frequently. If
in the course of the product development a bottleneck occurs,
resources have to be flexibly adapted. Hence, for a Lean PD
system, the availability of flexible, extra capacity is of large
importance. Toyota, for example, compensates excess resource
demands through a combination of flexible staffing and the use
of external satellite companies to which work can be outsourced
(Morgan and Liker, 2006).
Responsibility-Based Planning and Control
In general, two approaches can be distinguished for planning
and scheduling the detailed activities of a product development
project: top-down planning and responsibility-based planning.
Using top-down planning, all activities of the project are planned
by the project leader or a designated project planner. The
engineers who execute the tasks are not involved in the planning
process but are assigned detailed tasks with clearly defined, nonnegotiable deadlines by their superiors. In contrast to this, in a
responsibility-based planning approach, the project leader sets
only the major milestones for the project and communicates the
corresponding target dates to the engineers. Based on the targets,
the engineers detail their particular work streams, estimate their
duration, and report to the project leader whether or not the
proposed schedule is feasible. Through several iterative loops, the
project leader and the engineers negotiate deadlines for critical
activities to ensure that goals are realistic but at the same time
challenging enough to allow for a short lead-time of the overall
project. At Toyota this procedure of breaking higher-level goals
down into meaningful lower-level objectives and aligning them
across different stakeholders through extensive negotiations is
known as Hoshin Kanri (Morgan and Liker, 2006). Once the
project leader and the engineer have agreed on a milestone,
the engineer is free to choose the starting point of his work and
experiment with new approaches as long as he can meet the
deadline (Kennedy, 2003; Ward et al., 1995).
In the literature on Lean PD, several authors have argued that
responsibility-based planning is superior to top-down planning
as it contributes to a higher accountability and motivation of
engineers, more robust schedules, higher responsiveness to
unexpected events, and a continuous improvement of processes
(Kennedy, 2003; Schuh et al., 2007; Ward et al., 2007).
To ensure that the stronger distribution of responsibilities
does not go to the detriment of the project’s lead time, at Toyota
in the course of the project, program status, open issues, and
performance to metrics are tracked in frequent project reviews
which, equivalent to kanban cards in production, pull the work of
the engineers (Ward et al., 2007). Using andon boards and visual
management, every project member is given the opportunity to
check his own performance to determine if additional efforts are
required to achieve a milestone on time (Morgan and Liker, 2006;
Ward et al., 2007).
Cross-project Knowledge Transfer
It has been shown that even highly innovative products strongly
depend and build upon knowledge of older products. This
knowledge, if not appropriately captured, has to be continuously
regenerated (Morgan and Liker, 2006; Thomke and Fujimoto,
Engineering Management Journal
Vol. 23 No. 1
March 2011
2000). As an example, Watkins and Clark, studying the design
of front and rear auto body closures, found that problems are
often repeatedly solved in consecutive projects (Watkins and
Clark, 1994).
To avoid the regeneration of knowledge, it is generally
recommended that explicit documentation of the best practices
and lessons learned of projects take place. In the literature on
knowledge management, a vast number of methods and tools for
capturing and storing knowledge have been described, ranging
from sophisticated web-based repositories to simple checklists.
The detailed discussion of all the alternatives with their particular
advantages and disadvantages is a separate stream of research
and beyond the scope of this study. Here, it should only be noted
that, for the viability of knowledge transfer, it is of particular
importance that the barriers to enter, retrieve, and update the
knowledge be as low as possible. Data should be organized in a
clear, logical way so that engineers can quickly review it as they
face a particular design task (Brown, 2007). Additionally, the
usefulness of a knowledge database strongly depends on how
often the data it contains is updated. An organization should have
clearly defined processes for capturing insights on both good
and bad design practices during the projects. Engineers should
be given both sufficient time and an incentive to share their
experience with other members of the organization (Morgan
and Liker, 2006; Oppenheim, 2004). The accumulated knowledge
base should be regularly reviewed, reorganized, and simplified to
maintain its usability (Mascitelli, 2007).
At Toyota, for every major part of a vehicle there is a partspecific checklist containing what the company has learned
over the years. The checklists list the steps not to be missed
during the design process and provide highly detailed, often
visual information regarding “good and bad design practices,
performance requirements, critical design interfaces, critical to
quality characteristics, manufacturing requirements as well as
standards that commonize design” (Morgan and Liker, 2006).
Engineers use the checklists throughout the project to guide
their decision making and facilitate the review of designs. They
constantly update the information contained in the checklists
and abstract their experience using so-called trade-off curves that
graphically describe the governing influence factors determining
performance and failure modes of a part (Morgan and Liker,
2006; Ward et al., 2007).
Simultaneous Engineering
In traditional, sequential engineering, product development is
conducted in subsequent, mostly independent phases. After the
product concept has been developed and evaluated, the single
modules are designed, tested, and integrated. Once integration is
complete, the system of modules is tested and serves as the basis
for the design of production facilities and processes. In contrast
to this, in simultaneous or concurrent engineering, the single
phases of product development are not conducted one after the
other but in an overlapping way (Haque and James-Moore, 2004;
Nevins and Whitney, 1989; Sohlenius, 1992). This concurrency of
activities offers the potential to significantly reduce the lead-time
of the product development project (Karlsson and Ahlstrom,
1996; Sobek et al., 1999; Ward et al., 1995).
In practice, simultaneous engineering is typically
implemented in the form of cross-functional teams and
meetings. Organizational stakeholders such as manufacturing,
quality assurance, and purchasing are integrated in the product
development project at an early stage (Karlsson and Ahlstrom,
Engineering Management Journal
Vol. 23 No. 1
1996; Sobek et al., 1999). They are involved in discussing the
product concept and review design proposals to make sure that
the drafts meet the needs of all internal and external stakeholders
(Haque and James-Moore, 2004). Furthermore, representatives
from manufacturing and assembly work with designers and
product engineers to develop production processes and facilities
in parallel to the product (Womack et al., 1990). While requiring a
higher coordinative effort, this early consideration of abilities and
constraints in manufacturing helps to avoid iterations and rework
of designs at later points when decisions are already locked-in
(Brown, 2007; Karlsson and Ahlstrom, 1996; Liker et al., 1996;
Nevins and Whitney, 1989; Susman, 1992).
Toyota, to foster simultaneous engineering in its PD processes,
uses two major mechanisms: module development teams (MDT)
and the obeya (big room). MDTs are cross-functional teams
which are set up for each vehicle subsystem at the beginning of
a PD project. Their main task is to negotiate how to achieve the
performance characteristics given by the Chief Engineer and
resolve key challenges early in the process when there is still a large
amount of flexibility. Each of the MDTs is assigned one or more
designated simultaneous engineers (SE) who serve as programdedicated representatives from manufacturing. Furthermore,
Toyota has set up special rooms, called obeya, which serve as
venues for regular meetings between the chief engineer and the
leaders of the functional groups. On the walls of the obeya, the
functional engineers post the latest information on the status
of the project as well as drafts, simulations, and test results,
thereby enhancing cross-functional collaboration (Morgan and
Liker, 2006).
Supplier Integration
Traditionally (chiefly in the western world) companies work with
a large number of suppliers for every part. Before approaching
the suppliers, they define detailed part specifications, invite for
tenders and—mainly based on price as a criterion—award the
business to a supplier. As Liker et al. (1995) point out, in the
case of the automotive industry, this tradition has resulted in a
situation with adversarial relationships between automakers
and outside suppliers. Automakers have often used their market
power to extort low prices from suppliers. Suppliers, in turn,
have been reluctant to share inside information with original
equipment manufacturers (OEM), fearing that their customers
could use this knowledge against them in the bidding process.
After being chosen as the supplier for a particular part, they have
used inevitable changes in the product development process to
raise their initially negotiated price (Liker et al., 1995; Morgan and
Liker, 2006; Ward et al., 2007). The process of price negotiation
with a large number of suppliers requires a high amount of
resources on the part of the OEM, resulting in large purchasing
organizations (Fiore, 2004; Liker et al., 1995; Morgan and
Liker, 2006).
Companies with a strong emphasis on Lean practices have
been found to follow a fundamentally different approach regarding
their relationship with suppliers. They usually have a much smaller
supplier base with whom they work on a longer-term basis. Key
suppliers are integrated into the product development activities at
an early stage and work closely with the development engineers of
the OEM (Dyer, 2000; MacDuffie et al., 1996; Morgan and Liker,
2006). At Toyota, using pre-sourcing arrangements, key suppliers
(typically two or three per part) are already incorporated in
the extended product development team during concept stage
and actively participate in the design process (Fujimoto, 1999;
March 2011
9
Karlsson and Ahlstrom, 1996; Liker et al., 1995; Morgan and
Liker, 2006). In order to improve the performance of suppliers
and reduce costs, Toyota engineers discuss with the suppliers how
their product and development processes can be improved and
offer their help to solve issues with designs (Liker et al., 1995;
Ward et al., 1995). Furthermore, Toyota constantly hosts several
hundred guest or resident engineers who are residing full-time
at Toyota’s product development department (Liker et al., 1995;
Morgan and Liker, 2006).
Despite its close cooperation with suppliers and extensive
outsourcing of parts and engineering, Toyota is very careful to
not lose critical knowledge and prematurely award business to
suppliers who cannot guarantee to deliver the expected quality
(Liker et al., 1995; Morgan and Liker, 2006). The strategic
importance of parts is carefully evaluated before its development
is transferred to suppliers. Development and production of
critical parts are not outsourced but kept within the company in
order to maintain control (Morgan and Liker, 2006).
Product Variety Management
A large variety of products, components, and parts comes at the
cost of larger complexity, higher inefficiencies, and decreased
possibilities for using economies of scale throughout the entire
product lifecycle (MacDuffie et al., 1996). In order to avoid the
drawbacks that are connected with a high variety in products and
parts, in the literature on Lean PD several authors have suggested
using techniques that can be summarized under the common
heading of “product variety management” (Ramdas, 2003).
Specifically, authors propose to make use of commodities, reuse
parts, and define modular components and product platforms.
First, whenever a part of a product is not perceived as a critical
differentiating feature by the customer, can be easily ordered from
a catalogue, and cannot be manufactured by the company at a
significant cost advantage, it is generally recommended to order
the part from a supplier instead of developing and producing
the part within the company. Using catalogued parts allows an
organization to draw on the experience of suppliers who have
specialized in an area and helps to reduce engineering effort and
risk (Fiore, 2004; Ward et al., 2007).
Besides making use of commodities in designs, a company
should try to reuse product parts among different modules,
products, and product families as well as subsequent versions of
the same product. Parts should only differ if this is justified by a
perceivable value-added for the customer (Ulich, 1995). Toyota,
for example, has a carry-over rate, i.e. percent reuse of components
from a previous model to the successor, of about two-thirds
(Schuh et al., 2007). Toyota is very cautious about introducing
new technologies and tries to leverage their proven solutions
from existing products as much as possible (Fiore, 2004).
Ordering single components from catalogues and reusing
parts from previous products and other subsystems is difficult
if the product is highly integrated (Baldwin and Clark, 2000);
therefore, the literature on Lean PD generally recommends
dividing the products into distinct modules and subassemblies
with standardized interfaces. Modules facilitate the redesign of
particular parts of the product, allow parallelization of design
tasks, improve maintenance issues, reduce complexity, and foster
learning and continuous improvement (Fiore, 2004; Haque
and James-Moore, 2004; Morgan and Liker, 2006; Smith and
Reinertsen, 1997).
To be able to use modules across several product lines and
maximize the reuse of parts, a company can furthermore make
10
use of product platforms. Product platforms serve as a carrier for
different subassemblies. They allow the combination of modules
with standard geometries and interfaces in a way that leads to
high flexibility and diversified products while keeping overall
part variety low (Meyer and Lehnerd, 1997; Meyer and Utterback,
1993; Morgan and Liker, 2006).
Rapid Prototyping, Simulation and Testing
Considering the large number of iterations that are required for
one product development project, an increased speed of problemsolving can decisively shorten time-to-market and have a positive
effect on product quality, performance, and organizational
learning (Brown, 2007; Smith and Reinertsen, 1997). In this
context, authors in the literature on Lean PD have emphasized
that methods and technologies supporting fast prototyping,
simulation, and testing of designs can significantly contribute to
a high-performance product development system. They provide
the engineers with quick feedback on ideas, result in a faster
convergence of designs, and ensure integration among different
modules (Morgan and Liker, 2006; Oppenheim, 2004; Schuh et
al., 2007; Thomke and Fujimoto, 2000; Ward et al., 2007).
The traditional way of quickly evaluating designs lies in
building physical models and prototypes. It has been pointed
out that, to foster well-grounded decisions and avoid problems
in later phases, prototypes should be built in early stages of
product development (Ward et al., 2007). Using low-cost
techniques, mock-ups of products can first be modeled out of
foam, foam core, cardboard, or wood to gain fast insights on
geometric properties (Ward et al., 2007). Later, the designs
are translated into more sophisticated prototypes to check the
integration of modules and test the system for failure modes. At
Toyota, while the first prototypes are assembled very carefully to
check the interfaces of subassemblies, all subsequent prototypes
are produced and assembled using Lean Manufacturing
techniques (Ballé and Ballé, 2005). As Ward reports, by the
consequent application of Lean Manufacturing techniques, the
Toyota supplier Delphi in one instance was able to cut times for
simulation and tests from weeks and months to 24 hours each
(Ward et al., 2007).
In recent years, traditional ways of prototyping have been
more and more complemented by advanced digital technologies
such as computer-aided modeling, simulation, digital assembly,
and 3D prototype printers. The use of these techniques can, if
employed appropriately, strongly contribute to identifying and
solving problems at a faster rate. Iterations can be run earlier and
often at a lower cost than is possible with elaborate, expensive
physical prototypes that require a long time to build (Morgan
and Liker, 2006; Thomke and Fujimoto, 2000). Moreover, virtual
tools such as digital assembly can help identify problems before
the program enters prototype phase which can result in a lower
number of prototypes needed (Morgan and Liker, 2006).
Process Standardization
While product development projects naturally differ from case
to case, it has been found that many tasks required for planning
and executing product development are quite consistent across
different projects (Fiore, 2004; Morgan and Liker, 2006).
To increase product development performance, it is widely
recommended to identify these reoccurring tasks and standardize
them. Standardization helps to reduce variability, increase
efficiency, minimize errors, capture and manage knowledge, and
Engineering Management Journal
Vol. 23 No. 1
March 2011
serves as a basis for continuous improvement (Ballé and Ballé,
2005; Morgan and Liker, 2006; Sobek et al., 1999).
From a macro perspective, a very common way of
standardizing processes is to predefine a sequence of project
milestones in which product development projects within the
organization ought to be completed (Liker et al., 1995; Morgan and
Liker, 2006). Particularly in combination with other standardized
tools for project planning, using blueprints for project planning
can contribute to a higher reliability of plans and a better
synchronization of functions (Morgan and Liker, 2006). As every
project follows the same general order of steps, engineers are able
to develop a certain routine and gain a deeper understanding of
their role in the overall value stream (Morgan and Liker, 2006).
When problems arise during product development, the use of
standard processes facilitates more rapid problem diagnosis, root
cause analysis, and development of remedial countermeasures
(Spear and Brown, 1999). Also, in an organization where multiple
projects are conducted at the same time, knowing the sequence
in which tasks are completed can strongly facilitate the planning
and alignment of shared resources (Morgan and Liker, 2006.
To reduce variety during the execution phase of the
PD project individual engineers should be provided with
standardized tools and procedures that support them in their
creative design efforts (Ballé and Ballé, 2005; Morgan and Liker,
2006). These can range from standardized work instructions and
design standards to standardized methods for problem solving.
At Toyota, for example, besides standard checklists and tradeoff curves, engineers make extensive use of a method called “five
whys” that allows them to analyze the root cause to a particular
problem (Ballé and Ballé, 2005). Problem solving is supported by
special decision matrices (Morgan and Liker, 2006). Additionally,
documentation and communication of information is facilitated
by the use of dense and highly structured A3-reports (Morgan
and Liker, 2006; Ward et al., 2007).
Adherence to standards in many ways constitutes an
important part of a Lean PD system; however, as Ward and
Kennedy particularly put forward, imposing a large number of
standards can quickly lead to overregulation and impair the fourth
Lean PD component—responsibility-based planning and control.
Since this has negative consequences for organizational learning
and innovation, it is important to continuously challenge the
standards and make suggestions for their improvement (Morgan
and Liker, 2006).
Set-Based Engineering
Set-based engineering, also known as set-based concurrent
engineering or set-based design, describes a new paradigm
for structuring the process of developing a particular product
module.
Normally, at the start of a PD, project engineers develop a
small number of alternative concepts for each product module,
assess the solutions, and select the most promising one to be
pursued in the further product development process. In an
iterative process, the selected solution is then refined, tested,
and modified until it satisfies the requirements formulated at the
beginning, and can be successfully integrated with other modules
(Liker et al., 1996; Ward et al., 1995).
Using set-based engineering, a much larger number of
possible solutions for each product module is considered at the
front-end of the PD process. Instead of quickly narrowing down
the set of alternatives, engineers design, test, and analyze multiple
solutions for every subsystem in parallel (Morgan and Liker,
Engineering Management Journal
Vol. 23 No. 1
2006). Using extensive prototyping and testing, engineers explore
failure modes and trade-offs of particular solutions and check
for the compatibility with adjacent parts (Ballé and Ballé, 2005;
Morgan and Liker, 2006). Only when, based on objective criteria,
a solution has been proven to be inferior to other designs, this
design is removed from the solution space (Schuh et al., 2007). In
this way, the set of alternatives is gradually narrowed down and
finally converges to a single solution (Ward et al., 2007). Once
the engineers have decided on a particular solution for a design,
this solution remains unchanged until start of production unless
altering the module is absolutely necessary (Ward et al., 1995).
In the literature on Lean PD, it has been argued that the
procedure suggested by set-based engineering is superior to the
one used in traditional product development because investing
time and resources to explore alternatives early in the project
significantly reduces uncertainties and iterations in subsequent
phases of the project (Ballé and Ballé, 2005; Sobek et al., 1999).
Since changes in design become more costly as the project
proceeds towards the start of production, front-loading the
product development process instead of iterating in later stages
is likely to reduce the overall cost of product development
(Kennedy, 2003; Liker et al., 1996; Schuh et al., 2007; Ward et
al., 2007). Moreover, modifying a solution late in the product
development process causes rework, often affecting the design of
adjacent components and, therefore, causing major disruptions
in flow (Brown, 2007; Liker et al., 1996; Sobek et al., 1999;
Ward et al., 1995; Ward et al., 2007). Especially when capturing
and reusing the knowledge that is generated through early indepth investigations, set-based engineering can possibly find
more innovative and robust solutions than the point-based
approach (Kennedy, 2003; Sobek et al., 1999; Ward et al., 1995).
It should be noted, however, that in the case of complex and
costly goods, building a large number of prototypes might be
prohibitively expensive, making computer-aided simulations
the more viable option.
Interdependencies between the Lean PD Components
In the previous sections, the 11 Lean PD components derived in
the first step of the content analysis were presented. In this section
we summarize the findings of the second step—the analysis of the
component interdependencies. Exhibit 3 displays the cause-effect
matrix showing the theoretical qualitative interdependencies
between the 11 Lean PD components. The first row and column
each contain the 11 Lean PD components, spanning a table of
121 fields. The entries of the table qualitatively describe how the
row element and the column element are hypothetically linked.
Specifically, each entry details how the component in the row
may require the component in the column. As an example,
the component Responsibility-Based Planning and Control
(column) is thought to contribute to the component Specialist
Career Path (row) by enhancing individual learning through
higher involvement, accountability and ownership. Vice versa,
Responsibility-Based Planning and Control (row) is likely
supported by the component Specialist Career Path (column) in
the way that engineers have a higher expertise to set their own
goals, estimate the time they require for a particular task and are
better able to achieve the goals they have defined for themselves.
As explained, the relationships described in Exhibit 3 were
derived using two methods. First, links were directly extracted
from literature through content analysis. Second, based on our
thorough investigation of the components, we hypothesized
links for pairs of components where the content analysis yielded
March 2011
11
12
Engineering Management Journal
Vol. 23 No. 1
March 2011
Availability of knowledge
on feasibility of part
reuse, module and
interface design from past
projects [2]
Best practices in testing
and prototyping;
documentation of failure
modes [17, 22]
Gathering of best practice
milestones and
procedures; best practice
standard tools
X
Higher incentive for using
past knowledge due to
accountability and
ownership
Higher incentive for
integration of suppliers
due to accountability and
ownership
Higher incentive for part
reuse and modularization
due to accountability and
ownership
Autonomous development
of test plans; higher
incentive for early and
intensive testing and
prototyping due to
ownership
Continuously improving
standards; higher
acceptance of common
processes due to
involvement of engineers
in updating
Reliable planning of tasks
and estimation of
durations through clear
staggering and
prioritization of projects
Time for reviewing past
project findings before
project start, time for
reflection and
documentation of lessons
learned [17, 26]
Higher predictability of
demand for functional
specialists; improved
synchronization [17, 18]
Reliable deadlines for
parts delivery [13]
Time for reviewing past
designs and structural
best practices; time for
communication to
increase reuse, define
modules
Availability of qualified
testing and prototyping
personnel when needed
[26]
Improved planning
through standard process
logic, predictable and
repeatable processes [17,
18]
Time to follow several
alternatives in parallel and
test them rigorously
before narrowing in [24]
Technical expertise to set
goals, estimate time
required and adhere to
goals set [24, 26]
Higher ability for
reflection and
documentation of lessons
learned [17, 24]
Better understanding of
engineers for needs of
manufacturing [17]
Clear definition of
requirements; early
identification of problems;
mentoring and teaching of
suppliers [17]
High expertise in dealing
with particular part
functionality, geometry
and interfaces [17, 19]
Seamless cooperation
between designer and
testing personnel; testing
competence among
designers [17, 26]
Better adherence to
schedule and linear
process steps through
reduced iterations
Expertise for developing
alternative solutions,
defining interfaces,
weighing pros and cons,
choosing and merging
alternatives [26]
Alignment of sub-goals to
customer value; frequent
control of adherence to
goals and schedule [11]
Enforcement of use of
checklists and knowledge
transfer [17, 26]
Enforcement of early
integration and
synchronization of
product development and
manufacturing [12, 22]
Enforcement of early
integration and
synchronization with
suppliers [17]
Enforcement of reuse and
modularization due to
Strong Project Manager’s
responsibility for cost and
performance [11, 18, 22]
Coordination of testing
and prototyping [12, 17,
18]
Reduced variability in
processes through better
adherence to schedule;
reduced iterations due to
clear concept [19]
Coordination of parallel
development and driver
for narrowing decisions
[18, 22, 26]
Cross-project Knowledge
Transfer
Simultaneous
Engineering
Supplier Integration
Product Variety
Management
Rapid Prototyping,
Simulation and Testing
Process Standardization
Set-based Engineering
Autonomous development
of alternatives and
accountability for results
[24, 26]
Higher incentive for
cooperating with
manufacturing due to
accountability and
ownership
High predictability of
projects through better
adherence to schedule,
larger motivation [26]
Responsibility-based
Planning and Control
X
High availability of
functional specialists for
flexible planning; less
iterations through
standard skills, high
techn. expertise [17, 22]
High predictability of
projects through rigorous
project-internal planning
and control, clear
concept, cross-functional
coordination [7, 17, 19]
Freezing and re-use of
design sets from previous
projects; generalization of
solutions in trade-off
curves [22, 26]
Documentation of
supplier performance,
preferred suppliers and
their strengths and
weaknesses
Transfer of manufacturing
requirements and best
practice solutions [17, 22]
X
More reliable planning of
tasks due to availability of
past experience
Reduced variability
through avoidance of
unnecessary steps,
iterations and learning
Enhancement of technical
expertise through everincreasing knowledgebase [17, 22]
Workload Leveling
Enhancement of learning
through higher
involvement,
accountability and
ownership [26]
Time for teaching,
mentoring and reflection,
increased learning
through more reliable
project runs [26]
X
Project manager as role
model and mentor;
learning through constant
design reviews [17]
More reliable project
planning, cost and time
estimation [22]
Specialist Career Path
Reliable project planning
and progression through
better adherence to
schedule and larger
motivation; reduced
planning efforts [12]
Cross-project Knowledge
Transfer
Development of qualified
Strong Project Managers,
reliable concept
development and
planning due to help of
experienced engineers
[27]
Reliable project planning
and progression due to
reduced over-burdening
of engineers, lower
waiting times, clear prioritization of activities [26]
Responsibility-based
Planning and Control
Workload Leveling
Specialist Career Path
X
Strong Project Manager
Strong Project Manager
How does component in
row require component in
column?
Exhibit 3. Theoretical Qualitative Interdependencies Between the Components of Lean PD
Consideration of
alternative manufacturing
processes; evaluation of
alternatives for
manufacturability and
robustness [17, 22, 26]
Reduced variability of
processes due to early
integration of
manufacturing [14]
Use of manufacturing
expertise in prototyping
and testing; early testing
for manufacturing
requirements and
assembly [17]
Development of
alternative solutions and
narrowing in by suppliers;
frequent communication
[13, 17]
Reduced variability
through early integration,
careful outsourcing,
rigorous testing and fast
sourcing process [17]
Fast sourcing of testing
equipment, prototype
parts and tooling;
rigorous testing
conducted by suppliers
[13]
Definition of standard
designs and interfaces for
suppliers; integration of
suppliers in module and
platform development
X
Improved make-or-buy
decision making, precise
definition of requirements,
mentoring of suppliers in
manufacturing strategies
[26]
Integration of
manufacturing
requirements in modules
and reuse strategy [17]
Early integration of
manufacturing
requirements in supplier
contracts
Integration of supplier
requirements and ratings
in documentations
More reliable planning of
tasks due to fast sourcing
and high quality of
delivered parts
Reduced variability
through early integration,
careful outsourcing,
rigorous testing and fast
sourcing process [17]
Cooperation with
suppliers as important
competence of product
development engineers
More reliable project
planning and progression
due to early integration,
careful outsourcing and
high quality of delivered
parts
Supplier Integration
X
Documentation and reuse
of knowledge on
requirements of and
design for manufacturing
More reliable planning of
tasks due to large amount
of interaction with
manufacturing
Reduced variability
through early integration
of manufacturing/ parallel
development of product
and process [17]
Cooperation with internal
stakeholders as important
competence of product
development engineers
More reliable project
planning and progression
due to early integration of
manufacturing, parallel
development of product
and process [17]
Simultaneous
Engineering
Clearly separated
modules with standard
interfaces to be
developed in parallel [24,
26]
Reduced variability in
processes through
increased reuse, standard
designs and interfaces
[15]
Faster testing through
reuse and standard
designs; independent
testing and prototyping
through clearly separated
modules [15]
X
Reduced sourcing effort
through reuse; clear
separation and interchangeability of modules
through standard designs
and interfaces [15, 17, 26]
Reduced complexity of
parallel product and
process development
through standardized
modules and interfaces
Easier documentation of
best practice of structures
and designs due to lower
part variability and clearly
defined interfaces
Better planning and easier
control of tasks due to
clearly separated modules
Reduced variability
through reduced design
and testing requirements
and parallel development
of parts due to standard
interfaces [7, 19]
Better specialization and
faster learning due to
clearly separated modules
More reliable project
planning and progression
due to reduced design
and testing requirements
[16]
Product Variety
Management
Rigorous testing of
design sets; narrowing
based on profound
information base;
gathering of knowledge in
trade-off curves [22, 24]
Reduced variability of
processes through early
and shorter problemsolving cycles [23]
X
Higher robustness of
parts, modules and
platforms through early
and fast testing and
prototyping [17]
Faster formulation of
requirements and early
discovery of problems
with supplied parts
through rapid testing and
prototyping [26]
Early and faster testing
and optimization of
design for manufacturing
and assembly [1, 2]
Generation of objective
test data through early
and short problem-solving
cycles [23]
More reliable planning of
tasks due to early and
shorter problem-solving
cycles
Reduced variability
through early and shorter
problem-solving cycles
[23]
Increased and faster
learning through early
and shorter problemsolving cycles [23, 26]
More reliable project
planning and progression
due to early and shorter
problem-solving cycles
[1]
Rapid Prototyping,
Simulation and Testing
High synchronization of
parallel processes
through standard
procedures, tools and
documentation [17]
X
Systematic and faster
testing and prototyping
through standard
procedures [16]
Standardized processes
and tools for increasing
part reuse and developing
modules and platforms
[17, 22]
Better integration of
suppliers through
standard procedure for
contracting, partnering
and sourcing
Better synchronization of
product and process
development through
standard procedures and
tools [17, 22]
Better reuse of knowledge
due to similarity of
subsequent projects and
tools employed [17]
Improved planning and
control of tasks due to
standard tools for design
and communication [17]
X
Reduced variability
through reduced late
engineering changes,
high robustness of
solutions [24]
Development of expertise
in testing and prototyping
through testing of many
alternatives
Better understanding of
interdependence and
higher robustness of
parts, modules and
platforms [19]
Earlier and stronger
integration of suppliers
through involvement in
development of
alternatives and frequent
communication [17]
Earlier and stronger
integration of
manufacturing through
early consideration of
different alternatives [24]
Increased rate of
knowledge creation and
documentation through
consideration of wide
range of possible
solutions [10]
More reliable planning of
tasks due to reduced late
engineering changes,
high robustness of
solutions [14, 24]
Reduced variability
through reduced late
engineering changes,
high robustness of
solutions [24]
Increased and faster
learning through
consideration of wider set
of technical solutions [22]
Increased and faster
learning through standard
process logic, reduced
variability through
standard tools, and
documentation [17]
Higher acceptance of
common processes due
to more reliable project
runs and less waiting
times
More reliable project
planning and progression
due to reduced late
engineering changes,
high robustness of
solution [1]
Set-based Engineering
Faster project planning
and better control through
standard milestones,
tools, documentation and
communication [1, 2]
Process Standardization
no insights on interdependencies (which was the case for 30 of
110 total links specified.) The links identified from literature are
shown in Exhibit 3 with the references in square brackets, where
the numbers in the brackets correspond to the 27 publications
listed in Exhibit 1.
The links or interdependencies in Exhibit 3 represent a
potentially rich framework of hypotheses that not only lend
themselves to testing, but also provide further insights into
the structure and relationships in a Lean PD organization. An
interesting example is the case of Set-Based Engineering. It has
been identified in a number of different sources as a key practice
in Lean PD, but not described generally in relation with the
other Lean PD components identified in this study. Because it is
has been discussed frequently in other sources, all relationships
between it and the other components in Exhibit 3 are drawn from
existing references, albeit based to varying degrees on empirical
evidence. The nature of the relationships suggests that some
of the components are prerequisite to Set-Based Engineering
(e.g., Process Standardization, Workload Leveling, Specialist
Career Path, Product Variety Management, Rapid Prototyping,
Simulation, and Testing, Supplier Integration) because they
provide the necessary capacity, tools, or processes to execute
Set-Based Engineering as it is described. Other components may
not necessarily be prerequisites, but are likely coincident with
Set-Based Engineering in the near-term (e.g., Strong Project
Manager, Simultaneous Engineering) and over the longer term
(e.g., Responsibility-Based Planning and Control, Cross-Project
Knowledge Transfer) to support and augment its effectiveness.
This illustrates that these components may be interrelated on
multiple dimensions and in various ways. The relationships
between the components in Exhibit 3 are fully specified (i.e., all
fields define relationships), but the nature of those relationships
is far from fully explored.
Overall, while in the previous sections the 11 Lean PD
components were presented as separated entities, the theoretical
analysis of their relationships suggests that they are by no means
independent. In fact, as Exhibit 3 shows, it is likely that the
components interact with and depend on each other in a variety
of ways. Even though the degree to which components are linked
differs, our analysis suggests a view of Lean PD as a system of
highly interwoven elements which only in their concurrency lead
to a stream-lined and cost-efficient product innovation process.
Discussion
In this article we analyzed existing approaches to Lean PD
and integrated them into a parsimonious and succinct theory
framework. We reviewed frameworks for Lean PD suggested
in literature and found existing definitions of Lean PD to vary
regarding their focus and terminology. We concluded that
currently there is an apparent lack of consensus on the constituent
elements of Lean PD systems. To fill this gap, we used content
analysis to conduct an in-depth analysis of 27 publications on
Lean PD. We extracted a total of 316 quotes describing elements of
Lean PD and clustered them into 11 major categories, called Lean
PD components. Furthermore, we investigated the theoretical
interdependencies between the components we had identified.
Both the components and their relationships were described in
detail to give insights into the definition of a Lean PD system as
proposed in this article.
With our work we make three important contributions to a
more consistent description of Lean PD. First, while many of the
publications in the area of Lean PD when citing previous work refer
Engineering Management Journal
Vol. 23 No. 1
to a very limited number of studies, we provide a comprehensive
description of the background of the research field and its most
important contributors. By giving an overview of the historical
development of Lean PD, we point to the underlying dynamics that
have induced authors to focus on certain components of a Lean
PD system and have ultimately resulted in a high fragmentation
of the field. Understanding the history of Lean PD, from our
perspective, is essential when trying to advance the field in
future research. As the second important contribution, our work
integrates existing approaches to Lean PD into a single, coherent
framework. Unlike previous approaches, we do not simply present
another novel definition of Lean PD. Instead we systematically
investigate overlaps between frameworks presented previously
and combine them to achieve a robust definition of Lean PD. Due
to its integrating nature, our theory framework has the potential
to dissolve the current fragmentation of the research field and
contribute to a common conception of Lean PD. Third, our
work fosters the understanding of Lean PD as a system of highly
interwoven, interdependent components. In the past, several
authors have emphasized the importance of approaching Lean PD
from a systems perspective (Ballé and Ballé, 2005; Morgan, 2002;
Sobek et al., 1999). This paper presented a thorough investigation
of the theoretical relationships between the components of Lean
PD. From our point of view the hypothetical dependencies we
derived can serve as a fruitful basis for further studies.
An important caveat in the development of this framework
is that we have drawn almost exclusively from literature expressly
focused on Lean PD. Lean PD is a new and rapidly evolving area of
interest, but it represents only a small fraction of the many interest
areas associated with the study of PD systems, and ultimately is
empirically linked to a rather narrowly-defined population and
small sample. This represents a potential limitation in the scope
and completeness of the framework described here. We have
tried to include research and theory perspectives from the larger
PD research community, but are necessarily limited in the scope
of what we can include in this article. A more comprehensive
exercise of comparing the Lean PD principles identified in this
article with those found in existing literature on PD is appropriate
and recommended. We remain convinced that our central
premise that a generalized framework for Lean PD practices
will ultimately allow expansion of empirical findings and theory
remains sound.
Building upon our theoretical analysis presented in this
article, we suggest a number of directions for future work.
First, we recommend advancing understanding of Lean PD at a
component level. As pointed out, Lean PD currently builds on a
rather small number of empirical studies that have a strong bias
toward practices at the automotive manufacturer Toyota. So far,
it remains under-investigated as to what extent the components
described in this article are used in companies other than Toyota
and whether or not the positive effects observed at Toyota are
generalizable. More in-depth case studies in different sectors are
required to fully understand potential external contingencies
that determine the use and success of specific components. The
implementation of the Lean PD components should be studied
to identify factors and contingencies leading to their successful
implementation.
Second, we urgently call for further empirical research on
Lean PD from a systems perspective. In fact, of the component
interdependencies displayed in Exhibit 3, only a small number
result from systematic empirical study. So far, it is not well
understood how the use of particular components affects the
March 2011
13
effectiveness of others. We believe that a better understanding of
the interdependencies between the elements outlined in this article
plays an important part when trying to explain the performance
of a PD system. The study of the interdependencies between
components would also benefit from a wider range of samples. On
the one hand, these could replicate the large, complex, mediumvolume, medium mix PD environment of firms like Toyota. On
the other hand, it would be interesting to deliberately depart from
that combination of factors and investigate settings as they can be
found in high-volume consumer goods firms or large complex
projects such as in defense or public works. As far as we know,
there are no existing empirical studies of the implementation of a
Lean PD system (comprising the scope of the set of components
presented in this framework), apart from those of Toyota and
its decades-long evolution of its PD system. Insights gained
from the study of component interactions at the system level
will be of great help when deriving recommendations on how to
implement a Lean PD system in an organizational setting. Since
this question has a particularly high relevance for practitioners,
we are convinced that future research on Lean PD which assumes
a holistic systems perspective can add a great deal of value to the
field of innovation management.
References
Allen, Thomas J., and Ralph Katz, “The Dual Ladder: Motivational
Solution or Managerial Delusion,” R&D Management, 16:2
(1986) pp. 185-197.
Armstrong, Stephen C., Engineering and Product Development
Management: The Holistic Approach, Cambridge University
Press (2001).
Baines, Tim S., Howard Lightfoot, George M. Williams, and Rick
Greenough, “State-of-the-Art in Lean Design Engineering:
A Literature Review on White Collar Lean,” Proceeding of
the Institution of Mechanical Engineers, Part B: Journal of
Engineering Manufacture, 220:9 (2006), pp. 1539-1547.
Baldwin, Carliss Y., and Kim B. Clark, Design Rules: The Power of
Modularity, The MIT Press (2000).
Ballé, Freddy, and Michael Ballé, “Lean Development,” Business
Strategy Review, 16:3 (2005), pp. 17-22.
Brown, Jim, The Lean Product Development Benchmark Report,
Aberdeen Group (2007).
Charmaz, Kathy, Constructing Grounded Theory: A Practical Guide
Through Qualitative Analysis, Sage Publications (2006).
Clark, Kim B., W. Bruce Chew, and Takahiro Fujimoto, “Product
Development in the World Auto Industry,” Brookings Papers
on Economic Activity (1987), pp. 729-781.
Clark, Kim B., and Takahiro Fujimoto, “Reducing the Time to
Market: The Case of the World Auto Industry,” Design
Management Journal, 1:1 (1989), pp. 49-57.
Corbin, Juliet M., and Anselm Strauss, “Grounded Theory
Research: Procedures, Canons, and Evaluative Criteria,”
Qualitative Sociology, 13:1 (1990), pp. 3-21.
Cusumano, Michael A., and Kentaro Nobeoka, Strategy, Structure,
and Performance in Product Development: Observations from the
Auto Industsry, Massachusetts Institute of Technology (1990).
Cusumano, Michael A., and Kentaro Nobeoka, Thinking Beyond
Lean: How Multi-Project Management is Transmforming
Product Development at Toyota and Other Companies, Free
Press (1998).
Dyer, Jeffry H., Collaborative Advantage: Winning Through
Extended Enterprise Supplier Networks, Oxford University
Press, U.S.A. (2000).
14
Fiore, Clifford, Accelerated Product Development: Combining
Lean and Six Sigma for Peak Performance, Productivity Press
(2004).
Fujimoto, Takahiro, Organizations for Effective Product
Development: The Case of the Global Automobile Industry,
Harvard University (1989).
Fujimoto, Takahiro, The Evolution of a Manufacturing System at
Toyota, Oxford University Press, U.S.A. (1999).
Glaser, Barney G., and Anselm Straus, The Discovery of Grounded
Theory: Strategies for Qualitative Research, Wledenfeld and
Nicholson (1967).
Hall, G.R., and R.E. Johnson, “Transfers of United States
Aerospace Technology to Japan” in Raymond E. Vernon
(ed.) The Techonology Factor in International Trade, National
Bureau of Economic Resarch (1970).
Haque, Badr, and Mike James-Moore, “Applying Lean Thinking
to New Product Introduction,” Journal of Engineering Design,
15:1 (2004), pp. 1-31.
Holsti, Ole R., Content Analysis for the Social Sciences and
Humanities, Addison-Wesley (1969).
Karlsson, Christer, and Pär Ahlstrom, “The Difficult Path to
Lean Product Development,” Journal of Product Innovation
Management, 13:4 (1996), pp. 283-295.
Kennedy, Michael N., Product Development for the Lean Enterprise
- Why Toyota’s System is Four Times More Productive and How
You Can Implement It, Oaklea Press (2003).
Liker, Jeffrey K., Durward K. Sobek, Allen C. Ward, and John
J. Christiano, Integrating Suppliers into Fast-cycle Product
Development. In J. K. Liker, J.E. Ettlie and J.C. Campbell
(Eds.), Engineered in Japan: Japanese Technology Management
Practices, Oxford University Press (1995).
Liker, Jeffrey K., Durward K. Sobek, Allen C. Ward, and John J.
Christiano, “Involving Suppliers in Product Development
in the United States and Japan: Evidence for Set-Based
Concurrent Engineering,” IEEE Transactions on Engineering
Management, 43:2 (1996), pp. 165-178.
MacDuffie, John P., Kannan Sethuraman, and Marshall L. Fisher,
“Product Variety and Manufacturing Performance: Evidence
from the International Automotive Assembly Plant Study,”
Management Science, 42:3 (1996), pp. 350-369.
Mascitelli, Ronald, The Lean Product Development Guidebook Everything Your Design Team Needs To Improve Efficiency
and Slash Time-to-Market, Technology Perspectives (2007).
Meyer, Marc H., and Alvin P. Lehnerd, The Power of Product
Platforms: Building Value and Cost Leadership, Free Press
(1997).
Meyer, Marc H., and James M. Utterback, “The Product Family
and the Dynamics of Core Capability,” Sloan Management
Review, 34:3 (1993), pp. 29-47.
Morgan, James M., High Performance Product Development: A
Systems Approach to a Lean Product Development Process,
University of Michigan (2002).
Morgan, James M., and Jeffrey K. Liker, The Toyota Product
Development System: Integrating People, Process, and
Technology, Productivity Press (2006).
Murman, Earll M., Thomas Allen, Kirkor Bozdogan, Joel CutcherGershenfeld, Hugh McManus, Deborah Nightingale et al.,
Lean Enterprise Value: Insights from MIT’s Lean Aerospace
Initiative, Palgrave (2002).
Neuendorf, Kimberly A., The Content Analysis Guidebook, Sage
Publications (2005).
Nevins, James L., and Daniel E. Whitney, Concurrent Design of
Engineering Management Journal
Vol. 23 No. 1
March 2011
Products and Processes: A Strategy for the Next Generation in
Manufacturing, MacGraw-Hill (1989).
Oppenheim, Bohdan W., “Lean Product Development Flow,”
Systems Engineering, 7:4 (2004), pp. 352-378.
Ramdas, Kamalini, “Managing Product Variety: An Integrative
Review and Research Directions,” Production and Operations
Management, 12:1 (2003), pp. 79-101.
Schuh, Günther, Michael Lenders, and Solveigh Hieber,
“Lean Innovation - Introducing Value Systems to
Product Development,” Proceedings of PICMET, Portland
International Center for Management of Engineering and
Technology (2008), pp. 1129-1136.
Schuh, Günther, Michael Lenders, and Sebastian Schöning, Mit
Lean Innovation zu mehr Erfolg - Ergebnisse der Erhebung,
Werkzeugmaschinenlabor WZL, RWTH Aachen (2007).
Smith, Preston G., and Donald G. Reinertsen, Developing Products
in Half the Time: New Rules, New Tools, Wiley (1997).
Sobek, Durward K., Jeffrey K. Liker, and Allen C. Ward, “Another
Look at How Toyota Integrates Product Development,”
Harvard Business Review, 76:4 (1998), pp. 26-49.
Sobek, Durward K., Allen C. Ward, and Jeffrey K. Liker, “Toyota’s
Principles of Set-Based Concurrent Engineering,” Sloan
Management Review, 40:2 (1999), pp. 67-83.
Sohlenius, Gunnar, “Concurrent Engineering,” CIRP ANN., 41:2
(1992), pp. 645-656.
Spear, Steven J., and Kent H. Bowen, “Decoding the DNA of the
Toyota Production System,” Harvard Business Review, 77:5
(1999), pp. 96-108.
Strauss, Anselm, and Juliet M. Corbin, Basics of Qualitative
Research: Grounded Theory Procedures and Techniques, Sage
Publications (1990).
Susman, Gerald I., Integrating Design and Manufacturing for
Competitive Advantage, Oxford University Press (1992).
Thomke, Stefan, and Takahiro Fujimoto, “The Effect of ‘FrontLoading’ Problem-Solving on Product Development
Performance,” Journal of Product Innovation Management,
17:2 (2000), pp. 128-142.
Ulrich, Karl T., “The Role of Product Architecture in the
Manufacturing Firm,” Research Policy, 24:3 (1995), pp. 419440.
Ward, Allen C., Jeffrey K. Liker, John J. Christiano, and Durward
K. Sobek, “The Second Toyota Paradox: How Delaying
Decisions Can Make Better Cars Faster,” Sloan Management
Review, 36 (1995), pp. 43-61.
Ward, Allen C., and Warren Seering, “The Performance of a Mechanical
Design Compiler,” ICED Proceedings of the 1989 International
Conference on Engineering Design (1989a), pp. 39-45.
Ward, Allen C., and Warren Seering, “Quantitative Inference
in a Mechanical Design Compiler,” Proceedings of the First
Engineering Management Journal
View publication stats
Vol. 23 No. 1
International ASME Conference on Design Theory and
Methodology (1989b), pp. 89-97.
Ward, Allen C., John Shook, and Durward K. Sobek, Lean Product
and Process Development, The Lean Enterprise Institute
(2007).
Watkins, Michael, and Kim B. Clark, Strategies for Managing a
Project Portfolio, Harvard University (1994).
Womack, James P., and Daniel T. Jones, “From Lean Production
to the Lean Enterprise,” Harvard Business Review, 72 (1994),
pp. 93-93.
Womack, James P., and Daniel T. Jones, Lean Thinking: Banish
Waste and Create Wealth in Your Corporation, Simon and
Schuster (1996).
Womack, James P., Daniel T. Jones, and Daniel Roos, The Machine
that Changed the World: Based on the Massachusetts Institute
of Technology 5-Million-Dollar 5-Year Study on the Future of
the Automobile., Macmillan (1990).
About the Authors
Joern Hoppmann is a research associate and PhD candidate
at the Department of Management, Technology, and
Economics at the Swiss Federal Institute of Technology (ETH)
in Zurich. His research focuses on corporate management of
technical innovation. Currently, he investigates the impact of
policy incentives on innovation strategies in the renewable
energy sector.
Eric Rebentisch, PhD, is a research associate at the
Massachusetts Institute of Technology, with a focus on
developing and managing core product realization and
organizational learning capabilities in complex socio-technical
systems. He leads the Lean Enterprise Product Development
research effort in the Lean Advancement Initiative at MIT.
Uwe Dombrowski is a professor at the Technische
Universität Braunschweig and executive director of the
Institute for Production Management and Enterprise Research
(IFU). After studying Mechanical Engineering in Hamburg
and Hannover, Germany, and receiving his doctorate from the
Universität Hannover in 1987, he has been holding leading
positions in the medical technology industry as well as in the
automobile sector for 12 years.
Thimo Zahn is a research assistant and PhD student at the
Institute for Production Management and Enterprise Research
of the Technische Universität Braunschweig, Germany. Before
working for the IFU, he has studied Mechanical Engineering
at the Universität Hannover, Germany, and at the University
of Strathclyde, Glasgow, UK.
Contact: Joern Hoppmann, ETH Zurich, Phone: +41-76232-62-36; jhoppmann@ethz.ch
March 2011
15