"
^
"<$ ^ or
T
A
\
fJ^i^^wii-'
HD28
.M414
ALFRED
P.
WORKING PAPER
SLOAN SCHOOL OF MANAGEMENT
From
Project to Process
Engineermg:
for the Analysis of
P.
Management
in
An Empincallv-based Framework
Adler, A.
Product Development
Mandelbaum,
and
E.
Schwerer
Vien Nguyen
WP# 3503-92-MSA
October, 1992
MASSACHUSETTS
INSTITUTE OF TECHNOLOGY
50 MEMORIAL DRIVE
CAMBRIDGE, MASSACHUSETTS 02139
'ii
From
Project to Process
Management
in
An
Empiricallv-based Framework
for the Analysis of Product Development
Engineermg:
P.
Adler, A.
Mandelbaum,
and
E.
Schwerer
Vien Nguyen
WP# 3503-92-MSA
October, 1992
ml
From Project
to Process
Management
in
Engineering:
Strategies for Improving Development Cycle
Paul Adler^
Time
Ain Mandelbaurn
Department of Management and Organization
Faculty of Industrial Engineering and
School of Business Administration
Technion
University of Southern California
Haifa, Israel 32000
Los Angeles,
CA
Management
90089-1421
Vien Nguyen
Elizabeth Schwerer
Sloan School of Management
Graduate School of Busniess
Massachusetts Institute of Technology
Stanford University
Cambridge,
MA
02139
Stanford,
CA
94305-5015
Abstract
We
as a
view,
proposed
a recent article that a product development organization can be analyzed
system composed of more or
we
investigate in this paper
cycle time.
in
in
less repetitive
how
processes of activities.
to apply process
Through simulation experiments, we
are able to
draw some
insights
October. 1992
listed in alphabetical order.
From
manage development
the eight scenarios that
and recommendations
completion times.
Author's names are
to better
this process
assess the potential impact of various changes
the operation of a sample product development organization.
we analyze, we
^
models
Taking
for
reducing project
Statement of Contribution
The motivation
for the research reported here
is
the growing competitive importance of product
development time. Business observers have argued that the intensification of global competition
has created enormous pressures on firms to accelerate the process of developing and launching new
products.
unique
We
submit that while product development projects are often viewed
entities, in reality different projects within a given organization often exhibit substantial
similarity in the overall flow of constituent activities.
tools available to
many
as collections of
managers assume that projects are independent
organizations must
human and
Moreover, while most of the planning
manage concurrent
technical resources.
We
clusters of activities, in reality
projects that place competing
demands on shared
therefore propose that a process view - that
is,
a view of
the development process as a more or less repetitive "design production process" - can provide
a
framework
for better
understanding product development time
shared resources.
concurrent projects that
utilize
process models to better
manage development
In
this paper,
cycle time.
in
organizations with multiple
we
investigate
how
to
apply
Through simulation experiments, we
assess the potential impact of various changes in the operation of a sample product development
organization.
From our
analyses,
reducing project completion times.
we
are able to
draw some insights and recommendations
for
Many
firms treat [cycle time] as immutable,
a fact
of
life
m
their industry.
Hayes, Wheelwright, and Clark (1988)
As noted by business observers such
thal (1992), Stalk
as
Blackburn (1991), Clark and Fujimoto (1989), Rosen-
and Hout (1990), and Wheelwright and Clark (1992a, 1992b), the
intensification
of global competition has put enormous pressures on firms to accelerate the process of developing
and launching new products.
In
Adler
et al.
(1992a),
we proposed that
insights
cycle time can be gained by viewing the product development process as a
activities. First,
more
or less repetitive
Our approach was premised on two hypotheses concerning
"design production process."
velopment
about development
we submit that while product development projects
the de-
are often viewed
as collections of unique entities, in reality different projects within a given organization often exhibit substantial similarity in the overall flow of constituent activities. Second, while
most of the
planning tools available to managers assume that projects are independent clusters of
in reality
on shared
for better
many
organizations must
human and
manage concurrent
technical reosurces.
A
activities,
projects that place competing
demands
process view, therefore, can provide a framework
understanding organizations that pursue multiple concurrent non-unique projects using
shared resources. In particular, this approach should enable us to quantify the congestion effects
that arise from contention for shared resources
among concurrent
projects.
Taking the process view, we suggest modeling a product development organization as a
"stochastic processing network"
are "jobs" that
compete
for
in
which engineering resources are "workstations" and projects
"services"
stochastic processing network models in Adler
model of a sample
firm's product
We
from the workstations
et al.
characterized this class of
(1992a), and we also constructed a specific
development organization.
models to assess the potential impact of various changes
in
In this paper,
we use these process
the product development organization
through several simulation experiments. From the eight scenarios that we present here, we draw
several general insights and
The paper
approach.
call
We
is
organized as follows.
present
in
for
Section
reducing development cycle time.
1
discusses in
more
detail
the process model
Section 2 the sample organization, which, to preserve
its
anonymity, we
the Plastics Division of Chemicals, Inc. Section 3 describes the stochastic processing network
model that we constructed
et al.
that
recommendations
1990),
Using the simulation package
we simulated the process model and obtained predictions
we compared with
which we
for the Plastics division.
actual Plastics division performance.
The
refer to as the "base case," are presented in this Section
3.
SIMAN
(Pegden
of development cycle time
results of these simulations,
Sections 4-7 explore the effects of reducing the total "load" on the system through different
means.
in
we show how process models can
In Section 4.
identify bottlenecks in the
decisions regarding resource augmentation and allocation.
amount
of compressing the
load by controlling the
its
are the subjects of Sections 6 and
In Section 8
among
discipline.
and
in
The
We
assume
The
initiates.
The
division can also reduce
methods of input control
various
7.
in all
in
which we vary the amount of work shared
our models that each workstation uses the round-robin service
Section 9 we investigate the effects of switchmg to the first-m-first-out (FIFO)
effects of
we demonstrate the
11,
it
we present simulation experiments
resources.
discipline,
of projects
assist
Section 5 investigates the benefits
of time required to complete activities.
number
system and
rework and prototyping cycles are studied
benefits of a centralized
in
management system.
Section
Finally,
10.
In Section
we summarize our
findings in Section 12.
The Modeling Framework:
1
We
demonstrated
in
Adier
et
Stochastic Processing Network Models
(1992a) that for an important class of product development
al.
organizations, namely, those that pursue multiple concurrent non-unique projects using shared
resources, one can
as a "stochastic processing network" in
model the product development function
which engineering resources are "workstations
"
and projects are
"jobs'"
that compete for "service"
from the workstations.
A
workstation, or resource,
working
title,
the pool.
The
composed
of one or
Each workstation corresponds
in parallel.
who perform
is
the
same
functions.
The
more interchangeable and
to a pool of employees, typically with the
servers are the technicians or engineers
illustrate using
PERT-style diagrams, allow some tasks
others to be performed sequentially.
we
refer to the
same
who make up
organization processes projects, or jobs, which consist of collections of tasks that
These precedence constraints, which
require services from specified resources in specified orders
we
identical servers
phenomenon
been completed, we
call
it
When
as a "fork";
a "join."
and joining as necessary into
We
several tasks
when a
task
may
be performed
to
may
be processed.
but require
begin processing at the same time,
not begin until several other tasks have
think of projects "traveling"
activities to
in parallel
If
among
a server
is
the resources, forking
available
when
arrives at a workstation, then the server immediately begins working on the activity
a project
Otherwise,
the project waits in an in-box, or "queue," until a server becomes available.
The processing network
is
stochastic because times between
new project
times), times required to complete activities (processing times),
may
all
be subject to
statistical variability
We
starts (interarrival
and precedence requirements
say that projects are of the
same "type"
if
their
individual precedence constraints, processsing times, and interarrival times can be characterized
by the same set of probability distributions.
The models we
just described appear to share
models of manufacturing systems. Our models,
models.
The new
feature introduced here
processing of different activities.
acteristics of the
do not allow
for a
The
is
in
many
characteristics with queueing network
queueing network
fact, are generalizations of
the fork and join structure, which allows simultaneous
ease with which tasks fork
is
one of the distishguishing char-
product development environment. Whereas manufacturing activities typically
component
or subassembly to split into different parallel processes, designs and
drawings can be duplicated so that several people can work on them simultaneously.
Stochastic processing network models offer several advangtages over
particularly in terms of predicting product development cycle time.
PERT and CPM niethods,
PERT models depict an
idealized flow of project activites in which activity times are predictable and
succeed.
Many product development
activity times
organizations, on the other hand, face uncertainties
PERT
to a single project at a time.
Our
and
CPM
analysis in Adler
proc<='ss
models, on the other hand, explicitly account
ei al.
shows that these congestion
effects
Whereas previous studies of product development were
individual projects, our approach focusses on the
2
among concurrent
typically concerned with
management
The Research
zation chart of Chemicals Inc.).
The
Plastics division
of Chemicals' total domestic sales. Recently,
ciple competitor, a large
it
management
plastic parts
1
shows an organi-
and accounted
lost several possible
in
of
of resources as well
contracts to
Japanese firm with significantly faster product development
and corporate management were interested
Our
projects.
Site
made
had
for the
can greatly delay project completion.
host for this project was the Plastics division of Chemicals Inc. (Figure
divisional
both
analyses often assume that resources are dedicated
congestion effects arising from contention for shared resources
7%
in
and number of activity repetitions, and our process models naturally capture these
phenomena. Furthermore,
Our
attempts always
first
for
some
its
prin-
Thus both
accelerating the product development
cycle.
The
staff of the technical
department
in
the Plastics division consisted of engineers and tech-
nicians divided into functional groups specializing in design and applications.
group supported these engineering groups by helping to make and
test
A
technical services
product prototypes
addition, manufacturing engineers, product managers, salespeople, and other staff
made
in
critical
members
In
all
contributions to development projects. These resources constitute the workstations
our network.
Project Types
Section
in
projects of each type are assigned either priority
2,
years prior to our project, the Plastics division has shifted
The manager
products.
As we explained
processes two types of projects, new products and reformulations.
The network
three priority
1
or priority
1
much
of
During the few
2.
its effort to
developing new-
of the Plastics division estimated that his group initiates an average of
new product
new product projects every year On
projects and 2.5 priority 2
the
other hand, an average of one reformulation project of each priority designation was started every
These figures are summarized
year.
work can
oscillate
To
2.
(We were
told by our informants that the
mix of
between new product and reformulation projects over periods of several years,
so an important feature of our
Activities
Table
in
model
is its
ability to reflect a
changing mix of work
)
and Precedence Constraints
identify the activities that partitioned a project,
we turned
developed by the Plastics division to serve as an internal guideline
system" recently
to a "phase
new product development
for
This system partitions the development of a project into four phases, each phase consisting of
a set of issues to resolve.
In
Phase
1
("Concept/Feasibility"), a small team of marketing and
product development people explore technical, manufacturing, and marketing
team
3
is
assembled
in
Phase 2 ("Project Plan/Team") and a project plan
("Product Development") marks the project's peak
prototypes, working out technical, legal, and marketing issues
of the prototype takes place in
phase includes a concentrated
here,
effort;
is
full
Phase
drafted.
tests
Manufacturing ramp-up
Phase 4 ("Manufacturing Standardization/Launch").
effort to eliminate
\
team builds and
the
in detail.
feasibility.
any remaining technical wrinkles and
This
it
last
closes
with the project launch.
We
more
chose to aggregate Phases
detail.
We
1,
2,
and
focused on Phcise 3 because
4 into a single activity each,
it
and model Phase
contains the bulk of project work;
it
3 in
also proved
to be the time of crispest activity description. Table 3 describes the 8 activities involved in a
new
product development project. Because reformulation projects deal with existing products, they
often skip Phases
1
and 2 entirely and marketing
activities tend to be
minimal
these activities for
new product
projects and reformulation projects, respectively. For example, Figure 2 shows that
new product
Figures 2 and 3 illustrate the precedence constraints
projects begin with Phase
2
is
finished, engineers
issues.
On
marketing
1
and move to Phase
2 after
among
Phase
1
has been completed. Once Phase
and technicians simultaneously begin working on technical and marketing
the technical side, the engineers and technicians build and test prototypes; on the
side,
market position
is
established, sales strategies formulated, and lead-customer(s)
Once
identified.
a prototype meets specifications in the
development
lab,
it
is
sent to manufactur-
ing for ramp-up. Prototyping and manufacturing scale-up are iterated until a prototype satisfies
all
product, materials, and manufacturing requirements.
Meanwhile, once a prototype has been built and marketing
specifications group begins exploring whether the product
The
is
activities
subject to government regulations.
prototyping, marketing, and specifications activities culminate
Phase
Finally, the project enters
documentations are
4,
in
where the project undergoes
and the product
finalized,
have been completed, the
a final qualification testing.
manufacturing scale-up,
full
launched.
is
the Plastics division led us to conclude that prototyping and manu-
Our conversations with
facturing activities are likely to require several iterations before they are successfuly completed,
and that products are more
level.
prototyping stage than the manufacturing scale-up
likely to fail at the
75%
Figure 2 shows that
of prototypes need to be repeated.
scale-up results in the building of another prototype
60%
of the time
(Thus, the average number
of times the activities manufacturing scale-up and prototyping are carried out are
—
.75)"'
and
2.5
first
attempt. In
(1
=
10, respectively.)
reality,
a qualification test
may
it is
possible for
It
is
felt
some
is
four.
prototype
On
which the
is
likely to
is
60)"'
=
2.5
likely to
and
in
occur
particular of the
One can imagine another
in less
we
specifications), but
"Markovian," meaning that the probability
entirely independent of history,
be completed
meet certain
were significant and most
times that the activity has been carried out.
fifth
-
of these to be repeated several times (for example,
worth noting that our routing structure
of success of an activity
1
(
All other activities, however, are successful after the
reveal that the prototype does not
include only iterations that our host
manufacturing
In addition,
situation
in
number
which, say, a
time and with greater surety than the preceding
the other hand, four failed prototypes might signal a particularly difficult project
fifth effort is
we
in
highly likely to be unsuccessful. As our informants at the Plastics division
were unable to characterize their prototyping activities
iterations,"
of
settled for the
in
more
detail
than "average number of
Markovian routing structure. Subsequent studies can explore
this
issue in greater detail.
Figure 3 illustrates the flow of activities
in
reformulation projects.
Because reformulation
projects constitute a very small fraction of project-related work, we collected only
and consequently we do not model reformulation projects
product projects.
in reality,
at
the
same
summary data
level of detail as
new
For example. Figure 3 shows no iterations between the activities, whereas
one typically experiences several iterations of the prototyping
these simphfications, however, our models were
reasonable accuracy.)
still
activities.
(Even with
able to predict cycle-time performance with
Although the product development group considered
opment
in
its
principal
—
of "new products,"
it
also handled "reformulations'"
— and
it
supported products on the market.
existing products
mandate
to be the devel-
projects to replace the materials
New product development and
support efforts were typically triggered by customer interest; reformulations arose either when a
vendor discontinued a constituent material or when a better material became available.
Management
ically,
assigned formal priorities to projects to help resources allocate their time
projects involving the development of
priority)
new products were given
whereas most reformulation projects were treated as priority
tended to have
little
2.
priority
I
Typ-
(the highest
Reformulation projects
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. Only
rarely did
circumstances force reformulation projects into top priority
Managers and engineers often expressed exasperation over the long delays that
priority 2
projects suffered while waiting for attention from product managers or the manufacturing plant.
If
the priority reflected the true business importance of the project, then such delays might seem
inevitable and even appropriate.
months of work over
2.5 years, raising questions
opportunity cost of delay
One
distraction.
Nevertheless, one project we studied had spread two person-
in
about
inefficiencies
getting the product to market, and the
goal of this paper
is
due to mental set-up time, the
toll
to quantify the delays arising
policies so that these costs can be evaluated
more
of prolonged
management
from various management
explicitly.
The Simulation Model
3
Resources
The processing network model
consists of seven workstations, corresponding to the seven resource
pools Product Development (PD) Engineers, Product Development (PD) Technicians, Manufacturing Engineers, Application Engineers, Technical Services, Product
Table
cations.
1
lists
each pool, and the
work week
the engineering resource pools, the
maximum work
for these resources vary
capacity of each group
PD
of engineers or technicians in
Management estimates
in
work extra hours when projects are backlogged
maximum
server capacities
shown
of average
the technical department of the Plastics Division (these
engineers and technicians, application engineers, and technical services)
typically
Specifi-
between 40 and 55 hours per week, and we allocate additional
capacity to resource pools that belong
are
number
Management, and
in
resources work during critical periods.
Table
1
reflect the
or
These resources
when deadlines approach, and
maximum number
the
of hours that these
Processing and Interarrival Times
The amount
of time that resources devote to each activity
activity/resource
is
displayed
in
Tables
4
and
Each
5.
Table 4 shows the average number of hours that the resource spends on
cell in
An empty
that activity per iteration.
cell
indicates that the resource does not contribute to that
activity.
Table
on the other hand, shows the fraction of time that resources spend on administrative
5,
and support
activities.
The amount
of time spent on support reflects the nature and role of the
resource pool. For example, because the primary responsibility of manufacturing engineers
is
to
the manufacturing operation, they spend the bulk of their time on activities outside the product
development arena. Hence the fraction of time they spend on support
We model
exception
is
all
interarrival times
and processing tmies
relatively high
is
as exponentially distributed.
(The only
the interarrival times of administrative duties, which we take to be deterministic
Other distributional forms
(e.g.,
Beta,
Gamma, Normal)
data to justify other choices of distributions
sufficient
activities
we did not have
are clearly possible, but
Moreover, our preliminary experiments
indicated that cycle times are not significantly affected by the distributions that
conjecture that since there are
network, a small change
in
many
)
we used
— we
contributing factors to the total level of uncertainty in the
the variability of processing times would not have
much impact on
overall performance.
Pooling
We
also include a feature that allows resource groups to share their work, in particular,
overutilized groups to reallocate their work to those that are less heavily loaded.
We
for
learned from
discussions with the Plastics division that product development engineers often reassign part of
their
work
model, we
to the
let
product development technicians during
periods
In our simulation
product development engineers reassign work to product development technicians
whenever there are more than
PD
critical
Engineers to
PD
five
ongoing projects.
Technicians only
each of these activities, at most
30%
in
Phase
1,
We
assume that work can be transferred from
Prototyping, and Manufacturing Scale-f
-^
For
of the engineers' work can be given to technicians.
Service Discipline
The
last
rule by
component
in
the simulation model that
we need
to specify
is
the service discipline
which an engineer or technician chooses her next task from the in-box.
We
— the
implement the
"base case" using the "round-robin" service discipline at each workstation with service periods
equalto two weeks. Under
this discipline, a free engineer or technician takes the first top priority
task in her queue and works on
for
it
two weeks or
until the task
the task within two weeks, the corresponding job moves on to
its
is
finished
updated to
is
When
server.
tasks in the
reflect the last
the queue
round of service, and
empty of top
is
same manner. Clearly
its
waits until
remaining processing
next access to the
its
priority work, the station serves the second priority
there are other possible choices for service discipline, including
first-in-first-out, last-in-first-out, or project
the round-robin service discipline
it
she completes
successor task(s), forking and
joining as necessary. Otherwise, the task returns to the end of the queue,
time
If
is
with the earliest due-date
a reasonable approximation of
We
first.
conjecture that
human response
to
important
competing demands.
Percentage Utilizations
The data we described above
is
summarized
Table
in
which displays the
6,
"load"
imposed on
each resource pool (this exhibit assumes engineers and technicians do not pool their work). Each
Table
in
cell
6 reflects the fraction of a resouce pool's
example, the
first
column shows that
3%
product projects,
PD
engineers spend
of their time on priority
administrative activities.
The
first
time that
1
40%
reformulation projects, and
two rows of Table
show that
6
much
the
row indicates that the bulk of the Plastics division's time
fifth
time from the Plastics division than priority
The
last
row shows the
we
give
some resources additional capacity
that
1
The numbers
allocated to product development engineers.
priority
20%
1
is
1
new
reformulation work
In addition,
spent on priority
we have accounted
to allow for over-time work, so
1
work
for (recall
we do not expect
row suggest that too much work has been
in this
As we
For
of their time on
new product work.
total fraction of a resource's time that
that the total figures are 100%).
spent on an activity
of their time on priority
requires
less
is
will
show
in
Section
8,
the possibility for
engineers to reallocate part of their work to technicians greatly improves development cycle time.
Simulation Results: The Base Case
We
present the simulation results of the "base case"
primary interest here
time.
It is
the
is
amount
New product
project.
project completion time, which
we
will
To
is
the
will also refer to as
number
calibrate our models,
is
4).
of
development cycle
"end" of the
projects begin with concept generation and feasibility studies (Pha.se
and end when the product
report
we
The performance measure
of elapsed time from the ""beginning" of the project until the
and they end with the product launch (Phase
activities
in this section.
1),
Reformulation projects begin with prototyping
launched (Phase
4).
Another measure of performance that
of unfinished prG,ects in the organization.
we compare our findings with
figures provided by the Plastics division.
Our
host was able to provide us with detailed timelines for priority
1
new product
projects from
which we were able to compute average project completion tmies. Such records were not available
for
other types of projects, and for these statistics, we relied on estimates by the manager of the
Plastics division.
Table 7 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
new product
three years to rinish priority 2
projects.
For reformulation projects, the simulated completion times are 5 months for priority
and
by
year for priority 2 projects. These numbers are
1
r,
!
manager of the
Plastics division: 6-9
months
somewhat lower than
for priority
1
projects
the figures estimated
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
it
they are generally treated with less urgency than new product
We
priority.
as low priority work,
Consequently,
in reality
2,
mentioned
Section 2 that reformulation projects are treated
and only when a project needs
to be expedited
reformulation project
likely that a priority 2
is
in
simulated completion time for priority 2 reformulation projects
new product projects take longer
cycle time, whereas priority 2
is
it
elevated to priority
1.
often treated as "priority 3."
is
This informal setting of priorities may partly explain the biases
is
our simulation results:
in
the
shorter than the actual project
to complete than reported by the
Plastics division.
Figures 4-7 show histograms and cumulative distributions of the project cycle time for the 2
types of projects. (Note that histograms quickly communicate the general characteristics of the
distribution - e.g. skewness of the distribution,
tail
are useful for obtaining percentile information.)
The 90th
which can be read from Figures 5 and
for
example, while priority
them take more than
1
7,
It is
percentiles of project completion time,
are significantly longer than the corresponding averages;
new product
2.5 years!
behavior - whereas cumulative distributions
projects are completed
clear with these displays that
in
84 weeks on average.
it is
10%
of
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
column of Table
in
7
shows the
variability
and congestion on cycle time performance, the
ratio of the actual average project completion time (which appears
the 4'^ column) to the project cycle time predicted by
"actual- to- PERT" ratio,
to the
amount
of time
an average priority
1
it
last
PERT
(5'^
column). This number, the
compares the amount of time that a project spends waiting
actually spends being processed.
new product project
for resources
For example, Table 7 indicates that
suffers relatively little
from congestion, as
less
than
10%
of
its
time
spent
is
idle
other hand, spends (on average) more than half of
reformulation projects, which are
from the congestion.
It
A
waiting for resources.
its
priority 2
project, on the
time waiting to be processed.
time-intensive than
less
new product
new product
Priority 2
more
projects, suffer even
spends approximately twice as much time waiting
for a resource as
does
it
being processed.
The
rows
last four
in
Table 7 compare the simulated number of unfinished projects
Plastics division with the figures estimated by
its
in
the
manager. Again, readers should note the
dis-
parity between averages and 90th percentiles.
Finally,
must work
PD
Table 8 shows the fraction of time that each resource pool
its
majcimum overtime. These numbers appear
engineers work 60-hour weeks more than
work
their
maximum work-week
less
65%
The numbers
PD
that
engineers and
we report here
of the time.
On
PD
some resources -
the other hand,
PD
technicians
Because much of our data was
may have
over-estimated their contribution and
In Section 8,
we investigate the benefits of sharing
estimated by engineers, we suspect that they
more work between
the core technical group
to be quite high for
than 6 weeks per year.
under-estimated that of their technicians.
in
technicians.
are "long-run average" statistics.
We
obtained these figures
by simulating the models until they reach "steady-state" and taking the long-run averages as our
performance measures. The time horizon we used
2000 years! -
is
clearly inappropriate
in
the simulation experiments - approximately
when considering the product development environment.
(Each simulation run takes approximately 80 minutes of
difficulty here
is
essentially
one of finding the correct
CPU
initial
time on a Micro VAX 3800
conditions for the system
able to collect data concerning the present distribution of workloads -
currently in the system and the
amount
i.e.,
the
The
we were
If
number
)
of projects
of work remaining to be done on each project by each
resource - then simulation could answer practical questions such as "how will the system perform
over the next five years." Because we have no information regarding initial conditions,
we must
simulate the systems long enough for them to accumulate a reasonable amount of work, and we
approximate the performance measures by
4
How much would
a resource pool?
their steady-state values.
Adding Resources: Where
project completion time be reduced
Where would
way, which resource(s)
is
this additional
are the Bottlenecks?
if
one engineer/technician were added
employee have the most impact'' Stated another
the bottieneck(s) in the system?
such questions by comparing scenarios
in
to
Simulation can provide msiglits to
which different resource pools are augmented.
9 displays average project completion times under four such scenarios
10
In
Cases
1,
2.
Table
and
3.
one employee
is
added
to applications engineers, technical services,
engineers respectively. In Case
Adding one person amounts
4,
one additional person
3%
to roughly a
is
added
and product development
to each of these resource pools.
increase in the total resource pool; adding three
people amounts to about 9%.
Table 6 indicates that product development engineers are most heavily utilized among the
three groups being considered, so
Table
9,
and
may have
(The small increase
2.
Moreover, Table 9 shows that adding a resource to an
bear out this expectation.
"uncritical" resource pool
1
principles (Kleinrock 1975) thai they
be the best resource to augment. Our simulation experiments, whose results are summarized
will
in
we expect from queueing
in
no impact on cycle-time performance, as
virtually
project completion time under Case
as simulation "noise" rather than a significant change
Case
results in
larger reduction in cycle-time
histogram
investment
3 indicate that additional
if
the resource pool
is
in
cycle time.)
3.
Finally,
Case
Cases
should be interpreted
1
On
the other hand, the
resources can yield proportionally
chosen judiciously
new product completion times under Case
for
m
in
much
Figures 8-9 display the
4 implies
that not
much
can be gained over Case 3 by adding an additional resource to each of the pools applications
engineers, technical services, and
A
tional
PD
engineers.
final resource allocation decision (that
whether and
is,
to hire)
economic analysis comparing the cost of an additional employee
from shorter development cycle times. The data we present
as the (otherwise elusive) foundation of such an
5
A
whom
second avenue
to the savings resulting
these simulation studies could serve
economic analysis.
Process Improvement: Reducing Processing Times
for cutting cycle
time
to
is
reduce individual activity times
however, how
much improvement
times drop
processing times are reduced by 5%'' Will
if
in
to expect. For
example, how
it
far will
are reduced by 5%. For both priority
is
90'
and
more than 5%. The average
and priority 2 by 31%
The
1
is
not clear,
be more or
less
than
all
5%?
processing times
priority 2 projects, the resulting decrease in average
priority
1
new product
cycle time
is
reduced by 10%
In addition, the distributions of these times are tightened significantly.
percentile for priority 2
to 220 weeks, an
It
expected project completion
Figures 10-11 show the histogram for new product completion times when
cycle time
would require addi-
new product
projects, for example,
is
reduced from 350 weeks
improvement of 37%.
The magnitude
of these improvements
is
not surprising in light of the high percentage utiliza-
tion of the resource pools (all are approximately 90%).
Recall from queueing principles that the
relationship between cycle time and utilization factors
is
11
steep and nonlinear
when percentage
utilizations
decrease
approach 100%.
in utilizations,
so
A
small decrease
results in
it
in
processing times
is
equivalent to a proportional
times.
When
same magnitude
as the
more than proportionally lower completion
resources are not heavily utilized, the improvements will be of only the
processing time reduction.
We
have described
in this section a scenario in
reduces the processing time of
all activities.
which the product development organization
One might
also ask
if
the organization were to focus on
one activity c; a subset of activities for process improvement, which activities should management
We
can easily modify our
management can
use the results of such
target in order to most effectively reduce project completion time.
simulation models to explore questions of this type, and
simulation experiments to help them
its
improvement
decisions regarding process
efforts.
Benefits of Controlling Input
6
Durmg
make
our time at the Plastics division, the organization was involved
in
an effort to improve
procedure for selecting new projects according to their likelihood of success. This
prompted by management's concern about lengthening project
of aborted projects that fruitlessly tied up valuable resources.
effort
cycle times and the large
We
was
number
can use our simulation model to
assess the impact of a simplified version of such an "input control" policy in which the organization
does not bid for new projects when the
level of unfinished projects rises
above a pre-set cutoff
level.
Because reformulation projects support established product
nization could not decline these projects without great cost.
90th percentile of priority
projects,
1
new product completion times
and Figure 13 displays the same information
simulation results show that while priority
priority 2 projects benefit greatly
as
we noted
in
from
Section 10, priority
1
1
we guessed that the orga-
lines,
Figure 12 shows the average and
for cutoff levels
for priority 2
new product
project completion time
this control policy.
1
in
projects
to 5
Our
not reduced by much,
work
much congestion whereas
priority
System improvements have much
greater impact on low priority projects than on projects that are given
The improvement
is
2.5
This should not be surprising because,
projects do not experience
2 projects suffer long delays while waiting for priority
ranging from
first priority.
project completion times must be traded off against the
number
of
projects lost as a result of the input control policy. Figure 14 shows the long-run average fraction
of projects that are rejected at each cutoff level.
of
4%
of potential
product projects
new product
is
projects are
lost,
With a
cutoff level of 20 projects, an average
and average completion time
for priority 2 new-
reduced by approximately 18%. The benefits of input control policies would
obviously be considerably enhanced
if
management can
12
further select projects according to their
probabilities of success.
The simple
decreases the
we described reduces
control policy
amount
of work in the system.
It
cycle time for the obvious reason that
also has the
more subtle yet more powerful
of reducing the variability in the system by restricting the total
it
effect
number of jobs allowed
in
the
network at a time. (In the base case, the product development organization can have more than
20 unfinished new product projects
The improvement
40.)
proportional reduction
10%
cycle time with input control
in
the rate of
in
number
of the time, and the
new project
starts.
is
In
of open projects can reach
thus more dramatic that due to a
Figure
15,
we present histograms of
project completion times to illustrate that not only does input control reduce the average cycle
time,
it
also has a secondary effect of reducing the spread of the distribution.
Operating as a "Pull" System
7
Consider a scenario
constant
level:
which the number of concurrent projects
in
the organization
the development organization initiates a project only
been completed. This "pull"
implement the
in
when another
which project completions trigger project
arrive.
product development organization must always have
pull system, the
The manager
of the Plastics division confirmed
which the number of priority
results for the case in
maintained at a constant
project has
which jobs are injected into the sytem whenever they
that such a scenario was indeed compatible with the experience of his organization
is
kept at a
can be
projects "on the shelf" waiting to be processed.
we present simulation
is
starts,
policy, in
contrasted to a "push" policy,
In order to
in
1
In this section
new product
projects
level.
Table 10 compares the performances of the push system and the pull system at varying
The second and
of concurrent projects.
third
columns of Table
time for new product projects, and the fourth and
for reformulation projects.
The
number
1
rate:
the
of priority
projects they can complete each year.
the
same time, the longer
it
On
five
faster.
also
compare the
new product throughput
We
see immediately the
the other hand, the more projects they must juggle at
pull
all
1
new product
projects, the pull system
project types, and the average prionfv 2
new product
Moreover, the pull system produces at least as many projects
as the the base case (throughput rate
We
1
projects completed per year.
concurrent priority
delivers better cycle-time performance for
14%
priority
figures
takes to complete each individual project.
Table 10 shows that with
projects are completed
columns display the corresponding
column shows the resulting
new product
show the average completion
more projects that resources must handle concurrently, the more
the
possibility for trade-off;
last
fifth
10
levels
is
3.1 projects
per year).
system with a push system that
13
is
subject to input control. Figure
16 displays cumulative distributions of priority 2
that have approximately the
input control, where the
pull
same throughput
maximum number
new product completion times
rate: (i) the
of concurrent projects
system with the number of concurrent projects equal to
throughput rate
for priority
1
new product
projects
is
improvement
of
23%
systems
the push system with
set to
is
be 25. and
(iii)
the
In each of these three cases, the
five.
approximately three projects per year, but
system performs better than the other two systems; note that the
to 270 weeks, an
(ii)
Even with the higher throughput
the pull system has slightly higher throughput rate.
pull
push system
for three
over the push system and
7%
percentile
90'
rate, the
is
reduced
over the push system with
input control.
The
system improves cycle time performance by eliminating the
pull
controlled) arrivals of
in
new
projects.
It
is
more
the previous section (in which the system
variability.
is
due to (un-
variability
effective than simple input control as described
still
open) because
essentially
it
keepmg constant
Clearly, even greater benefits can be achieved by
further reduces
number
the
of
projects in each category.
8
Tradeoffs of Cross-Training: Effects of Pooling
Because product development engineers are much more heavily
technicians (see Tables 6 and 8),
these pools. As
we noted
in
utilized
we examined the consequences
Section
3,
engineers and technicians
in
than product development
of sharing
more work between
the Plastics division frequently
reallocate their work assignments. In the simulation experiments described here,
number
engineers reassign a portion of their work to technicians whenever the
exceeds
5.
In Section 10,
technicians. Here
we assumed that 30%
we explore the
of the engineers'
effect of varying this
amount
we assume that
of ongoing projects
work could be performed by
of transferable work
The
results
provide one measure of the benefits of cross training.
Figure 17 shows the average completion times
ranging from
resulting
10%
to
70%. The numbers
from giving an additional 10%
to their technicians.
is
new product
projects with pooling levels
parentheses are percentage reductions
to the
amount
of work that
PD
negligible.)
is
The graph
in
busier.
20%
to
30%,
1
Figure 17 suggests that the expected benefit of additional
statement further: As engineers reassign more work to technicians, the engineers
become
time
reduced by 13%. (Again, note that the impact on priority
pooling becomes less pronounced as the amount of shared work increases. Figure 18
while the technicians
in cycle
engineers can reassign
For example, by increasing the fraction of pooled work from
average priority 2 completion time
cycle time
in
for
clarifies this
gam
slack time
Eventually product development engineers cease to be the
bottleneck.
14
We make
the simplifying assumption that no loss of efficiency results from pooling
transfering work from engineers to technicians could result
in likelihoods
We
of errors.
might expect higher
processing times and increased
number
levels of
differences in processing times or
in
pooling to be accompanied by longer
of iterations. Although our hosts shared this expectation,
they were not able to quantitatively estimate these effects for
observation with the insight gained from Figure 17,
level of
it
us.
Nevertheless, combining this
should be clear that there
an "optimal"
is
pooling beyond which cycle time gets longer.
Finish
9
We
In general,
have assumed so
convention because
What You
The FIFO DiscipHne
Started:
far that resources process their tasks in a
it
seemed
discipline
is
We
chose this
to
competing
way that workers might respond
to be a reasonable
demands. An alternative service
round robin fashion
(FIFO),
"first-in-first-out"
tasks in order of arrival, working on each one continuously until
Table 11 displays cycle time performance under the
FIFO
it
is
in
which resources process
finished.
service discipline
Notice that
shows no significant difference between the round-robin discipline and FIFO service
cycle time performance.
used
in
We
if
the results might be very different.
technician
may
We
among
the next task.
may
example.
not be efficient for the reason that an engineer or
some "mental set-up time"
In the
projects frequently, a significant
We
for
plan to explore this topic further in future research
issues each time she returns to a project.
switch
were cut to two days or two hours,
this interval
service discipline
require
terms of
in
conjecture that this result reflects the service period of two weeks
the round-robin scenario:
The round-robin
to relocate
documentation or
to recall relevant
round-robin service discipline, where resources
amount
of time
may be
spent
in
getting ready for
have assumed that resources require no set-up time when they begin
task, so this set-up cost
it
would be absent under FIFO.
We
a
new
investigate the effects of set-up time in
the next section.
10
Effects of Iterating
better understand the effects of iterations between activities, we investigated several models
To
with varying number of iterations, but with constant total activity times. Suppose that activity
A
requires i person-weeks to be successfully completed, and p
iteration
We
is
set the
successful
(i.e.,
the average
number
is
the probability that any given
of times that activity
time required to complete each sub-task
(i.e.,
.4
is
repeated
each iteration) to j
=p
us to isolate the effects of increased variability on total project completion time.
15
i.
is
n
=
1/p)
This allows
We
conducted two sets of experiments with two different
of experiments, only prototyping
successful in the
scale-up.
both
In
first
FIFO
repeated. In the second set. prototyping activities are always
iteration, but cycling
sets, the probability of
third set of experiments,
but with
is
In the first set
levels of iterations.
back to prototyping can occur after manufacturing
returning to protoyping ranges from
we investigated models
in
00 to
which only the prototypmg activity
is
90
In a
repeated,
service discipline.
Figures 19-22 summarize the results of these experiments.
The graphs suggest
that cycling
doe not significantly affect project completion time. For new product projects, a marked increase
in
project completion times appears only
The
effects of
FIFO
when
the probability of repeating
service, on the other hand, are rather interesting.
is
very high (090).
Under FIFO, new product
projects have uniformly better cycle time performance than under round-robin, and reformulations
do uniformly worse. This phenomenon springs from the fact that reformulation projects are much
smaller than
new product
projects.
Under round-robin
service, jobs rotate in
and out of service
frequently with the length of service constrained by the predetermined service "slice
service, however, an activity can start only
when
all
"
Under FIFO
predecessor activities have been completed,
so reformulation projects suffer increased delay due to the
more time-consuming new product
projects.
Our second
set of
experiments incorporates the observation that total activity time may not
be perfectly divisible into times for subtasks. For example, each iteration
may
involve
some
level
of inefficiency and consequently increase total activity times. In a heavily loaded system such as
the one
we
consider, a small increase
performance.
repeated.
We
utilization levels can have disastrous effects on
system
simulate this effect by charging each activity with a small set-up each time
As stated
the project,
in
it
is
previously, this set-up can represent time spent relocating documentation on
communicating with groups that worked on the upstream
task, or simply recalling
the project's relevant issues. In our experiment, we set the probability of repeating prototyping
to be
to be
090, and the probability of returning to prototyping from manufacturing scale-up
0.80.
(Thus, the total number of times that prototyping and manufacturing scale-up are carried
out are 50 and 5 respectively.) The set-up time accompanying each repetition
is
1/2 hour
Table 12 displays the average project completion times under this scenario. Table 13 compares
percentage utilization of resources for the base case and the system described here, and Figure 23
compares cumulative distributions of
priority
scenarios.
Note that even though percentage
cycle time
is
1
new products
project completion time for the two
utilization increases at
quite dramatic.
16
most by 2%, the increase
in
The Importance
11
An
often-addressed topic
in
the product development literature
manager (we
ferent functions under one
them operate independently under
The
(Wheelwright, 1989).
shows that
all
this a
call
different
the benefits of organizing
is
managers (which we
call a
product development activities
in
dif-
"centralized" system), rather than letting
"decentralized'" system)
Plastics division operates under the centralized scenario:
functions involved
engineers, product
of Priority Coordination
(e.g.,
Figure
I
product development
management, and marketing) are grouped under one manager. Consequently,
same
projects are assigned the
priority across
all
groups
—
•
Conversely,
at least, in principle.
if
these groups were placed under separate managers, projects would likely face different priorities
in different
groups.
To examine
the consequences of the decentralized organization,
which manufacturing engineers and product management treat
priority
much
compared
6),
in
play relatively small roles
system
in
in
Table
14, are
Recall that, manufacturing engineers and product
the product development process (see Tables 3 and
in
terms of both absolute number of hours contributed and percentage of time dedicated
to project related work.
For example, only
product management's time,
is
10%
of manufacturing engmeers' time, and
12%
of
spent on new product and reformulation projects. Yet, when these
groups do not treat project work as
project completion times can suffer by 35%.
first priority,
Conclusion
12
We
a
project-related work as low
Project completion times, shown
to their support activities.
longer for the decentralized system.
management
all
we analyzed
have demonstrated that for an important group of product development organizations
namely, those that pursue multiple concurrent projects using shared resources
—
— process models
provide a promising framework for better understanding and managing development cycle time.
From our simulation experiments, we
for
are able to
compressing project completion times.
Acknowledge delays
thai result
draw some
We summarize
from congestion
useful insights
and recommendations
our findings below.
effects:
Development cycle times experienced
by product development organizations are typically longer (and often much longer) than estimates
obtained from
arise
(ii)
from
PERT
2 sources:
and
(i)
CPM
analyses.
delays are due
the inherent uncertainty
the contention for shared resources
play an important role
The
in
the
in
on compressing development cycle time,
part to congestion effects that
the product development environment, and
among concurrent
management
in
projects.
Process models therefore can
of product development, particularly
-^nd
if
the focus
is
our experience suggests that such models can be
17
created and maintained without
in identifying
much
and collecting data,
An
Reduce resource utilizations:
to reduce the load
(i.e.,
as
and cost (the bulk of the work
difficulty
we described
m
Adler
in
the project was
1992b)
el al.
obvious method for compressing development cycle time
We
percentage utilizations) of the resource pools.
showed how
is
to use
process models to evaluate resource allocation decisions, to identify resources that are likely to
be bottlenecks, and to quantify the benefits of an additional employee. (For example, we found
that adding a person to an "uncritical" resouce
may have
similar way, process models can identify activities that are
Control new project starts:
better
management
of
new
most suitable
Development cycle time can
We
project starts.
no impact on cycle time.)
virtually
also
for process
level.
considered a simple policy of input control
Our simulation experiments showed that
can greatly improve project completion time, and that simulation
the "optimal"
Our
cutoff level.
implementing a "pull" policy
we trade
in
a
in
improvement
be effectively decreased with
which new projects are not undertaken whenever the number of ongoing projects
exceeds a preset cutoff
In a
is
in
in
the division
this input control policy
a useful tool for determining
results suggested that even greater gains can
be realized by
which project starts are triggered by project completions. Here,
value of undertaking more projects with the benefit of completing each project
off the
more timely manner.
Balance workload among resources:
balance the workload
among
A
method
third
for
improving cycle-time performance
is
to
resources. This can be achieved through cross-training which allows
resources to reallocate portions of their work to less heavily utilized resources in critical periods.
We
found that the benefits of cross-training and work-pooling decreases as the workload between
resources
become more
general result
equal.
We
also noted that reassigning
to a
secondary resource may
in
longer processing times and greater likelihoods of errors. In light of our findings
in
regarding the incremental benefits of work-pooling,
it
and that one can use process models
to
cross-training,
work
follows that there
determine that
is
an "optimal"
level of
level.
Coordinate priorities between resources: Our model suggests that a "centralized" system of
management,
can be
in
which the different product development functions
much more
effective
than a "decentralized" organization,
independently to different managers, at least
in
in
all
operate under one manager,
which different functions report
terms of cycle-time performance. Even a resource
pool that contributes only marginally to the product development process can significantly delay
project comnpletion by assigning
Finally,
First,
it
low priority.
we used our simulation models
we explored the impact of using a
to investigate
some
interesting and diflRcult issues.
first-in-first-out service discipline rather
than a round-
robin convention. Although our preliminary results in this study are inconclusive, they do raise the
question of
when
is
one discipline better than
another'^' Is the
18
answer dependent on the structure
of the network or the characteristics of processing times'^ Does the existence of additional "mental
set-up" time imply that first-in-first-out
always
is
preferable';'
Second, we investigated how different iteration structures can aiTect overall cycle time. Our
results suggest that
is
if
the total
amount
of time mvolved
not significantly affected by an increase
these experiments, we were interested
the probability that activities have to be repeated. In
in
the question of time allocation:
in
to allocate additional time to each protyping run
greater likelihood that the prototype
prototypes, each taking a smaller
towards the end of the process
is
if
m
of time?
more advantageous
Is it
the additional time investment resulted
acceptable; or
amount
(e.g.,
kept constant, project completion time
is
a
better to perform several iterations of
is it
Is it
in
better to allocate the additional effort
manufacturing scale-up) or
beginning (during
at the
prototype runs)?
It
is
clear that these are
We
unresolved.
development
sues.
We
two important topics
in
framework we have suggested, namely, representating product
believe that the
as a stochastic processing network, provides a powerful tool for exploring such
plan to undertake some of these tasks
We
this direction of research appealing.
in
much can be gained from analyzing
Acknowledgements:
and
of
in
is
a highly aggregated
the Plastics division.
We
believe that
various components in greater detail.
We owe
called Chemicals, Inc
staff of its Plastics division.
thanks
in
particular to the
manager
This project has also benefited from the advice and support
Chuck Holloway and Mike Harrison.
is
model
close by noting that our
This study would not have been possible without the generous coopera-
company we have
Association
is-
future work and hope that others also find
representation of the product development activities
tion of the
product development that remain largely
Funding from the Stanford Integrated Manufacturing
gratefully acknowledged. Elizabeth Schwerer
was supported by
a National Science
Foundation graduate fellowship.
References
Adler,
cess
p.,
a.
Mandelbaum,
Management
in
Engineering:
Development. Submitted
Adler,
P.,
A.
Nguyen, and
V.
An
E.
Schwerer.
1992a.
From Project
to Pro-
Empirically-based Framework for the Analysis of Product
for publication.
Mandelbaum,
V.
Nguyen, and
ological Challenges in Engineering Process
E,
Schwerer.
Management:
Design Conference, Los Angeles, California (September).
19
1992b. Managerial and Method-
Lessons from a Case Study
UCLA
1^
Blackburn,
D. 1991.
New Product Development: The New Time Wars.
The Next Battleground
tition:
Irwin,
J.
m
American Manufacturing,
J.
D
Blackburn
B.
and T. Fujimoto.
1989.
Lead Time
in
(ed).
Business
One
Automobile Product Development Explaining
the Japanese Advantage. Journal of Engineering and Technology
Hayes, R. H.,
S.
Wheelwright, and K.
Learning Organization, Free Press,
Kleinrock,
L. 1975.
Rosenthal,
S.
R
B.
New
Clark.
1:
Effective Product Design
Satisfaction. Business
Stalk, G. Jr. and T. M. Hout. 1990
1988.
Management
6, 25-28
Dynamic Manufacturing: Creating
York.
Queueing Systems Volume
1992
Customer
Increase
IS
Time-Based Compe-
Homewood.
Clark, K.
the
In
One
Theory, Wiley
&
and Development:
Irwin,
Sons,
How
New
to
York.
Cut Lead Times and
Homewood.
Competing Against Time:
How Time
Based Competition
Reshaping Global Markets. Free Press, 1990
Pegden, C.
SIMAN
D., R. E.
Shannon, and
McGraw-Hill,
Wheelwright,
S.
C
R. P. Sadovvski.
1990. Introduction to Simulation Using
Inc.
and K. B. Clark.
1992a. Creating Project Plans to Focus Product Devel-
opment. Harvard Business Review, March-April, 70-82.
and
.
1992b. Revolutionizing Product Development:
Efficiency and Quality, Free Press,
New
York.
Quantum Leaps
in
Speed
Resource
Name
._.
.
.
Case
System
( CEO
^I
r
I
Corp
PRODUCTION DIVISIONS
R&D
REGIONAL AND PRODUCT FAMILY GROUPS
Technology
Finance/
Admin
Mkt
PRODUCT DIVS
Analysis
and Sales
Plastics
Div.
Technical Dept
~1~
I
Mfg
Mktg
Finance
Mgt
Prod
Prod
Technical
Appl
Dvpt
Dvpt
Teh
Services
Eng
Eng
Product
Qlty
1
1
Figure
1:
Organization Chart of the Chemicals Inc.
Assurance!
Figure
2:
Activities
(Proto-A
typing^
Figure
3:
Flow Diagram -
^/^Plant
^ ^
^Scale-up/
Activities
/
New Products
Phase 4
V
Flow Diagram - Reformulations
3
f
E?
n
o
n
o
3
•a
3
n
,
250.0
I
o
OQ
290.0
330.0
370.0
410.0
TO
C
z
n
a
Io
o
n
o
o3
o
3
3
n
c
3
c_
<'
ft
e
410.0
NJ
21
I
•a
s
i
o
o
o
o
C
-J
n
5'
3
R'
n
o
a3
o
H
§
o
n
c
3
c
<
c
o
10.0
50.0
mc
o
90.0
5
Z
o
130.0
o
o.
"0
,o
I-
n
o
3
n
T3
I
O
3
§•
H
3
o
170.0
B
210.0
o3
H
"^
o
<
n
3
3
>
c
Ot3
3
o
3
I
250.0
5'
(TO
0
O
m
3
290.0
IJQ
3
-0
330.0
o
3
370.0
410.0
o
O
o
TO
C
o
3.
z
g.
7
.o
n
o
3
a.
5'
3
3
n
70
o
a.
c
o
5'
TO
TO
3
Vi
330.0
370.0
Project Completion
s
1=
3
c
c
S)
o
3.
z
T3
o
o
3
a_
o'
H
i
oC3
n
o
3
O
g
o
00
o
o
Time
in
Weeks
o
o
Project Completion
n
o
Z
n
J
n
o
3
o
5'
3
H
i'
n
o
3
Time
in
Weeks
Fraction of
o
Z
o
3
i
c
3
(X3
ft
3
B
3
Z
Z
B
3
f
I
e
o
2.
<^
n °
s
3
a
c
3
C
O
o
3
I
5f
c;;
^ ^
New
Product Projects Rejected
LA
o
0<a
c
7
5
z
ft
2.
c
r>
n
o
o
S"
c
o
3
o
I
e
3
I
250.0
+
290.0
-
330.0
-
370.0
-
410.0
-L
Z
B
3
i"
n
o
a
o
e
8
o
Project Completion
J
Time
in
Weeks
Resource Percent Utilization
Ln
Project Completion
O
3
21
o
Time
in
Weeks
o
Project Completion
g
a.
73
a
OQ
>
o
s
(a
-J
1^
o
o
o
o
Time
-J
o
in
Weeks
00
o
o
o
Project Completion
S
b
<
3
ere'
n
o
3.
p
o
?3
ST
I
n
o
n
o
a3
(t
c.
o
9
98
>
n
3
tn
1^
o
b
Time
in
Weeks
Project Completion
o
31
to
10
s.
p
o
to
n
I
§
s.
SB
n
o
3
s
B
on
I
>
n
5*
i"'
tfl
R
o
I-
3
en
O
O
8
Time
in
Weeks
^
00
o
p
p
3
ci5
c
to
1
o
Z
2.
c
o
JJ
0
o
a3
?r
I
H
3
i
5
9
CO
I
o
5'
410.0
j
/
bo
oo
o
o
o
-J
bo
o
Date Due
APR.08W3;
my 31 mi
^
MIT LIBRARIES DUPL
3
TDflD
DD7n23T
3