REPO/Trs AND
ARTICLES
Tarek K. Abdel-Hamid' s pres-
ent research interests include
the management of software
development projects, appli-
cation of system dynamics to
software engineering. Stuart
E. Madnick's research in-
cludes system design method-
ologies, management infor-
mation systems and database
computers. He is an associate
editor of TODS, a trustee of
the VLDB Foundation, a for-
mer member of the board of
governors of the IEEE Com-
puter Society, and a founding
member and past chairman
of the IEEE Technical Com-
mittee on Database
Engineering.
Authors' Present Address:
Tarek K. Abdel-Hamid and
Stuart E. Madnick,
Center for Information
Systems Research,
MIT, Sloan School
of Management,
50 Memorial Drive,
Cambridge, MA 02139.
Madnick @ MIT-Multics
Permission to copy without
fee all or part of this material
is granted provided that the
copies are not made or dis-
tributed for direct commer-
cial advantage, the ACM co-
pyright notice and the title of
the publication and its date
appear, and notice is given
that copying is by permission
of the Association for Com-
puting Machinery. To copy
otherwise, or to republish,
requires a fee and/or specific
permission. 1983 ACM
0001-0782/83/
0500-0340500.75.
340 Communications of the ACM
THE DYNAMICS OF
SOFTWARE PROJECT
SCHEDULING
TAREK K, ABDEL.HAMID and STUART E, MADNICK Massachusetts Institute of Technology
1. T H E D Y N A M I C S O F S O F T W A R E P R O J E C T
SCHEDULING: AN INTRODUCTION
T h e s o f t w a r e i n d u s t r y is young, growing, and m a r k e d by
rapid c h a n g e in t e c h n o l o g y a n d application. It is not sur-
prising, then, that t h e ability to e s t i m a t e p r o j e c t re-
squrces, i n c l u d i n g t h e t i m e r e s o u r c e , is still r e l a t i v e l y
u n d e v e l o p e d . In a r e c e n t s t u d y i n v e s t i g a t i n g t h e m a j o r
p r o b l e m areas faced by s o f t w a r e p r o j e c t m a n a g e r s today,
" . . . t h e ability to e s t i m a t e a c c u r a t e l y t h e r e s o u r c e s re-
q u i r e d to a c c o m p l i s h a s o f t w a r e d e v e l o p m e n t " a n d
" . . . t h e ability to e s t i m a t e a c c u r a t e l y t h e d e l i v e r y t i m e
on a s o f t w a r e d e v e l o p m e n t " w e r e t w o of the t h i r t e e n
" d e f i n i t e " p r o b l e m areas i d e n t i f i e d [8].
The problem of resource estimating of computer pro-
gram system development is fundamentally qualitative
rather than quantitative. We don't understand what has
to be estimated well enough to make accurate estimates.
Quantitative analyses of resources will augment our qual-
itative understanding of program system development,
but such analyses will never substitute for this under- ABSTRACT: Software project
standing [1]. scheduling is one of the major
problem areas faced by software
T h i s is w h y w h e n m e t h o d s of e s t i m a t i n g are r a n k e d , project managers today. While
t h e list is h e a d e d by w h a t A a r o n called the e x p e r i e n c e several quantitative software
m e t h o d - - e s t i m a t e s that are largely b a s e d on h u m a n project resource and schedule es-
judgements gained through previous experiences with timation methods have been de-
s o f t w a r e projects [1]. veloped, such techniques raise
In the last f e w years t h e r e has b e e n a surge in a c t i v i t y some important, but as yet unre-
to d e v e l o p " q u a n t i t a t i v e " r e s o u r c e e s t i m a t i o n m e t h o d s , solved, dynamic issues. A sys-
for e x a m p l e , T R W ' s C O C O M O m o d e l [3] and P u t n a m ' s tems dynamics (SD) approach is
SLIM [5]. A closer look, h o w e v e r , r e v e a l s that "at h e a r t "
used to analyze several key dy-
s u c h m e t h o d s are still of t h e e x p e r i e n c e type, since t h e y namic software project schedul-
all get c a l i b r a t e d u s i n g h i s t o r i c a l data on c o m p l e t e d soft- ing issues.
w a r e projects.
For e x a m p l e :
The initial COCOMO m o d e l . . , was calibrated using 12
completed projects. The resulting model was then evalu-
ated with respect to a fairly uniform sample of 36 proj-
ects, primarily aerospace applications, producing fairly
good agreement between estimates and a c t u a | s . . .
The calibration and evaluation of COCOMO has not
relied heavily on advanced statistical techniques. After
trying to apply advanced statistical techniques to software
cost estimation, and after observing similar efforts by oth-
ers, I have become convinced that the software field is
currently too primitive, and software cost driver interac-
tions too complex, for standard statistical techniques to
make much headway; and that more initial progress
M ay 1983 Volume 26 Number 5

