Project Dynamics with Applications to
Change Management and Earned Value Tracking
Balaji Janamanchi
Texas Tech University
Rawls College of Business Administration
ISQS area, P.O.Box 42101
Lubbock, Texas 79409-2101
(806)742-2397 Fax-(806)742-3193
Dr James R. Burns, Ph.D.
Texas Tech University
Rawls College of Business Administration
ISQS area, P.O.Box 42101
Lubbock, Texas 79409-2101
(806)742-1547 Fax-(806)742-3193
Abstract
In this paper, we present a novel project management model that incorporates
several features yet to be actively addressed in the literature and focuses on earned value
management. The model utilizes the basic structures employed in building project
dynamics models. The effects of time-varying project team size, of varying productivity, of
training and communication overload, and of change management are incorporated into
our model. With the help of our model and a hypothetical software technology project, we
demonstrate how a system dynamics model can contribute beyond basic project tools like
MS Project, in generating the earned value management indicators required by project
managers under different scenarios and starting assumptions. Results indicate the later
within the projects that the changes arrive, the longer is the delay in completing the
projects. Also, the later the changes arrive, the more expensive they are to fix. These
phenomena are propagated through the earned value measures to see the actual effects
upon schedule and cost performance indices.
1.0 Introduction
Traditional methods of project management and analysis were based around the
idea of decomposing the project into its individual parts in a structured way. For example,
Project Dynamics and Earned Value Management — page |
PERT charts were used to manage time and the Work Breakdown Structure was used to
manage scope. Although both of these models were very informative, they did not focus
much on the relationships between the parts of a system. They fail to provide useful
guidance to project managers in certain areas for the simple reason that they represent a
static view of the project taken before the start of the project or at some point in time
during the project execution. Customers often change the requirements of a project
causing a rippling effect of delays and cost overruns. As projects grow complex, and
"project failure" is appallingly a major trend in the several areas of economic activity,
traditional approaches to project management have proven ineffective to cope with the
complexity, and hence new, more sophisticated techniques are needed to improve
performance. Managing modern complex, integrated projects requires the use of models
that have the power to focus on the relationships between the different parts of a system.
Therefore, a holistic approach is required. System Dynamics views the project in its
wholeness.
“Project management is, at once, one of the most important and most poorly
understood areas of management. Delays and cost overruns are the rule rather than the
exception in construction, defense, power generation, aerospace, product development,
software, and other areas’(Sterman, 1992). This assertion clearly underscores the
importance of need for greater research in the area of project management.
Project management has long since been a topic of interest for system dynamics
researchers. Significant contributions have been made to the study of project management
using a system dynamic approach by Cooper (1980), Richardson and Pugh (1981),
Project Dynamics and Earned Value Management — page 2
Morecroft and Abdel-Hamid (1983), Abdel-Hamid (1984), Ford and Sterman (1997),
Lyneis et al., (2001), and more recently by Park and Pena-More (2003). However, certain
features of technology projects that are not explicitly addressed in the research to date
provide motivation for extensions to existing research.
In this paper, we shall utilize system dynamics to capture project dynamics vis-a-
vis a tracking methodology known as earned value management. The interest in this paper
is to re-visit some former project dynamics models and to incorporate within them features
that are missing, such as the actual earned value tracking mechanism and the human stress
levels that can accrue as the project nears scheduled completion. The project type assumed
here is of the technology type, where there is lots of communication and interaction
overhead. This is in contrast to conventional construction projects where the
communication overhead is minimal and there are many trained human resources. The
effects of a time-varying project team size in which new members must be trained before
they can be added and such addition necessarily lowers the productivity level of the
aggregate are incorporated into existing project model structures. In addition, the effects
of change management are included in which changes to the existing build result in
substantial rework. Therefore, within the existing structure, these additional considerations
are included—training and interaction (communication) overhead, change orders along
with explicit modeling of earned value factors such as schedule performance index and
cost performance index.
The client also plays a huge role in project dynamics. An enormous amount of
projects run over-budget and over-schedule, and this is due to a multitude of reasons but
Project Dynamics and Earned Value Management — page 3
one of the dominant ones is the client. When clients (customers) change their requirements
and budgets, they send a rippling effect throughout the project that inevitably makes the
project late and over budget. This is especially true when the change is late breaking.
These changes can build up and expand the scope of the project so dramatically that it will
never reach completion within the scheduled time; no matter how much more money the
client is willing to spend. Clients also may impose schedule restrictions and introduce
delays in many different ways. System Dynamics helps the manager to deal with these
changes and complete the project on time.
The use of System Dynamics models within Project Management (PM) appears to
be focused on three major objectives: (1) estimating, (2) risk analysis, and (3) progress
monitoring and diagnosis. Some models estimate the duration of the project, cost of the
project, the resources used on a project. This is essential in determining the value of the
project. Risk analysis models allow for the possible affects of various policies to be
assessed. Here is where a modeler inputs a series of possibilities to see how it would affect
the overall project. With models that consider progress monitoring and diagnosis, the
project manager is able to see if the project is on schedule and under budget, how certain
client requests will affect the development, and so on. The proposed model falls largely
within the last two categories of system dynamics models for PM.
Alexandre Rodrigues and Terry Williams, of the University of Strathclyde,
Glasgow, Scotland, have developed a project management integrated model (PMIM,
1996). PMIM provides a general framework for the use of System Dynamics models in an
integrated fashion with traditional procedures in supporting ongoing project planning and
Project Dynamics and Earned Value Management — page 4
control. PMIM uses System Dynamics models at both the strategic and the operational
management levels, aimed at providing continuous support to the planning and monitoring
functions. Within the planning function, the models are used to estimate the project
outcome and to help identify better planning alternatives, ensuring that the plan is based on
realistic assumptions.
Whether the Client will ask for changes, introduce delays, or impose schedule
restrictions, situations occur in which effective negotiation is crucial for the project
outcome. Traditional tools and techniques have proven inadequate to provide quick and
reliable information to the manager. In order for a project manager to effectively and
efficiently manage the project, they must use a combination of the traditional models,
mental models and System Dynamics models. If they are used in unison, they can be very
effective tools in guaranteeing the projects’ success. “The application of System
Dynamics to Project Management covers a wide range of uses, in particular creating team
learning and training environments, providing a tool for advanced planning and control of
on-going projects, and post mortem analysis to support legal dispute resolution”
(Rodrigues and Williams, 1996).
The remainder of this paper is organized as follows. Section 2 discusses the choice
of software and explains the general outline of the hypothetical project being modeled,
with the details of the Vensim model developed using a PLE version (Vensim 2005).
Additionally, section 2 also discusses the Earned value management concepts, and the
manner of adopting them in the current model. The results from the simulation of base
case and three other alternate scenarios are presented with comments in section 3, followed
Project Dynamics and Earned Value Management — page 5
by discussion of inferences that may be drawn from these results. Finally section 4 lists
the contributions, limitations of our model and possible future improvements.
2.0 Modeling Methodology
We choose to develop our model using Vensim PLE application software (Ventana
2005). Since basics of a typical project management model are well known in the system
dynamics community, we go straight to the discussion of the project being modeled. (The
detailed Stock-and-Flow-Diagram-SFD views representing the project dynamics are
depicted in figures 1, 2, and 3).
The project
The project stereotype we are dealing with here is a seemingly simple software
technology project. However, the seemingly simple project needs to be planned and
executed with caution in the view of the often-quoted Brook’s law, “adding resources to a
late project makes it even later.” Brook’s statement was made with specific reference to
software projects (Sterman, 1992). If the project was to be characterized into the two
categories identified by Boehm (1981) and referred by Morecroft and Abdel-Hamid
(1983), then it would be a hi-bred of ‘organic mode’ and ‘embedded mode’ with a greater
lean towards embedded mode. In a typical embedded mode software development project,
the constraints on the project are rather tight and demands on innovative data processing
architectures and algorithms are high (Morecroft and Abdel-Hamid 1983, pp13).
Referring to the SFD in Appendix-A, we can quickly spot the main segments as,
‘project work,’ and ‘project staff.’ Workload requirements affect the staff assignments to
the project, and the project team size influences the workflow rate, subject to the
Project Dynamics and Earned Value Management — page 6
productivity factor. Schedule pressure factor affects the rejection rate and staff turnover
normal. Staff turnover normal affects the staff turnover rate, which in turn affects the staff
requirements.
In its present form, the model consists of three basic components, a project-staff-
and-wages component that includes a staff pool from which project staff are extracted and
returned, a work sector, and a changed-requirements-and-earned-value component. The
work sector includes four stocks: project-work-to-be-done, project-work-in-progress,
work-completed and rework-identified. Additionally, the model includes the information
infrastructure necessary to compute the basic variables that comprise earned value analysis,
including earned value, planned value, schedule variance, cost variance, as well as
schedule and cost performance indices.
In a base case scenario, the project starts at time 0 (months) with an ‘initial-
contracted-load’ (expressed in person*month). Staff are assigned to the project based on a
staffing requirement arrived at by dividing the initial-project-load (person*month) by the
“‘scheduled-completion-time.’ (Denoted in months) The initial-contracted-load is the
starting value for the stock ‘project-work-to-be-done.’ Work performed by the project
staff, moves from the stock project-work-to-be-done to the stock ‘project-work-in-
progress.” However, the work flow is affected by a productivity factor that is derived from
a table look-up based on the number of staff currently on the project. The project-work-in-
progress is subjected to an inspection. Inspection process is assumed to be built into the
workflow and performed by the staff performing the project work;
such explicit staff
Project Dynamics and Earned Value Management — page 7
assignment is not made for inspection process. Whereupon, the work failing to meet the
required standards moves to ‘rework-identified’ and the work that passes the inspection
moves to ‘project-work-completed’. Rework-identified gets priority over project-work-to-
be-done for the simple reason that typical technology projects build up in cumulative
fashion. The structure for the work sector appears below in Figure 1.
<project staff <Project stall <productivity>
assigned to rework>
INITIAL INCREASE IN acceptance normal
PROJECT LOAD WQRK NORMAL
Project work [Pybject Work-In-Progress
work Additibgs | 0 be done | Pg e
rejection rat
COMPLETION
Rework identified Lag f
TIME
normalizing factor
schedule pressure
tab lookup
CHANGE schedule pressure
factor
REQUEST TIME
Project work completed
tahce
available time rework ra
workflow normal
<Time>
SCHEDULED
work normal}
obsbleted
OBSOLESCENCE
NORMAL.
Figure 1. The Work Sector for the Project Dynamics Model
The “logic” of the staff-and-wages sector follows. As previously mentioned, staff
are assigned to the project based on a staffing requirement arrived at by dividing the initial-
project-load by the ‘scheduled-completion-time.’ An appropriate fraction of project staff is
assigned to attend rework, and the remaining staff tackles the project-work-to-be-done. As
the project advances, at each time interval, the requirements of project staff are assessed,
Project Dynamics and Earned Value Management — page 8
and if additional staff is required based on scheduled completion, such additions are
allowed. (Conversely, towards the end when there is surplus of staff on project they are
moved back to the available pool). It is assumed that this particular enterprise has some
available staff awaiting assignment to different projects. As the project advances, the
available time declines, this causes an increase in ‘schedule-pressure’. An increase in
schedule-pressure increases, rejection-rate and staff-turnover-rate. These changes have
negative impacts on the project completion time. The structure for the staff-and-wages
sector(s) appears in Figure 2 below.
Project stall
mien
hiring normal assignment ate ‘paid rate
rate normal AVG WAGE FOR
| PROJECT STAFF
|
Sultin ming Tine LO \
Available is staff tumover <work addition
gt hey ane
eA Saale
4
rs stall ~S
ic wie vin ne
avaabiny pc
Bree sevens
productivity project salt
productivity table assigned to rework
lookup
project end
tablelookup factor
<INITIA
PROJECT LOAD> identifed>
Figure 2. Structure of the Staff-and-Wages Component of the Project Dynamics Model
Finally, the project dynamics model includes all the necessary infrastructure for
accommodation of changes and change management as well as supporting structure for
Project Dynamics and Earned Value Management — page 9
Earned Value Management. The structure of this third component appears in Figure 3
below.
fotal value For] mation rat
additions and| _8¢Cumulation rate work
OS} additions
changes ons L_cmulative
accyfhulation rate
nt —
“ht id a <Time>
Sane OY for addins eo
Jae x addiddas>
oes ‘SCHEDULED
; SLCOMPLETION
Planned Value -for#X ea Planned
changes per montly Z 3 Value-basecase
Ps INITIAL,
nrmalizing factor Qf PROJRCT LOAD>
<work obsoleted>
Planned Value for —
additions after change <AVG WAGE FOR \S
request PROJECT STAFF>
Total Planned Earned Value
Value
ral \A4 My
Schedule Project staff Cost Performance
Performance index. wages> Index.
Schedule Variance Cost Variance
Figure 3: Change Management and Earned Value Management Structure
Alternate scenarios
The one major difference, between the base case and each of the alternate cases is
that a change request is incorporated in the alternate scenarios. In fact, whether the
changes are requested by the client, or caused by some hidden factors in project work, they
are typically stochastic in nature. One never knows when these changes arise. However,
what is well known in project management circles is that, ‘changes are a rule rather than an
exception.’ Therefore, there appears to be a certain deterministic tendency to their
Project Dynamics and Earned Value Management — page 10
unfailing occurrence. The alternate cases are modeled to reflect this situation of change
requests arriving at different points of time in project execution. For simplicity’s sake, the
changes are assumed to arrive at end of first quarter, at end of second quarter and at the
end of third quarter in case 2, case 3, and case 4 respectively.
What is new in the current model?
In the work sector (component) of the model, there is explicit provision for
“Rework identified” rather than just returning this work to “Project work to be done.” This
allows for this work to be handled differently from “project work to be done” so that this
work can be expedited, etc.
The model includes a productivity multiplier that declines as team size increases.
In a typical large technology project, there is a lot of interaction overhead. We have
created a productivity table look-up using data provided by Louis Fried (1995) in his book,
“Managing Information Technology in Turbulent Times.” The author provided productive
time estimates for groups ranging from 10-100 employees. These tables have been
extended for smaller groups based on Fried’s comments in the same chapter in respect to
smaller groups, “...therefore, it may be estimated that 55 percent of each employee’s time
can be considered productive in a group of up to 10 employees” (Fried 1995, pp 130). At
each iteration interval, project staff requirements are adjusted to meet the scheduled
completion. This adjustment is made by dividing the work yet to be done by available
time without considering the productivity factor, as a normal project manager would do
based on his mental models. When available time is <1, an If-then-else construct retains
available time=1 for the purpose of this equation.
Project Dynamics and Earned Value Management — page 11
All new staff joining the project midway needs training like the orientation to the
current stage of the project with an appreciation of work done up to date to be effective and
the training time depends upon the time-point when the new staff is to join existing project
staff. Typically, in the initial stages at time point 1, no additional training is required since
the initial project team is selected on the basis of their suitability to execute the project as
well as the fact that the initial team defines the outline and manner of project execution.
However, if new staff is to join six months into the project, they need about 2 months
training before they are effective. The following table look-up delivers the logic required
for this model by returning training time requirements as a function of time. Note that no
one requires more than five months training, and training time is zero, initially.
Graph Lookup - training time look up
i
Yemin:
ZI
J
Xin] ox) x=2.141 y=2.456 Xmax|100 | Reset Scaling
OK | ClearPoints | Clear AllPoints | Cur>Ref| ClearReference | Ref>Cur| Cancel _|
Figure: 4 Training time requirement
Project Dynamics and Earned Value Management — page 12
From the ‘staff in training’ stock, a fraction of trained staff is moved to the project
staff stock based on training time value.
What is new in the model: Earned Value Management (EVM) Indicators
Earned value management is a project performance measurement technique that
integrates scope, time, and cost data (Schwalbe 2004, pp 242). The basics of earned value
management are simple and easy to understand. Projects have budgets, scope, and
schedules. It is important to know how the project is progressing in terms of a) staying
within the budget, b) percentage of completed work at each regular time interval and c)
staying on course towards a scheduled completion. A few simple cost variables are used to
compute the EVM indicators. The following descriptions of various cost computations are
adopted and / are summarized from Schwalbe (2004).
Planned Value (PV), formerly called Budgeted Cost of Work Scheduled (BCWS),
is that portion of the approved total cost estimate planned to be spent on an activity during
a given period.
Actual Cost (AC), formerly called the Actual Cost of Work performed (ACWP), is
the direct and indirect cost incurred in accomplishing the work on an activity during a
given period.
Earned Value (EV), formerly called the Budgeted Cost of Work Performed
(BCWP), is an estimate of the value of physical work actually completed.
Project Dynamics and Earned Value Management — page 13
Cost Variance (CV) is, by definition, the earned value minus the actual cost. If cost
variance is negative, it means that the actual work performed cost more than the value
earned thus far.
Schedule Variance (SV) is, by definition, the earned value minus the planned value.
Schedule variance calculates the difference between the current value earned and the value
that was scheduled to be earned at this point in time.
Cost Performance Index (CPI) is the ratio of earned value to actual cost and can be
used to compute the projected cost of completing the project. An index equal to ‘1’ (or
100%) denotes that earned value and actual costs are equal, or costs are exactly as planned.
If the index is lower than | (or 100%), it indicates that, then the project is over budget.
Schedule Performance Index (SPI) is the ratio of earned value to planned value and
can be used to estimate the projected time to complete the project. This index is
interpreted similar to the cost performance index, with the difference that SPI measures the
time and schedule aspects instead of the costs.
The following table (Schwalbe 2004) lists the formulas for EVM indicators.
Table 1
Term (Indicator) Formula
Earned Value EV = PV to date * percent completed
Cost Variance CV =EV-AC
Schedule Variance SV =EV-PV
Cost Performance Index CPI= EV / AC
Schedule Performance Index SPI=EV/PV
Estimate at Completion EAC=BAC / CPI
Estimated Time to Completion Original time estimate/SPI
Adopting EVM indicators
Project Dynamics and Earned Value Management — page 14
Software developers’ wages form the bulk of the software technology project cost.
Controlling and monitoring the wage bill in a software project needs greater priority than
controlling other direct and indirect costs. In the proposed model under this study, we
have attempted to provide the EVM measures with reference to the ‘project staff wages.”
It is our contention that project managers have to keep a close watch on the wage bills
more than any other costs in a project of this type and hence, the model will be helpful in
assisting managers in this goal. The Vensim model view labeled “Earned Value Tracking”
incorporates all the significant EVM indicators mentioned in Table 1 (see Figure3).
3.0 Simulation Run Results and Discussion
The SFD needs the units, equations, and starting values for the stocks and rates to
make simulation runs. We have already identified some of the required values in our
description of the project under section 2. Given below is a complete list of all major
assumptions and data values used in the model.
Assumptions and Data Values
Work to be done: 100 man-months (person*month)
Initially staff available: 20 (persons)
Scheduled completion time: 25 months
Initial project staff assigned will be 4 (persons).
Interaction effect is provided by way of table look up (Fried 1995)
Base case —simulation is for project with no change requests
Case1,2,3 are for projects with change requests(only one) at time point
Tth, 13th, and 19" month
Each change entails in 20% increase in work load.
Each change also obsoletes 40% of work completed to date.
Staff requirements are adjusted on monthly basis.
New staff joining the project need training--training time is a time
dependent value ranging from | to 5 months
e Rejection normal is initially set at 5%
° Acceptance normal is complement of rejection normal, hence 95% at start.
e Rework identified gets priority over project work to be done.
Project Dynamics and Earned Value Management — page 15
All rework identified is assumed to be reworked within one month
Project staff are allocated to rework first and the remaining are assigned to
project work to be done.
Entire (combined) project staff is taken as the basis for productivity table
look up
Available time is computed as ‘schedule time-elapsed time,’ subject to a
minimum of ‘one moth’ at all times.
Reduction in available time, increases schedule pressure ranging from | to 2
and this schedule pressure affects the rejection rate as well as staff turnover
Average wage per staff per month is $5,000.
Available staff at all times needs to be maintained at 10% of the project
staff.
If-then-else logic is employed in many equations to prevent negative
draining of stocks as well as to prevent recurring fractional computations
With the above assumptions and some constructs implicit for a Vensim model, the
base case an
d three alternative policy runs are made and the results appear below.
Project work to be done
100
q5
50 +
25
0
0 4 8 12 16 20 24 28 82 36 40
Time (Month)
Project work to be done : PM_tl. —+ + + + + +— Month*person
Project work to be done : PM_t7 Month*person
Project work to be done : PM_t13 Month*person
Project work to be done : PM_t19 4 Month*person
Fig 5- Behavior-Over-Time (BOT) graph- project work to be done
In Figure 5, the project is virtually complete when the “Project work to be done” is
zero. The curve labeled “1” has no changed requirements and finished in 28 months. The
Project Dynamics and Earned Value Management — page 16
curve labeled “2” has changed requirements that occur at the end of the first quarter only.
The project is still able to be completed in 28 months. The curve labeled “3” has changed
requirements that occur at the end of the second quarter only. The result is a month’s delay
in the entire project. The curve labeled “4” has the same changed requirements observed
in connection with curves 2 and 3, except these changes are now occurring at the end of the
third quarter. Clearly late-breaking changes result in substantial delay in the completion of
the project—roughly six months. This is so because, the later the change arrives, the
greater is the volume of completed work rendered obsolete that needs to be reworked.
Further as will be discussed in the Future Improvements section (refer #3) of the paper,
current model assumes available time to be always no less than 1 month. Thus, an increase
in the workload arising from changed requirements at the end of 1‘ and 2"! quarters does
not appear to have serious impact on the completion time, though it increases the wage bill.
Project staff
20
0 4 8 12 16 20 24 28 32 36 40
Time (Month)
Project staff : PM_t1 person
Project staff : PM_t7 person
Project staff : PM_t13 person
Project staff : PM_t19. —+ ~ - + person
Figure 6-BOT graph - project staff
Project Dynamics and Earned Value Management — page 17
Project staff wages
2M
500,000
0 4 8 12 16 20 24 28 32 36 40
Time (Month)
Project staff wages : PM_tl dollars
Project staff wages : PM_t7 dollars
Project staff wages : PM_t13 dollars
Project staff wages : PM_t19. -- + dollars
Figure 7-BOT graph - Project staff wages
productivity
1 ;
0.85 f
/
[
0.7 |
|
0.55 J
te
0.4
0 4 8 12 16 20 24 28 32 36 40
Time (Month)
productivity :PM_tl ' 1 ' ' ‘ ‘ 1 Dmnl/person
productivity : PM_t7 Dmnl/person
productivity : PM_t13 g——g-_33 3 Dmnl/person
productivity :PM_t19. —4 444 4——4 Dmnl/person
Figure 8-BOT graph - productivity
Project Dynamics and Earned Value Management — page 18
Total Planned Value
800,000
600,000
400,000
200,000
0 4 8 12 16 20 24 28 32 36 40
Time (Month)
Total Planned Value : PM_tl t + t ‘ ‘ ‘ +— dollars
Total Planned Value : PM_t7 dollars
Total Planned Value :PM_t13. —3 3 3 3 3 dollars
Total Planned Value :PM_t19. —+ + + + + + dollars
Figure 9-BOT graph - Total Planned Value
Earned Value
800,000
-—
600,000
400,000
200,000
0
0 4 8 12 16 20 24 28 32 36 40
Time (Month)
Eamed Value : PM_t1 + + t ‘ ‘ ‘ +— dollars
Eamed Value : PM_t7 dollars
Eamed Value : PM_t13 3 3 3 3 3 dollars
Eamed Value : PM_t19 4 $ ‘ 4 4 dollars
Figure 10-BOT graph - Earned Value
Project Dynamics and Earned Value Management — page 19
Cost Variance
0
-250,000
-500,000
-750,000
ae)
-1M
0 4 8 12 16 20 24 28 32 36 40
Time (Month)
+ + + + + + + + dollars
dollars
[_t13 3 3 3 3 3 dollars
Cost Variance : PM_t19 + + + + + dollars
Figure 11-BOT graph - Cost Variance
Schedule Variance
04 ia
-100,000 he
-200,000
-300,000
-400,000
Schedule Variance : PM_tl + + + + + + + + dollars
Schedule Variance : PM_t7 dollars
Schedule Variance : PM_t13 3 3 3 $ 3 dollars
Schedule Variance : PM_t19 + + - + + dollars
Figure 12-BOT graph - Schedule Variance
Project Dynamics and Earned Value Management — page 20
Cost Performance Index
0.6
0.45 \
0.3
0.15
0
0 4 8 12 16 20 24 28 32 36 40
Time (Month)
Cost Performance Index: PM_t1 + + + + + + + Dmnl
Cost Performance Index: PM_t7 Dmnl
Cost Performance Index : PM_t13 3 3 3 3 Dmnl
Cost Performance Index: PM_tl9 + + + + + + Dmnl
Figure 13-BOT graph - Cost Performance Index
All figures 6 through 13 depict the effects of the same four scenarios discussed in
figure 5. Specifically,
Curve 1- has no changes- is the base case
Curve 2-Change requests arrive at the end of 1* quarter
Curve 3-Change requests arrive at the end of om quarter
Curve 4-Change requests arrive at the end of 3m quarter
shows the sudden surges in project staff engaged in the project work in order to
clear the surges in rework, as well as to catch up with mounting workloads towards the
completion of the project. All three change requests lead to more than proportionate
increases in the costs compared with budgeted costs, as may be seen from Figure 7. This is
because of the productivity losses occurring with increases in staff size.
Figure 8 shows falling productivity levels corresponding to increasing team sizes.
The fall would have been more dramatic if we were simulating projects that required teams
Project Dynamics and Earned Value Management — page 21
of 40 or more members, based on the productivity table look-up adapted from Fried (1995)
as reproduced below in Figure 14.
Graph Lookup - productivity table lookup
Output
Eg
|
=<
2
‘
a ol
ee l Dn
7] 7 imnl/perso
[10 [osees P
[20 [osst
[30 [o.s06s
[40 (a.a72
Ea ee
feo [oa73
70 [03065
80 [0234 | Yin:
New a z
| | |
Xmin:|O x} 98235 y=1.031 Xmax {100 _y| Reset Scaling
OK | ClearPoints | Clear AllPoints | Cur>Ref | ClearReference | Ref>Cur| Cancel _|
Figure 14: Productivity Multiplier-based on team size
As may be seen, the productivity does not vary much from team size 10 to 20, as
much as it would between team sizes 30 to 40 and higher. (Here, each vertical bar
represents 25 additional employees.)
Figure 9 and Figure 10 show how the ‘planned value’ (PV) and ‘Earned value’
(EV) fluctuate under the different scenarios. Cost variance and schedule variance in Figure
11 and Figure 12 bring forth the effect of change requests by quantifying the same in dollar
amounts. The cost performance index displayed in Figure 13 provides a means to compare
the various project scenarios because the index here is dimensionless and a standardized
indicator.
Project Dynamics and Earned Value Management — page 22
Inferences from the simulation results
Some straightforward inferences may be made from the plain reading of the graphs
as follows.
1. With or without change requests, project executions will be delayed and project
costs exceed the budgeted costs, for the simple reason of team size effect on the
productivity of the project staff. So productivity effects need to be factored in, while
assessing the project staffing requirements as well as cost budgets.
2. Without a proper intervention to complete the projects within the scheduled
time, all project executions will exceed the scheduled time for the reasons of team size
effect on productivity as well as the inherent rejection rate (error rate) in the project work.
3. As was seen in the base case, typical increases in project costs with no
interference could be as high as 40%.
4. Change requests coming in the first half of the project execution are easier to
handle in terms of staying on schedule than the change requests received in the later half of
the project. In all cases, more than proportionate increases in costs is unavoidable.
5. EVM indicators captured show that cost variance and cost performance index are
most favorable in the base case than in any alternate scenario.
6. It may easily be shown that, by defining a larger scheduled completion time and
reducing the initial team size suitably, cost variance and the cost performance index
indicators can be improved, and total costs (project staff wages) will be reduced.
Project Dynamics and Earned Value Management — page 23
7. Similarly, by suitable changes, we can show that reducing the volume of
interaction among team members and increasing the productivity of project staff can
provide substantial cost savings and improve the financial bottom line of the enterprise.
Simulations with small variations can provide some very useful insights into the
project dynamics and the effect thereof on project costs and EVM indicators.
4.0 Contributions, Limitations and future improvements
There are many useful contributions emerging from the model as follows.
1. The model incorporates the effect of team size and interaction effect on the
productivity of project team, to help project managers to take suitable decisions.
2. The model demonstrates the capture of EVM indicators and shows how these
vary over time.
3. By varying the parameters (model constants) like, ‘INITIAL PROJECT LOAD,’
‘INCREASE IN WORK NORMAL,” ‘CHANGE REQUEST TIME,’ etc. (all coded in
upper case letters in the model), and by suitably adjusting the initial project staff, several
different project scenarios can be simulated.
4. The model provides decision support to project managers in assessing the effect
of customer change requests in an objective manner and to make suitable price quotes.
5. As was stated in the introduction section, a model like the current one can also
provide help in resolving cost disputes arising out of change request.
6. The model can very easily be adopted to other types of projects by making
suitable changes in the structure to reflect the peculiar/unique situations present under
Project Dynamics and Earned Value Management — page 24
those projects. Namely, delays in construction projects due to climatic changes, could be
accommodated, as could the effects of crashing and shortening the duration of tasks as
suggested by Goldratt (1997).
Limitations of the model
As is the case with any simulation model, no model can be validated perfectly.
“All models are wrong, so no models are valid or verifiable in the sense of establishing
their truth. The question facing the client and modelers is never whether a model is true
but whether it is useful” (Sterman 2000). So also, the real values of the parameters are
bound to differ with the values used in the model to gain an understanding of the dynamics
present. The true usefulness of the model lies in providing a better understanding of the
dynamics and guidance in the place of the mental models that would be used otherwise.
Some explicit limitations of the model are,
1. All parameter values used in the model, like the workload, rejection rate, and
acceptance rate are assumed for a typical technology project. Estimates that are more
accurate need be used for studying the effects with reference to a real enterprise based on
empirical data of the specific enterprise.
2. The model assumes a steady rejection rate (affected only by the schedule
pressure) but rejections pattern and identification of rework pattern may be different and
distinct in certain project settings.
3. Staff interaction effect and the productivity table look up that is modeled herein
is assumed to take care of the effect of time lost in training the new members joining the
team midway. No other explicit time loss is modeled.
Project Dynamics and Earned Value Management — page 25
4. Staff working overtime is not explicitly modeled; instead more staff are assigned
to the project as the schedule demands.
5. Fractions in staff numbers are allowed on the assumption that the enterprise will
be able to allocated the idle time to other useful productive tasks (other than the project).
Future Improvements
Many variations to the current model are possible to improve the usefulness and
effectiveness of the model as a decision support tool.
1. Effects of multiple change requests can be studied by providing for multiple
change requests arriving at stochastically selected time points.
2. Change request coming in may be assumed to have varying degrees of effect in
terms of increasing the work load and obsolescing the work completed to date.
3. Currently, the model assumes that available time is never less than 1 month.
However, by modeling the available time to explicitly reflect reality, we can devise a
model that would show all alternatives reaching completion of the project at schedule time.
It is to be assumed in those cases that cost is not a serious constraint.
4. Currently, the model doesn’t assume any upper limit on staff. If there are
constraints on the project staff, we may specify an upper limit on the project staff that may
be employed in a project to see the effects on schedule and costs.
5. By extending the structure of the model, costs other than the staff wages may
also be tracked to provide more comprehensive EVM indicators. Those costs would
include indirect costs, which in turn, would enable the effects of crashing on both direct
and indirect costs to be more realistically represented.
Project Dynamics and Earned Value Management — page 26
References
1. Abdel-Hamid, T.K., (1984) “The Dynamics of Software Development
Project Management: An Integrative System Dynamics Perspective.” Doctoral thesis, MIT,
Cambridge, MA.
2, Boehm, B.W. (1981), “Software Engineering Economics,” Englewood
Cliffs, New Jersey, Prentice Hall Inc.
3 Cooper, K.G., (1980), “Naval ship production: A Claim settled and
framework built,” Interfaces 10(6).
4. Ford, David, N., and Sterman John, D., (1998) “Dynamic modeling of
product development processes,” SDR, Vol.14 No.1, (spring).
5. Fried, Louis, (1995) “Managing Information Technology in Turbulent
Times,” New York: John wiley.
6. Lyneis, James, M., Cooper, Kenneth,G.,and Els,Sharon,A., (Fall 2001)
“Strategic Management of Complex projects: a case study using system dynamics,” SDR,
Vol. 17, No. 3 p 237-260.
wh Morecroft, John, D.W., and Abdel-Hamid, Tarek, K., (1983) “A Generic
System Dynamics Model of software Project management,” SDS literature collection,
MIT, MA.
8. Park, Moonseo and Pena-Mora, Feniosky, (Fall 2003) “Dynamic Change
management for construction: introducing the change cycle into model-based project
management,” SDR Vol.19, No 3 pp213-242.
9. Richardson, G.P., and Pugh, A.L.III, (1981) Introduction to System
Dynamics Modeling with Dynamo. MIT Press, Cambridge, MA.
10. Rodrigues, Alexandre and Bowers, John. (1996) The role of system
dynamics in project management. International Journal of Project Management, Vol.14,
No. 4, 1996.
11. Rodrigues, Alexandre and Williams, Terry. (1996) “System Dynamics in
Project Management: Assessing the Impacts of Client Behavior on Project Performance.”
University of Strathclyde, www.mansci.strath.ac.uk.
12. Schwalbe, Kathy, (2004) Information Technology Project Management:
Third Edition, New York: Thompson—Course Technology.
Project Dynamics and Earned Value Management — page 27
13, Sterman, John D, (1992) “System Dynamics Modeling for Project
Management.” Massachusetts Institute of Technology, Sloan School of Management.
14. Sterman, John D., (2000) Business Dynamics-Systems Thinking and
Modeling for a Complex World McGrawHill Companies Inc.
15. Ventana Systems Inc, (2005) at http://www.vensim.com/optimize.html
date accessed 3/31/05
-00o-
Project Dynamics and Earned Value Management — page 28
