fl-:'
/•
/O
K:
HD28
.M414
^2-
ALFRED
P.
WORKING PAPER
SLOAN SCHOOL OF MANAGEMENT
From
Project to Process
Management
in
Strategies for Improving
Development Cycle Time
Engineering:
P.
Adler, A.
Mandelbaum,
and
E.
Schwerer
Vien Nguyen
WP#
3504-92-MSA
October, 1992
MASSACHUSETTS
INSTITUTE OF TECHNOLOGY
50 MEMORIAL DRIVE
CAMBRIDGE, MASSACHUSETTS 02139
From
Project to Process
Engineering:
Management
Strategies for
in
Improving
Development Cycle Time
P.
Adler, A.
Mandelbaum,
and
E.
Schwerer
Vien Nguyen
WP#
3504-92-MSA
October, 1992
JAN
I
1
3 1993
From Project
Management
to Process
An
S.
Engineering:
Empirically-based Framework
for the Analysis of
Paul
in
Product Development
Adler
Art Mandelhauui
Department of Management and Organization
School of Business Administration
Technion
University of Soutiiern California
Haifa, Israel 32000
Los Angeles,
CA
Management
Faculty of Industrial Engineering and
90089-1421
Vien Nguyen
Elizahdh Schwerer
Sloan School of Management
(Iraduate School of Business
Massachusetts Institute of Technology
Stanford University
Cambridge,
MA
02139
Stanford.
C
\
9430.>o01o
Abstract
Product development work has often been studied as though it consisted of isolated
This approach allows organizations' activities to he described in terms of
unique projects.
PERT
models, which either do not acknowledge resource limitations at
all
or
assume that
However, many product development organizations do not rely on
fully-dedicated teams, so their projects suffer delays when re.sources have more than one project
resources are dedicated.
framework for analyzmodel the product development organization as a
stochcistic processing network in which engineering resources are "workstations" and projects
are "jobs" that flow among the workstations. At any given time, a job is either receiving
service or queueing for access to a resource, and our model's spreadsheets and simulations
quantify this division of time. This class of models provides a valuable managerial framework for studying product development becau.se it enables formal performance analysis and
to contend with concurrently. This study develops an empirically-based
ing development time in such contexts.
it
We
points to data that should be collected by organizations .seeking to improve development
cycle times.
These models can serve
as
management
regarding resource allocation and to help
in
tools, for
example, to support decisions
predicting project completion time.
They
also
provide a vaJuable conceptual framework, since they point to commonalities and differences
between engineering and manufacturing operations.
November 1992
^
Author's names are
listed in alphabetical order.
Contents
1
Introduction
1
2
A
2
3
The Conceptual
4
The Research
5
Constructing the Model
9
51
Project Types
9
52
Resources
10
5.3
Tasks
11
5.4
New Product
Projects: Activity
5.5
New Product
Projects: Precedence Const rauits
5.6
Reformulation Projects
Brief Literature Survey
Fi-aniework:
Site:
6
Analysis, Stage
I:
7
Analysis, Stage
II:
8
The
A
Process Model
Plastics division at Chemicals Inc.
Capacity
Cycle Time
Times
5
7
12
13
16
16
18
7.1
The Simulation Model
19
7.2
Simulation Results
22
Conclusion
24
List of Tables
Times of New Produoi Projects
1
Interarrival
2
Resource Characteristics
3
Fraction of
4
Activity Descriptions
5
Processing Times for
6
Probability of Involvement -
7
Maximum
8
Average Number of Times Activities are Executed
9
Processing Times for Reformulations
35
10
Utilization Profile
36
11
Utilization Profile with Pooling
37
12
Values of Adjustable Parameters
38
13
Simulation Model - Resources
39
14
Activity Descriptions - Simulation Model
39
15
Processing Times - Simulation Model
40
16
Utilization Factors - Simulation
40
17
Simulation Results
18
Fraction of
Time Devoted
30
30
to Administrative
and Support Activities
30
31
New Products
32
New Products
33
permissible pooling
Time Spent
34
Model
for
New
Protiucts
34
41
in
Overtime
41
List
Figures
()f
1
Processing Network Representation
2
Traditional
3
Organization Cliart of Chemicals Inc
4
Process Flow Diagram -
5
Process Flow Diagram - Reformulations
6
Iteration Structure for
7
Utilization Profile with Pooling - Graphical Representation
8
New Products
9
Reformulations Activities Flow Diagram - Simulation Model
48
10
New Products
Project Completion
Time - Histogram
49
11
New Products
Project Completion
Time - Cumulative
12
Reformulations Project Completion Time
13
Reformulations Project Completion Time - Cumulative Distribution
PERT
42
Representation
42
43
New Products
44
45
New Products
Activities Flow
46
Diagram - Simulation .Model
111
Distribution
- Histogram
'.
47
48
50
51
52
Introduction
1
I'm
late.
I'm
late,
Product development organizations often view
unique
activities.
The While Rabbit,
for a very important date.
In reality,
Wonderland
Alice in
independent collections of
their projects as
however, projects are often mutually dependent because they place
simultaneous demands on shared resources. Moreover, different jirojects witlim an organization
often exhibit substantial similarity
the overall flow of constituent activities.
in
hypothesize that a process view - that
therefore
a view of the development process as a regular
is,
production process" - can provide a framework
for better
a project
"design
understanding organizations that pursue
multiple concurrent non-unique projects using shared resources
should allow us to quantify the delays
We
experiences as
it
particular, this approach
In
To
waits for resources.
test this
hypothesis, we constructed a process model of an actual firm's product development activities.
In this
paper, we present the models that we constructed and discuss potential roles of process
models
for
managing development
cycle time.
Several business observers, including Blackburn (1991), Stalk and Hout (1990). Clark and
Fujimoto (1989a), and Wheelwright (1989), have noted the increasing pressures on firms to
ac-
and launching new products. The most prevalent tools
for
celerate their process of developing
predicting product development times are descendants of
Technique) and
for several
CPM
(Critical
phenomena
PERT
(Project Evaluation and Review
Path Method) (Dean, 1985), but these techniques
that can slow project progress.
the>
First.
project activities in which activity times are predictable and
first
for
attempts always succeed. Many
at a time.
resources
We
Thus they
fail
in
We
PERT/CPM
assume that resources are dedicated
development organization can be viewed
terms of processes.
development, which we survey
instead of on the
both activity times
analyses,
if
they
to a single project
from contention
for
shared
projects.
posit that the product
can be described
all,
Second, typical
to account for the congestion effects arising
among concurrent
m
example, proposed designs are often tested and iteratively
redesigned and retested until specifications are met
acknowledge resource limitations at
to account
depict an idealized flow of
product development organizations, on the other hand, face uncertainties
and number of activity repetitions:
fail
management
in
This approach
Section
"2,
in
that
it
differs
as a system
whose
activities
from previous studies of product
focuses on the
management
of resources
of individual projects.
model the product development organization
as a stochastic processing
network
iii
which
engineering resources are 'workstations'" and projects are jobs" that compete for "service' from
the workstations. At any given time, a job
Our representation
ing for access to a resource.
from
either receiving service
is
is
the spirit of
in
We
turing.
elaborate upon these differences
models that we
The subsequent
use.
tiiaii
in
workstation or queue-
queuemg network models
manufacturing processes, but the product development environment
that lead to networks with different features
a
lias
for
unique characteristics
those traditionally associated with manufac-
Section
3,
where we describe
m
detail the process
sections of this report are organized as follows
Section 4
describes the division that was our host for this project. Section 5 describes the components of the
model and
data that we collected. Sections
specifies the
discusses the
first
The underlying
work with the time available
is
presented
in
Section
and
'capacity analysis," which culminates
stage
utilization profiles.
6
7.
A
calculations
to resources.
first
7
m
present
OLir analysis.
Section 6
spreadsheets displaying resource
compare the average demand of project-related
The second
stage of analysis focuses on cycle time and
companion paper Adier
(
the methodological challenges of this study, and a second
et.
(
nl.
AdIer
1992b) discusses
tt
m
greater detail
i992a) demonstrates
al
how
such models can be used to better manage time-to-market. Section 8 highlights the lessons that
we learned
in
carrying out the project, points out some limitations of our study, and discusses
future prospects for process modeling
Our
objectives
in this
in
product development environments.
study were threefold.
ment could be meaningfully represented within
that
see
is,
ment managers and
tools based on such a
to test
whether product develop-
framework of process models, "meaningfully,"
model that would be both
theoretically interesting to researchers.
would highlight major differences and
effort
the
we wanted
from the dual perspectives of the practitioner and the academic. Second, we wanted
we could build
if
First,
similarities
to
useful to product develop-
Third, we hoped that this research
between engineering 'knowledge work"
and manufacturing operations.
We
feel
that our effort has been successful on
significant insights into a broad
all
of our three goals: a process
model can
offer
spectrum of product development organizations; both our spread-
sheet and simulation models appear to be promising practical and theoretical tools; and we have
identified a rich
framework
for identifying the differences
and similarities between manufacturing
and engineering operations.
2
The
literature on project
A
Brief Literature Survey
management and product development
addresses the question of congestion
in
is
multi-project environments.
voluminous, but
A
little
of
it
brief survey ot previous
studies highlights the need for research addressing this issue.
A
first
body
of research focuses on information and task flows within projects but does not
tackle problems of queues within a single project or within rnulti-projerr environments
For
example, Cooper (1983) synthesizes the results of nian> held studies of product development.
new product development
finding several key phases of
project success.
a systematic
A
He proposes
way
a "flow" approach,
to ensure that
second body of research
nothmg
(for
is
in
wiiose effective pxecution
is
critical
to
which management considers these phases
in
overlooked.
example, Allen and Cohen 1969, Tushman 1978, and Tushman
1979) has studied both information flow
in
development organizations and the
effect of organi-
zational structure and behavioral patterns on the operation of these organizations. However, the
focus on complex information flows in this research
is
not linked to the cycle-time performance of
discrete projects.
A
third
body
of research
product development work.
is
It
more attentive
complex iterations that characterize most
to the
attempts to describe the overall structure of these iterations but
remains focussed on the single project environment.
highlight lead time as a critical performance measure
Clark
in
1989a. 1989b. 1991)
(1987.
al
f/
product development
They analyze the
coordination between development and manufacturing departments and the integration
stream and downstream
In p.articular tiiey consider the issues of
activities.
^f
up-
simultaneous versus
sequential performance of tasks and of the piecemeal rejt^ase of information from upstream
sources to downstream ones, but they
fail
to recognize
how these processes
re-
are affected by resource
limitations.
Imai, Nonaka, and Takeuchi (1985) consider both
the ability of organizations to adjust their processes
study these performance measures
in
in
cycle time and
response to exogenous factors.
They
the light of five cases of recent product innovations
Japanese and American companies. They identify
innovative development: "top
new product development
management
six critical factors that
encourage
efficient
in
and
as catalyst, sell-organizing project teams, overlapping
development phases, multilearning, subtle control, and the organization transfer of learning."
Again, the focus
is
on management of single projects.
Black, Fine, and Sachs (1990) propose a matrix
method
for deciding
of a product design process according to the flow of information
how
to order the activities
among them Eppinger. Whitney,
Smith, and Gebala (1989) take a similar approach based on models of the design process
organizations. These studies focus on the overall structure of the work flow -
in
in several
particular, the
likelihood of iterations - but they consider neither the queueing effects created by the flow through
this structure nor those created by multii^le concurrent projects
A paper
closer in spirit to ours
is
Taylor and Moore
(
1990)
competing
They take
(Graphical Evaluation and Review Technique) network, which
is
a
for resources.
as their
generalized
that allows probabilistic routing and repetition of activities \ia fin^dhark ioo[is
GERT
model
a
PERT
network
(Neumann.
1979).
They
use the simulation package
Q-GERT
(Pntsker 1979) to study
with multiple research teams and multiple projects. Since
to a single project at a time, their
a
devplopment organization
a.ssume that each
tlie>
team
is
dedicated
model does not include any resource contention and queueing
effects.
Another group of studies
in
now emerging that
is
multi-project environments.
highlights the importance of the process issues
Hayes, Wheelwright, and Clark (1988) develop a framework
understanding the management challenges of product development. Of particular relevance
for
to our
research, they identify "manufacturing capability" as a key determinant of project performance
(pp. 323-327).
By manufacturing
capability, they
mean
not only the manufacturing organization's
readiness to ramp-up production, but also manufacturing
They
speedily constructing high-quality prototypes.
s
contribution to the earlier phases by
further stretch the concept to include the
design engineering organization's internal "process capabilities'" that allow for fast turnaround
of key engineering tasks such as laboratory testing. This e.xtension of the idea of manufacturing
capabilities to the engineering organization leads naturall_\- to the idea that engineering operations
too can be organized according to JIT principles
to
make
this
new approach
But
tht.'v
do not develop the concepts needed
operational.
Several recent studies have attempted to define the more specific concepts needed to flesh
out a process view of project management.
cessful
new product development and
Blackburn (1991) emphasizes the
between suc-
link
the Just-In-Time manufacturing strategy
In
particular.
he discusses the ideas of organizational design (how functional groups should be structurf>d
).
batch sizing, and coordination with "suppliers"; and he discusses how to translate the Japanese
manufacturing philosophy into the product development setting.
VVatkins and Clark (199'J) present a framework for studying organizations that
evolving portfolio of projects.
They
identify project scheduling, resource dedication,
specialization as three key dimensions in the framework.
They e.xamine
manage an
and resource
strategies used by
man-
agers in deploying their resources and conclude that these strategies are based on assumptions
about the nature of the new product development process that have become
Clark identify the inherent uncertainty
in
the
invalid
Watkins
new product development environment
aiul
as a source
of difficulty for such stratgies.
Schonberger (1986) discusses a case study of
In-Time approach to identify the obstacles
They found that
a
group that
tried to
implement
to rapid project completion
m
their
this type of Just-
own organization
careful recording of their work times highlighted bottleneck areas that they were
able to reduce or eliminate.
Finally,
like
Alexander
(
1990) sketches a queueing network model of product development projects
the one we analyze in this paper.
The author
4
discusses
many
issues of
modeling and data
collection,
and he suggests how principles of queueing theory could he used
Our present study contributes
to this
emerging body of research on the impact of congestion on
project cycle-time in multi-project organizations.
it
to data from real projects
3
We
focus on testmg this approach by applying
a real organization.
in
The Conceptual Framework: A Process Model
For our purpose, a stochastic processing network consists of a collection of "work-
1).
stations" or "resources," each of which
A
"servers" working in parallel.
in
We
propose to model the product development organization as a "stochastic processing network"
(Figure
the
to identify bottlenecks.
same
title,
who perform
the
is
composed
more interchangeable and
of one or
identical
workstation corresponds to a pool of employees, typically with
same functions interchangeably. For example, two
of the resources
our model are "process engineers'" (a pool of two employees) and "manufacturing engineers" (a
pool of five).
The
servers are the technicians or engineers
who make up
the pool
The organization
processes projects, or "jobs," which consist of collections of tasks (such as "Product Prototyping"
and "Product Testing") that are performed by specified resources
tasks can be carried out
tasks
task
may
may
in parallel
while others must be performed sequentially
not begin until several other tasks have been completed, we
is
called its '"processing time," or
between the starts of new projects are called
For example. Figure 2
1.
is
the
PERT
Each job consists of
call
it
a
'activity time."
When
several
"join."
The time
and the intervals
'"
""interarrival times.
use PERT-style diagrams to illustrate constraints on the order
Figure
Certain
specified orders.
begin processing at the same time, we refer to the phenomenon as a "fork": when a
required to complete a task
We
in
in
which tasks are executed.
diagram associated with the processing network depicted
7 activities.
and "Slab Prototype" can be performed
Activities "Vlanufacturing Process
in parallel
(they represent
a fork)
in
Development"
and "Manufacturing
Scale-Up" begins when activities "Product Testing" and "Manufacturing Process Development"
are both completed (a join).
The
processing network
is
stochastic because interarrival times, processing times, and prece-
dence requirements may be subject to
"type"
if
Projects are said to be of the
statistical variability
their individual precedence requirements, processing times,
characterized by the
we distinguished
same
set of probability distributions. In the
2 types of projects, ""new product projects""
discussion in Section
same
and interarrival times can be
sample organization we studied.
and 'reformulation projects"
(see
5).
Underlying our model are several assumptions
First,
we a.ssume that the organizations
tasks and technologies are stable over time and that projects can
!it^
characterized h\
sets of
probability distributions.
We
further assume
tiiat
there
m
of projects and that projects within each type are uniform
their realizations can be attributed
fo stochastic varialnlity,
many common
organizations whose projects share
this class are organizations devoted to the
this
paper can be read as a
number
small
a
is
tlie
of identifiable types
sense that differences
among
Tliese assumptions restrict us to
We
cliaracteristics.
hvpothesize that
among
development of well-defined families of products, and
test of that hypothesis.
On
the other hand, our model
not very useful for understanding groups whose mission
is
is
probably
where projects are by
basic research,
nature more idiosyncratic.
When
new
a
project enters the network,
proceeds to the station(s) corresponding to
it
forking as necessary into the appropriate
first task(s),
number
of tasks. In Figure
project forks into three tasks, and each task then proceeds to
its
1,
its
an incoming
corresponding workstation.
Notice that the activity "Manufacturing Process Development" requires attention from both the
product engineer and the process engineer, we therefore distinguish "process development by
product engineers" and "process development by
the sake of simplicity, we have
and
later figures
tables.)
one of the servers
is
to gain access to a server.
it
has received
its
a task arrives at a station,
available), or
two different tasks. (For
out several arrows and tasks from Figure
left
When
|5rocess engineers" as
it
joins the
end of the queue
for that
its
(if
workstation and waits
(stociiastic) processing time,
Each task has an associated
requisite service at the workstation,
that appear in
either served immediately
is
it
1
and when
project proceeds to the next task(s),
again forking or joining as necessary. In the context of product development, the entities passed
from one workstation
to the next could be engineering drawings,
work orders, or
Hence, one can think of a project "traveling" from one workstation to the next
"departing" from the network when
Although
is
it
all
of
its
for
test results.
processing and
tasks have been completed.
simplest to think of tasks as physical processes (this would be natural
in
ap-
plications such as assembly or manufacturing operations), the flow of tasks can also represent
information flow. Indeed, the ease with which tasks fork
engineering from manufacturing tasks. Whereas
allow different engineers to work
component
in parallel,
a
is
one of the features that distinguishes
drawing and
a
CAD
file
can be reproduced to
manufacturing processes typically do not allow
or subassembly to fork into different parallel processes. Process models for manufac-
turing environments must allow for joins (as components and subassemblies
they do not
in
The queue
come
together), but
general need to confront the greater modeling complexity of forking processes.
at
each workstation (repre.sented by shaded boxes
the "in-box" of the resource.
A
We
in
Figure
1)
corresponds to
complete description of the model must also specify the service
discipline at each station - that
the queue.
for a
is,
the rule by which the server chooses the next task from
implement our basic model using the
6
rouiKl-robm" discipline within priority
In this discipline, a free server takes the next top |Driority task in the
classes.
on
for a pre-specified length of time.
it
If
queue and works
she completes the task withm the time period, the
corresponding project moves on to a successor task, and the server continues with the next top
Otherwise, the task returns to the end of the queue,
priority task in the queue.
processing time
updated
is
to reflect the last
the server.
When
tasks in the
same manner. Clearly there
the queue
empty
is
is
it
waits until
its
remaining
next access to
of top priority work, the station serves the second priority
are other possible choices for service discipline, including
first-in-first-out, last-in-first-out, or project
the round-robin service discipline
round of service, and
its
with the earliest due-date
a reasonable
first
We
conjecture that
approximation of human response to important
competing demands.
In
the
summary, a complete
number
number
of resources
in
specification of a processing network requires the following ingredients:
the network and the iiumiier of parallel servers within each resource; the
of project types; and for each project type, a set of probability tlistributions characterizing
the type's precedence requirements
(i.e.,
the numl)pr of tasks and the order in which they are to
be executed), the processing time of each task, and the interarrival times of new projects.
The model
that
we have proposed
clearly
draws from queueing theoretic concepts and terminol-
ogy and can be seen as a "generalized queueing network." Since Jackson
queueing networks as models of job shops, they have had
ufacturing, communications,
(
1957, 1963) introduced
a rich history of
computer systems, and transportation science
applications
The
in
man-
generalization
of classical queueing networks to processing networks, which allow forking and joining, enables
analysis of systems that are characterized by parallel as well as sequential processing (Nguyen.
1990, 1992). Such models have been used, for example, to represent distributed database systems
(Baccelli, 1989).
We
hypothesize that stochastic processing networks can also be used to analyze
product development organizations.
4
Our
The Research
The
Site:
Plastics division at Chemicals Inc.
whom
research site was an organization
we
call
the Plastics division at Chemicals Inc
order to protect their anonymity (Figure 3 shows an organization chart of Chemicals Inc
Plastics division
sales.
made
Historically,
industries.
With
it
plastic parts
and accounted
for
some
79c
had sold primarily custom-designed products
the slow-down
automobile industry - an
in
defense contracts
effort that coincided
moving away from defense and
into a
in
recent years,
)
in
The
of Chemicals' total domestic
for the
it
was
aerospace and defense
shifting
its
focus to the
with that industry's increa.sed use of plastics. In
commercial market, the Plastics division was increasingly
concerned with cost and time-to-market
issues.
The
Plastics division offered several advantages as a research site.
corporate management were interested
development
in
both divisional and
Fir^t,
understanding how they could accelerate then- product
m
cycle, so they were eager to help us
The
our research.
Plastics division had
recently lost several potential contracts to their principle competitor, a large Japanese firm with
significantly faster product development.
Management support was
project because of the time and effort involved
crucial to the success of our
helping us collect data
in
Second,
years the Product Development manager had been collecting time cards from his
for several
staff,
and these
could be retrieved for our use.
The
staff of the technical
department
in
the Plastics division consisted of engineers and tech-
m
nicians divided into functional groups specializing
cations.
test
A
technical services group supported these engineering groups by helping to
product prototypes.
other staff
product design, process design, and appli-
members
all
Finally,
made
make and
manufacturing engineers, product managers, salespeople, and
critical
contributions to development projects
All these resources
constitute workstations in our network.
Although the group considered
ucts,"
- and
it
it
its
mandate
principal
to be the
development of "new prod-
also handled "reformulations" - projects to replace the materials
supported products on the market.
typically triggered by
customer
constituent material or
when
New
i.iroduct
development and support
interest; reformulations arose either
a better material
became
in e.xisting
available
when
a
products
efforts
were
vendor discontinued a
Reformulation projects tended
to have little urgency: the plant might have several months' supply of the current material, and
the potential cost savings from using a different material was typically small.
circumstances force reformulation projects into top
Management
ically,
rarely did
jiriority
assigned formal priorities to projects to help resources allocate their time. Typ-
projects involving the development of
priority)
Only
new products were gneii
whereas most reformulation projects were treated as priority
affected the trajectory of a project by
department how they should
communicating
]iriority
2
1
(the highest
This priority system
to resources both inside
and outside the
Managers and engineers often expressed exas-
treat the project.
peration over the long delays that priority 2 projects suffered while waiting for attention from
product managers or the manufacturing plant
If
the priority reflectetl the true business impor-
tance of the project, then such delays might seem inevitable and even appropriate. Nevertheless.
one project we studied had spread two person-months of work over
about
inefficiencies
to market,
and the
due to mental set-up time, the opportunity cost of delay
toll
of prolonged
management
quantify the delays arising from various
more
explicitly.
2 5 \ears. raising questions
distraction.
management
in
One purpose
getting the product
of our project
is
to
policies so that these costs can be evaluated
The
Plastics division liad recently defined a standard, five-phase procedure for product de-
velopment. This phase system was the product of
to explicitly characterize the
development process
a
for
new products. Their
a "living guideline which insured that key issues were discussed
moved
into the next phase" of
team that had sought
(luahty im|)rovement
effort
and com|)leted before
from the beginning.
A
a
them informed and
in
in
project
development (quoting from internal division documents).
objective of the phase system was to get people from diflferent functions involved
early stage in order to keep
culminated
One
projects at an
on customer needs
to ensure that projects focused
second purpose was to systematize project evaluation so that people would
ask critical questions early and prevent wasted work. For
us,
the phase system proved crucial by
establishing a nomenclature for project tasks.
5
To characterize
identify
statistically
Constructing the Model
the projects at the Plastics division, we asked our informants to
major categories of projects, according
to the similarity of the projects' acti\ity histories.
For each project type, we required data on the frequency of new job starts
tasks involved, the order in which they were executed (pi
(
mterarrival times), the
edence requirements), and the time
required to complete each task (processing times). Because we accounted explicitly for time spent
on support and administrative duties, we also needed data on the time that each resource pool
devoted to these
activities.
Recall from Section 3 that our model requires the entire distribution
of these quantities and not only their averages.
We
collected our data in three half-day workshops with a group of Plastics division employees
representing most of our resource pools.
recent
new product
aisk
new product
We
Our
intended this preliminary exercise to provide
our informants to generalize to probability distributions
projects."
The data
from the Plastics division
5.1
m
the group and had
a baseline
from which
for the entire "portfolio of
that we describe below are the final estimates that ue obtained
for its portfolio of projects.
Project Types
categorization criteria for project types required that each type occupv a substantial
of resource time and that each have
We
asked them to estimate average activity times for a
project (Project X) which had enjoyed high visibility
been well documented.
we could
We
identified three
main features of
some
structural features distinguishing
a project: the
it
amount
from other types.
assigned priority, the characteristics of the final
product, and the nature of the development effort as reflected
in its
precedence relationships
assigned priority affected the service discipline ai^plied to the [)roject.
The
The
characteristics of the
product determined
Finally,
technical requirements and lience the necessary development activities.
its
the nature of the development effort determined the required resources and activity
sequence.
Following the suggestion of our key contact at the Plastics division, we focused our study on
a family of products
we
will call plastic
engineering organization's time.
in
the broader class of
all
This product family accounted
parts
The other
family was
made up
eitlier priority
Although we recognize two distinct project types, we
and
1
explicitly
less
Our model
1
how
consists of two plastic parts project types:
We
1
Therefore, we
modeled them simply
as support
new products and reformulations. Our
First,
it
various project characteristics affect the product development cycle
combination with support
priority
2.
of our simulation scenarios.
these two categories of projects,
In
As
model only new product
decision to isolate these two types of projects accomplishes two goals.
explore
projects.
or priority
than 49c of the resources' capacity.
collected only aggregate data for reformulation projects, and
many
of the
Reformulation projects, which typically are smaller
priority 2).
than new product projects, constituted
activities in
more idiosyncratic
80%
products, plastic parts work included both new product developments
and reformulations, and these projects could be assigned
projects (of both priority
of
for over
we manage
activities
based our data
all
also treated as
of the group's time.
job interarrival times on management interpretations of quarterly
for
status reports for the few years preceding our study.
there had been 3 priority
.Second, with
to capture the bulk of the Plastics division's time.
and admivistratiie duties (which the group
work), they accounted for virtually
allows us to
1
new product
percent more starts, or 3.15 per year.
final
Our informants estimated
that recently
design reviews per year, with approximately 5
Our contacts
also characterized for us the distribution of
project terminations for those projects that were never completed. Typically these terminations
occurred toward the end of Phase 3 when engineers determined that no feasible solutions existed
for the
remaining problems inhibiting scale-up or launch.
we learned that roughly
summarizes these
5.2
The
For priority 2
2.5 projects per year were initiated
new product
and none were terminated
projects.
Table
1
figures.
Resources
core resources are the product and process engineers and technicians
to product development, but this
"development group"
relied
who dedicated
their
time
on several other resource pools. For
example, they ordered materials from other divisions, ran prototypes
in
the manufacturing plant,
requested tests from the technical services group, sought marketing and sales advice about the
10
concerns of the lead customer, consulted with the specifications group about possible legal
and
relied
on product management
wide differences
effort revealed
and promote these
to coordinate
actlvitit^^i
issues.
Our data gathering
the quality of information available to us on these resources.
in
Considering these information gaps, we distinguished resources that satisfied the following two
the group had potential impact on project process, and
criteria:
acti\ities
its
were adequately
documented. Those groups that potentially affected the rate of project completion but that did
not satisfy the latter requirement are combined into a group called 'Miscellaneous'" which includes
the following functions: Sales. Finance, Specifications, Logistics, and Quality Assuranro
We
of
identified 9 resources.
According to management estimates of resource availability (number
work hours per week per server within each resource), average work weeks varied from 40
55 hours depending on the resource.
The name
number
of the resources, the
of parallel servers
within each resource, and the average availability per week for each are group are shown
2.
The
first 4
to
Table
in
resources. Product Engineer, Process Engineer. Product Technician, and Process
Technician, constitute the core development resources. Collectively they handled approximately
65%
of the product development work.
Table 3 shows estimated fractions of time devoted to
administrative and support activities by each resource group
Tasks
5.3
To
find a partition of the
product development activities
the phase procedure mentioned
in
Section
4.
at
the Plastics division, we turned to
This procedure described
of the development process, specifying a standard protocol for resolving the key issues
phase.
Phase
1
phases
five sequential
each
in
("Concept/Feasibility") was characterized by the intensive involvement of
a
few
marketing and product development people who simultaneously explored technical, manufacturing and market feasibility. In Phase 2 ("Project
project plan was drafted.
as the
Phase
team worked out the
3
Plan/Team")
a full
team was assembled, and a
("Product Development") signaled the project's peak
technical, legal, and marketing issues in detail.
It
effort,
was here that
the development group expected to face the project's critical challenges. Phase 4 ("Manufacturing Standardization/Launch")
full-scale
manufacturing.
wrinkles, and
it
It
marked the
transfer of the project from the development labs to
included a concentrated effort to eliminate any remaining technical
closed with the product launch.
Finally.
Phase
.j
("Continuous Improvement")
Each phase consisted of
represented ongoing refinements while the product was on the market
approximately a dozen issues to be resolved.
To
simplify the data collection and the analysis, we decided to focus on the
(through Manufacturing Standardization/Launch), aggregating Phases
11
1,
2.
and
first
4 into
four phases
one
"activ-
each and specifying Phase 3 (Product Development)
ity"
Phase 3 of the development process because
illustrated
some
it
ni
greater detail
W'e chose to highlight
contained the bulk of project work and because
interesting network features which distinguish product development from
ufacturing, namely, forking, looping
among
activities, continual
marked the time of
it
man-
transmission of information be-
tween steps, and resources who potentially juggled several activities at onct\ Phase
to be a felicitous choice for the additional reason that
it
proved
3 later
crispest activity
definition.
Working with the
Plastics division staff,
model of the development process
and descriptions appear
product development
they skipped Phases
in
Table
for
4.
and
3.
The complete
consists of 17 activities
whose names
fewer resources and fewer person-hours to complete. Often
and began with Phase
as defined in Section 3
3.
Each activity may require attention
corresponds to an activity/resource pair
Thus while each
Review Patent/Product Engineer)
(e.g.
Phase
Reformulation projects tended to be smailpr projects than new
2 entirely
from several resources. A "task"
identified 14 activities in
new product projects
efforts, requiring
1
we
task
is
performed by exactly one
resource, each resource can be responsible for several tasks.
New Product
5.4
We
Projects: Activity
Times
asked our informants at the Plastics division to consider their portfolio of projects' and
estimate the 10th and 90th percentiles of the processing times
expect that 10% of all occurrences of an activity took
more time than our high estimate.
less
We characterize each
time
for
tlian
most
activities.
That
we
is,
our low estimate and \0% took
protyotyping activity by only one number,
which we take to be the actual processing time. Members of the Plastics division perceived that
these activities were of relatively short and invariant duration and that the variability
spent prototyping activities was due mostly to the number of repetitions.
product development projects are shown
in
Table
5.
An empty
The data
activity /resource
times
in
for
new
box indicates
that the resource did not contribute to the activity.
In
empty
Table
cell
6,
an entry of
1
indicates that the resource was always involved in the activity, and an
implies that the resource never devoted time to the activity. Fractional probabilities,
however, can be interpreted
in
two diametrically opposed ways.
On
might be independent, indicating that the activity was not necessary
appropriate representation of the activity "Phase
2.'"
According
tiie
one hand, such entries
This
for all projects.
to Tal.de 6, only
30%
is
an
of projects
required application engineers to contribute to this activity, and independently of the application
engineers' contribution, manufacturing engineers could expect to spend time on Phase 2
the projects.
On
the other hand,
some
m 90%
fractional probabilities reflected interchangeability
12
of
among
Technical employees tend to liave more general
resources.
When
suggest.
the probabilities
in
Table 6
iiulicate the
than their
skills
official
functions
average proportions of times that each
resource was assigned exclusively to a task, we asterisk the corresponding entries.
According
to
this interpretation, asterisked fractional probabilities in each
row sum to the total probability that
m
any given project, either application
the activity occurred. For example, Table 6 indicates that
engineers or product engineers, but not both resources, spent time on
A
field trials.
second issue arises from this tension between interchangeability and specialization.
En-
gineers and technicians - unlike machines and equipment which are their manufacturing counterparts - are capable of handling a wide variety of tasks beyond their formal functions
in
the
organization. For example, during busy periods at the Plastics division, the development group
might turn some of
work over to engineers with nominally
its
different functions, such as
manufac-
turing or applications engineers (who normally dealt with factor^' and customer implementation
Since specialization
issues respectively).
technical capability,
is
it
up
to the
The
terize as fixed versus variable.
our informants, indicate the
A
resources.
modeler to decide how much of
entries
maximum
feature that
plan?
if it
Or
is
7,
which we obtained from conversations with
was
we did not include
In this table, the substitute resources are
in
our models
prolonged Phase
a
1
is
time resolving Phase
1
issues,
Our model assumes that
among
assumed
was
was
more representative it
to
long Phase 2 -
also difficult to formulate a process
if
the development group spent
more straightforward
we would need
a
activities.
it
the two activities are independent
activities,
among
the possible dependence
was topically followed by
difficult to resolve feasibility issues,
the opposite scenario
of dependence
it.
efficiently as the original resources.
One might wonder whether
is,
Table
negative entry indicates a resource giving away some responsibility, and a positive
complete the work as
that
m
this specialization to charac-
extent to which we permit reallocation of work between
entry reflects another resource accepting
A
often a matter of organizational choice and not of
is
for
them
more
to formulate process plans'?"
To answer empirically the question
a joint distribution of all the tasks that
compose
a product development effort; the engineering organization we studied did not keep the detailed
data necessary for such analysis.
New
5.5
Product Projects: Precedence Constraints
Simultaneously with our effort to identify tasks, we asked our key contact
at
the Plastics division to
translate the phase system into PERT-like diagrams illustrating the flow of activities.
flow
diagram presented
shown
in
in
The
activity
Figure 4 reflects the resulting model of the [irocess flow. Activities are
boxes, and arrows indicate precedence
among
13
activities;
if
several resources were involved
in
an activity, we assume
they could execute their tasks
tliat
have only forward arrows: a downstream
activ
it>
Figure 4 represents the following process flow:
a
to
Phase
and testing material samples ("slabs")
product prototypes
and
finally
ideal" project
would ne\er be followed by an upstream
new project begins
Product engineers and technicians begin
3 activities.
An
Phase
at
1
would
activity.
and then proceeds
completion of Phase 2 triggers the start of several (possibly) simultaneous Phase
Its
2.
ui |)arallel.
making
acti\ities in the prototyping cycle:
to refine the material formulation,
making and
testing
the lab to explore product geometries and to study the material's behavior,
in
making product prototypes
in
the plant to uncover manufacturability issues
Product
engineers, process engineers, and technicians simultaneously develop the manufacturing process,
getting information from the product engineers about special product reciuirements and sharing
their
own
cost
and
feasibility results.
At the same time, people
and product management begin the
sales
in
lower-left corner of the flow chart.
These
activities initially
have
acti\ities
shown
m
the
impact on the technical
little
side of product development, but ultimately the two groups negotiate through the interface of the
product specifications
effort.
When
a final product
and
set of specifications are defined, technical
services performs a comprehensive set of qualification tests to ensure that the product meets these
specifications. If
all
goes well, the new product proceeds on to
review, and ultimately to the
The
full
field trials, to
the phase 3 (design)
manufacturing scale-up and launch of Phase
4.
proliferation of reverse arrows in the flow chart illustrates necessary iterations
activities.
For the sake of simplicity
in
among
our model, we include onl> those loops that our informants
believed occurred with significant frequency.
As we mentioned,
Figure 5 displays the process flow diagram for reformulation projects
reformulation projects are simpler than new product development efforts and require significantly
fewer activities. In particular, note that our model bypasses Phases
1
and
2.
and Phase
3
contains
fewer activities.
The
likelihood of iterating
characterize
it,
we would need
but also the order
in
was the most
difficult part of
to describe not only the
our model to specify. To completely
number
of times that activities occurred,
which they occurred, and we would need probability distributions over both
of these differentiating features.
The informants found
it
diflicult to discuss the
range of possible
configurations that they encountered or to identify characteristic patterns, so we needed to take
a simpler route.
We
asked the engineers to
cla.ssify
11 recently
completed projects according
to
the complexity of the iteration structure (2 projects were simple, 5 medium, and 4 complex); we
developed profiles
for
each class as we describe below; and then we used the weighted average uf the
resultant profiles to analyze the organization's overall performance. Implicit
the assumption of dependence
among
different iterations in a project
14
m
this
In reality,
it
approach was
appears that
in
some
projects,
correlated; but
some
iterations were independent of one another, and others were negatively
we only picked up piecemeal indications of what form of data
collection might
prove most revelatory.
We
gathered two forms of data
making and
(involving the
times,
we have "expected
For "inner
for the iteration structure.
prototyping iterations
number
total
of iterations per project
expectation of strong negative correlation
among
'"
This form of data reflects an
nested levels of iterations
It
we considered
it
which typically did not occur often, we
For "outer iterations.'
sometimes with
collected data in the form of "probability of iterating."
times that an activity could be executed.
when
question:
the
maximum number
maximum
is
numbers of
best to ask each informant only for estimates of the
iterations she herself performed.
treat visits before the
also reflects our
phenomena outside
finding that our informants were typically not well informed on the iteration
their domains;
many
testing of materials and products), which were typically repeated
We
maximum
treat this
a
maximum number
maximum
as a global
of
and
This raises the following interpretive
as independent.
reached, should we assume that further visits to the activity will
always succeed, or should we allow the possibility of failure (representing project termination)?
Figure 6 displays data of the iteration structure
ities
within a
among each
cell
are
assumed
new product development
in
to proceed either in sequence
(i.e
other) or in parallel. Arrows indicate the direction
arrows indicate that an activity
is
in
.
there
is
no chance of iterating
which activ
successfully completed and the project
projects. Activ-
ities flow:
moves on
"forward"
to successor
activities
must be repeated. Num-
bers accompanying backward arrows describe the likelihootl of repeats
Percentages indicate the
activities,
and "backward" arrows indicate that
number of
a
probability of iterating, and integers denote the expected
executed. Figures
parentheses indicate the
in
maximum number
executed. Each pair of numbers corresponds to data for
tively.
Following our informants' recommendation, we use
profile of a
a project of
medium
complexity.
otir
is
of times that an activity can be
medium and complex
in
projects, respec-
baseline project (project X) as the
20%
medium
60%
the problem could be solved
Table
8
complexity, there was a
15
In
in
manufacturing scale-up.
for
it
20%
-309^
chance
of such cases
required product redesign, and
them
condenses the iterating data
each activity.
testing experience of
of
complexity, however, one expected to execute the
three times.
(|ualificatioii
returning to a previous activity
the flaw required material reformulation, in
the remaining
about the
6 reveals
For a project of
that a qualification test would result
visits for
of times that an activity
simple project.
As an example, consider what Figure
medium
number
In
any project of
t|iialification testing activity at
new products
in
into an average
most
number
of
Reformulation Projects
5.6
Finally, Table 9
These
summarizes the average work content of
new product
that we presented for
data:
from an internal study
figures were obtained
that
is,
number
for the total
number
reformulation projects.
at the Plastics division
numbers
i)rojects, the
these numbers are the total
eacli activity in
Unlike the figures
Table 9 correspond to "aggregate"
in
of hours required for each task, accounting
of times that tasks are carried out and weighted with the probability of
involvement of each resource.
6
Our
first level
related
work with the time available
the resource can complete
shown
I:
of analysis estimates divisional capacity by
as Table 10)
Capacity
comparing the average demand of project
to the resources. For each resource,
we calculate
average rate at which the resource receives work to
utilization: the ratio of the
is
Analysis, Stage
it.
We
calculate utilizations by
means
tiie
which the organization can take on new work
management can examine
their influences
top row of Table 10, labeled
resource group spends on an average
on the average load
"NP
Although the division did not keep track
in
the spreadsheet,
each resource.
The second and
actual data that
is
project.
(We
discuss
how
third rows of Table 10
these
compare
available for the Plastics division.
of the time spent by individual resources on individual
did record the total hours spent by various groups on recent projects. Thus, we can
development resource pools on an average
not too far from the division estimate of 4408.
However, we appear to significantly
overestimate the time spent by technical services on an average project, and
appears that we
may
in
particular
it
be attributing to them work actually performed by the development group.
This kind of analysis can point to interesting
of their work and the way
it
difi'erences
between the way our contacts conceived
actually occurred, or between the nominal functions of resources and
the roles they actually performed. For example,
to
rate at
Hours," shows the total amount of time that each
see that our estimate of 3910 hours spent by the four
is
for
new product develoi)ment
some spreadsheet-generated measures with
project
which
to identify under-
maximum
and estimate the
By varying key parameters
figures were calculated at the end of this section.)
it
rate at
For managing development cycle-time, utilization information provides
staffed resources, determine probable project bottlenecks,
activities,
percentage
of a spreadsheet (part of which
important first-order performance measures. Managenient can use these figures
The
its
it
appe.ir* that technical services was cliartered
do a significant amount of routine testing that was often
may have been because
clone by the
development group. This
technical services was often a project bottleneck, so development engineers
16
felt
they could do the work more efficiently themselves. Finally, the fourth row of Table 10 shows
the
amount
It is
of time resources sjient on an average reformulation project.
useful to
decompose the
work and project-related and non-project-related work, lo compute the
1
new product development
product project (displayed
new product projects
Table
2).
That
projects,
the
in
we multiply the average number
are started (Table
Then we
1).
to priority
of hours devoted to a
at
new
which priority
1
divide the result by resource capacity (from
new product projects (NP)
1
due
utilization
row of the spreadsheet) by the rate
first
the utilization due to priority
is,
and low priority
utilization factors into categories of high priority
for resource
A
is
calculated by
.
utilization
(NP
pri 1,A)
(rate of prioritv
=
NP
1
starts) x (avg hours per
utilizations
similarly.
due to priority
Beneath the
priority
1
to the various activities.
A
for
almost
all
are calculated
reformulation utilization row are two rows showing contributions
activities.
estimates from our informants as reported
The
A
new product projects and reformulation projects
2
from administrative and support
the longer work weeks.
project)
:
capacity of resource
The
NP
^
Unlike the other rows, these entries represent direct
in
Table 3 (eg
total utilization factor
is
from
then simply the
percentage utilization close to 100
of the resource's time. Note that
we
ilo
i|iiarterly reports),
7(.
sum
adjusted to
of the utilizations
due
indicates that our model accounts
not have figures for the administrative and
support activities of those resources formally outside of the product development organization
In
that
Table
is,
11,
we show percentage
utilizations
when resources
are allowed to pool their
work -
resources share their work with others according to the Reallocation level specified at the
bottom of Table
12
and the
Maximum
Permissible Pooling Level defined
we multiply the maximum permissible hours given
amount
7 to obtain a total
in
Table
12
in
Table
7.
Specifically,
by the weighting parameter
in
Table
of work that the resources exchange. For example. Table 7 shows that
product engineers can potentially turn over much of their prototyping work to product technicians,
and the Reallocation parameter of 0.80
maximum
permissible
perfect efficiency,
and thus the
summarizes
The
for
i.e,,
total
The Total column
example allows them
indicates that
to
do so
at
80 percent of the
we assume reallocation happens with
a task does not take any longer when performed by a substitute resource,
number
of
manhours does not change when we introduce
pooling.
Figure 7
this information in a barchart.
utilization figures in Tables 10
some resources
them
level.
in this
to
complete
to maiximally reassign
for this result.
all
work
and
11 raise several issues.
One
of these
of their work (including priority 2 work),
to other resource groups.
There are
a
Since engineers estimated most of our numbers. the>
overestimated their own contributions
at
that in order
we need
to allow
few possible explanations
may have
the expense of their technirian^
17
is
systematically
,\nother possibility
is
that the group simply took on more work tlian
gotten done
for
in last
minute
stints of
We
be simply too high.
This extra work may have
overtmie as deadlines approached. Our model does not allow
overtime beyond the hours estimated
may
could handle.
it
Table
in
Fnially. our average activity time estimates
2.
believe that this last factor cannot account for
much
of the problem
because our calculations of total average time per project agree closely with the division's own
data.
Table 12 summarizes the adjustable parameters of
shows how we compute the average
eter"
activity times
percent and 90 percent estimates. The value
We
estimate and 10% to the higher one.
.9
total hours per project.
Although
this
from the figures that we collected
means that we
give
90%
was
order to arrive at
in
a
significant negative correlation in the activity times:
a
given project
is
a distribu-
reasonable estimate of
disturbing finding, we think
a
initially
likely to
it
may
point to
have one or two
"sticking points" that take abnormally long to complete, but the process of working through
facilitates other activities.
skewed to the
The
It
as 10
of the weight to the lower
needed to use such a high factor (indicating
skewed towards the lower estimates)
tion heavily
The "weighting param-
this spreadsheet.
also implies that the processnig time distributions
may
them
be heavily
left
"loop factor adjustments'" were introduced
in
response to an informant's
comment
that
our estimates for the number and duration of the prototyping loops were unreasonably high. This
too
most
is
likely
21 iterations (as
number
full
to negative correlation.
shown
in
Table
in the
The average
but each iteration
first
iteration
their estimates of each Iteration,
example
is
slab prototyping effort did indeed take
unlikely to take the Product Engineer the
Based on our informants' reaction to the totals
we introduced the Loop Factor Adjustments
to bring the totals into closer conformity to reality.
7
To
8),
of hours required by the
we derived from
shown
due
Analysis, Stage
II:
Cycle Time
carry out the second stage of our analysis, we developed
a
Miiuilation
model
for
cycle-time performance of the product development process at the Plastics division.
first-order analysis which used only information regarding averugt processing times
new
start rates, the simulation
process.
some
model
explicitly incorporates the uncertainty of the
studying
Unlike the
and average
development
For example, interarrival times as well as activity times are subject to variability, and
activities
may need
to be iterated several times before they are successfuly completed. In the
next section, we show how the simulation model can be used to identify trends, develop qualitative
insights,
The
and suggest system improvements.
basic information regarding resources, project types, activity rimes, and routing require-
18
ments necessary
to build a simulation
However, instead of using
all
of this information,
significantly by aggregating activities
of detail provided
in
a
Section
5.
represt^iitation of the process
simulation model
at
the level
Section 5 (and indeed to experiment with such a model) would require an
it
would only marginally improve
insight.
Our
intended to capture the spirit of the product development process at the
is
Plastics division without actually mimicking
manual (Conway, 1990) provides an
els
we simplify the
and resources. To create
overwhelming amount of time, and we believe
simulation model
m
model of the Plasties division are roiitained
all levels
of interactions. (Section
H
of the
XCELL
excellent discussion of the virtues of keejjing simulation
small and simple.) All simulations were performed using the simulation package Siman
(
mod1990).
The Simulation Model
7.1
Resources
The simulation model aggregates
pools (see Table 13)
First,
the 9 resources
we group
shown
combined
Table 2 into
7
composite resource
the product engineers and process engineers into a single
resource called product development (PD) engineers
cess technicians are
m
Second, the product technicians and pro-
into a pool called product
replace the group miscellaneous, which previously was
develoment (PD) technicians. Third, we
composed
specifications department, solely by the specifications group
of several groups including the
(i.e., all
other groups
in
the miscella-
neous category have been deleted from consideration). Our aggregation, which coalesces several
resources into a single group, essentially creates pools of interchangeable resources that were not
Such an aggregation scheme clearly creates
treated as interchangeable in the original model
more
efficient
a
organization and consequently results more optimistic predictions of system perfor-
mance. However, because we are pooling resources with comparable
levels of utilization,
we do
not expect this aggregation to have a significant impact on system performance.
Finally,
we
allocate additional capacity to resource pools that belong in the technical group of
the Plcistics division (these include product development engineers and technicians, application
engineers, and technical services). These resources typically work extra hours
backlogged or when deadlines approach, and the
13 reflect the
In
maximum number
maximum
when
server capacity figures
projects are
shown
m
Table
of hours that these resources uork during those critical periods.
our simulation models we report the fraction of time that each resource pool must work
maximum
overtime.
19
its
Project Types
As described
Section
in
5,
the two job types
the network are "new product projects'" and
in
"reformulation projects," and eacii job type can be assigned either priority
Plastics division initiates an average of 3 priority
product projects per year.
Times
priority every year.
starts of
new
Activities
In addition,
of
new
new product projects and
1
starts an average of
it
1
1
or priority 2
The
2.5 priority 2
new
reformulation project of each
project starts are typically uncertain, and we assume that the
projects are characterized by a Poisson process.
and Precedence Constraints
model
In addition to aggregating resources, the simulation
as
shown
as
"Review Patent" and "Identify Lead Customer"
in
Table
we coalesced
14.
For example, we grouped
prototyping activities into
all
also groiip.s together several activities
activities related to
all
into an activity called "Marketing."
a single activity called
much
subset of a network can be replaced, without
among
"Prototyping
sacrifice in accuracy,
suitably defined processing times and routing instructions
times, queueing times, and routing
marketing and sales such
by
The combined
""
Moreover,
any
In general,
a single
node with
effects of processing
the nodes of the subset can be reasonably approximated
We
by a single node whose processing times and routing probabilities are defined appropnatel_v.
investigate a simplified model. Subsequent studies can determine the
first
and examine these individual nodes
in
new product
in
have been aggregated, the simulation model
activities. In
our simulation model we treat
route of a job
is
not affected by
its
of repeating a prototyping activity
manufacturing scale-up
is
0.60.
prototyping are carried out are
all
still
nodes
0.75,
projects
Note that even though some
exhibits iterations
among
ac-
the aggregated
routing as "Markovian." meaning that the future
processing history
is
significant
greater detail.
Figure 8 depicts the flow of activities
tivities
most
As indicated
in
Figure
8,
the probability
and the probability of returning to prototyping
after
Thus, the average number of times manufacturing scale-up and
(1
-
.60)"'
Figure 9 illustrates the flow of activities
=
2
m
nd 2.5x(l - 75)~'
'
=
10 respectively.
reformulation projects. As discussed
in
Section
5,
reformulation projects constitute a very small fraction of project-related work and we collerfed
only
summary data
projects at the
same
for
this type of projects.
level of detail as for
iterations between the activities, whereas
Consequently, we do not model reformulation
new product
m
reality,
projects
For example. Figure 9 shows no
one typically experiences several iterations of
the prototyping activities. Even with these simplifications, our simulation models were
to predict cycle-time
performance with reasonable accuracy
20
still
able
Task Times
Table 15 displays the average processing time
spreadsheet calculations discussed
Section
in
6.
several sub-tasks, then the average task time
sub-tasks
in
the aggregated task over
simplified matters
pair:
We
all
If
is
an activity corresponds to an aggregation of
calculated by
if
discussed
in this
task times of those
We
(m terms
we consider that resource
to
spend
chose the level of significance based on our understanding of the
at Chemicals, Inc
section, our goal
was
In
working out
this issue, as well as several other issues
to identify the suwplfst
organization at the Plastics division that captured
its
model of the product development
essential characteristics.
Even though we collected some distributional information
and 90
all
that resource's contribution
of hours) exceeds a pre-set level of significance; otherwise,
development process
summnig
a "level of significance" test to each activity/resource
assign time to an activity/resource pair only
We
derive these averages from the
resource groups composing the aggregated resource.
somewhat by applying
zero time on the activity.
We
for eacii task
percentiles of individual task times), in the end
for task times (for
we modeled
all ta.sk
example, the 10
time distributions as
exponential. In our preliminary simulation experiments, we found that system performance did
not vary significantly with different distributional forms for several key activities
We
and manufacturing scale-up).
We
in
in
the variability of [processing times produce imperceptible
cycle-time prefonnance.
took support ami administrative times from Table 10
otherwise,
prototyping
conjecture that because there are several other contributing
sources of uncertainty, small changes
changes
(e.g.
we approxmiated them based on our understanding
when such
figures were available;
of the role of the resources and the
nature of their work. (For example, because the manufacturing engineers primary responsibility
is
to the production
and manufacturing operations, they spend the bulk of
outside the product development arena. This
is
their time on activities
reflected in their high support times.)
We
found
it
necessary to reduce the administrative times for several resources to obtain reasonable performance
measures. This modification
be forgone
is
in critical situations.
to be attended,
and training
partially justified by noting that
many adminstrati\e
duties can
For example, vacations can be postponed, meetings do not have
activities can be rescheduled.
We
model
support and administrative activities as exponentially distributed
Wheras support
arrive according to a Poisson process, administrative times, which are
arrive deterministically.
•21
activity times for both
more regular
activities
in
nature,
Pooling
Using spreadsheets similar to those described
noted
ronment
is
the possibility of pooling work
other resource groups
is
we calculate the percentage
6,
utilizations
results of these calculations.
Section 6 that an important characteristic of the product development envi-
in
analysis from Section 6 indicated that
there
Section
summarizes the
of each resource in the network. Table 16
We
in
let
some resources had
to
maiimally reassign their work
From Table
Ki,
it
product development engineers reassign part of their work
PD
engineers to
PD
-5
ongoing projects
technicians only
ufacturing Scale-Up. For each of these activities, at most
SO'/J.
Phase
in
1.
to
also appears that
part of their work with technicians
for engineers to sharf
development technicians whenever there are more than
can be transferred from
Moreover, our spreadsheet
various resources.
they are to have enough capacity
if
much opportunity
simulation model, we
among
to
We assume
In
our
product
that work
Prototyping, and Man-
of the engineers' work can be given
to technicians.
Service Discipline
We
set the service discipline at each
segments equal
to
two weeks. Under
workcenter to be the "round robin" discipline with service
an engineer or technician processes the
this discipline,
task in his queue for two weeks or until the task
is
finished.
weeks (the service period), then the job moves on to
end of the queue and
to the
its
its
next
remaining service time
is
If
first
he completes the task within two
Otherwise, the task returns
ta.sk(s).
updated
to reflect the last
round of
service.
Simulation Results
7.2
Table 17 shows various
statistics
primary interest
paper
cycle time. It
the project.
is
in
the
New
this
amount
is
and end when the product
we study
is
Our
will also refer to as project
product projects begin with concept generation and
number
is
in
feasibility studies
(Phase
1),
Reformulation projects begin with prototyping
-4).
launched (Phase
of unfinished projects
calibrate our models,
of
of elapsed time from the beginning"" of th* iTOject until the "end" of
activities
To
we
project completion time, which
and they end with the product launch (Phase
the
The performance measure
obtained from the simulation
4).
Another nieasure of performance that
the organization.
we compare our findings with
figures provided by the Plastics division.
host was able to provide us with detailed timelines for priority
which we were able to compute average project completion
•22
tinies
1
new product
projects from
Such records were not available
for other types of projects,
and
we
for these statistics,
relied
on estimates
l)v
the
manager of the
Plastics division.
Table 17 shows that the simulated average completion time of priority
is
1
new product
84 weeks, compared to the figure of 82 weeks reported by the Plastics division.
On
projects
the other
hand, both simulated and reported figures indicate that the Plastics division requires more than
3 years to finish priority 2
new product
projects.
For reformulation projects, the simulated completion times are 5 months for priority
and
year for priority 2 projects. These numbers are
1
somewhat lower than
by the manager of the Plastics division: 6-9 months for priority
projects
1
the figures estmiated
reformulation projects and 1-3
1
years for priority 2 reformulation projects. Although reformulation projects are formally assigned
or
either priority
1
projects of the
same
is
it
reality they are generally treated with less
priority.
We
mentioned
in
likely
that a priority 2 reformulation project
is
This informal setting of priorities may partly explain the biases
simulated completion time for priority 2 reformulation projects
cycle time, whereas priority 2
urgency than new product
Section 4 that refornnilation projects are treated
and only when a project needs to be expedited
as low priority work,
Consequently,
in
2,
new product projects take longer
is
it
elevated to priority
1.
often treated as "priority 3."
in
our simulation results:
the
is
shorter than the actual project
to
complete than reported by the
Plastics division.
Figures 10-13 show histograms and cumulati\e distributions of the project cycle time for the
The 90th
2 types of projects.
Figures 11 and
priority
1
13, are siginificantly
new product
than 2.5 years!
percentiles of project completion time, which can be read from
longer than the corresponding averages; for example, while
projects are completed
in
clear with these displays that
It is
84 weeks on average.
it
is
lO'/J
of
them take more
not enough to measure just average project
completion times; information concerning the distribution of project completion time must also
be considered.
To measure the impact
of variability and congestion on cycle time performance, the
last
column
of Table 17 shows the ratio of the actual average project completion time (which appears
fourth column) to the project cycle time predicted by
"actual- to- PERT" ratio,
to the
amount
of time
an average priority
10%
of
its
time
is
1
it
compares the amount of time that
actually spends being proces.sed.
new product project
spent
idle
waiting for resources.
reformulation projects, which are
It
less
A
its
column).
(fifth
a project
the
This number, the
spends waiting
for resources
For example. Table 17 indicates that
suffers relatively little
other hand, spends (on average) more than half of
from the congestion.
PERT
m
priority 2
from congestion, as
new product
less
than
project, on the
time waiting to be processed
Priority 2
time-intensive than new product projects, suffer e\eii more
spends approximately twice as much time waiting
23
for a
resource as
ii
does
being processr^d.
The
last four
rows
in
Table 17 compare the siniulateil iiuinber of
Plastics division with the figures estimated by
uiiftiiished projects in the
manager. Again, readers should note the
its
dis-
parity between averages and 90th percentiles
Finally,
must work
PD
Table 18 shows the fraction of time that each resource pool
its
maximum
maximum work-week
their
the core technical group
overtime. These numbers appear to be quite high for
engineers work 60-hour weeks more than
work
in
less
65%
On
of the time.
the other hand,
As pointed out
than 6 weeks per year.
some resources -
in
PD
technicians
Section
6,
our
data appears to be heavily skewed towards engineers: because much of our data was estimated by
engineers,
we suspect that they may have over-estimated
that of their technicians.
It
is
also possible that
their contribution
more work
is
|")ooled
and under-estimated
l.^etween engineers
and
technicians than we have allowed.
Readers may notice that we have presented our results
times and "average" number of unfinished projects.
in
terms of "average" project completion
We
obtaineii these figures by simulating
the models until they reach "steady-state" and take the long-run averages as our performance
measures. The time horizon we used
is
clearly inappropriate
the simulation
in
when considering
run takes approximately 80 minutes of
experiments- approximately 2000 years! -
the product development environment
CPU
time on a Micro\',4.\ 3800-)
essentially one of finding the correct initial conditions for the system.
data concerning the present distribution of workloads the system and the
amount
i.e.,
Because we have no information regarding
systems long enough
for
The
difficulty here
we were able
is
to collect
the luimber of projects currently
in
of work remaining to be done on each project by each resource - then
simulation could answer practical questions such as "how
five years."
If
(Each simulation
them
to
accumulate
a
will
initial
the system perform over the next
conditions, we
must simulate the
reasonable amount of work, and we approximate
the performance measures by their steady-state values.
8
When we
began
this project,
Conclusion
we hypothesized that process management would
offer opportunities
to improve product development in a wide class of businesses and that process modeling would
prove to be a valuable tool supporting that
effort.
We
believe that the results reported
previous sections are sufficiently positive to encourage further research along these
hurdles
we encountered along the way, however,
lines.
are also valuable research results
in
the
The
Here we
discuss these lessons under two headings - technical constraints and organizational impediments
From
a technical point of view, there are
some
24
difficulties inherent in the differences
between
Whereas manufactur-
product development engineering and repetitive manufacturing operations
ing produces thousands of identical units of dozens of different products, the tasi< of
ing organization has
tiie
inverse structure:
it
tlie
engineer-
produces dozens of different product designs using
thousands of possible engineering and support
activities.
For manufacturing, repeatability
is
of
the essence, and the constituent activities have to be rigorously standardized. In the engineering
product design
case, the
required activities
in
aims at the optimal unique solution, and
effort
whatever order, combination, and form necessary
group performs the
tlie
(Of
to reach that goal
course, customized manufacturing job shops look a lot like engineering from this perspective
seem-
In this technical setting, a process perspective
development engineering, and the
difficulties
essence of product
iitithetical to the very
we encountered
in
)
building a process model have
helped us better understand the distinctive nature of engineering. Our research was designed to
test the
hypothesis that
that there
is
tliis
view of engineering as essentially non-routine
enough repetitiveness
model possible and
useful.
We
in at least
is
sufficiently false -
some engineering organizations -
make
to
a process
believe the results reported in the previous sections support our
hypothesis.
Second, even
if
a process view
complexity of process modeling.
is
feasible,
another technical difficulty
Many managers
are familiar with the
in
lies
the intrinsic
enormous complexity
of
manufacturing process plans, and they justifiably worry that the burden of creating, maintaining
and exploiting "engineering process plans" would outweigh any
benefits.
We
hope that
this project
has shown that this burden can be greatly reduced by appropriate simplifications and that the
benefits are potentially considerable.
A
third technical
impediment that surfaced only occasionally
m
our project might prove to be
an interesting subject for future research. Our approach takes the project as the unit of analysis,
but
in reality
ones.
For example, dialogue with
adapt product specifications
in
of project data proved difficult,
the organization's work as
If
we
new products
projects belong to streams:
new customers
are often generated as variants of old
often leads the product development group to
order to broaden their potential customer base
it
was
composed
in
If
our collection
part because the engineers and managers tended to view
of such streams, rather than as a set of discrete projects.
are right and a process approach could be a powerful
been attempted before? Our project also
led us to several
nizational impediments that account for engineering
management
tool,
why has
it
not
hypotheses about the specifically orga-
management's traditional focus on
discrete
projects rather than on ongoing processes.
First,
engineering managers have tended to concentrate on the unique features of each project.
a point of view that
depends most
is
critically
rooted
in
the assumption that the effect ivene.ss of an engineering project
on creativity.
It is
natural that the culture of engineering should
25
hie;hli,B,ht
and celebrate the distinctive and novel challenges
organizations, however, there
to non-routine activities.
is
in
engineering work.
In
many engineering
considerable cross-project commonality and a high ratio of routine
such contexts, projects can be managed as variants of previous
In
and effectiveness depends not only on the creativity with which the truly creative parts
projects,
of the project are conducted but also on the efficiency with which the routine parts are conducted.
As product development time becomes
shift its attention
there
is
no unobtrusive way to
nomenclature of
way
to
to consider as
for
engineering managers
is
the lack of requisite data.
It is
determine what data ought to be gathered; moreover, unlike manufacturing operations,
some organizations do
the
management needs
development process.
second organizational impediment
difficult to
salient competitive factor,
from an exclusive focus on creativity and product features and
well the efficiency of the product
A
more
a
collect the
data that process modeling would require. Nevertheless
time cards from engineers, and
collect
activities, then times
to systematic process
can be collected
the organization has a consistent
if
for projects
and perhaps most fundamentally, the reluctance
stem from an image of engineers
their jobs. Indeed, process
believe, however, that
if
as
process
management
as a
way of making engineers work harder but
will
be enthusiastic about
found a high
level of
support
Our experience
for
will
is
done on
is
a recipe for
presented as
opening
CAD/CAE
grow.
to develop process
"autonomous" professionals who should not be
models might connote
it.
activities, thus
modeling. In the future as engineering work
workstations, the opportunities for unobstrusive data collection
Finally,
and
models might
told
how
to
regimentation and alienation.
a route
as a tool that helps
do
We
towards effectiveness - not
them work smarter - then they
at the Plastics division supports this hypothesis.
We
our project, and the engineers were very cooperative throughout
our time-consuming data collection
effort.
It is
appropriate that we close this report by thanking
them.
Acknowledgements:
tion of the
and
staflF
This study would not have been possible without the generous coopera-
company we have
of
its
called Chemicals, Inc
is
thanks
m
particular to the
Plastics division. This project has also benefited from the advice
Chuck Holloway and Mike Harrison. Funding from
Automation
We owe
manager
and support of
the Stanford Institute for Manufacturing and
gratefully acknowledged. Elizabeth Schwerer was supported by a National Science
Foundation graduate fellowship.
References
Adler,
Mandelbaum,
p., a.
agement: Strategies
,
,
for
in
"From Project
,
Data Collection Challenges
Alexander,
E.
Schwerer, "From
Improving Development Cycle Time," submitted
AND
,
Nguyen, and
V.
in
UCLA
Building a Process Model,"
for publication
Management: Modeling
to Process
unpublished master's
(
thesis,
1992a).
Issues
Conference Proceedings
R., "Scheduling and Resource Allocation Methodologies for Fast Product
a Multi-Product Environment,"
Man-
Project to Process
(
and
199'2b)
Development
Sloan School of Management,
Massachusetts Institute of Technology, 1990
Allen, T.
and
J.
S.
I.
Cohen, "Information Flow
in
Research and Development Laboratories,"
Administrative Science Quarterly, 14 (1969) 12-19
Anthony,
R. N., The
Baccelli,
F.
Management Control
and a. Makowski, "Queueing Models
straints," Proceedings of the
Black, T.
Function, Harvard Business School Press, Boston, 1985.
C. H. Fine,
A.,
dence Relationships:
An
Systems with Synchronization Con-
for
IEEE, 77 (1989), 138-161.
and
M. Sachs, "A Method
E.
The Next Battleground
Clark, K.
in
American Manufacturing.
J
D
P.
Sloan School of
Institute of Technology. 1990
"New Product Development: The New Time Wars,"
J. D.,
Homewood,
Systems Design Using Prece-
Application to Automotive Brake Systems," Alfred
Management Working Paper No. 3208-90-MS, Massachusetts
Blackburn,
for
in
Time-Base Competition-
Blackburn. Ed
Business
.
One
Irwin.
1991.
B.,
W. B Chew, and
Industry," Brookings Papers on
T.
Fujimoto, "Product Development
Economic
AND T. Fujimoto, "Lead Time
in
Auto
Automobile Product Development Explaining the Japanese
"Overlapping Problem Solving
,
the World
Activity. 3 (1987), 729-781.
Advantage," Journal of Engineering and Technology Management.
AND
in
in
6 (1989a), 25-58
Product Development,"
m
.\fanaging Interna-
tional Manufacturing, K. Ferdows, Ed., (1989b), 127-152
AND
in the
,
Product Development Performance: Siralegy. Organization, and Management
World Auto Industry, Harvard Business School Press, Boston, 1991.
Conway,
R.,
W.
L.
Maxwell,
J.
Factory Modeling System, Release
Cooper, R.G., "A Process Model
O. McClain,
J,.0,
The
S.
L.
Worona,
Scientific Press.
for Industrial
User's Guide to
XCELL-h
South San Francisco, 1990
New Product Development." IEEE
Transactions on
Engineering Management, 30 (1983), 2-11.
Dean, B. V. (Ed),
Eppinger,
S. D.,
Project
Management: Methods and
Studies. North-Holland, .\msterdam, 1985.
D. E. Whitney, R. P. Smith, and D. A. Gebala. "Organizing the Tasks
m
Complex Design
Projects," Alfred P. Sloan School of
Institute of Technology, 1989.
MS, Massachusetts
Hayes, R.
H.,
Wheelwright, and K
S.
Learning Organization. Free Press,
Imai, K.,
Nonaka, and
I.
Management Working Paper No- 3083-89-
New
B.
New Product Development
H. TakeUCHI, "Managing the
Kim
Creating the
York, 1988.
Japanese Companies Learn and Unlearn,"
Technology Dilemma,
Clark, Dynamic Manufacturing:
in
The Uneasy Alliance: Managing
Productivity-
the
H Hayes, and Christopher Lorenz, Eds, Harvard
B.Clark, Robert
How
Process:
Busi-
ness School Press, Boston, 1985.
Jackson,
"Jobshop-Like Queueing Systems," Management
,
Kleinrock,
Neumann,
in
Res., o (1957), 519-521
"Networks of Waiting Lines," Oper.
R.,
J.
Queueing Systems Volume
L.,
K.,
"GERT
"Heavy
V.,
Sons, Npvv
.k
"^'ork.
1975
Network and the Time-Oriented Evaluation of Projects,"
Economics and Mathematical Systems.
Nguyen,
Theory. Wilex
1:
10 (1963), 131-142.
Sci..
Vol.
m
Lecture \o1es
112. Springer V'erlag, .New "^'ork, 1979
Traffic Analysis of Processing .Networks with Parallel
and Sequential Tasks,"
Ph.D. dissertation. Department of Operations Research, Stanford, 1990.
,
"Processing Networks with Parallel and Sequential Tasks;
Brownian Limits," Ann. Appl.
Pegden, C.
D., R. E.
McGraw-Hill,
Shannon, and
New
Sadowski
R. P.
SchOENBERGER, R.
J.,
One
Irwin,
,
L. J.
New
Edition), John Wi-
to
Cut Lead Times and Increase Customer
York, 1986.
New
Moore, "R&D
Management
L., "Technical
Characteristics,"
(2'"^
World Class Manufacturing: The Lessons of Simplicity Applied. The Free
Reshaping Global Markets, Free Press,
TUSHMAN, M.
Networks
Homewood, 1992
Stalk, G. Jr., and T. M, Hout, Competing
Taylor, B. W. and
Q-GERT
How
Product Development:
Division of Macmillan, Inc.,
Simulation,"
Introduction to Simulation Using .s'/.IM.V
York, 1979.
S. R., Effective
Satisfaction, Business
A
and
Prob.. forthcoming
Modeling and Analysis Using
B.,
ley/Halsted Press,
Press,
Traffic Analysis
Inc., 1990.
Pristker, a. a.
Rosenthal,
Heavy
Academy
.Against
How Time Based
Time:
Competition
Is
York, 1990.
Project Planning with
Q-GERT
Network Modeling and
Science, 26 (1980), 44-59.
Communication
of
Management
in
R
D
1'
Laboratories:
The Impact
of Project
Work
Journal. 21, (1978). 624-645.
"Work Characteristics and Subunit Communication
Structure:
A Contingency
Analysis,"
Administrative Science Quarterly, 24 (1979) 82-98.
Watkins, M. D. and K. B. Clark,
"Strategies for
No. 93-004-, Harvard Business School, 1992.
Managing
a
Project Portfolio," W'orking paper
Wheelwright,
November
S.
C, "Time
to
Market
in
New Product Development." ICL
Technical Journal.
(1989), 62.5-646.
AND K.
B.
Clark, "Creating
Project Plans to Focus Product Development."
Harvard
Business Review, March-April (1992), 70-82.
AND
,
Revolutionizing Product Development:
ciency and Quality, Free Press,
New
York, 1992.
Quantum Leaps
in
Speed.
Effi-
Project
Type
Rate of work generation, new products:
- priority
1
new
project starts per year
Resource
Name
Slab
•Mfg
Proio
Process
Prod
Eng
'\
p-^g_;PTodProto
y"^
y
Scale-up
'SlabProto
•QualTest
\.« Prod Test
Figure
Mfg. Proc.
Defn.
<
1:
Processing Network Representation
CEO
Corp
PRODUCTION DIVISIONS
R&D
O
REGIONAL AND PRODUCT FAMILY GROUPS
r
I
Technology
Finance/
Admin
Mki Analysis
PRODUCT DIVS
and Sales
Plastics
Div.
Technical Dept
-|
u
1
Technical
Appl
Services
Eng
Prod
Prod
Process
Process
Eng
Teh
Eng
Teh
---.
Figure
3:
Mfg
Product
Mktg
Finance
Mgt
Organization Chart of Cliemicals
Qlty
Assurance
Inc.
]
Figure
5;
Process Flow Diagram - Reformulations
101.26
98.46
100.00
97.7
93.62
80.00
—
New
Products Priority
New
Products Priority 2
^ Reformulations
U Reformulations
Priority
1
1
Priority 2
[H Admin
60.00
td Support
e
o
a
D
e
u
a
40.00
20.00
~
18.19
0.00
Prod
Proc
Prod
Proc
Tech
Prod
Engr
Engr
Tech
Tech
Svcs
Mgt
Figure
7:
Utilization Profile with Pooling
Misc
- Graphical Re presentaiion
Mfg
Appl
Engr
Engr
-[
Phase
1
\^»[
Figure
\-^'(
Phase 2
8:
New Products
Activities
/^ Proto -^^y'Plam
Figure
9:
Phase4
Flow Diagram - Simulation Model
A
^.(>hasc4
Reformulations Activities Flow Diagram - Simulation Model
j^>
L
1
OOlt-
O'OLi
ooee
0063
Q
00 It'
-
OQLi
3
>
3
£
3
U
0)
E
c
o
a
_u
o.
E
o
U
o
3
1)
z
3
SO
d
so
d
d
d
d
d
d
0>8
0-9L
089
009
ao
<N
S
T
O't^
-
09Z.
g
•s
a
JO
I
"a-
E
s
U
o
"S
"5.
E
6
I
09
e
I
OS
d
00
d
d
d
d
d
d
/
7bb
,85
Date Due
UBBABlE'>„P!'f,\,
llllll
3 c,Q60
00624021
?