could be made by trying to formulate empirically the
nature of the interactions between cost drivers, using
functional forms which reflected the best available per-
spectives and data on software life-cycle phenomenology.
Because the c u r r e n t l y available quantitative techniques
are usually tailored to a limited set of p r o j e c t / o r g a n i z a -
tional types and are still imperfect, the developers of
such techniques emphasize the necessity to c o n t i n u o u s l y
collect project data via the p l a n n i n g and control activi-
ties, compare estimates to actuals, and use the results to
improve the estimating tools.
F u r t h e r m o r e , research findings over the past few years
have clearly shown that the decisions that people m a k e
in organizations and the actions t h e y choose to take are
s i g n i f i c a n t l y influenced by the pressures, perceptions,
and incentives p r o d u c e d by the organization's p l a n n i n g
and control system(s) [9]. In particular, knowledge of
pr oj e c t schedules was found to affect the real progress
rate that is achieved, as well as the progress and prob-
lems that are reported u p w a r d in the organization.
What this implies is the existence of a feedback loop
(see Figure 1): an estimation t e c h n i q u e produces project
schedules, w h i c h affect the decisions and actions of the
technical performers and their managers, w h i c h in t u r n
I'-stimotion
y Method
Performonce Schedules
Actions,Y
Decisions
FIGURE 1. SchedulingFeedback Loop.
affect work performance, w h i c h e v e n t u a l l y is fed into
the organization's projects' database to influence future
estimations.
But w h a t does the existence of such a feedback loop
mean? Is it good or bad? To most of us, the answers to
such questions will not be i n t u i t i v e l y obvious, that is, we
cannot a n s w e r t h e m with confidence m e r e l y on the basis
of our private mental models. The h u m a n m i n d is not
a d a p t e d to correctly anticipate the d y n a m i c conse-
quences of interactions b e t w e e n the parts of a c o m p l e x
societal system [4], such as that of software project m a n -
agement. The most familiar e x a m p l e in the literature is
perhaps "Brooks' Law.' W h e n a project falls b e h i n d
schedule, managers often attempt to speed up the project
by adding more people. Brooks suggests that managers
fail to anticipate the d y n a m i c consequences of such an
action, for example, the increase in the c o m m u n i c a t i o n
o v e r h e a d and the need to divert p r o d u c t i v e time of the
current personnel to the training of the n e w people. The
net effect is that the project m a y actually fall further
b e h i n d schedule.
A Systems Dynamics Model is i m p o r t a n t because "Un-
like a mental model, a system d y n a m i c s c o m p u t e r model
can reliably trace through time the implications of any
messy maze of assumptions and interactions" [6]. It can
do so without s t u m b l i n g over phraseology, emotional
bias, or gaps in intuition. Even for those gifted few w h o
can correctly a n s w e r the above questions on the basis of
m e r e intuition, a formal system d y n a m i c s m o d e l can
provide a powerful c o m m u n i c a t i o n tool that can mini-
mize m i s u n d e r s t a n d i n g and m i s c o m m u n i c a t i o n .
May 1983 Volume26 Number 5
REPORTS AND ARllCLES
In the r e m a i n d e r of this p a p e r we will elaborate the
above a r g u m e n t further. We will a t t e m p t to d e m o n s t r a t e
how the modeling, simulation, and analysis techniques
of system d y n a m i c s (SD) can be powerful tools in study-
ing the c o m p l e x area of software project m a n a g e m e n t in
general, and the scheduling issues discussed above in
particular.
2. COMPUTER MODELING OF SOCIAL SYSTEMS:
THE SYSTEM DYNAMICS PERSPECTIVE
People would never attempt to send a sp/lceship to the
moon without first testing the equipment by constructing
prototype models and by computer simulation of the an-
ticipated space trajectories. No company would put a new
kind of household appliance or electronic computer into
production without first making laboratory tests. Such
models and laboratory tests do not guarantee against fail-
ure, but they do identify many weaknesses which can
then be corrected before they cause full-scale disasters.
Our social systems are far more complex and harder to
understand than our technological systems. Why, then,
do we not use the same approach of making models of
social systems and conducting laboratory experiments on
those models before we try new laws and government
programs in real life? The answer is often stated that our
knowledge of social systems is insufficient for construct-
ing useful models. But what justification can there be for
the apparent assumption that we do not know enough to
construct models but believe we do know enough to di-
rectly design new social systems by passing laws and
starting new social programs? I am suggesting that we
now do know enough to make useful models of social
systems. Conversely, we do not know enough to design
the most effective social systems directly without first
going through a model-building experimental phase. But I
am confident, and substanci~ ! supporting evidence is be-
ginning to accumulate, that the proper use of models of
social systems can lead to far better systems, laws, and
programs [4].
Indeed, it is now possible to use the modeling, simula-
tion, and system analysis techniques of system d y n a m i c s
in the laboratory to construct models of managerial sys-
tems. Such models are obviously simplifications of the
actual social systems but can be far more c o m p r e h e n s i v e
than the m e n t a l models that are otherwise used.
System Dynamics (SD) is the application of feedback
control systems principles and techniques to managerial
and organizational problems. The SD philosophy rests on
a belief that the b e h a v i o r (or time history) of an organi-
zational entity is principally caused by its structure. The
structure includes, not only the physical aspects, but
more importantly, the policies and traditions, both tangi-
ble and intangible, that d o m i n a t e decision m a k i n g in the
organizational entity. Such a structural f r a m e w o r k con-
tains sources of amplification, time lags, and information
feedback similar to those found in complex engineering
systems.
The system d y n a m i c s approach begins w i t h an effort
to u n d e r s t a n d the system of forces that has created a
p r o b l e m and continues to sustain it. Relevant data are
gathered usually from a variety of sources, for example,
literature, informed people, etc. As soon as a r u d i m e n -
tary m e a s u r e of u n d e r s t a n d i n g has been achieved, a for-
mal model is developed. This model is initially in the
format of a set of logical diagrams showing cause-and-
effect relationships. As soon as is feasible, the visual
m o d e l is translated into a m a t h e m a t i c a l version. The
model is exposed to criticism, revised, expressed again,
Communications of the ACM 341
REPO/Trs AND A/Tr/CLES

