Document 11049642
advertisement
NOV 12 1987
7
6^StWtNT•
MODELING THE DYNAMICS OF
SOFTWARE PROJECT MANAGEMENT
TarekK. Abdel-Hamid
Stuart
E.
Madnick
September 1987
CISRWPNo. 163
Sloan
WP No.
1935-87
Center for Information Systems Research
Massachusetts
Institute of
Sloan School of
Technology
Management
77 Massachusetts Avenue
Cambridge, Massachusetts, 02139
^
MODELING THE DYNAMICS OF
SOFTWARE PROJECT MANAGEMENT
Abdel-Hamid
Stuart E. Madnick
Tarek
K.
September 1987
CISRWPNo. 163
Sloan
*
WP No.
1935-87
1987 T.K. Abdel-Hamid and
S.E.
Madnick
Submitted for publication to the Communications of the
Center for Information Systems Research
Sloan School of Management
Massachusetts Institute of Technology
ACM
•
?
TTS-vii*^
^^riM
'\
l\W
RtCE^gL
MODELING THE DYNftMICS OF SOFTWARE PROJECT MANAGEMENT
Summary
development of software has been marked by the problems of cost
poor reliability, and users' dissatisfaction
late deliveries,
which continue to persist in spite of the significant advances that have
been made
in
the software engineering field to tackle the technical
hurdles of software production.
The objective of this paper is to enhance our understanding of, and
gam insight into the general process by which software development is
managed by integrating our knowledge of its multiple activities into an
integrated continuous view of the software development process.
The model
is
currently being used as an experimentation vehicle to
study/predict the dynamic implications of an array of managerial policies
and procedures pertaining to the management of software projects.
The
overruns,
cost-effectiveness
the
number
economical
the
estimate
that
applications
continuously
operation
and
is placing greater and greater demands for
increase
in
record
shows
overruns,
late
[(Buckley
and
the demand for software has not,
in
deliveries,
Poston,
conservative
(Musa,
however,
1985).
been painless.
development of software has been marked by cost
the
that
fl
the demand for software each
or a hundred fold increase between 1965 and 1985"
growth
made in the
enormous expansion in
of computer software systems,
"tenfold
a
ar\
being
which computing is becoming a feasible and
for
This in turn,
solution.
are
computer hardware are causing
of
indicates
This
The
of
development
decade,
improvements
impressive
The
poor
1984),
reliability,
(Ramamoorthy
et
and
al.,
users'
1984),
dissatisfaction
and
(Newport,
1986)].
In
attempts
and
effort to bring discipline to the development of software systems,
an
have
engineering
significant
been made since the early 1970s to apply the rigors of science
to
progress
the software production process.
has
been
made
over
the
On the technology side,
last decade,
leading to the
2
of a large number of methodologies
d»v»lopm«nt
structured
and
compilers,
diagnostic
coding,
verification,
formal
design,
so
language
forth)
structured programming,
(e.g.,
design for more reliable
address
that
many
of
the
t*?t!Di?§i problems experienced in software development.
evolution
comparable
fi
[(Zmud,
1980)
on the managerial front has not occured, however
(Beck and Perkins,
and
1983)].
Software engineering project management (SEPM) has not enjoyed the same
progress
the technology of software development). While it might be
(as
argued that SEPM has been defined, it is far from a recognized discipline
...
The major issues and problems of SEPM have not been agreed on by the
priorities for
whole,
and consequently,
community
as
a
computing
addressing them have not been widely established. Furthermore, research
in this area has been scant (Thayer et al., 1981).
substantiated by a survey, reported in the same
revealed that only a handful of U.S.
which
paper,
is further
position
This
universities offer courses
in the area of software project management.
"deficiency" in the field's research repertoire is being blamed by a
This
number
growing
difficulties
meets
in
fundamental
lack
a
that
without
address
such
of
understanding
Gehring,
1960),
(Thomsett,
1960),
and
expressed is that, as of yet, we still
the software development process,
the
and
or likelihood of any
possibility
1962)
and
1963)].
paper
the
comprehensive
use
concern
understanding
an
and
gains on the managerial front is questionable [(Basili,
significant
This
such
[(Pooch
chief
P
and practitioners for the B§CiiiiiD2f o^ our
software that is on time, within budget, and that
producing
1982)].
(Weinberg,
researchers
requirements
user
(McKeen,
of
a
reports the results of an ongoing research effort designed to
above
concerns.
mathematical
model
as
Specifically,
model
it
is
our
goal
to develop a
of the software development process and to
a laboratory vehicle to study,
gain insight into,
and
2
make predictions about the software project management process.
parts
remaining
the
In
dynamic
integrative
developed.
arguments
for
presentation,
our
begin
We
present
we
and
management
project
discuss
the
has been
that
will provide an overview of both the model's structure and its
We
behavior.
software
of
model
paper
this
of
however,
first
by
presenting
the
utility of such a formal dynamic modeling approach in the
the
study of software project management.
Ibg_bi3b_Q9™Bi§><it^_2f_tbi_i9ftyi!2§_E!22Jf£t_M§nagement_Process
management
Project
captured
portrays
model
(1)
resources
project
accomplished
completion
forecast
remaining
out
be
the
on
time
job.
loop
completed
IS
adjustments
What
is
simple.
wield.
But
management?
(6)
date
is
(3)
equipment).
Ps
(£)
work is
through some project control
(4)
project's
in man-days)
(e.g.,
the level of manpower working on the
productivity
as
and
the
of the project team.
difference,
the
(4)
believed by management to
forecast
if
any,
The feedback
between the
completion
date
(5)
causes
in the magnitude or allocation of the project's resources.
attractive
It
The
to the current date the indicated time
the project,
(closed)
completion
scheduled
1981).
(Roberts,
Assessing the job's remaining time involves figuring
perceived
the
and
is reported
adding
by
complete
to
project,
and
it
the magnitude of the effort
remaining
1
cumulate and are processed to create the
reports
Such
system.
in Figure
facilities,
(manpower,
the project,
on
shown
model
work is accomplished through the utilization of
project
how
based simpl istically on a "mental picture"
is
single-loop
the
by
often
therefore,
is,
it
about
an
adequate
the above model is that it is both reasonable
a
mental tool that is not too difficult to
model
for the dynamics of software project
(5)
SCHEDULED COMPLETION
DATE
(1)
(61
PEOPLE i OTHER
PROJECT RESOURCES
RESOURCE CHANGE &
ALLOCATION DECISION
(2)
WORK RATE
REPORTED PROGRESS
FORECAST COMPLETION •*DATE
(3)
(4)
FIGURE (1)
A MODEL OF SOFTWARE PROJECT MANAGEMENT
4
•oftw«r« project management system is
Th»
of
fashions.
environment,
softwar*
some
excluding
By
that
variables
interdependant
above
the
manager.
could
model
interrelated
aspects
vital
see how,
To
are
far more complex conglomerate
a
of
seriously
the
in
various
nonlinear
real software project
misguide
the
unsuspecting
us consider some of the typical decisions
let
pondered in a software project environment.
6ddiD9
suggests
the
a direct
rate
resources
the
world
on
higher
the
has
i§t§
§
B!29Ji?t!
The mental picture of Figure
1
relationship between adding people resources and increasing
work
of
1°
Bi9Bii
!!!2!2§
the
the
many
led
project,
the higher the level of project
i.e.,
work rate. Subscribing to this simplistic view of
a
software
manager into serious trouble (Brooks,
1978).
For
example,
one
vital
manager
can
afford
software
Figure
known
"Brooks'
as
project
makes
project,
which
productivity
project
Law",
dynamics that no
ignore is captured by the feedback loop of
to
leads
to
higher
can
in
turn
adding more people to a late software
that
i.e.,
later (Brooks,
it
often
people
project
portrays some of the dynamic forces that create the phenomenon
It
2.
software
of
aspect
1978).
fis
the figure indicates,
communication
adding more
and training overheads on the
the project team's productivity.
dilute
Lower
translates into lower progress rates, which would delay the late
even
further.
This
turn
in
could
trigger an additional round of
workforce additions and another pass around this "vicious cycle."
Figure
In
link
between
3a
the
we,
therefore,
workforce
level
amend Figure
(and
the
1
by incorporating the vital
associated
communication and
training overheads) and productivity.
ttli_i£!l!§dyii_2f_§_U§t§_E!!2J§9t' Another part of the real system
ftdjusting
ignored
The
by
Figure
attitudes
and
1
is the human element
motivations
of
in project actions and decisions.
software
developers and their managers.
Product!
Progress
Rate
vi
ty
Communication &
Training Overheads
(5^
Workforce
Hi r 1 ng
Fi
S<
qure
Fin ng
(2)
EXAMPLE FEEDBACK LOOP
ICNXSUUE CaiMITION
bATI
CKAJiCt
RTOOLTICT
4
rtOfU.
.
4
OTHtX
PROJtn Msoinicrs
ALLOCATION DICISIOK
/
/
/
/
\
\
\
WORX RATI
RZPORTri PkOCRtSS
LATl
(a)
scMtDULi: conriXTiCM
CAT!
Kt%C'J!>'n
aul(>:at:on
\
CHAHOt
FTCriE 4 OTHr«
4
dicieio
fkZ^tn MiOL'RCEi
\
tChODULI
COrff JTICW
ItATI
rORICx£T
PRODUCT! VI IT
kiposrt: PKXRiss
•^-
(b>
REFINEMENTS TO THE M3DEL OF SOFTWARE PROJECT MflN«GEMENT
(CHXDULSC COnPLITION
UTt
n^Flt » OTHtR
PfcCtCT RISOySCE'
PRODUCT vir>
I
RiPCRTi: ntocust
(c)
SCMlDCLlr Curr.ITlO
'tC'l Lt
i
roMCAS- coruTiih*
tATI
Id;
EiSyCi-lil
iAfc/u;jkT
(continued)
i
CTHrk
s
.
the
affect
real
and current estimates in the project,
the schedules,
of
knowledge
their
that
progress
achieved,
is
all
well as the progress and
as
problems that are reported upward in the organization.
For
behind
falls
1978).
(Ibrahim,
on
and by concentrating more on the essential tasks of the job
one
In
experiment,
Boehm (1981) found that the number of
devoted to project work increased by as much as lOOX. Most of this
man-hours
gain
faced with schedule pressures that arise as a project
schedule, software developers typically respond by putting
its
hours
longer
in
when
example,
by reallocating people's slack time by spending less time
achieved
was
activities
off-project
such
as
personal
business,
coffee
breaks,
non-project commmunicat ion.
This
Figure
link
schedule
Does this mean,
3b.
adjusting
between
the
then,
pressure
and
productivity
is captured in
that software managers need not worry about
schedule of a late project and should rely,
instead,
on simply
maintaining the pressure on their project teams?
to
The
impact
the
above
visible
roles.
increase
the
the project
of
schedule pressures on software development is not limited
relatively
For
direct role. Schedule pressures can also play less
example,
as
Figure 3c suggests, schedule pressures can
error rate of the project team and thus the amount of rework on
[(Radice,
1982)
and
(Mills,
1983)3.
People under time pressure don't work better, they just work faster ...
In the struggle
to deliver any software at all, the first casuality has
been consideration of the quality of the software delivered (DeMarco,
1982).
The
the
rework
necessary
to
correct such software errors obviously diverts
project team's effort from making progress on new project tasks,
and thus
can have a significant negative impact on the project's progress rate.
Alto,
rate
contldtr
(Figure
3c).
tht impact of schedule pressure on the workforce turnover
There
is
evidence
to
suggest
that workforce turnover
6
increases
when
organization
unreasonably
(Freedland,
tight
scheduling
can
This
1987).
situations
persist
quite costly, since
be
in
a
an
higher
turnovtr ratt tr«nil«t«i into low»r productivity on the project.
Hoe
EiD§ii^i
manager
back
can
succeed
track
on
imperative
development
difference
progress
between
is
for
that
Before
"5
software
a
lagging software project and bringing
it
adjusting
is
the
schedule,
etc.,
it
of the magnitude of the delay be on target.
an
lack
intangible
of
during
product
visibility
achievement
real
error
an
(Figure
real
too
the
extent
rate,
accumulate
This
process.
the
To
job.
basically
is
a
people,
assessment
the
that
is_a_Late_Sgftware_Proj.ect
rescuing
in
adding
by
software
But
Late
Bi§iiy
can
produce
most
a
of
the
significant
and the B§C£§iy§d progress on the
the perceived progress rate differs from the real
in
perceived
cumulative
progress will gradually
This undoubtedly poses yet another complication that
3d).
software project manager to exclude from any model or
the
analysis of the process.
8_y§§^_f9!2_§D_l!l!ii9!2§*i^§_B§!!iB§?li^§_2f_Softwart_Devel^OBment
above
The
Furthermore,
another
one
behavior
such
of
major
has
components
of
measurement,
fashions.
systems
been
the
and
there
are
a
is
number of
that impact the software development
Perhaps most importantly,
complex
large
far
beyond
the
but are related to
understanding the
capacity
of human
1981).
deficiency
management
total
that
these variables are not independent,
in complex
intuition (Roberts,
ft
illustrates
both tangible and intangible,
variables,
process.
discussion
much of the research to date on software project
in
its
inability
to integrate our knowledge of the micro
software development process such as scheduling,
staffing
socio-technical
to
system
progress
derive implications about the behavior of the
in
which
the
micro
components are embedded
"
7
1979).
(Thayer,
words
the
In
phases
individual
attention
on
sequence,
but
the
on
little
Jensen and Tonies (1979): "There is much
of
and
functions
of the software development
whole
lifecycle
as
an integral,
continuous
process.
The
perspective.
process,
second
ft
web
management
taken
by
Examples
been
through
The
integrative
functions
(e.g.,
planning,
or
modeling
our
approach
is the use of the
variables
projects.
thing
involved
in the development and
Feedback is the process in which an action
will
eventually affect that person or thing.
systems in the software project environment have
feedback
demonstrated in the above discussion and are evident in Figures
3.
significance
managerial
(Roberts,
an
System Dynamics to structure and clarify the complex
interacting
software
such
of
feature
of
person
of
already
1
unique
of
a
such
reviewing, testing).
dynamically
of
provides
as well as the software production-type activities (e.g.,
principles
feedback
paper
management -type
the
both
staffing)
coding,
this
in
integrates the multiple functions of the software development
It
including
control,
design,
presented
model
systems
and
has
applicabilty
been
For example,
1981).
of
substantiated
the
by
feedback systems concept to
a
large
number of studies
Weick (1979) observes that,
The cause-effect relationships that exist in organizations are dense and
often circular.
Sometimes these causal circuits cancel the influences of
one variable on another,
and sometimes they amplify the effects of one
variable on another.
the network of causal relationships that
is
It
impose many of the controls in organizations and that stabilize or
disrupt the organization.
It is the patterns of these causal links that
account for much of what happens in organizations. Though not directly
these causal
patterns account
for more of what happens in
visible,
organizations
than do some of the more visible elements such as
machinery, timeclocks, ...
of
The
third
the
computer
distinctive aspect of our modeling approach is the utilization
simulation
tools
of
System
Dynamics
to handle the high
a
complexity
of
tven
•ntlyiii,
reasonably
complex
point!
feedback
The
implications
structures
(Richardson and Pugh,
describing
portion
For
paper.
Madnick,
1987a)].
of
software
projects; that
is,
once
such as choice of programming language.
is
intended
research
behavior
decided
of
a
productivity
intended
project
change
model's
otherwise
mental
time
rather than
throughout the
constant
how
time
yD^i!Z§t§!I}^iDS
variables
like
why)
rather
and
°^
*^b dynamic
workforce-level
than
to
and
provide
of the number of errors generated).
the
review,
model
developed based on field studies and a
was
a model
is,
by definition,
a
simplification.
Thus
value ultimately depends upon its ability to help us understand an
overly
model,
the
provide
to
(e.g.,
over
although
literature
careful
and
This is particularly relevant because this
accomplish.
to
E2i!2tzE!!§^i£ti2Di ^s. g.,
Fourth,
and
1984)
necessary to have a perspective about what the model is and
primarily
is
(flbdel-Hamid,
aspects that change during the
remain
then
project,
it
C
such as workforce level and productivity,
project,
are
there are several
the focus of this research is on
Second,
that
not
of real problems are often so
the reader is referred to
and
the
Third,
isolated loops may be
entire modal can be presented and explained in this
th*
of
aspects
a
The behavior of
due to its length and complexity
First,
details
di;nami^cs
of
of
the model and experiments performed,
more
(flbdel-Hamid
IS
model.
1981).
that are important to clarify.
A
life
feedback
the behavior they generate over time can usually be traced only
that
Before
dynamic
the
though
obvious.
by simulation
the
integrative
of interconnected feedback loops often confounds common intuition and
systems
only
resulting
the
a
complex
situation.
Specific
benefits
are
that unlike a
System Dynamics simulation model can reliably trace through
implications
of
a
messy
maze
of
assumptions and interactions,
"
9
without stumbling over phraseology, emotional bias,
dynamic
integrative
Our
developed
of
basis
the
on
battery
a
software
of
model
or gaps in intuition.
project
management
was
27 field interviews of software
of
managers in five software producing organizations, supplemented by an
project
extensive
depicts
database
model's
four
Management
Subsystem;
(2)
Controlling
Subsystem;
the
findings
empirical
of
and
namely:
subsystems,
Software
the
(1)
Production
Planning
the
(4)
the
from
literature.
Figure 4
Human
Resource
the
Subsystem;
Subsystem.
The
(3)
the
figure also
illustrates some of the interrelationships among the four subsystems.
ThB_Human_Resource_Management_Subs^5tern:
Human
The
assimilation,
System
in
systems
can
Management
Subsystem captures the hiring, training,
and transfer of the human resource,
conventions
schematic
The
used
Resource
Dynamics
represented
is
an
5.
used in Figure 5 are the standard conventions
models.
be
as shown in Figure
in
From
terms
a
of
System
Dynamics perspective all
"level," "rate," and "auxiliary"
variables.
^
i§Y§i
changes
to
that
accumulation,
or
an integration, over time of flows or
come into and go out of the level.
The term "level" is intended
invoke the image of the level of a liquid accumulating in a container.
flows
increasing
WORKFORCE"
is
a
below,
and
level
of people that
Thus,
"NEULY HIRED
is increased by the "HIRING RATE" and
"WORKFORCE RSSIMILflTION RATE.
decreased by the
Rates
and decreasing a level are called rates.
The
levels
are
represented as stylized valves and tubs, as shown
further emphasizing the analogy between accumulation processes and the
flow of a liquid.
1
/
/
/
/
PR03RESS
STATUS
'
/
/
^
•VCRACE
AvcniOC
0€l*t
aSSIHIt. AllON
eui'LOtutNi
MlREOY
Otl «»
—
o
o
HIRER!
liUL
ASIMDY
^
VVFNtW
HI WLT
MIHtO
WOHKFOACt
i
Avi
—
S
wrfxp
flPCHlENCfO
WONkFORCC
aSlMRT
OUITHI
l»0*t»KJ«Ct
(
NE WTRR
NfWlT HtRCD
IRANSflR RlIC
\
ExPTRR
\^.
[ipcriEnCCD
\l tR»Nif{M Hkll
.-t)^
IRNSDT
IHlNSKR
DtL*t
ouii RAie
RAIE
/
IRNSOT
T,^
o
IR*NSFE.II
V
riou''e 5
MPT
*FNf fO
«0««fORCt
)
10
^
LEVEL
RATE
The
flows
diff»r»ntly,
that
RfiTE
are
d«p»nding
controlled
the
rates
are
usually diagrammed
on the type of quantity involved.
We will use the two
by
types of arrow designators shown below:
INFORMftTION FLOUS
OTHER FLOWS
(e. g.
fill
,
People)
variables are either levels or rates,
tangible
flows
are
presently
i.e.,
they are either
flowing.
Auxiliary
accumulations
of
previous
variables,
the
other hand, are information-type variables in the system,
and
on
or
capture things like concepts (e.g., the concept of a "WORKFORCE GPP") and
policies
(e.g.,
the
policy
for allocating "DAILY MANPOWER FOR TRfllNIING").
Auxiliary variables are represented by
a
circular symbol.
11
variables
Finally,
are
that
defined
in other sectors of the model
are
represented by enclosing the variable name in parentheses as shown below.
FROm\
/VORIfiBLE
\
that the project's total workforce in Figure 5 is comprised of two
Notice
workforce
Disaggregating
employees
necessary
is
productive
the
HIRED
WORKFORCE"
workforce
for two reasons.
these
into
First,
and
"EXPERIENCED
categories
two
of
newly added team members are
the average) than the "old timers"
(on
Secondly,
1980).
"NEWLY
namely,
levels,
WORKFORCE."
less
ONOTHER sector/
(Cougar and Zawacki,
allows us to capture the training processes involved in
it
assimilating the new members into the project team.
On
deciding
consider
be
completion
discussed
believes
would
completion
the
stability
the
the
hand
tht
even
workforce
of the project,
the
project managers
fis
is the current
part of the planning subsystem
management determines the workforce level that
to
complete
In addition to this,
of
level desired,
One important factor, of course,
necessary
Different
general,
changes
total
workforce.
it
the project within the scheduled
however, consideration is also given to
Thus,
before adding new project members,
typically contemplates the duration for which the new members will
needed.
one
date
later),
be
time.
management
be
the
number of factors.
a
scheduled
(to
upon
with
project
though
organizations weigh this factor to various extents.
In
relative weighing between the desire for workforce stability on
and
the desire to complete the project on time, on the other,
the stage of project completion.
th«r«
the
could
time
and
For example, toward the end of
b« considerable reluctance to bring in new people,
effort perceived remaining might imply that more
12
«r»
paopl*
there
wouldn't
just
mechanics
the
of
reluctance
This
needed.
enough
be
would
time
acquaint
to
integrate
project,
arise from the realization that
the new people with the
them into the project team,
and train
them in the necessary technical areas.
Figure
model.
depicts
It
behavior
1983).
demonstrates
6
model's
the
output
that
by
(Abdel-Hamid,
198A).
that
proceeds
towards
workforce
level
NASA's
was
slippages
were
accepted
peaks,
That
project
to
translated,
as
project's
actual
here
the
in
differs
literature,
from
i.e.,
behavior
the
"typical"
the concave type
and then drops back to lower levels as the project
1981).
The reason why the
to the completion of the DE-A software,
overrode
that
management
avoid
before
days
90
serious schedule
Specifically, all software was required to be
tolerated.
not
developed
necessary
the
scheduling constraints. Because NASA's launch of the DE-A
tied
pressures
is,
(NASA,
here shoots upwards towards the end of the project has to do
frozen
and
the DE-fl software project
system testing phase (Boehm,
the
tight
satellite
discussed
as
rises,
to
pattern
workforce
the
pattern
workforce
from simulating the
points in the figure), as is documented in detail in
the
that
accurately
quite
(represented
Notice
resulted
Appendix for more details on the DE-A project.) The model's
the
conformed
r«»ulti
with
kinds of dynamic behaviors reproduced by the
of one of NASA's software projects,
(See
curve
the
launch.
the
As this date was approached,
workforce stability considerations.
became increasingly willing to "pay any price"
overshooting
the figure indicates,
the
90-day-before-launch
date.
This
into a management that was increasingly
Milling to add more people.
The_Sof t war e_Production_Sub5y stem
The
four primary software production activities are: development, quality
assurance,
rework,
and
testing.
The development activity comprises both the
-
—
«
r« r^
CI
Oi
^
tl
3 3 3 3
u u u u
ooo^
,
(
1
)
SCHEDULED COMPLETION
DPTE
(2)
ESTIMOTED C'RDJECT COST
IN MftN-DAYS
C*
O
i—1—
*A (%
^-"
O O
— "^
.^^s— ^Mi
1^ sC
.-.
o
,'^
®'
limn
M
C)
bctuol fbqction op
md on project
UORKTORCE
(PEOPLE)
100
200
DESICN- PiJkSE
300
CODING PHASE
-T"
380
TESTING^
TIME (Davs)
^
^
®
DE-0' s actual
DE-P' s act ual
DE-P' s actual
D? VE
"SrHEDULED CDMP'LETION DPTE
"ESTIMPTED PROJECT ZOST IN MPN-DPYS"
"WORKFORCE" (Full-Tirne Equivalent People)
(
FIGURE 6
!
OUTPUT FOR MODEL OF NASA
DE-fi
SOFTWARE PROJECT
13
design
of the software,
coding
and
fls
the software is developed,
it
is also
structured walkthroughs) to detect any errors.
Errors
reviewed
(e.g.,
detected
through such quality assurance activities are then reworked. Not all
errors
using
detected and reworked, however. Some "escape" detection until the
get
testing phase.
The
Software
space
limited
overview
this
paper,
rather
but
the total subsystem we Hill,
of
structure
of
Production Subsystem is too complex to fully explain in the
of
one
subsystem's
the
of
than
provide just
a
high level
instead, discuss in some detail the
important
components,
the
namely,
structure that captures the dynamics of software productivity.
model's
The
IS
based,
psychologist
in
productivity structure is depicted in Figure
software
part,
Ivan
on
a
Sterner
model
of
(1972).
group
Steiner's
productivity
proposed
7.
It
by the
model can simply be stated as
follows:
Octual
Productivity
=
Potential
Productivity
-
Losses Due to Faulty
Process
where
losses due to faulty process basically refer to a group's communication
and motivation losses.
Paraphrasing Steiner (1972):
Potential
productivity is defined as the maximum level of productivity
that
can occur when an individual or group ... makes the best possible
use of its resources (that is, if there is no loss of productivity due to
faulty process)
...
Potential
productivity can be inferred from a
thorough analysis of task demands and available resources, for it depends
only upon these two types of variables. Actual productivity, what the
individual or group does
in
fact
accomplish, rarely equals potential
productivity.
Individuals and groups usually fail to make the best
possible use of their available resources.
Problems of coordination
and/or motivation are responsible for inadequacies in process, and for
consequent losses in productivity.
1
/WFEXP
\
NPwPNE
^•OOUCTIVI T T - t «»
NPWPEX
/WFNEW
\
o
KHAUSTlON
OtL*'
•"»»£
EXMDDT
'pi
I
£XM_rv
tlHAuStlON
C* »<<OjtCT
1
I
'MOOTPO
AFMDPJ
0' i
M«S-DAT
ON ••OjECT
/
'<
pjBa*k
•/.
\
0' JOB
NC'v»vOT
Ov{»«rO<»«
'"•€SxO,.0
F
1
qu
>-
e
7
SOFTWftRE PRODUCTIVITY SECTOR
-~-^
.
14
according
Thus,
sets
effects
Botential productivity 15 a function of two
the
of
task
and the group's resources.
The
of various factors belonging to these two sets of determinants on the
productivity
software
of
literature.
siz*
nature
the
factors,
of
Sterner,
to
These
(examples
availability
development
factors
include
task-type
of
software
of
have
been widely investigated in the
such
as product complexity and database
variables)
and personnel capabilities and the
development
tools
(examples
of
resource-type
variables)
Notice
while
that
most
organization
to organization
capability,
and
within
project
size,
throughout
a
dynamic
and
from
personnel
project
to
product complexity, database
(e.g.,
software
tend
would
role.
Thus,
any
of
of
this
for
one
Bi!;ticul.ar project.
discussion.
It
This
means that in
patterns of software productivity during the lifecycle
dynamic
Bitzticyiar
life
significant
quite
is
the
variables
remain
to
which
project,
constant
representing
in
our
is
and,
concern here,
the above
therefore, would not play a
the dynamics of software productivity
the life of a software project such factors could be captured by a
throughout
single
development
the
observation
of
characteristics)
organization
single
factors would tend to vary from
availability of software tools,
(e.g.,
computer-hardware
a
above
the
programming language) they, however, would tend to remain constant
and
studying
of
invariant paramter.
In our model this is termed the "NOMINfiL POTENTIAL
PRODUCTIVITY" parameter.
Not
determinants
all
non-dynamic
dynamic
increases
(Weinberg,
nature.
role
in
are
EQliDtiii pi'oduct ivity are, however, of such
a
Two variables identified in the literature that do play a
the
project
1982)].
of
workforce
familiarity
experience
due
to
level
learning
(Chrysler,
1978)
and
[(Shell,
1972)
and
These dynamic variables are captured in Figure
7.
15
Due
actual
rarely
in communication and motivation overheads,
equals
potential
productivity.
Communication
ii th» drop in th» productivity of the average team member caused by
losses
of
incurred
losses
productivity
ov»rh»«d
the
the
to
the
incurred
in
relationship
investigated
communicating with others on the project. The nature
between
several
by
communication
authors.
For
overhead and team size has been
example,
it
has been suggested that
2
communication
overhead
of the team [(Brooks,
(Zelkowitz,
proportion
1978),
to n
,
where n is the size
and (Shooman,
1983)].
same distinction mb made above between factors that remain constant
the
during
of any one particular project and those that tend to change
life
the
throughout
in
1978),
in
understand the effects of motivation losses on productivity we need to
To
make
increases
the
life of a project.
literature
the
responsibility,
organizational
setting
factors
be
would
for
possibility
(e.g.,
and salary)
Many of the motivational factors discussed
growth
and
advancement,
are factors that tend to characterize the overall
climate.
and
implicitly
formulation, such non-dynamic
our
In
within
incorporated
the
definition
of
the
potential productivity parameter.
On
the
throughout
other
the
motivational
to
expand
fraction
goals and schedules play a dynamic motivational role
hand,
life
of
a
software project. Boehm (1981) suggested that the
role of schedule pressures and project deadlines is specifically
or
contract
the project members'
"slack time." Slack time is the
of project time lost on off-project activities, e.g.,
coffee-breaks,
personal business, and non-project communication.
The
impacts
motivation
of
mechanism in the model captures such dynamic motivational
schedule
pressures
pressures
the
fraction
full-time
team
member
"NOMINAL
FRPCTION OF
ft
of
to
on
daily
"slack time." In the absence of schedule
hours
allocated
(on
the
average)
by a
project-related work is captured by the parameter
MftN-DftY
ON PROJECT.
"
Several studies indicate that the
1&
value
to
lies
Gehring,
and
(Pooch
1378),
value
parameter
this
of
within
the 50-70X range [e.g.,
and
1980),
implies that an employee allocates,
the
amounts to
^0% cut
a
an
S-hour
in potential
on the average,
For example,
0. 6
X
8 = 4. 8
schedule
to
both
a
hours
productivity.
of course,
throughout the life of the project. The motivational effects
constant
of
a &0-A
Under such conditions, the loss
day).
lost In productivity du« to motivational factors does not,
Th»
remain
(assuming
project
1981)].
(Boehm,
see (Brooks,
pressures can push the "PCTyflL FRfiCTION OF
ft
ON PROJECT"
MfiN-DfiY
higher value (under positive schedule pressure) as well as a lower
value (under negative schedule pressure).
developers
to
what
typically
physically)
continued
the
deficit,
1984),
and
and to bring the project back on
(Ibrahim,
1978)].
rate.
not
based on our own field study results,
answer,
1984).
(fibdel-Hamid,
employees
long
was
Our findings indicate that there is a
would
willing
be
to
work
at
an
other words, workers need their slack time and they
In
tolerate
a
prolonged deprivation of such "breathers."
slack time, therefore, exhausts them (psychologically more so than
the
in
sense
over-working.
model
interested
Madnick,
The
how
would
Compressed
in
no
for
"above-normal"
software
up in a late project,
build
such a situation persists? Would workers be willing to work
indefinitely''
threshold
(DePree,
1981),
if
overwhelmingly
perceived
the
for
schedule [(Boehm,
But
pressures
to work harder by compressing their slack time in an attempt
tend
compensate
harder
schedule
positive
When
is
reader
1987a).]
[ft
devoted
should
that
it
cuts
into
their
tolerance
level for
significant portion of the productivity structure
to
refer
handling these intangible dynamic forces. The
to
(ftbdel-Hamid,
1984) or
(flbdel-Hamid and
17
dynamic behavior of the "ACTUAL FRACTION OF A MAN-DAY ON PROJECT" for
The
is depicted in Figure 6.
the
DE-A
the
end-of-development
happens
project
need
we
started,
"new"
project's
Figure
(in
To
understand
why
this
that when project DE-A
6)
underestimated its true size by 45X. As the project
had
job tasks were discovered causing upward adjustments in the
scope
man-day
the
approached.
is
observe
to
first
management
developed,
milestone
Notice the "spike" that occurs as
measured in man-days. As is typically the case, however,
as
adjustments made were not quite enough. This created a deficit
in
the project's man-day allocation which only became visible towards the end
of
the
development
when the development work was almost finished and
phase
the man-day budget was almost used up.
As
working
track.
man-day
the
harder
translates
This
the
the
in
model into the higher values of the "ACTUAL
FRACTION OF A MAN-DAY ON PROJECT" as shown in Figure
But
as was explained above,
maintain
an
exactly
what
above-normal
work
That
6.
project teams are not,
rate
is,
willing to
On project DE-A this is
indefinitely.
the
in general,
persistence
the
of
work
backlog
overwhelms the workforce's intensified efforts, and around day 300
eventually
arrangements
project
happened.
project's team reacted by
hours in an attempt to bring the project back on
longer
and
visible
became
deficit
were
deficit
made
with
management
project
to
handle
the remaining
through adjustments to both the project's man-day budget and
its schedule.
I!lli_Q2!2t!!9i_iyk§^5t.§!D
made
Decisions
information
is
actually
available
information
variables
it
Apparent
in
is
represents.
conditions
may,
any
organizational
available
to
inaccurate,
The
the
i.e.,
information
therefore,
setting
decision
not
are
based
on
what
«aker(s). Often, this
identical
may be late,
to the primary
biased,
and noisy.
be actually far removed from the actual
IS
or
depending on the information flows that are being used and the
true state,
amount of time lag and distortion in these information flows.
True
variable
true
the
needs
to
productivity
that
accomplished
difficult
true
date
to
values
and
study
measured
team
is a good example of a
To know what
the total amount of project work
both
expended.
however,
This,
can be
to evaluate because the software product remains largely intangible
then,
process.
measured
progress
is
corroborate
findings
progress,
of
resources
the
during most of the development
How,
project
productivity is at any point in time in the project, one
of
the
know
software
a
often not knowable by members of the project.
is
value
of
especially
in
those
the
a software project? Our own field
in
reported
earlier
in the
phases
of
literature,
software
that
namely,
development,
is
by the rate of expenditure of resources rather than by some count of
accomplishments.
example,
For
perceived
budgeted
would
be
expended;
and
when
complete,
etc.
50
a project
as
man-days
being
are
for which a total of 100 man-days is
10%
complete
expended
it
when 10 man-days are
would be perceived as
50?4
IS essentially impossible for the programmers to estimate the fraction
What is A55C of a program? Worse yet, what is
the program completed.
A55C
of three programs'" How is he to guess whether a program is ^0% or 30%
complete''
The easiest way for the programmer to estimate such a figure is
of time actually spent on the task to date by the
to divide the amount
time budgeted for that task. Only when the program is almost finished or
is
almost
when the allocated time budget
used up will he be able to
recognize that the calculated figure is wrong (DeMarco, 1982).
It
of
This
surrogate
for
measuring
project
progress
has
some
interesting
implications
on how management assesses the project team's productivity.
progress
in
the
tl),
measured
is
earlier phases of software development
by
(call
the rate of expenditure of resources,
it
When
time period
status reporting
:
19
ends
PERCEIVED
"MftN-DfiYS
conditions,
more
nothing
being
up
than
echo
an
of the original plan.
STILL NEEDED FOR NEW TfiSKS" (MDPNNT)
becomes,
That
is,
under such
equal to the "MPN-DfiYS PERCEIVED REMfilNING FOR NEW TASKS"
simply
(MDPRNT)
= MDPNNT
MDPRNT
tl
tl
PERCEIVED
"MflN-DPYS
But
(implicitly
if
REMfilNING"
(TSKPRM)
productivity,
explicitly)
the
NEW
value
manager's
the
by
value
the
to
equal
divided
by
i.e.,
That
(PRDPRD).
not
FOR
NEEDED
STILL
TfiSKS"
(MDPNNT)
is
"TASKS PERCEIVED
of
notion
of
the
team's
"PERCEIVED DEVELOPMENT PRODUCTIVITY"
of
is,
MDPNNT
=
TSKPRM
/
PRDPRD
tl
tl
tl
Substituting MDPRNT for MDPNNT, we get
MDPRNT
=
TSKPRM
tl
/
PRDPRD
tl
tl
which leads to,
PRDPRD
=
TSKPRM
tl
This
IS
measure
would
progress
TASKS"
interesting result.
divided
(TSKPRM)
(MDPRNT).
tasks
remaining
by
they,
by so doing,
their productivity equals "TfiSKS PERCEIVED
the
"MfiN-DftYS
PERCEIVED REMfilNING FOR NEW
What makes this interesting is the fact that such an assumed
productivity
for
MDPRNT
by the rate of expenditure of resources,
i!5Eiicitl_^ assuming that
be
REMfilNING"
value
an
/
tl
tl
For, it suggests that as project members
and
solely
is
a
function of future projections (i.e.,
remaining man-days) as opposed to being a reflection of
accomplishments (i.e., completed tasks and expended resources).
This
implicit
notion
of
productivity
is
captured in the model by the
variable "PROJECTED DEVELOPMENT PRODUCTIVITY" (PJDPRD), defined as,
PJDPRD = TSKPRM
At
th»
projtct
«dv*nc»«
/
toward!
MDPRNT
it» final stages,
and accomplishments
20
become
to
relatively more visible,
perceive
perceived
IS
productivity
determined
"PERCEIVED
t»«m'«
productive
how
I'h
the
TfiSKS
workforce
basis
of
actual
a result,
fts
accomplishments. That
approaches
PRODUCTIVITY"
DEVELOPED"
has actually been,
function of projected productivity and
a
PRODUCTIVITY"
DEVELOPMENT
MON-DflYS EXPENDED"
ThUi
on
DEVELOPMENT
"CUMULATIVE
the
ceases to be
instead
"flCTUftL
project members become increasingly more able
(CUMTKD)
the
(fiCTPRD),
divided
is,
value
of the project
i.e.,
the
value
of
by the value of "CUMULATIVE
(CUMDMD).
Ihi final ttAgtl of a toftwart projtct
PRDPRD
(call
it
time period t2),
ACTPRD
>
t2
t2
where,
flCTPRD = CUMTKD
To
recapitulate,
DEVELOPMENT
PRODUCTIVITY"
projections
(i.e.,
on
project,
explicitly
One
other hand,
the
about
progresses.
"infamous"
It
is
phases
development,
of
"PERCEIVED
implicitly
determined
on the basis of future
tasks
man-days).
Towards the end of the
and
basis
of
productivity,
however,
consequence
the
early
CUMDMD
"PERCEIVED DEVELOPMENT PRODUCTIVITY" gets to be
the
on
their
The change,
discussion.
is
ri!!!§iDiD9
determined
assumptions
the
in
/
accomplishments.
actual
therefore,
change
as
the
People's
project
is typically gradual not abrupt.
of
this
error
in perception deserves some
"90* syndrome phenomenon." Baber (1982)
provides the
following description of the problem:
...
estimates of the fraction of the work completed
(increase) as
originally planned until a level of about 80-90S is reached.
the
programmer's individual estimates then increase only very slowly until
the task is actually completed.
There
syndrome
is ample evidence
in
in the literature on the
software development projects (DeMarco,
pervasiveness of the SOX
1982).
Its manifestation
21
project is depicted in Figure
in
the
in
the earlier phases of the project by the rate of expenditure of resources,
simulated
status
plan.
reporting
This
created
resources
are
accomplished
apparent,
"illusion"
the
that
project was right on target.
the
same
the
appreciation
progress
Thus,
the
of
amount
percent
tasks
of
became increasingly able to
effort
of
started
it
to,
in
actually remaining,
effect,
fls
this
discount the project's
although the project members proceeded towards the final
project
progress
net
the
workforce has actually been. This results in a
the
the
of
developed,
rate.
between
members
project
time,
productive
how
discrepancies
percent of resources expended became increasingly more
the
appreciation
stages
being nothing more than an echo of the project's
up
consumed),
and
flt
perceive
their
ended
By measuring progress
8.
as the project approached its final stages (e.g., when 80-90* of the
However,
better
DE-fl
at
high work rate because of schedule pressures,
a
slowed down considerably. This continued until the
rate
project completed.
It!§_Bi§DDiC3_iybs^5tern
completion
project's
schedule,
By
of
the
or
staffing
do
For
plans
a
then
example,
can
little
to
be
of
estimates
<e. g.
,
for
man-days) are made at the beginning of the
load,
are
project
initial
revised,
handle
revised
both.
necessary,
as
a project that
to
more
add
throughout the
is perceived to be
people,
extend the
The Planning Subsystem is depicted in
S.
dividing the value of "MAN-DAYS REMAINING"
effort
REMAINING"
would
Subsystem,
estimates
life.
schedule,
Figure
time,
These
project.
behind
Planning
the
In
a
still
manager
remaining)
can
at
determine
(a
measure of the magnitude
any point in the project, by the "TIME
the
"INDICATED WORKFORCE LEVEL.
"
This
represent the workforce size believed to be necessary and sufficient to
75
50
r
25
200
100
300
TIME
FIGURE 8
REPORTED
v.
OF WORK COMPLETED OVER TIME
380
, '
1
\
/ CtlLlNC ON
"^ T01*L W0<««FWCI
\
^
22
complete
date.
of
simply
is true,
the
has
as
hiring
level
been
on
the
For
are
project,
excessive employees would
If on the other hand,
the opposite
project,
not
the
in
Human
determined
Resource
only
on
the
Management
basis
of
Consideration is typically given to the stability
organizations
Different
example,
DE-ft
explained
decisions
considerations.
workforce.
extents.
ifi
on the currently scheduled completion
based
then this would indicate a need to add more people.
•ch»duling
NPSft' s
time
transferred out of the project.
be
Subsystem,
the
workforce
actual
However,
of
on
indicated workforce size turns out to be lower than the value
this
If
the
project
the
workforce
weigh
stability
this
factor
to various
had relatively little weight in
Such organizational differences are captured
as we saw.
by th« policy variable termed "WILLINGNESS TO CHANGE WORKFORCE
MOdtl
LEVEL," and whose form is organization-specific.
By
the
dividing the value of the "WORKFORCE LEVEL SOUGHT"
above
REMftlNING,
to
of
set
"
complete
factors
management
the
is contemplated)
determines the time
project.
Once
this,
it
(that emerges after
into the value of the "MflN-DfiYS
perceives to be still required
in turn,
is known,
it
can be used to
adjust the project's "SCHEDULED COMPLETION DATE," if necessary.
Referring
inclined
not
back
development
the
project,
is
Figure
6,
notice
how project DE-0' s management was
to adjust the project's scheduled completion date during most of
the
behavior
to
phase
were
of the project.
instead
not atypical.
made
It
to
arises,
Adjustments,
the
project's
in the earlier phases of
workforce
level.
This
according to DeMarco (1982) because of
political reasons:
Once an original estimate is made,
it's all too tempting to pass up
subsequent
opportunities to estimate by simple sticking with your
previous numbers.
This often happens even when you know your old
estimates are substantially off.
There are a few different possible
explanations for this effect:
It's too early to show slip ... If I
re-estimate now,
risk having to do it again later (and looking bad
I
twice) ... As you cart see, all such reasons are political in nature.
23
discussion
this
With
overview
interested
reader,
mathematical
and
198A)
a
model's
the
of
presentation
the model's Planning Subsystem we conclude our
of
structure
and
behavior.
For
more detailed description of the model's structure,
formulation, and of its validation is provided in
(fibdel-Hamid and Madnick,
[
the
its
(fibdel-Hamid,
1987a)].
It}i_?!!9d§i_§i_i!l!_E>lB§!2i
