MATAGING R&P IN A FIGH-GROWTH COMPANY:
the Significance of Coordinating People and Products
George P. Richardson
Systen Tynamics Group
Alfred P. Sloan School of Management
Yassachusetts Institute of Technology
The Preklem
A number of high technology firms have recently reported increasing
delays in the develomment of computer-related hardware and softwere. One
suct company, experiencing increesing product development times and
schedule overruns, conmissioned a systen dynamics study of the management
of its product develoment group. The purpose of the study has been to
locate a range of potential sources for rising product development times in
thé confeny, and to identify aspects of the problem over which management
can exercise gone control.
Such froduct develomment problens are frequently blened on exgoneous
factors. The primary culprit is thought to be rising technological
conplexity--the incressing difficulty of designing and debugging the
densely packed chips in very large scele intergated ciruitry (VISI). Some
miett see the pattern as another instance of declining American
productivity. Some in our client company placed part of the blene on the
flerce corpetition for development engineers, which makes it difficult to
meet hiring goals. And noting the tendency for growing firms to pass
through periodic crises, some obeervers might suggest that corporate growth
itsel® is to bleme.
The systen dynamics study described in this paper has identified two
policy areas under management's control that have the power to produce
rising preduct development times even in the absence of any increase in
product complexity.
312
The Model
The model developed in the study captures in detail the etructure of
the company's product develomment group. It contains four main sectors:
engineering manpower, managers, product development, and revenue and
budget. There is sufficient structure to explore a wide range of issues
relating to RAD productivity, including the assimilation and supervision of
new personnel, the develoment of engineering and managerial expertise,
competing demands for an engineer's time, tightness of the labor pool for
engineers, and interactions between product develoyment and the compeny’s
market and market share. Of central importance in the model are the
endogenous representations of the.decisions to introduce products for
develoment, to hire engineers to carry out the work, and to acquire
manegerial structure to oversee the growing development group.
T™e model differs significantly from other eysten dynamics nodele of
the RSD process in that it does not focus on the lifecycle of a single
product develoment project. Rather, it traces over time a continuous
stream of products and their aversge product develoment time. In
addition, the model places the structure and behavior of the develoment
process in the context of extremely rapid corporate growth.
Model Behavior and Policy Analysis
Our study indicates that the pattern of problems confronting the
client company cen be generated without assuming a number of the external
factors some might feel are at the heart of the problems. It demonstrates
that there exist rational and reasonable R&D managenent policies that can
generate the problem behavior and alternative policies which cen
significantly improve the situation. Those policies deal with the general
problem of coordinating the flows of engineers, managerial talent, and
Frojects in the develoment group. The paper defines this notion of
coordination and shows how weaknesses in coordinating flows can lead to the
renge of rroblens experienced by our client R&D group.
Figure 1 shows the pattern of rising product develoyment times
exhibited by the base run of the model. Also shown in the figure are two
of the patterns in the model which lead to the rise. One cause is the
ing vedge between products in development ard products supportable by
the runter of engineers in the develomment group. The other is an
oscilletory pattern in the fraction of an engineer's time devoted to
orgenization end communication tasks, a mix of non-engineering activities
nececsery for the functioning of @ product develoment group in a growing
cerporation. The widening wedge can permanently raise product development
tines and give the appearance of a gradual decline in engineering’
Frefuctivity. The osedlatory pattern creates ups and downs in engineering
Freductivity thet can cause short-term increases in product development
tines ard sckedule overruns.
Figures 2 and 3 show simplified views of the important feedback
structures underlying these patterns. The paper analyzes these patterns,
divcusses the structure of R&D management policies responsible for then,
end suggests how they can be countered by a careful coordination of people
and rroducts.
313
Figure 1: Base run behavior showing the pattern
of rising product development tine, together with
graphs reflecting a lack of coordination of the
flows of people and products in the RAD group.
Figure 2: Summary of feedback Figure 3: Summary of feedback
structure surrounding the de- structure surrounding the de-
cision to introduce @ product cision to acquire menagers in
for development. the develoment group.
314
EEEEEE 2 OE
1 PRepuct déversemanr Time
gf8 i - i a
a oe Spee a
¥ etre
E : fees
a eg sai
a 1
E '
: Fraction gr aN VCE gece cH
ry ENGINEER'S THE IN
= ORGAMIBAITION £ COMMAN CATIA:
S ME 32 ae
g
Time (monrres)
Figure 1: Pase run behavior showing the pattern
of rising product development time, together with
graphs reflecting a lack of coordination of the
flows of people and products in the RAD group.
ener, sewer
~
Aewescnat oF
Natagene Tiaaee
reoecerty
Seat ws
SEN gene
nae
Tow eater Wane
cnn /
we
“ane
Figure 2: Summary of feedback Pigure 3: Sumary of feedback
structure surrounding the de- structure surrounding the de~
cision to introduce a product cision to acquire managers in
for development. the development group.
MANAGING R&D IN A HIGH-GROWTH COMPANY:
The Significance of Coordinating People and Products
George P. Richardson
System Dynamics Group
Alfred P. Sloan School of Management
Massachusetts Institute of Technology
Cambridge, MA., 02139
I. Introduction
A number of high technology firms have recently reported increasing
delays in the development of computer-related hardware and software.
Experiencing increasing product development times and schedule overruns,
one such company commissioned a system dynamics study of the management of
its product development group. The purpose of the study has been to
uncover potential sources for rising product development times in the
company and to identify those over which management can exercise. some
control.
The results of the study are interesting to consider in light of
current perceptions of declining industrial productivity in the United
States and increasing question about the efficiency and effectiveness of
research and develoyment efforts. The study has demonstrated that the
symptoms of what is apparently a problem of declining engineering
efficiency of can be generated by a pattern of decisions in the firm. This
paper describes the study that supports this conclusion and analyzes the
decision structures that have the potential to produce rising product
development times.
Section II of this paper describes in more detail the nature of the
problems addressed by the study and discusses a number of perspectives on
such problems. Section III describes the structure of the computer
simulation model developed in the course of the study. Section IV analyzes
” -p-3324 2
the causes for rising product development times in the model. Section V
discusses implications of these model-based analyses for the management of
a development group in the context of rapid corporate growth.
II. The Problem
Our client company is a developer and manufacturer of data-
communications equipment. Having enjoyed a real rate of revenue growth in
the neighborhood of thirty-to-thirty-five percent per year for the past ten
years, the firm now encompasses six diverse product lines, including high-
speed modems, multiplexers, intelligent terminals, and diagnostic devices
for computer communication systems. The firm projects that the personnel
in the product development group will grow over the next five years at more
than twenty percent annually.
Since 1977, the company has experienced increases in the time it
takes to bring a product from the initiation of development to its first
shipments. In this period overruns in product development schedules have
increased in frequency and severity. Product development times have risen
from a norm of 18-to-24 months to as high as 40 months, and schedule
overruns have gone as high as nine months. In addition from 1977 to 1979
the company lost a number of senior development engineers. The reasons
expressed varied considerably, but seemed to center on changes in the
character of the firm brought about by its dramatically rapid growth:
increasing administrative burdens on senior engineers, a large and growing
percentage of new engineers in the development group, and the feeling that
the quality and commitment of personnel were not quite what they used to
be.
These two dynamic patterns, shown graphically in figure i, are the
focus of this study. It is reasonable to suggest that they are related: a
loss of highly productive, senior engineers could easily set development
projects back considerably. sn influence in the opposite direction is also
conceivable: a prolonged pattern of rising product development times could
produce such a pressured atmosphere to meet schedule deadlines that
engineers eventually opt for more comfortable job situations.
D-3321 3
AVERAGE c
Propuct
DEVELOPMENT
Time
Actua a,
~ PLANNED,
Mey,
oss OF
Seniog. ENGINEERS
Figure 1: The problem focus: rising product
development times and an increase in turnover of senior
development engineers
Perspectives on the Problem
Such patterns may be viewed as natural, unavoidable aspects of the
dynamics of rapidly growing, high-technology industries. A number of
experts in the data~communications industry trace recent overruns in
product development schedules to the shift to more sophisticated
technology--from LSI (large-scale integrated circuitry) to VLSI (very
large-scale integration). "At the heart of the problem," says Business
Week [1], “are the complex logic circuits that make up the computer
processor. As more and more of this circuitry is squeezed onto a single
high-density chip, it becomes tougher to correct design flaws. Once the
circuits are cased in silicon, they cannot be changed without redesigning
and refabricating the entire chip, a process that takes at least four to
six weeks." So product development times are seen to rise for two likely
and related reasons: increasingly complex products inherently take longer
to design, and undiscovered errors in the new VLSI technology take longer
to correct. Fierce competition for development engineers skilled in LSI
and VLSI design and manufacture is a natural consequence. Turnover is
likely to be increasingly high, as engineers are lured from company to
company by ever more attractive job situations. {2]
" p-3321 4
If the problems are industry-wide and essentially beyond managerial
control, no one firm's share of the market is threatened by a pattern of
rising product development times. Everyone will reach the market somewhat
later than advertised, and no one will be able to capitalize permanently on
the development delays of others. If, however, there are aspects of the
phenomenon that are potentially within the control of corporate management,
then. those companies that learn the quickest stand to reap considerable
benefits in market share and revenues. Our client company wished to
investigate the point of view that some aspects of the problem could
actually be exacerbated by its own R&D) management policies. It requested a
study focused internally on the operation of its development group.
An internal perspective leads naturally to a focus on engineering
productivity, for it has an obvious effect on product development time:
tasks in product development
Cengineers/product) * productivity’
product development time =
where a "task" is some arbitrarily defined unit of work and productivity i
measured in tasks per person per unit time. It is thus easy to view a
problem of rising product development times as a problem of declining
engineering productivity per person. If fewer engineering tasks per month
per engineer are completed, then even if the complexity of the development
effort remains constant product development time will rise.
Management experience and the R&D literature suggest numerous factors)
have the power to influence productivity. Cotiis and Dyer {3], for, {
example, discuss twelve dimensions of project management that correlate
significantly with the efficient use of product development resources.
Stahl and Steger {4] relate an engineer's productivity to characteristics
of the individual and his or her development group. Allen {5] documents
the role of communication networks. The notion of undiscovered rework,
implicit in the above comments about the increasing difficulty of debugging
VISI circuitry, has been shown to have considerable power to cause schedule
overruns in large projects. fel,f7
D-3321 5
Our work thus focused initially on a range of productivity issues. A
number of iterations through the modeling process produced the insight that
is the central thesis of this paper: that what is apparently a problem of
declining productivity can be generated by decisions within the development
group that appear to be far removed from productivity concerns.
III. Modeling the Process of Product Development
A number of system dynamics models relating to the management of R&D
projects have been developed and used for policy analysis. [6] - [11] The
model in this study differs from these in that it does not trace the
lifecycle of a single project; rather, it reproduces the dynamics of a
development group over an eight year period as a continuous stream of
products are developed and placed into production. The model focuses on
the number of products under development, the use of resources required,
and an aggregate average product development time. In addition, the model
differs from past modeling efforts by placing R&D dynamics in the context
of rapid corporate growth. It is intended to replicate the structure and
behavior of a product development group growing initially at 25 percent
per year.
As shown in figure 2, the model consists of four major sectors
focusing, respectively, on engineers, managers, product develoyment, and
revenue and budget. ‘The engineer sector (70 equations) traces the flow of
engineers as they are hired into the firm, as they become assimilated and
develop into highly productive senior engineers, and as they are promoted
to managers or leave the firm. The sector monitors pressures that have the
potential to cause quits of senior engineers and keeps account of competing
demands for an engineer's time. The manager sector (23 equations) hires
and promotes people into managerial and coordinating positions and traces
the effects of managerial experience on the productivity of engineers. In
the product development sector (29 equations) products are initiated,
developed, completed, passed into production, and eventually drop out of
production «s they become obsolete. This sector computes an engineers’
estimated luct development time, the compromise target development time
settled o. « light of perceptions of market needs, and the actual product
D-3321
development time that results from the dynamics of the entire development
group. The sales and revenue sector (30 equations) contains a simplified
treatment of a growing market. The firm's market share responds to the
quantity and quality of the firm's output, relative to its competitors. A
percentage of the revenues from products in production is allocated to the
development group and used for salaries and product development. With the
market effects assumed in the model a closed loop of action and information
exists: the operations of the development group affect revenues, and the
resulting growth in revenues affects the growth of people and products in
the development group.
Cr
Upgrene
tare Poor
leurs >)
MANAGERS
ENGINEER le
Lheok Poot
ENGINEERING
Manrower
Duveave ti
Darerve at)
+ WiEING, = Promotion
7 ASCUN LATION Presganes fo -Exreciumce
sexrenauce | Zucemnver
= ORK AN RAT EN
f Communication,
7 ~fR
EGUEES onic TS
NU SPM Secon *y
\
Prosucrivity
\
Peopuet
\ SALES | MarceT
DevevopmenT 7 Seat ae
\ “Srces P Fates = Perceptions
| ~ ConPLevion IWrorMATUN | = Dena
Times
(
Sacaries!
’
1
Revenue
AND BubeeT
’
~Marver —— —-—— ie
N SHAEE even
Manrewe R ~Devevrrent
SuPror TABLE Corrs
(The Fiery J
Figure 2: Overview of the structure of the model
D-3321 Hf
The internal operations of the firm are influenced by three exogenous
factors: a gradually growing pool of engineering talent, a growing market
for the firm's products, and increasing competition for the firm's market
share. These exogenous influences can be varied to test different
scenarios. When kept the same in differeit computer simulations, they
provide a common background against which to test different management
policies within the firm. The dynamics of all of the remaining variables
in the model are determined endogenously, that is, internally, by the
assumed decision structure of the firm.
Three competing demands for an engineer's time are recognized in the
model: engineering, supervising engineers new to the firm, and handling a
mix of non-engineering activities called the "organization and
communication burden" of the development group (described in section IV).
To perform the necessary productivity computations the model introduces the
concept of a "full-time equivalent experienced engineer," defined to be the
mythical senior engineer who spends every minute of a working day in
engineering activities. The computation is
FOEPP = BTS * EF * ESPP * EQEP * EIP
where
FTEPP = full-time equivalent engineers per product,
ETS = effective team size (people/product),
EF = engineering fraction (see below),
ESPP = effect of schdule pressure on productivity,
EQEP = effect of the quality of engineers on productivity,
EIP = effect of incentives on productivity (a policy parameter).
Essentially, the number of full-time equivalent engineers per product is
equal to the actual number of engineers per product, multiplied by the
fraction of these people that are "full-time, experienced equivalent
engineers," and modified further by effects on productivity from short and
long-term schedule pressure, the overall. quality of the engineering group
in the firm, and a potential effect of an incentives policy. The
engineering fraction EF translates the number of inexperienced and
D-3321 8
experienced engineers in the model into an equivalent number of experienced
engineers and subtracts out the fraction of time engineers spend in
supervisory and organization and communication activities. The equation is
F = EFEP - FEX*FMHS - FEOC
where
EF = engineering fraction,
EFEP = effect of fraction experienced on productivity,
FEX = fraction experienced,
FMHS = fraction of experienced manhours to supervision,
FEOC = fraction of an engineer's time in organization and
communication activities.
Thus, six factors in the model affect engineering productivity: the basic
quality of the engineering group, average aggregate engineering experience
in the firm, supervisory activities required of engineers, team size,
requirements for nonengineering activities related to organization and
communication, and pressures arising from development schedules. Product
development time is then simply the result of dividing the number of
man-months of actual product engineering required by the number of full-
time equivalent engineers:
PDT = PER/FTEPP
where
PDT: = product development time (months),
PER = product engineering requirement (man-months),
PTEPP = full-time equivalent engineers per product (people).
Moving outward from productivity concerns, two concepts form the
focal points for model conceptualization: accumulation processes -- stocks
and flows of people and material -- and feedback loops -- closed paths of
action and information. Pigure 3 shows the principal levels (stocks) and
rates (flows) assumed in the model. (A number of other accumulations that
appear in the model as delays or averaging processes are not shown.) The
| D-3324 9
model separates both engineers and managers into “inexperienced” and
"experienced" pools so that a number of productivity effects can be
represented. Supervision of new engincers by senior people, for example,
creates two opposing effects on engineering productivity: increased
supervision speeds the assimilation of new engineers and shortens their
period of lower productivity, but it pulls senior engineers away from
actual product development work. Both effects are captured in the model.
= Protuet
Jue Pe eiENCeD| »f x BENE eT)
GQ Engintens we
a JwexFeerenced
Heng Fxaoweee
Paster ate DS oun tate
oe Prope ts nm
DeveropHewT
ExPe RieNce D eee .
ENGINEERS Expenevees °
poe DM gis
ciemeen om PET ON
Prootin fy 7
Prive
Tae RPE RIENCED Prodvers IN
Managers R— LD. PRoDUCTEN)
ot werrenences
" aig B
PAGER, ait ATE
Asc mL aT Od
rae
Mauser ExPeneNceD
rein Mayeger out
Rare Pare
Figure 3: Principal levels (stocks) and rates (flows)
in the model
The concept of feedback arises naturally in analyzing cause and
effect sequences that appear to be related to the problems of rising
product development times and increasing quits of senior engineers.
Considering supervision once again, suppose the firm experiences an
increase in quits among senior engineers who spent some fraction of their
time providing engineering guidance to others. The loss would mean that
less day-to-day supervisory time would be available to newer engineers. As
a consequence, it should take longer to assimilate new engineers into the
firm -- a longer apprenticeship or development period before a new person
D-3321 10
reaches the productivity of a senior engineer. Thus, the rate of flow into
the pool of experienced engineers would tend to slow up. In sum, an
increase in the outflow from the experienced pool tends to decrease (other
things being equal) the inflow to that pool, further exacerbating the drop
in senior e1gineers caused by the increase in quits. This self-reinforcing
process, called a positive feedback loop, is shown in figure 4.
@ @
ASSLULATION. Protenoy
Pare Pave
INERPEP ENCED Experiences
p23 mated |
HIeinG
Bate
/ _
THe . ae THasleeeS
ASSIMILATE SuPeRvisioN
TueyPERIENCED «= (4)
ENGINEERY
i
Total Smrervisien)
Suregvision, TUE AVAILAELE
Tike pee
TREXPE RiENC
Eneinece.
Figure 4: Self-reinforcing (positive) feedback loop in
the supervision of new engineers by senior development
engineers.
The feedback perspective illuminates two general types of processes
at work in any complex system -- those that are self-regulating and those,
like the supervision loop, that are self-reinforcing. The model in this
study was formulated from the point of view that all decisions are made in
the context of feedback. Some aspect of the system is perceived; change
comes from the desire to move the system closer to some desired state;
decisions are made to bring the actual state of the system closer to the
desired; the actions taken alter the state of the system, giving rise to
new perceptions of the system. Such a closed loop of action and
information is called a feedback loop, because information eventually
"feeds back" to its point of origin, affecting future perceptions and
“D-3321 1
actions. The model developed in this study contains hundreds of such
loops. The dynamic behavior of the system is a consequence of the complex
interactive structure they form.
The decision to introduce a product for development illustrates a
number of such feedback patterns, and is an important determinant of the
behavior of the system over time. The decision is based upon the current
workload in the development group, the availability of resources, project
completions, and growth goals. The model equation states:
PGEN = (DPDEV-PDEV)/PPEVAT + COMP + GP*PDEV,
where
PGEN = product generation rate (products/month) ,
DPDEV = desired products in development,
PDEV = products in development,
PDEVAT= adjustment time for products in developnent (months),
COMP = product completion rate (products/month) ,
GP = growth factor for products in development.
Essentially, the equation states that new products are added to the
workload of the development group when old ones are completed (COMP) and
when additional ones are necessary to keep up with planned growth
(GP*PDEV). The term (DPDEV-PDEV)/PDEVAT represents pressures in the
decision process that adjust the rate of introduction of new products to
the availability of development resources. It adjusts the actual
introduction of products above or below the base rate (COMP + GP*PDEV)
depending upon how PDEV compares to its desired value, DPDEV. ‘The latter
is an aggregate concept representing the firm's perception of the number of
products in development that is necessary to meet its market needs and that
can be supported by the manpower and revenue currently available to the
development group. The parameter PDEVAT reflects how closely management
monitors the workload in the development group and how rapidly it takes
action to bring actual conditions more in line with desired. In the base
ease in the model PDFVAT is set at 24 months, the average product
development time at the start of a simulation.
|
|
|
|
|
D-3321 12
A feedback loop is evident in the first term in this formulation.
The current number of products in the development group (PDEV) is compared
to a desired number (DPDEV). Any discrepancy generates countervailing
action in the product generation rate: if PDEV is too small, for example,
the adjustment term will be positive, and more products will be generated
per month witil PDEV is brought up to DPDEV. igure 5 shows the simple
feedback loop represented by this adjustment term. The loop is self-
regulating: it continuously strives to adjust PGEN to keep the number of
products in the development group equal to the number desired. It is
called a negative feedback loop because it tries to negate or counteract
any change in PDEV from its goal, DPPEV.
PeopucT Pi
eOMIET
GENERATION Combed Ton,
Rave kate
Awa Propucts iw 7 >
O- | Pevevop HevT
Desired
Products IN
DEYEVOPHENT.
Figure 5: Self-regulating (negative) feedback loop in
the decision to introduce products for development
The formulation of PGEN also illustrates a positive or self-
reinforcing feedback loop. The positive feedback loop linking products and
revenue and is among the most important self-reinforcing feedback loops
associated with a technology-based company. Products in development
eventually become products in production, which are the source of the
company's revenues. Revenues support the budget of the development group:
the more revenues generated, the more engineers, money, and technical
resources are available for further product development. In the model,
more revenues thus mean a higher number of products supportable in the
development group, that is, a higher DPDEV, and hence a greater rate of
product generation. The fundamental growth-producing loop of a technical
D-3321 bie
company involves cummulative expansion of products and revenues: more
products in development lead eventually to more products in production,
which produce more revenue; more revenue means more resources for product
development, which lead to more rapid generation of products and a growing
stock of products in development.
This closed sequence of causes and effects appears as three loops in
figure 6. Each is clearly self-reinforcing: by generating additional
revenue products in development usually lead to still more products in
development. In unfortunate circumstances each loop in figure 6 can be
self-reinforcing in a catastrophic direction, when products in production
produce declining revenues, leading to fewer resources available for
product development, leading to a cutback in products in development,
eventually fewer products in production, and still greater declines in
revenue.
teaeet cy \ enero Onan
bre fare TE
&> Sop Prorsens Sy Products WW 52 onael)
DeveroPhenr| f Deve corte vane
Propet
Deverorhenr
Tine Pevenue
Desirer
: ct
Proper IN )
DevercpHedT RED
Busey
(eobuete
SuProptaete
ey Mires ae fEnein tee]
ConPeraTe
Prepucts Grout
Surportapie Pate
by Revere
GrowtH GOAL For
Peopverr tN
DG VELOPKENT
Figure 6: Self-reinforcing (positive) feedback loops
in the decision to introduce products for development
D-3321 14
The model contains more than 150 equations representing a. complex
structure of interacting variables and interconnected feedback loops
assumed active in a corporate product development group. It was
constructed over the course of a year with the aid of the senior director
of business planning in our client company in consultation with the vice
president for development and a senior director of development. A complete
description of the model is not possible here. fie] Instead, in the
following discussion of the behavior exhibited by the model, those pieces
of model structure that support the insights it has helped to generate will
be presented in detail.
Iv. Analyzing Rising Product Development Times
The base run of the model replicates the problem behavior of our
client company. Figure 7 shows a pattern of rising product development
times set against the engineers’ projections, management's desired product
development time (assumed constant at 24 months), and the compromise upon
which engineering and management decisions are based. Figure 8 shows the
the fraction of senior engineers leaving the firm each month, along with
the three quit pressures generated endogenously in the course of the
simulation. We ultimately want to know why product development time is
rising, but figure 7 prompts the question of why it stops rising for two
years in the middle of the simulation. Figure 8 suggests that the burst in
quits of senior engineers is related to the quit pressure from the
“administrative burden" -- a notion linked to the concept of the |
organization and communication burden mentioned above and described in more
detail below. But why the rise and fall in that quit pressure?
The simulation model is a laboratory tool. By altering parameters,
changing the strengths of assumed effects, or deactivating pieces of model
structure we learn the connections between model structure and behavior.
Such experiments are simple in the model and impossible in the real system.
With care, and a number of iterations of conceptualization, formulation,
testing, and refinement, we try to move toward understanding the
connections between the structure of the real system and its behavior.
D-3321
2
8
a
oe ’ ' '
' ‘ ENGINGERS'
a i i Prosectep
8 woe Pronucr en Mee
oy re 1 . ' “Bete ener :
m " Probucr ' ‘
a ' DEVELOPMENT! a
& Time :
8
Boo '
ee i cr ec oe
3 cn get no eH ee
os : ComPRoMise
“ : Probucr
a Deve wor MenT
an) ' TE
a 8 1 presser race) oc evel
S ' Desieep PRobuctT ‘
8 ' ' DEVELopMEN'T TIME ‘
3 1 ; :
8 af
h ge or 48 oy % no
S THE CHoNTHS) =
Figure 7: Product developnent times in the base run
»
u
of
S,
83
ae
. '
Se '
2 | cs ne cert gethee aes A i
at IENCED ' '
eT ENGINGER ‘ '
a é Quit FRACTION “ i
Soe
& So : . ' '
SB BA b & wxergines (Rew aR RET AR BES ceqvemememenuacan soonmasten 3S
n ®o ‘ ' ‘quiy Peessuee FeoM
oT ' cee, ADMINISTRATIVE
y i oO awe se Burden 1
a ox
& Bo 1 1
se see eM... QUT, PREssuRE, gscerrmegneuse <a see
ors co From scxebut ie aaa
ae one 2 r
a eckinnrerer ot at . oy
bd [aa aner ur cm UET rate SOE Mhainhd MEER MEER ett An See Men eR aited one Deal
Ear ‘ : @uir Peessuee
oS 39 ‘ ' FROM Exrerrences
SR
{i slo a 8 ars % Re
3 Time (mon-rne)) —e
Figure 8: Quits and quit pressures in the base run
D-3321 16
As a result of such an iterative modeling process, we can pinpoint
directly the causes of the model behavior shown in figures 7 and 8. The
pattern of rising product development times (PDT) can be traced to two
relatively independent sources. One has the capability to push up PDT
almost indefinitely; the other generates fluctuations in engineering
productivity that translate into relatively short-term ups and downs in
PDT. The cyclic pattern is due to the way the organization and
communication burden is handled as the firm grows. The long-term pressure
upward on PDT actually comes from the structure of the decision to
introduce a product for development. Figure 9 shows the behavior over time
of several of the variables underlying these pressures on PDT.
T
DMP
20°
8838
88s
28
ask ' : .
8 : : Propucts
2 wpe . ¥ DEVELOP MONT
8 8388
B RSS]... eee. i] ye cGIRMRNS i LYR BSE ee Ee
m8
eas Product * ' : :
Si DevevoPp MENT t we
i Time.) :
a
2 se0 N
883 Serr ao roe ge
fom .
Rowe K Fears Sueporratie
z By MANPOWER
2 8 geet pe eee ee 1 gener
Bee sO ccna or oe Wen
Paes ES
A, as La” 1 Exaueer's Time Nese ae on ‘
i 1 IN ORGANIRATON 1 1
B oae |, AND COMMUN (CATION i ‘
838
fo sore w 48 a2 % Re
eB aon
5 Tine (Mew rHe) —e
Figure 9: Underlying causes of rising product
development times in the model
Products Supportable in the Development Group
Corporate officers in our client company described a lengthy process
leading to the decision to develop a product. It begins with a compre-
hensive five year corporate plan that forms the framework for yearly
planning. Anticipated revenues, the behavior of competitors, availability
" D-3321 17
of corporate resources, the market for the firm's products, and more, all
figure into planning for a sequence of product revisions and new product
developments. Plans are reconsidered each year in light of then current
conditions and projections. Orders for the necessary additional
engineering manpower are formulated accordingly and then updated quarterly
in light of available revenues and the availability of engineering manpower
outside the firm. In the model that description is represented in the
formulation for the product generation rate, PGEN.
The critical features of the decision represented by PGEN are the
formulation of desired number of products in development, DPDEV, and the
basic growth rate of the number of products under development, GP. The
model computes DPDEV by first computing the number of products supportable
given the number of engineers in the development group and the number of
products supportable given the trend in revenues. These two figures are
brought together to determine DPDEV, as follows:
DPDEV = PSR * f(PSM/PSR)
where
DPDEV
desired products in development,
PSR = products supportable by revenue,
PSM = products supportable by manpower,
and f is a function chosen to reflect whatever biases are inherent in the
decision in the client company (and probably many others). Perhaps the
most rigidly rational policy would chose f so that DPDEV is the minimum
of PSR and PSM, but that is not likely to be the case in actual practice.
The bias in DPDEV in the model is to lean slightly more toward PSR and to
downweight PSM if the revenue stream suggests more products than the
current number of engineers can easily handle. (The shortage of
development engineers and the fierce competition for them means that PSM is
almost always less than PSR.) The model formulation attempts to capture
the tendencies to start a project somewhat before the full team of
engineers has been assembled. It reflects existing pressures to reassign
people somewhat prematurely from projects that are winding down and to
shift people off long-term projects to deal with short-term product
D-3321 18
refinements, all with the assumption that extra effort and talent can bring
the projects in on time.
The growth in products in development, determined by the term
GP*PPEV and responding to long-term corporate growth goals, has a similar
potential to push more products into the development group than the
engineers can comfortably handle. The model computes a growth factor for
the total workload in the development group, setting it equal to a growth
target, GT, the long-term growth trend in revenues. That growth in
workload is then allocated by decisions internal to the model (and the
company) into a growth in the Size or technical complexity of products and
a growth factor for the number of products, GP. In periods of accelerating
revenue growth, GP will tend to be less than the growth rates of revenues
and people in the development group, so the group catches up to its
workload. In periods of decelerating revenue growth, however, the company
in the short-run tries to continue growing at its traditional rate, and the
growth in products in the development group will tend to be slightly
greater than the growth in manpower.
Combined, the policies determining the number of products supportable
in the development group and the basic growth rate of the number of
products under development lead to the widening wedge between PDEV and
PSM shown in figure 9. In spite of increases in productivity that the
model assumes as schedule pressure increases, too many products under
development lead to inexorably rising product development times.
Such a conclusion is hardly remarkable. But the fact that policies
associated with the decision to initiate a product development project can
cause problems that look like declining productivity was a revelation to
our client company. Midway through the project, a senior director of
development estimated that the group had been ten to fifteen percent
understaffed since at least 1977 because of the shortage of engineering
talent. Yet that was not seen by many as even a potential contributor to
rising product development times. Corporate management leaned toward such
cures as incentives policies, corporate reorgenizations, and improving
engineering communication channels to cope with the problem.
D-3321 19
Policies aimed at improving productivity that do not address the
underlying problem described here may work in the short run but will fail
in the long =v. Suppose, for example, that a dramatically successful
incentives gram creates a permanent ten percent increase in engineering
productivii, A reasonable expection would be that product development
time should rapidly fall about ten percent, the amount of the productivity
increase. Tracing around the feedback loops shown in figure 6 one sees
that products would flow quicker into production, revenue and revenue
growth would rise, profits would rise, leading to an increase in the R&D
budget, and the product generation rate would eventually rise in response,
producing more products in development. With the higher productivity the
firm would enjoy higher revenues, but the tendency to overextend the
development group would remain, and product development times would rise
back up as a result. The feedback structure of the system compensates
naturally for the increase in productivity that stems from the incentives
policy. The notion of compensating feedback is one of the important
insights of the feedback perspective on the behavior of complex systems.
f13]
The Fraction of an Engineer's Time in Organization and Communication.
Activities
A growing “organization and communication burden" is responsible for
the cyclic pattern show in figure 9. As each engineer spends a greater
fraction of his or her time in non-engineering activities, less productive
engineering time is available and product development times should rise as
a result. Conversely, if less time is spent in non-engineering activities,
product development times should fall. The model exhibits a recurring up
and down cycle in the fraction of time an engineer spends dealing with the
organization and communication burden of the development group.
Consequently, there is alternating upward and downward pressure on PDT.
The organization and communication burden, OCB, is a highly
aggregated concept in the model representing a mix of nonengineering
activities assumed to be required in the normal operation of a development
~3?
D-3321 20:
group. We intend the concept to include such things as reporting,
coordinating members of a team, coordination between teams, budget
preparation, scheduling, ordering materials, handling crises, interviewing
and hiring, evaluation for salary and promotion decisions, and so on. It
is a range of tasks including many commonly considered managerial. No
attempt was made to model the detailed interactions OCB is intended to
represent. OCB is formulated simply to rise slightly more rapidly than the
total number of engineers in the development group:
oc = at(nw®)
where
OCB = organization communication burden (man-months per month),
™ = total engineering manpower (people),
= proportionality constant to set initial conditions,
"
an exponent slightly larger than 1.
(The exponent b used in the above runs was 1.2.) The final section of
this paper discusses variations on the formulation for OCB.
The model assumes that a certain amount of the organization and
communication burden must be handled by engineers. Fifteen percent of an
engineer's time is deemed acceptable in the model. When it is perceived
that engineers are forced to devote more than that to these nonengineering
activities, pressures build to speed the acquisition of more managerial
people. The primary role of managers in the model is to draw off the
burden of organization and communication activities from engineers,
increasing their productivity by leaving them freer to engineer.
The cyclic pattern in the fraction of an engineer's time in
organization and communication activities can be traced to a set of
negative feedback loops and perception delays involved in the decision to
acquire managers. The equation for the acquisition of managers has exactly
the same basic structure as the equation given above for the product
generation rate: it contains a term to replace quits and retirements, a
term for growth, and a short-term adjustment to keep the number of managers
D-3321 : at
equal to the number desired. Figure 10 shows an overview of the structure
assumed in the model. Essentially, managers are promoted or hired in a
planned ratio to the number of engineers in the development group. As it
is perceived that engineers are spending too great a fraction of their time
in nonengineering activities, the company deliberately changes the planned
ratio of managers to engineers to correct the situation and return the
development group to full productivity.
GRowrd Rerlrcenenty
Acoust TON OF
MANAGERS THPovt
Hiking AWD ProreTon
\ MenaGerae
Desired Nunger EXPERIENCE
or MaANAGEes [Hevesers |
| ENGINEERS
\ ManAceer aL
Puaines Patio Propueriviry
or MANAGERS
ae ERERELIE ORGANIZATION AND
COMMUNICATION
\ BURDEN \
Fercewed Fraction,
OF AN Exuicee’s OCB TAREN KP
Tae nt ORGARITA TION BY MANAGERS
AND CoMmenicaTion
OCB HANDLED
By EnGiweter
Figure 10: Structure underlying the cyclic pattern in
the fraction of an engineer's time in organization and
communication activities
There are several rather unavoidable delays around the large negative
loop shown in figure 10. It takes the engineers themselves some time to
realize that the time they can devote to engineering has gradually
declined. Top management takes even longer to come to the conclusion that
past operating policy should be changed and then change itself takes time.
D-3321 22
The loop can be thought of as representing some aspects of organizational
change: a change in the ratio of managers to engineers probably represents
in reality a shift to another layer of management, or to a matrix
structure, or from matrix to product line organization. These various
perception and action delays around the negative feedback loop tend to
produce a natural oscillating pattern in FHOC, the fraction of an
engineer's time in organization and communication.
The sequence of events is as follows: the burden of organization and
communication activities grows slightly more rapidly than the development
group. Additional managerial structure is acquired in proportion to the
growth of the group, but because OCB grows faster the planned ratio
eventually proves to be too small; the fraction of an engineer's time in
organization and communication activities, FFOC, grows. When it is finally
perceived that productivity is suffering from having engineers deal with
various nonengineering activities, steps are taken to increase the planned
ratio of managers to engineers and speed the acquisition of managers. The
planned ratio continues to increase until PFEOC, perceived FEOC, has
returned to an acceptable level. The delay between FEOC and PFEOC
guarantees that for PFEOC to fall to the acceptable fifteen percent level
FEOC will drop even further. Excess managerial capacity is acquired, and
the group profits from considerably increased engineering productivity
until further growth pushes it into a repeat of the cycle. The pattern is
reminiscent of the corporate evolutions and revolutions discussed in the
literature. [14],[15]
One result of this ebb and flow of group reorganization is periodic
upward and downward pressure on product development times. It coexists
with the insistent upward pressure on PDT that stems from the widening
wedge (discussed above) between products in development and products
supportable by manpower. The graph of PDT shown in figures 7 and 9 is thus
the result of two patterns superimposed. The rise in PDT exhibited by
these simulations of the model is not a consequence of a rising technical
complexity or an increasing number of man-months or’ product engineering
required (PER), although PER is rising throughout the simulation. Rather,
the schedule overruns and rising product development times result from
D-3321 23
natural tendencies and perceptions in the decision structure of the firm.
We can verify these conclusions by simulating the model with revised
policies in product generation and the acquisition of managers. In model
terms the pattern of rising product development times shown in figures 7
and 9 is essentially eliminated if DPDEV (desired products in development)
is set equal to the minimum of PSR and PSM (products supportable by revenue
and manpower, respectively), PDEVAT (product development adjustment time)
is reduced from 24 months to, say, 6 months, the time to perceive FEOC is
reduced from 18 months to, say, 6 months, and the planned ratio of managers
to engineers is set to respond more quickly to values of PFEOC above the
acceptable fifteen percent level.
Vv. Policy Implications
The parameter changes described above represent improved coordination
between the flows of people and products in the development group.
Revising DPDEV as described in the previous paragraph amounts to trying
harder to match the amount of work to the number of engineers in the
development group. If market needs and the revenue stream suggest the
initiation of a product development effort but the firm can not hire
engineers fast enough, the revised policy says to hold off until an
appropriate team can be assembled. Shortening the adjustment time PDEVAT
means that more attention is paid to any discrepancies to desired and
actual conditions, and action to correct them is taken sooner. Management
listens more and responds more quickly to claims of an overload of work
emanating from the development group. Perhaps a formal monitoring system
(designed to add only minimally to the organization and communiction
burden) is implemented. The parameter changes shortening the delays and
reaction times in the acquisition of managers can be interpreted similarly.
In both areas of the system the effort is to get enough people to do the
job and -- the other side of a loop -- to adjust the growth in workload, if
necessary, to match the people available.
The goal of the analyses in section IV is eventually an increased
understanding about the relationships between structure and behavior in the
D~3321 24
real product development group. The critical question for model-based
analyses is their transferability: to what extent should we believe that
policies that work in the model will work in reality? The answer hinges on
our confidence in the degree of match between the real system and the
model.
While we might agree that it is the matching of essentials, not the
congruence of all details, that is required, the extremely high level of
aggregation involved in the formulation of the organization and
communication burden, OCB, is a potential source of a lack of confidence in
the model-based analyses. Current work is exploring formulations that
compute OCB as a function of product team size (people per product) as well
as the total size of the development group. Our client company believes
that team size has a significant effect on OCB; they estimate that a
doubling in the average size of a product development team (other things
being equal) would increase OCB more than a doubling in total engineering
personnel (other things being equal).
Experiments with reformulations of OCB indicate that matching the
number of managers to the size of the task they are supposed handle is
rather subtle. In these reformulations we have assumed that it is not
possible for a company to directly perceive the size of the organization
and communication burden; it must be inferred from the number of people
enaged in it and the extent of their effort. The company must try to match
the growth of its managerial staff to the growth of an assumed or inferred
organization and cummunication burden. Although these investigations are
incomplete, the behavior of the model under the reformulations remains much
the same as shown above. Again, a fundamental negative loop with
perception and action delays surrounding the acquisition of managers tends
to produce an oscillatory pattern in the time an engineer spends in, these
nonengineering activities. While some of the details differ, the basic
structural insight remains unchanged.
The analyses in IV have deliberately simplified model structure and
behavior, much as the model deliberately simplifies the structure of the
real system. Other pieces of structure in the model (and the real system)
D-3321 25
have the power to push up product development times. The increasing
difficulty of finding and correcting design errors in VISI can increase
product development times by lengthening the time involved in rework.
{6],f7]. Mistakes in estimating the extent or complexity of a product
development effort can lead to assembling too small a team and obviously
cause overruns in a project schedule. The model shows that a sharp
increase in the corporate growth rate and the hiring of new development
engineers can push up product development times in the short run by
decreasing average productivity per engineer and increasing the time senior
engineers devote to supervision. The escalation of salaries in the
industry tends to cause the range of engineers’ salaries in a company to
compress over time; if uncorrected, salary compression can lead to
disgruntlement and departure of senior engineers and a consequent drop in
aggregate average productivity. Our simulations indicate that it might
even be possible for the company to promote such a number of senior
engineers into management that engineering productivity could not keep up
with corporate growth; product development times can rise as a result of
the development group's promotion policy.
Faced with rising product development times, a company thus has a
wide range of policy areas and procedures to reconsider. By emphasing
policies associated with product generation and the acquisition of
managerial talent, this paper suggests that the range of policy options to
consider is broader than previously thought. The analyses in section IV
should not be interpreted as a claim that weak coordination between the
flow of people and products is the sole cause of the problems. However, if
present, weak coordination is an extremely powerful source of rising
product development times and the problem symptoms (such as increasing
quits) that can follow as consequences. Because of its importance and the
relatively low cost associated with the monitoring required to improve the
situation, the coordination of people and products should be considered
near the top of a policy check list designed to halt rising product
development times.
D-3321
26
Notes and References
[1]
{2]
[3]
[4]
[5]
fe]
[7]
{s]
[9]
[10]
[a1]
[12]
[13]
14]
[15]
Snafus that Delay New Products. Business Week, 1 June 1981, p. 110.
What Makes Tandem Run? Business Week, 14 July 1980, pp. 73-74.
Thomas A DeCotiis and Lee Dyer, Defining and Measuring Project
Performance, Research Management, January, 1979, 17-22.
M. J. Stahl and J. A. Steger, Motivation and Productivity in R&D:
associated individual and organizational variables, R&D Management
7,2(1977): 71-76. EE
Thomas J. Allen, Communication Networks in R&D Laboratories, R&D
Management 1,1(1970):14-21.
Kenneth G. Cooper, Naval Ship Production: A Claim Settled and a
Framework Built, Interfaces, 10,6(1980):20-36.
The development of a model of the dynamics of an R&D project is
traced in George P. Richardson and Alexander L. Pugh, Introduction to
System Dynamics Modeling with DYNAMO (Cambridge, Ma.: The MIT Press,
1981).
Edward B. Roberts, The Dynamics of Research and Development (New
York: Harper and Row, 1964).
Edward B. Roberts, A Simple Model of R&D Project Dynamics, R&D
Management, 5,1(1974).
{. J. Kelly, The Dynamics of R&D Project Management, M.S. thesis,
Alfred P. Sloan School of Management, Massachusetts Institute of
Technology, 1970.
Edward J, Poziomek, Delbert W. Rice, and David F. Andersen,
Management by Objectives in the R&D Environment--a Simulation, IEER
Transactions on Engineering Management, FM-24,2(1977):45-51.
A complete, documented equation listing is available as working paper
D-3327 from the System Dynamics Group, B40-203, Alfred P. Sloan
School of Management, M.I.T., Cambridge, MA., 02139.
See Jay W. Forrester, Urban Dynamics (Cambridge, Ma-: The MIT Press,
1969), p. 111.
Larry E. Greiner, Evolution and Revolution as Organizations Grow,
Harvard Business Review, July-August, 1972.
Stephen A. Allen, Understanding Reorganizations of Divisionalized
Companies, Academy of Management Journal, 22,4(1979):641-671.