and so on, in an iterative process that continues as long
as it proves to be useful. Just as the model is i m p r o v e d as
a result of successive exposures to critics, a successively
better u n d e r s t a n d i n g of the p r o b l e m is a c h i e v e d by the
people who participate in the process.
Such an approach forces those involved in system de-
sign to m a k e explicit and thoroughly test the assump-
tions that u n d e r l i e their design decisions: the n a t u r e of
problems, their causes, the consequences of alternative
actions, and how various h u m a n , managerial, economic,
and operational factors interrelate. Weil reports that his
e x p e r i e n c e has shown that this is a very valuable proc-
ess; people are really quite surprised w h e n it turns up
things no one had thought of before, incorrect assump-
tions, and differences of opinion about cause and effect
[9].
Roberts has stated that people's
... intuition about the probable consequences of pro-
posed policies frequently proves to be less reliable than
the model's meticulous mathematical approach ... This is
not surprising as it may first appear. Management systems
contain as many as 100 or more variables that are known
to be related to one another in various nonlinear fashions.
The behavior of such a system is complex far beyond the
capacity of intuition. Computer simulation is one of the
most effective means available for supplementing and
correcting human intuition [7].
System d y n a m i c s is suitable for addressing certain
kinds of c o m p l e x problems. In addition to complexity,
such problems have at least two features in common.
First, they are d y n a m i c , that is, they involve quantities
that change over time and that can, therefore, be ex-
pressed in terms of graphs of variables over time. Oscil-
lating levels of e m p l o y m e n t in an industry, a decline in a
city's tax base and quality of life, and the d r a m a t i c a l l y
rising p a t t e r n of health care costs are all d y n a m i c prob-
lems [6]. Cost overruns, slippages in s c h e d u l e d comple-
tion dates, and the variability in p r o d u c t i v i t y are some of
the d y n a m i c problems that can arise in a software pro-
ject.
A second feature of the p r o b l e m s to w h i c h the system
budget. In all these cases a "closing of the loop" occurs.
A delay, w h e t h e r short or long, i n t e r v e n e s b e t w e e n ini-
tial action and feedback results. Closed loops and time
delays in consequences are characteristic of all feedback
processes.
It is apparent from the above that the m a n a g e m e n t of
software d e v e l o p m e n t is a prime c a n d i d a t e for applica-
tion of the system d y n a m i c s method. It clearly is com-
plex, it is d y n a m i c , and it does exhibit feedback behav-
ior.
In [2] we discuss, in some detail, a system d y n a m i c s
model we d e v e l o p e d of software project m a n a g e m e n t .
The model was d e v e l o p e d to be a tool in investigating
the m a n y managerial problems that seem to be plaguing
software d e v e l o p m e n t activities in most organizations,
for example, cost and s c h e d u l e overruns. In particular,
the model serves as a " s k e l e t o n " on top of w h i c h "cus-
t o m " models can be built to fit different o r g a n i z a t i o n a l /
project settings.
In Sec. 4 we use the model to a n a l y z e the d y n a m i c s of
software project scheduling, an exercise we hope will
p r o d u c e some insights into the issues raised in Sec. 1. To
set the stage for this discussion, we will characterize,
next in Sec. 3, the software project (which we will sim-
ply call EXAMPLE) to be used in our analysis.
3. C H A R A C T E R I Z I N G THE "EXAMPLE" S O F T W A R E
PROJECT
One of the attractive features of a c o m p u t e r model is its
high versatility. By simply changing a few model p a r a m -
eters, for example, one can easily s i m u l a t e a wide range
of software project types. The software project EXAM-
PLE involves the d e v e l o p m e n t of a 400,000 DSI system.
(DSI stands for "Delivered Source Instructions." See [3]
for a complete definition.) All of the m o d e l ' s graphical
output, will be in terms of the unit, task, w h e r e a task is
o0OOO
c~O 0(5
~oOoo
ooooo I ~ I
-~o at}- Currently Perceived
P r o j e c t Size

d y n a m i c s perspective applies involves the notion of feed-

back. "Most succinctly, feedback is the transmission and 00000
OOO(5(5
r e t u r n of information. The emphasis, i n h e r e n t in the o Loo o ~,1 - -
r--~. Or'-- ScheduIed
word feedback itself is on the r e t u r n " [6]. A feedback Duration
,'/
system exists w h e n e v e r an action t a k e r will later be in-
fluenced by the consequences of his or her actions. The
consequences m a y be quick and directly a p p a r e n t in re- 00000
sults produced, for example, w h e n the hiring of ten more ~0 0O0000 d __ W o r k force ,'5W
0.n~ 0~<r
0~n ,,'~
p r o g r a m m e r s increases the p r o g r a m m e r s ' workforce to a .,2"
certain desired level, w h i c h in turn feeds back to affect Cumulatlve ,~,9"
the hiring rate, that is, stopping further hiring. Or the Tosks
Wor.d ~ , 2
consequences m a y be d e l a y e d though directly a p p a r e n t 00000
00000 ,.~
in results produced, for example, w h e n a software devel- O~Oo~ --
,,2_~ o'' .",'Y~--- c 0 ~t
o p m e n t m a n a g e r ' s decision to use a p a r t i c u l a r package to
estimate h i s / h e r h u m a n resource r e q u i r e m e n t s affects /z
the project's completion time and cost, w h i c h in t u r n ~- ,~ / D,scovered
Rewot W

influences the m a n a g e r ' s later estimation procedure. Fi- 0ooq

0000 ~" I I I
nally, the consequences m a y be both d e l a y e d and quite 0 0 00 I0000 20000 30000

O
Time (months)
indirect in p e r c e i v e d results, for example, w h e n a deci- o
sion to increase the software d e v e l o p m e n t budget leads
W Workforce (people)
to the hiring of higher quality managers and a n a l y s t s / C , Cumulotlve
D ~ Discovered
T a s k s WorWed (TosWs)
Rework (Tosks)
programmers, who m a y then develop i m p r o v e d products, S ~ Scheduled Ouraflon (months)
T ' C o s t ($1,OOO)
w h i c h m a y e n h a n c e the c o m p a n y ' s competitive position, P : Currently Perceived Project Size ( T a s k s )

in t u r n increasing sales a n d / o r profits, w h i c h m a y t h e n

influence the decision on the software d e v e l o p m e n t FIGURE 2. The "Flawless" Project.

342 Communications of the ACM May 1983 Volume26 Number 5

 REPORTS AND ART/CLES

equivalent to 400 DSI. (Our project is, thus, of size 1000
tasks.) The development period modeled begins at the
beginning of the product design phase and ends at the
end of the integration and test phase. We deliberately
excluded the requirements definition/specification
phase so we could incorporate the use of TRW's COn-
structive COst MOdel (COCOMO) [3]. That is, we assume
that management will use COCOMO to estimate the ef-
fort in man-months (MM), the total development time in
months (TDEV), and the staff size (SS).
In this section we characterize our EXAMPLE software
project. We will do it in a stepwise fashion. We will start
with an "ideal" project situation and then, step-by-step,
add increments of "reality."
Step (1): The "Flawless" Project
In the ideal case, managemenrs estimate of the project's
size will be exactly on target, that is, 400,000 DSI or 1000
tasks. Using the (Basic form of the) COCOMO model, an
estimate of the effort in man-months (MM) can then be
made.
MM = 2.4 (DSI/1000) '.'~
= 2.4 (400,000/1000) 15
= 1295 man-months
From this an estimate of the project's total develop-
ment time (TDEV) can be calculated.
TDEV = 2.5 (MM)":m
= 2.5 (1295)"38
= 38 months
(if ever) realized in real organizations. It will, therefore,
only serve us as a reference point for further analysis.
Step (2): Introducing Rework
Not all work done in the course of a large software pro-
ject is errorless. Some fraction of the work will be less
than satisfactory (e.g., inconsistent design, defective
code, etc.) and must be redone. The unsatisfactory work
may not be discovered right away, however. For some
time it passes unrecognized, until the need for reworking
the tasks shows up. The discovery of unsatisfactory work
that needs reworking can, of course, cause major disrup-
tions in a software project (e.g., people are diverted from
new tasks to redoing old ones) and is, therefore, a signifi-
cant element of the software development environment.
In the model, the generation of rework is regulated by
FERR, which is the fraction of work that is erroneous.
For example, a value of FERR equal to 0.1 means that 10
percent of the tasks completed in a particular unit of
time will be defective, and will thus require reworking.
FERR is not modeled as a constant, however. It is a
variable that changes during the life of the project. Fig-
oooo~o
o
o O o. o~ od
oOddo
~0-~0- - 1 ,~ I I I
Currently Perceived
Project Size
so S' /
/,///
oooO~
o .oo o /s ,/
Q~Q
Scheduled p/

Finally, the average staff size (SS) is determined.

SS = MM/TDEV OoO~Oo
= 34 people oooo8O
o -- Work force ~ ." /
o0~
The dynamic behavior of the "flawless" project situa- /
// /
tion is shown in Figure 2. The project's scheduled com- Curnulotive / /
Tosks /
pletion duration is set to 38 months and a workforce of OoO~O
Worked } / i /

34 people is assembled (e.g., during the requirements/ o

o ,oooo~
specification phase). As can be seen, the project proceeds
"smoothly" and is completed on schedule at a total cost
of $7,810,600. (It is assumed that a rather uniform effort
is required throughout the project. This simplifying as- 8qg~
sumption will be relaxed in a later version of the model oOOQU
0 do I0.000 20.000 30000
in which the software lifecycle will be explicitly divided Time (months)
into three phases: design, coding, and testing.)
Unfortunately the project behavior of Figure 2 is rarely FIGURE 4, Introducing Rework.

ure 3 depicts the assumed relationship between FERR

and the fraction of tasks completed.
0.4 The rationale for making FERR a variable in this fash-
ion is the realization that tasks near the beginning of a
0.3 large software project (e.g., design) are much different
from those near the end (e.g., documentation). Near the
beginning, the project is being defined, different ap-
~:
.,'e 0.2 proaches are being explored, ideas are on the drawing
board, etc. Near the end, the tasks are more like finish-
ing touches: assembling documentation, typing reports,
0.1 and so on. The likelihood of performing work that must
be redone is, thus, modeled to be greater at the begin-
0.0
ning of the project than at the end.
v
0.0 0.2 0.4 0.6 0.8 1.0 The behavior of the model is shown in Figure 4. At the
bottom of the figure, the level of rework perceived (i.e.,
Fraction of Tasks Completed discovered) throughout the life of the project is shown.
The generation of rework means, of course, that more
FIGURE 3. Assumed Shape of FERR. effort will be required to complete the project satisfactor-

May 1983 Volume 26 Number 5 Communications of the ACM 343

REPORTS AND AR'r/CLES

8oo~o
oo0
OOoO o
0]
For this run, we assume that management initially
Cur rently Perceived . estimates the system's size to be 320,000 DSI or 800
tasks, that is, 20 percent lower than the real size of
8 Oo8 o
400,000 DSI or 1000 tasks. The resulting project behavior
ooo~o is shown in Figure 6. The project completes in 51
Scheduled
~/, C)UTOtlOn ~'/ months but at the slightly higher cost of $9,757,200.
." / Notice that the "currently perceived project size"
. . . .
oo8~o starts at 800 tasks, but as the project progresses and the
8ooo8 .-" ,/ ~. ~. level of uncertainty decreases, it is adjusted upwards
/" /
until at about month 35 "currently perceived project
Cumula,,ve
Tasks ."
.
~"
/ size" is in fact equal to 1000 tasks--the true project size.
oo o Oo ~o .o
Worke d " ~ s " /.f As management learns about the upward adjustments in
o" / the project's size, it adjusts its workforce upwards to the
level it perceives is sufficient to complete the project
within the scheduled 35 months. However, unexpected
ooo
o do8o problems arise, for example, a system integration test
o ooo o
o oo
o
I0 OOO 20 OO0 50000 4O000 50O00 fails miserably, which will necessitate the reworking of
Time (months)
tasks believed to be successfully completed. When such
FIGURE 5. Introducing Personnel Turnover. disruptions occur towards the end of the project, man-
agement is reluctant to hire new employees, and there is
ily. After month 13 enough rework is discovered to cause almost no other alternative but to extend the scheduled
management to start hiring more people in order to meet completion date, as shown in Figure 6.
the initial scheduled completion date. This policy con- In the next section we will use EXAMPLE to analyze
tinues until month 29, when management chooses in- the dynamics of software project scheduling. In all our
stead to extend the project's target completion date and subsequent simulation runs we will maintain our pro-
slow down the hiring of new people. The project eventu- ject's present level of "realism," that is, include rework,
ally completes after 41.5 months, at a total cost of personnel turnover, and underestimation.
$9,024,700.

Step (3): Introducing Personnel Turnover 4. THE DYNAMICS OF SOFTWARE PROJECT

In this run we divert even further from the flawless SCHEDULING: A SIMULATION EXPERIMENT
project situation. In addition to the generation of re- In Sec. 1 we suggested that project schedules create pres-
work, we introduce the effect of personnel turnover. In sures, perceptions, and incentives that affect the deci-
the flawless project run it was assumed that people do sions and actions of the technical performers and their
not quit (after all, who would quit an ideal project?). For managers, that this in turn affects work performance,
this run, we assume that the average employment time which is all eventually fed into the organization's proj-
is 24 months. As shown in Figure 5, the project is ad- ects' database to influence future scheduling activities.
versely affected, finishing even later at month 51 and at We also suggested that the dynamic consequences of
a higher cost of $9,582,400. such a feedback loop are not intuitively obvious. The
modeling, simulation, and analysis techniques of system
Step (4): Introducing Estimating Error dynamics were then proposed as a powerful tool to relia-
In the flawless project we assumed that management's bly deduce and analyze the dynamic behavior of com-
estimate of the project's size was exactly on target, that plex feedback systems, such as that of managing software
is, 1000 tasks. Obviously this is too optimistic an assump- projects. In this section we use our system dynamics
tion. model of software project management to conduct a lab-
oratory experiment to investigate the software project
ooo~O scheduling issues raised in Sec. 1.
~ oo OO OOOO
The experiment involves a hypothetical situation in
which a company undertakes a sequence of ten identical
Curren~l
yPercelved
........... '"-L._/ /, o

8.0
.
o
.%
. --
/ Scheduled ~.~ J~
.-2." --
software projects, all identical to project EXAMPLE of
Sec. 3. On the first such project, EXAMPLE1, the com-
pany (lacking the experience) underestimates the size of
. /s// the project by 20 percent, that is, estimates the project's
size to be only 800 tasks. Using the (TRW calibrated)
/ -/ />
Oo o o
o o8
08 COCOMO model, the project's total effort and duration
are then estimated to be 1025 man-months and 35
months, respectively. But as we have already seen in
Cu~ulahve sJ
Tosks #" Sec. 3 (Figure 6), the project actually consumes 1626
ooo~o
oo ~0,.d "~."
s / man-months and is completed in 51 months.
oo~8 / I/

/ 5 / " ~ CS##
ost
After completing project EXAMPLE1, the following is
~N~N~ /Rework
O,scove,ea
learned:

Project EXAMPLE1 is really 1000 (and not 800)

o od~',~ I0 000 20OOO 50000 40OO0 5OOOO
O
O Time (months)
tasks.
d It consumes 1626 man-months.
FIGURE 6. Introducing Estimating Error. It takes 51 months to complete.

344 Communicationsof the ACM May1983 Volume26 Number5


The COCOMO model's " g u a r d i a n " in the c o m p a n y
t h e n notes that had an accurate estimate of project size
(i.e., 1000 tasks) b e e n made, COCOMO's estimates for
effort and project d u r a t i o n w o u l d have b e e n 1295
m a n - m o n t h s and 38 months, respectively. Knowing that
COCOMO is an imperfect estimation tool that needs to
be c o n t i n u o u s l y improved, a d j u s t m e n t s are m a d e such
that for a n y future projects identical to EXAMPLE1 esti-
mates of 1626 m a n - m o n t h s a n d 51 m o n t h s w o u l d be
produced.
Some time later w h e n project EXAMPLE2 (which is
identical to EXAMPLE1) comes along, m a n a g e m e n t will
be in a position to better estimate its true size. In fact, w e
assume that EXAMPLE2's size will be e s t i m a t e d per-
fectly, that is, to be 1000 tasks. F u r t h e r m o r e , the now
" i m p r o v e d " COCOMO m o d e l will p r o d u c e estimates of
1626 m a n - m o n t h s and 51 m o n t h s for EXAMPLE2's total
effort and duration, respectively. Based on these figures,
m a n a g e m e n t d e t e r m i n e s that a staff size of 32 will be
required.
Conducting project EXAMPLE2 u n d e r such circum-
stances produces the b e h a v i o r of Figure 7. The project
s t i l l finishes late, 56 m o n t h s after it started, a n d is 5
m o n t h s b e h i n d the " i m p r o v e d " schedule.
W h e n we repeated the above sequence of actions a n d
reactions eight more times for projects EXAMPLE3
through EXAMPLEIO, we w e r e surprised to observe that
the s c h e d u l e was o v e r r u n in each case. As a result m a n -
agement started each project (e.g., EXAMPLEi) with a
slightly longer s c h e d u l e d d u r a t i o n t h a n the previous one
(i.e., EXAMPLEi-1). However, EXAMPLEi w o u l d still
o v e r r u n its schedule, w h i c h caused m a n a g e m e n t to use
ooooo
oO0oOOOOoo
0o0oo [ II t i
Curr~tly PercelveO
Project Size
oooo Scheduled J
Durolion
I Ill
sS
Workforce
is! ~
,~o. ...,.-.~.~ - ~-- - - - - ~ . . ~ .
ooog
Cumulotive
Tosks l*
s
~ In our e x p e r i m e n t we saw h o w looking at the symp-
oo~o wor~ld ~ . Cost ~ / toms of trouble (i.e., s c h e d u l e overruns) for a cause a n d
D~seove~e~
oo g the system's p r o b l e m a t i c behavior.
oo o O OOO 20000 30000 4000O
8 Time (months)
d ability to conduct s i m u l a t i o n e x p e r i m e n t s in w h i c h we
FIGURE 7. EXAMPLE 2 [Notice change in the COST scale],
an even longer s c h e d u l e d d u r a t i o n for the next project.
The results for the ten s i m u l a t i o n runs are s h o w n in
Figure 8.
It seems our feedback loop t u r n e d out to be quite a
villain, p r o d u c i n g devastating effects, especially over the
long run. Notice that EXAMPLE1 was c o m p l e t e d in 51
months, while nine projects later, EXAMPLE10 com-
pleted in 81.25 months! A very significant deterioration
indeed.
The, surprising p h e n o m e n o n we observed is one that
has b e e n frequently e n c o u n t e r e d in system d y n a m i c s
studies of real organizations. It has b e e n t e r m e d "The
May 1983 Volume 26 Number 5
REPORTS A N D ART/CLES
80 - Actual
Project Duration
70 _
60
== /~// Project Duration
| 50
_//
/
/
40
30 I I I
I I I I I 1-
1 2 34
5 67 8 910 v
EXAMPLE i
FIGURE 8. Results of the Ten Simulation Runs.
Policy Resistance of Social Systems," "Shifting the Bur-
den to the Intervenor," and " A d d i c t i o n , " among other
things. A simple e x a m p l e of such a p h e n o m e n o n is that
of caffeine addiction, w h e r e b y an addict has to c o n s u m e
a certain a m o u n t of caffeine per d a y to m a i n t a i n a cer-
tain level of alertness. As time goes on the b u r d e n of
m a i n t a i n i n g alertness will keep shifting from the n o r m a l
physiological body processes to the e x t e r n a l l y supplied
caffeine dose. The result, of course, is that higher and
higher doses will be r e q u i r e d to m a i n t a i n the s a m e level
of alertness.
Forrester put it this way:
Social systems are inherently insensitive to most policy
changes that people select in an effort to alter the behav-
ior of the system. In fact, a social system tends to draw
I .. our attention to the very points at which an attempt to
intervene will fail. Our experience, which has been de-
veloped from contact with simple systems, leads us to
look close to the symptoms of trouble for a cause. When
we look, we discover that the social system presents us
with an apparent cause that is plausible according to
what we have learned from simple systems. But this ap-
parent cause is usually a coincident occurrence that, like
the trouble symptom itself, is being produced by the feed-
back-loop dynamics of a larger system [4].
opting for the most a p p a r e n t one, namely, that schedules
were too tight, might lead to relaxing the schedules.
However, this turns out to be quite ineffective in curing
5OOOO A n attractive feature of system d y n a m i c s models is the
can isolate the effects of factors we suspect are causing
the problematic behavior. By exploring the b e h a v i o r gen-
e r a t e d by i n d i v i d u a l feedback loops and by various com-
binations of loops in a model, the m o d e l e r can precisely
pinpoint the structure responsible for the behavior.
By c o n d u c t i n g such e x p e r i m e n t a t i o n w i t h our model,
we were able to identify the real cause of the persisting
s c h e d u l e o v e r r u n p r o b l e m in our m o d e l e d software de-
v e l o p m e n t project. It t u r n e d out to be a consequence of
the interaction b e t w e e n m a n a g e m e n t ' s h i r i n g / f i r i n g pol-
icy and the " e l u s i v e " n a t u r e of software errors.
W h e n deciding u p o n the n u m b e r of employees, m a n -
agement (in the model) takes into account the p e r c e i v e d
time r e m a i n i n g for the project. T o w a r d the end of the
Communications of the ACM 345
REPORTS AND ART~I.ES
project, for example, management would be very reluc-
tant to bring in new people, even though the perceived
time and effort remaining imply more people are needed.
It would just take too much time to acquaint new people
with the mechanics of the project, integrate them into
the project team, and train them in the necessary techni-
cal areas.
While such a policy may sound perfectly reasonable,
and may in fact be successfully employed in many areas
of managerial endeavour, it does pose certain risks (our
model reveals) when applied to the software develop-
ment area. As was mentioned in Sec. 3, not all work
done in the course of a large software project is errorless.
Some fraction of the work will be less than satisfactory
and must be redone. The unsatisfactory work is not dis-
covered right away, however. For some time it passes
unrecognized, until the need for reworking the tasks in-
volved shows up. When the unsatisfactory work does get
discovered, it usually causes major disruptions. The
problems, however, are particularly devastating when
this happens towards the end of the project, for example,
at system integration testing, when management (under
the above hiring/firing policy) is very reluctant to hire
new employees. When this happens, management will
have almost no other alternative but to extend the pro-
ject's scheduled completion date.
There is still, though, an interesting and as yet unan-
swered question: Why was the system so "unresponsive"
to the "schedule relaxing policy?" The answer is because
of the compensating property of complex societal sys-
tems. Changes in most (but certainly not all) parameters
in one part of such systems may weaken or strengthen
some feedback loop, but the multiloop nature of complex
feedback systems will, in most cases, "naturally"
strengthen or weaken other loops to compensate [6]. In
our particular software project situation, extending the
project's schedule weakens the strength of the schedule
pressure in the system, to which the hiring loop (for one)
simply compensates by causing the project to start with a
smaller workforce. For example, in EXAMPLE2, on the
basis of an estimated project duration of 51 months,
management starts the project with 32 people. When
supplied with the more generous and presumably more
accurate estimate of 56 months for EXAMPLE3, manage-
ment simply (and rationally) factors that in the decision
h~aking process, and then determines that a workforce of
29 people (1626 MM/56 months) is needed.
5. CONCLUSIONS
It is clear from the above discussion that viewing the
problem of software project scheduling as simply a prob-
lem of generating improved schedules is too limited a
view, and one which can in fact lead to a serious long
term deterioration in an organization's effectiveness in
ACM 84 San Francisco, California October8-10
3~,6 Communications of the ACM
managing its software projects. Our own research efforts,
as well as those of others, have convinced us that the
project management of software development is a very
complex undertaking in which a complex network of
interrelationships and interactions exists. It is, therefore,
essential that software project managers adopt an inte-
grative perspective or model of software project dynam-
ics in order to effectively answer the difficult questions
they need to raise when assessing their organizations'
health, selecting improvement interventions, and imple-
menting their choices. Such an integrative model would
be useful to alert managers to all the important elements
or aspects of a problematic situation, and to help them
assess the second- and third-order consequences of some
set of actions.
However, such an integrative model will undoubtedly
contain a large number of components with a complex
network of interrelationships: What would still be
needed is an effective means to determine both accu-
rately and efficiently the dynamic behavior implied by
such component interactions. We feel (and hopefully
have demonstrated) that the computer-based simulation
techniques of system dynamics can be a powerful tool to
do just that.
REFERENCES
1. Aaron, J. D. Estimating resources for large programming systems. Soft-
ware Engineering: Concepts and Techniques. Edited by J. M. Buxton,
P. Naur, and B. Randell. Litton Educational Publishing, Inc., 1976.
2. Abdel-Hamid, T. K. and Madnick, S. E. A model of software project
management dynamics. The Sixth lnt'l Computer Software and Appli-
cations Conference (COMPSAC), November 8-12, 1982.
3. Boehm, B. W. Software Engineering Economics, Prentice-Hall, Inc., En-
glewood Cliffs, New Jersey, 1981.
4. Forrester, J. W. Counterintuitive behavior of social systems. Technol-
ogy Review, January, 1971.
5. Putnam, L. H. Software cost estimation and life-cycle control: Getting
the software numbers. IEEE Computer Society, IEEE Catalog No.
EHO 165-1, 1980.
6. Richardson, G. P. and Pugh lIl, A. L. Introduction to System Dynamics
Modeling with Dynamo. The MIT Press, Cambridge, Massachusetts,
1981.
7. Roberts, E. B.,'Ed. Managerial Applications of System Dynamics. The
MIT Press, Cambridge, Massachusetts, 1981.
8. Thayer, R. H., Pyster, A. B., and Wood, R. C. Major issues in software
engineering project management. IEEE Trans. on Software Engineer-
ing, July, 1981, pp. 333-342.
9. Weil, H. B. Industrial dynamics and management information systems.
Managerial Applications of System Dynamics. Edited by E. B. Rob-
erts. The MIT Press, Cambridge, Massachusetts, 1981.
CR Categories and Subject Descriptors: D.2.9 [Software Engineering]:
Management--cost elimination; K.6.1 [Management of Computing and
Information Systems]: Project and People Management--management
techniques
General Terms: Management
Additional Key Words and Phrases: software project scheduling, com-
puter simulation, system dynamics
Received 6/82; revised 9/82; accepted 10/82
May 1983 Volume 26 Number 5