PERGAMON Computers and Structures 67 (1998) 401±419

Desman: A dynamic model for managing civil engineering

design projects
Stephen Ogunlana *, Jason Lim, Khalid Saeed
School of Civil Engineering, Asian Institute of Technology, GPO Box 2754, Bangkok 10501, Thailand

Abstract

Traditional project management tools are useful in managing design projects. However, incorporating ``soft data''
into tools like the critical part method (CPM) and bar charts is problematic. They are also best used for bottoms to
top management and are, therefore, not very e€ective for macro managing projects. A system dynamic model can
improve the current practices and reduce the problems in design projects when used as a tool for macro
management. A model was developed for the management of detailed design process of a civil engineering project.
The model consists of four interrelated subsystems: human resources, design production, controlling and planning.
Two sets of data were used to test the model. Some policies and scenarios were then explored to gain insight into
the model's behaviour and to seek alternatives for better management. The experimentation showed the following
policy hierarchy. In terms of meeting scheduled time, the e€ectiveness of policies is in the order: (1) progress
control, (2) manpower allocation, (3) estimation of workload and (4) realization of underestimated work. If the goal
is to minimize labour-days expended or to reduce the cost of design, the e€ectiveness of policies is in the order: (1)
manpower allocation, (2) progress control, (3) estimation of workload and (4) realization of underestimated work.
As such, good project control and early perception of real progress are needed to ensure ecient resource allocation
and on-time completion. This requires creation of a project organization which is able to recognize and process
changing information on those issues. # 1998 Elsevier Science Ltd. All rights reserved.

1. Introduction ment requires that the e€orts of individuals with di€er-

The two major phases of civil engineering design are:
(1) preliminary design and (2) detailed engineering
design [1]. Preliminary design stresses architectural
concepts, evaluation of technological process alter-
natives, size and capacity decisions and comparative
economic studies. During detailed design, the process
becomes more formalized, having more speci®c steps
and with less random interactions. It involves succes-
sively breaking down, analyzing and redesigning the
structure and its elements so that standards are com-
plied with and drawings and speci®cations needed
for site construction are produced. It also involves the
integration of the e€orts of people with di€erent
specializations. Sawczuk [2], noted that design manage-
* Corresponding author.
ent skills be integrated to give the most bene®ts to the
design organization and as such, team members need
to be changed from time to time to ensure that knowl-
edge is shared. It is critical, therefore, that the design
manager uses appropriate tools to ensure ecient inte-
gration of design tasks. This has not been achieved in
practice. Design management continues to experience
the three problems of any stage of project manage-
ment: cost overrun, schedule slippage and the inability
to meet quality requirements without excessive change
orders and rework.
It is common knowledge that planning for design
work, as currently done, is not as sophisticated as the
planning for the construction stage of projects.
Coles [3] attributed this to the perception that planning
and control techniques applied to construction are
too rigid for design work, or the common belief that
design work cannot be planned or the belief that

0045-7949/98/$19.00 # 1998 Elsevier Science Ltd. All rights reserved.

PII: S 0 0 4 5 - 7 9 4 9 ( 9 7 ) 0 0 1 4 8 - X
402 S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419
designers are impeded by factors beyond their control.
The work being reported attempts to model the
detailed design process with the view of optimizing
time, cost and schedule performance through the use
of the model. It is hoped that the model can serve as a
tool for planning and monitoring at the design phase
of construction projects and overcome the barriers
listed by Coles.
2. Why model construction projects as dynamic systems?
System dynamics modeling is useful for managing
processes having two major characteristics: (1) they
involve changes over time and (2) they allow feedback,
the transmission and receipt of information [4]. A
recurring theme in the works by Sawczuk [2] and
Coles [3] is the need to provide timely information to
aid management. In addition, Chang et al., [5] and
Stermann [6] have shown that construction design and
management processes can be studied with advantage
using system dynamics modeling. This is because
the amount of work changes over time and the actors
have access to output information that can be used to
improve the process.
Stermann [6] justi®ed the application of SD to
construction modeling thus:
Ð Construction projects are extremely complex and
consist of multiple interdependent components. SD
models are well suited to representing multiple inter-
dependencies.
Ð Construction projects are highly dynamic. SD
was developed to deal with dynamics.
Ð Construction projects involve multiple feedback
process. SD is the modeling method of choice where
there are signi®cant feedback processes [7].
Ð Construction projects involve non-linear relation-
ships. System dynamics, more than any other modeling
technique, stresses the importance of non-linearities in
model formulation [4].
Ð Construction projects involve both ``hard'' and
``soft'' data. SD modeling permits both forms of data.
Literature on the application of SD to project
management is sizable. A useful summary is available
in Ref. [8]. However, the bulk of the applications are
in research and development [9, 10, 4, 11, 12] and soft-
ware development [13±24]. The application of SD to
construction project management is very limited.
System dynamics was ®rst applied to general project
management by Roberts [9] who demonstrated that
project management could be improved through
dynamic simulation. Richardson and Pugh [4] adopted
Robert's model for teaching general principles of pro-
ject management. However, their model was intended
to be used as a general teaching model and is not
speci®c to any industry. Jensen [11] applied SD to
client and project relationships in construction. He
demonstrated that project team relationships could be
improved with the aid of dynamic modeling. Pugh±
Roberts Associates [25] applied SD to various large
projects with emphasis on design and workscope
changes and dispute resolution.
Stermann [6] has written on the potentials for
improving construction project management through
dynamic modeling. A summary of his thought was
given earlier in this paper. Saeed [26] has also demon-
strated that civil contracting can be improved through
dynamic reasoning. However, the two have not devised
any formal models for project management.
The management of site construction was modeled
by Chang et al., [5]. Their work showed that a model
of the site construction process could help to reduce
project time and forecast the e€ect of materials supply
disruptions on project performance.
The application of system dynamics modeling to
design is limited to a speci®c application for a building
construction project by Huot and Sylvestre [27]. Huot
and Sylvestre's work was concerned with strategic pro-
ject management focusing speci®cally on fast-tracked
design and build projects. Their work showed that
management performance could be improved through
model simulation. This paper reports on a model con-
structed for general application to the detailed design
stage of a civil engineering project. The major purpose
of the model is to answer questions that are important
in design management such as: When should ad-
ditional work team members be introduced? What
quality of work force should be introduced? How do
we ensure that a project will ®nish as scheduled and
within budget? How should the e€ort of management
be distributed amongst the management functions
(planning, estimating and controlling)?
It has been advocated that system dynamic modeling
should complement rather than displace traditional
techniques as a tool for modeling construction
projects [6, 28]. The two approaches are di€erent in
focus and in emphasis. Traditionally, engineering pro-
jects are managed using tools such as bar charts, net-
works, earned value charts, etc. They normally require
that projects be decomposed into constituent elements
(work packages, activities, etc.) and cost, time and
resources estimates made for the constituent elements
based on experience. A larger model is then con-
structed from the individual parts. The reconstruction
of the project often ignores ``intra-project forces'' [8]
and thus a holistic view of the project is impossible.
System dynamics modeling considers the project in a
holistic way. Rodrigues and Bowers [29] stated that the
power of the SD modeling approach lies in its ability
to incorporate the more subjective factors which can
 S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419
have important in¯uence on the whole project. Those
factors are dicult to incorporate into traditional
CPM models.
System dynamics as a modeling technique allows the
incorporation of feedback. A major requirement in
modeling projects with the CPM, for example, is that
looping (feedback) is not allowed. However in the real
world information feedback is a major part of human
activity. Suppose one asks a project manager what
are the critical factors that a€ect project success. The
manager might mention things such as planning e€ort,
control e€ort, quality of work force, etc. It is unlikely
that the manager will remember that planning e€ort
itself is a€ected by project success. If a project is fail-
ing, it is reasonable to increase the planning e€ort and
if the project is running smoothly (succeeding) there is
no need to increase planning e€ort. Thus, information
on project performance a€ects the level of planning
e€ort. The ability to incorporate feedback information
into modeling separates SD from traditional modeling
techniques.
3. System dynamic modeling
System dynamic modeling (detailed procedures are
available in Ref. [4]) procedures fall into two parts:
model validation process and policy analysis process.
In model validation process, key variables associated
with the perceived causes of problematic behaviour are
identi®ed and abstracted from real world evidence.
Reference modes are then de®ned for the existing sys-
tem behaviour over a suitable time horizon. Feedback
theory is then applied to structure the relationships
among the problem parameters, forming causal loop
diagram (see Fig. 1). Two building blocks are used to
represent the structure of a system, i.e. level (also
called stock) and rate (sometimes called ¯ows). Level is
accumulation of change caused by the rate. As inter-
mediate between level and rate, auxiliary is used
for added clarity and simplicity. In addition to these,
constants and graph functions are used. After formu-
lating a model, it is simulated with the aid of computer
software.
In the policy analysis process, the sensitivity of
parameter and structural changes to the model are
explored. Policies aimed at achieving desired goals or
improving model behaviour can then be assessed to
show how a real system might be modi®ed.
Today there are a few proprietary system dynamic
modeling tools of which Professional Dynamo,
VENSIM and Powersim are the popular ones for the
PC platform, while STELLA or iThink and VENSIM
are popular for the Macintosh platform although
STELLA and iThink are now also available on the
Windows platform. This model was implemented in
403
Powersim, a Windows based tool for system dynamic
modeling.
4. The engineering design model
A model of the software development process was
constructed by Abdel-Hamid and Madnick [18]. The
process of detailed design is similar to software devel-
opment. The engineering design model was, therefore,
developed from Abdel-Hamid and Madnick's software
model.
Engineering design can be viewed as a system con-
sisting of di€erent components or subsystems which
are interrelated. These subsystems are human
resources, design productions (drawings, speci®cations
and bills of quantities), controlling and planning. The
design model is constructed on the premise that a
design ®rm will ®rst agree on needs and timing with
the owner and then proceed to decide how to manage
the project to facilitate completion within the agreed
time.
4.1. Overview of the model's main feedback loops
Simpli®ed feedback loops of the model are shown in
Fig. 1. Fig. 1 consists mainly of three major loops.
The ®rst is a goal seeking or negative feedback loop
with two stocks (in Appendices A±F). The goal is
the indicated work force to ®nish the project within
the scheduled time. More work force will consume
more man-days. Man-days remaining is the di€erence
between total job size in man-days and the cumulative
man-days expended. Man-days remaining divided by
the time remaining indicates the level of work force
needed. Comparing this needed work force to the
available work force will in¯uence the hiring/®ring
policy of work force which in turn will determine the
work force level available.
The second loop is also a negative feedback loop
but with three stocks. The loop determines how pro-
ductivity is perceived and the job size (work load) is
adjusted. It is assumed that the productivity perceived
is not the actual productivity as the fraction of draw-
ings/documents needing rework will take some time to
discover. The assumed development productivity deter-
mines the change of job size in man-days which later
a€ects man-days remaining and, consequently, the
work force level.
The third loop is a positive feedback loop with three
stocks. It controls how schedule date is maintained or
adjusted based on the available work force level and
the resistance to change in schedule date. A detailed
explanation of the model construction is available in
Ref. [30].
404 S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419

Fig. 1. Major feedback loops of the design project model.

4.2. The human resource management subsystem
Fig. 2 shows the details of the human resource sub-
system. Design work force can be of two types: new
work force (WFNEW, see Appendix A) and experi-
enced work force (WFEXP, see Appendix B). This
di€erentiation captures the di€erences in productivity
between the two groups.
4.3. The design production subsystem
The detail design of a civil engineering project starts
with analysis of preliminary estimated dimension and
is followed by re®nement through successive calcu-
lations to seek the optimal dimension and compliance
with standards. The result of calculation is then trans-
formed to drawings and speci®cation documents on
which site construction will later be based. During the
calculation, there is usually no e€ort spent for check-
ing. Quality assurance or checking is done only on the
drawings. If an error is found in a drawing, only then
will the error be traced back to the design calculation.
The design production stage is divided into three
sectors: (1) manpower allocation (Appendix C), (2) de-
sign development (Appendix D) and (3) rework
(Appendix E).
 S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419
Fig. 2. The human resources subsystem.
4.4. The controlling subsystem
The controlling function has three elements:
measurement, evaluation and communication.
Measurement is to detect what is happening, evalu-
ation is to compare what is happening with what is
planned and communication is to report what has
been measured and decide further action. The sub-
system is further elaborated in Appendix F.
4.5. The planning subsystem
In the planning subsystem (illustrated in Fig. 3),
initial project estimates are made to start the project
and the estimates are revised as necessary throughout
the project life.
Schedule completion date (ScheduleDate) represents
the number of working days planned for the project.
By subtracting the current value of TIME, which
represents the number of working days elapsed in a
simulation run, we can determine the schedule time
405
remaining (TimeRemain). Dividing MD Remaining
by TimeRemain gives the indicated work force level
(WFINDC) at any point in the project. If WFINDC is
lower than TotWF, Excess WF could be transferred
out of the project. If WFINDC is larger, then more
people would be brought in.
Work force level needed (WFNEED) is formulated
as a weighted function of current TotWF and
WFINDC as follows:
WFNEED ˆ WFINDC*WCWF
‡TotWF*…1 ÿ WCWF † …10†
Where WCWF (willingness to change work force)
is a variable which has values between 0 and 1. Setting
WCWF = 1 re¯ects the willingness to change work
force level or concern on schedule stability. On the
other hand, setting WCWF = 0 shows that the
concern is to stabilize work force and its level is not
changed anymore.
406 S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419

Fig. 3. The planning subsystem.

5. Testing the design model
Design work is intangible and creative. The ®nal
product is in the form of calculation sheets, drawings,
speci®cations and other documents. Sourcing data for
testing the model proved dicult. Most design prac-
tices approached do not keep detailed records of man-
power planning and usage. The experience showed that
design oces have poor records on the running of
their projects.
Data needed to run the model include total planned
duration, planned man-hours/days, planned man-
power loading, total documents produced, average
design productivity (documents per man-day), amount

Table 1
A comparison of actual result and model output
Actual Simulated base run
WWR Project
Cumulative work-days 4,554 (with 723 days of overtime work) 4,588 (with 358 days of overtime work)
Scheduled completion time 220 days 218 days
E€ort for checking and rework 10% (455 work-days) 7% (311 work-days)
Peak work force level 56 people (around day 176±198) 48 people (at day 174)

AFBC Project
Cumulative work-days
Scheduled completion time
E€ort for checking and rework
Peak work force level
21,286 (no overtime data) 20,896 (with 710 days of overtime work)
not available (268 planned) 282 days
10% (2,128 work-days) 11% (2,240 work-days)
114 people (around day 100±125) 90 at day 240
 S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419 407

of rework and e€ort spent for checking and rework.
Additional qualitative data include task distribution
e€ect, communication losses, e€ect of schedule
pressure on overtime, etc. They are based on senior
engineer's judgment.
The model, as developed, is aimed at projects with
duration long enough to allow for hiring and attrition
and having about 10 or more design sta€. As such, it
cannot be tested with just any civil engineering design
project. The two projects used for testing the model
are referred to in this paper as the WWR project and
the AFBC project.
5.1. The WWR project
The WWR project covers the preparation of master
plan for an area of 86.5 km2 of which 16.95 km2 are
subject to detailed design of drainage, sewerage and
waste water treatment systems in the Rayong province
of Thailand. The detailed design part was initially
planned for 9 months but ®nished in 10 months. There
was underestimation of work (around 20% of total)
which was realized mainly during the seventh and the
eighth months. The underestimation was attributed
to the lack of clear de®nition of project scope and
optimism in predicting the productivity of the design
team. Most design team members were responsible for
more than one project at the same time. Only three
persons concentrated solely on the project. On average,
it was estimated that most team members were work-
ing on two projects at the same time. The team esti-
mated that the e€ort spent on quality assurance was
around 10% of the total time. 85% of the team mem-
bers were senior designers. Additional designers, when
needed, were usually transferred from sister companies.
The average time need to e€ect a transfer was one
month.
A detailed plan of manpower used for each docu-
ment was not available, but a rough allocation of key
persons to the project was obtained. The oce did not
establish formal control procedure for the project. As
such, assessment of progress and the need to add to or
decrease sta€ level was based solely on the judgment
of the project engineer.
5.2. The AFBC project
The AFBC project is an engineering procurement
contract for natural gas compression in Indonesia. It
covered the design, procurement of equipment and ma-
terials, installation of gas gathering, separation, dehy-
dration and compression plant. Total planned duration
of the whole project was 26 months (March 1993 to
July 1995. The engineering was planned for 268 days
(March 1993 to December 1993). The project was
planned in detailed using a computerized project man-
agement software.
The result of the base run using data from the two
projects are shown in Table 1. The results show fairly
good agreement between actual results and thus con-
®rms that the model is a good replication of reality
(see Fig. 4). This is an important step in proving that
the model can be used for any civil engineering design
project.
6. Policy analysis and design
The advantage in creating a SD model of project is
that it can serve as a laboratory for experimentation.
The modeller's desire is to improve project behaviour.
The two options available for achieving this goal are
parameter changes and structural changes.
6.1. Parameter changes
Parameter changes involve changes in the values of
constants and variations in the shape of graph func-

Table 2
Comparison of di€erent policy runs
No. Simulations WWR Project AFBC Project

1 base run
2 good estimation
3 good progress control
4 good estimation and good progress
control
5 quicker realization of
underestimated work
6 no overtime
7 manpower allocation
4,588 work-days (including 368 days of
overtime work); 218 days
4,529 work-days (including 168 days of
overtime work); 208 days
4,453 work-days (including 45 days of
overtime work); 201 days
4,474 work-days (no overtime); 198 days
4,543 work-days (including 179 days of
overtime work); 209 days
4,369 work-days; 223 days
4,409 work-days; 205 days
20,896 work-days (including 710 days of
overtime work); 282 days
20,878 work-days (with 515 days of
overtime work); 279 days
20,596 work-days (including 1.37 days of
overtime work); 268 days
20,688 work-days (including 1.35 days of
overtime work); 268 days
20,700 work-days (including 542 days of
overtime work); 279 days
20,493 work-days; 285 days
ÿ
408 S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419

Fig. 4. Test runs on the AFBC and WWR projects.

tions. The modeller changes the values of parameters
which are within the project manager's control in
the real world. These parameters are called policy
parameters. Changing their values correspond to policy
changes. Before e€ecting the changes, the modeler
must be satis®ed that the changes can be made in the
real world being modeled. Parameter changes that can
be experimented with are listed below;
(1) The number of projects a design team member
can be involved in at the same time.
(2) Time required by a new design team member to
fully understand the project. This can be improved
through training.
(3) The use of overtime work to speed up the design
process.
(4) Time delay in e€ecting corrections to drawings.
(5) The willingness or reluctance to adjust schedule
which may be limited by contract.
(6) The spread of project activities. Usually parallel
activities are more during the peak of the project.
(7) Discovery of underestimation which may be due
to unanticipated changes but can be e€ected through
scope de®nition and contract arrangement.
(8) Willingness to change work force. This is e€ected
through hiring policy.
(9) The accuracy of productivity assessment.
6.2. Structural changes.
permit experimentation with di€erent policy options.
The policy changes experimented with are listed below
and the results shown on Table 2;
(1) Good estimation of project scope. This is e€ected
by setting the value of underestimation fraction to
zero. The result (Table 2) showed a better performance
in reducing duration and leveling of work force.
Absence of underestimation reduces changes to scope
and additional e€orts are needed only to correct draw-
ings. Overtime use can be reduced and sudden changes
to work force eliminated. This accords with project
management literature (Refs. [31, 32], for example).
(2) Good control of work progress. This is possible
if there is a good perception of real progress. In the
model, it is implemented by making assumed develop-
ment productivity, a value used to adjust job size,
to be more of perceived productivity than projected
productivity. The result showed signi®cant improve-
ment (Table 2). Improved progress assessment can be
achieved through better measurement method to re¯ect
real progress rate of time, cost (man-hour) and work.
Table 3
Scheduled
completion
Run Cumulative work-days (days)

Structural changes are changes in the feedback struc- Base run 4,588 (including overtime 368 218
ture. This policy experimentation is more e€ective than work-days)
parameter changes as it focuses on di€erent ways of Scenario 1 5,223 (including overtime 640 241
doing things. The base run for the model replicates work-days)
normal practice very well. However, it contains ¯aws Scenario 2 4,916 (including overtime 284 213
work-days)
inherent in design management practice such as under-
Scenario 3 4,988 (including overtime 327 216
estimation of work, misperception of progress and
work-days)
rework. To aid design management, the model should
 S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419
(3) Combined policy of good estimation and pro-
gress control. It showed signi®cant improvement and
removes overtime use as schedule pressure is elimi-
nated.
(4) Quicker realization of underestimated work. This
means that additional tasks are discovered at a faster
rate and after 60% progress, there are no additional
tasks. The change improved project baselines, as
management will be able to make better work force
arrangement for the project.
(5) Stang policy is critical to schedule attainment.
In design management, a schedule date is established,
man-hours are then estimated and the project stang
is decided. The obvious problem is to keep the sta€ as
small as possible to minimize overhead and communi-
cation losses while meeting the schedule. Options may
include: overtime work, contract sta€, increasing per-
manent sta€ and using CAD systems to reduce draft-
ing and engineering time. The policies implemented are
listed below:
(i) No overtime policy: This resulted in schedule slip-
page but reduced cumulative man-days. This implies
that the extra time spent in the base run to speed up
project is due to overtime.
(ii) Manpower allocation policy: This concerns the
number of projects a member of sta€ is allocated to.
While some companies allocate sta€ to one project
only, pressure of time and design priorities and man-
power availability may force some companies to move
sta€ around projects. The result for one project
showed that assigning sta€ to one project only signi®-
cantly improves performance as assimilation is better.
6.3. Scenario analyses
SD modeling allows management to experiment with
possible scenarios during the implementation of a pro-
ject. The analyses conducted with the design model are
shown in Sections 6.3.1, 6.3.2 and 6.3.3.
6.3.1. Scenario 1: Shortage of experienced work force
In this run, market condition e€ect on hiring is
assumed to be 0.25 instead of 0.85. During peak
demand for design services in the industry, manage-
ment will not be able to hire as many experienced
workers as are needed. It is here assumed that three
quarters of the work force are hired from new work
force and only one quarter are available from the ex-
perienced work force. Management needs to know
how the use of new work force will a€ect the project.
6.3.2. Scenario 2: Scenario 1 plus manpower allocation
policy
Shortage of experienced work force forces manage-
ment to use part-time work force.
409
6.3.3. Scenario 3: Scenario 2 plus sudden departure of
experienced work force
The management needs to know what will happen
to the project if there is a sudden loss of experienced
work force in the course of the project. This may
happen in a very competitive market environment or
for any other reasons. Here the quit rate of experi-
enced work force is reformulated to show a sudden
loss of 5 experienced workers at day 100 as follows:
QuitRt ˆ WFEXP=AvEmploy ‡ Pulse…5,100,1000† …11†
Scenario analysis can enable design managers to
manage by perception and thus prevent/reduce the
need for crisis in a dicult project environment. The
results from the simulations are shown in Table 3.
Scenario 1 will force the project to consume much
more man-days and to ®nish late. This is due to the
longer time in hiring new work force, additional time
and e€ort to train/guide them and lower productivity.
Scenario 2 shows improved result since by allocating
more of the design team's time to the project, or con-
verting part-time to full-time, means lesser new work
force is needed. This shows that a small team consist-
ing of experienced work force is better than a large
team with many inexperienced workers.
The result of scenario 3 is not much di€erent from
scenario 2. In this model, the work force is an aggre-
gate quantity, di€erentiated only for experience. In
reality, the absence of some key personnel may cause
the project to stop.
7. Conclusions and further research
A survey of 110 design practices in the U.S.A. [31]
has identi®ed 10 major concerns of design ®rms in
order of frequency of mention as (1) making a pro®t/
budget; (2) meeting schedules and deadlines; (3) change
order and/or scope management; (4) internal com-
munications; (5) quality control; (6) client communi-
cation; (7) lack of experienced sta€ and/or PMs;
(8) low fees/determining fees; (9) planning/scheduling
and (10) time management. These are management
problems created mainly due to poor management
in design ®rms. A model of the design process has
been constructed which incorporates most of the
problems identi®ed by Birnberg. The model, when
tested with data from two large design projects, repli-
cates ®eld practice well and has also been simulated
to show that improvements can be made through
policy changes. However, not all changes are ben-
e®cial. The results of experimentations with two design
projects show the following policy hierarchy for meet-
ing project deadlines: (1) good progress control; (2)
ecient manpower allocation; (3) accurate estimation
Fig. 5. E€ect of market condition on hiring.

Fig. 6. The manpower allocation sector.

 S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419
of workload and (4) early realization of under-
estimated work. If the goal of management is to reduce
cost, then ecient manpower allocation is better than
progress control.
SD modeling is a powerful tool for experimenting
with possible, even extreme, scenarios in project
management. It can uncover ¯aws in practices which
in the short run may seem to improve performance but
are not bene®cial on the long run. Model experimen-
tations can isolate a system and show the e€ects of
changes in the real world situations. The model
described has shown that civil engineering design can
bene®t much from SD modeling.
It has been suggested that SD modeling should
complement traditional project management tools. A
good combination could be to model the whole project
using SD at the beginning but to micro manage the
details of the project using traditional tools like the
CPM. The SD model will serve to inform the manage-
ment on the likely impacts of di€erent policies while
the CPM will be a tool for e€ecting chosen policies. It is
Fig. 7. The design development sector.
411
unlikely that a single model incorporating a traditional
model and a SD model will ever be constructed as the
two focus on di€erent aspects of a project.
The design model, as constructed, does not dis-
tinguish between drafters and designers. This needs to
be improved through the segregation of the functions.
The model also does not consider the eciency of
overtime usage. It should be possible from actual
records to build eciency considerations into the
model. Finally, projects are managed at the ®rm level,
it is desirable to expand the model for overall ®rm
management.
Appendix A. New work force
The new work force is formulated as below:
WFNEW ˆ INT…WFNEW †
‡ dt…NewHire ÿ AssimRt ÿ NewTr† …A:1†
412 S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419

Fig. 8. Fraction of experienced work force e€ect.

where INT(WFNEW) is the initial number of new
work force (people), NewHire is the hiring rate of new
work force (people/day), AssimRt is the assimilation
rate of new work force (people/day) and NewTr is the
new work force transfer rate (people/day).
Many companies recruit graduates from universities.
If these new engineers have enough knowledge
in design beforehand, then the overhead needed to
train them, trainers per new hires (Trainer per New), is
low. In a di€erent situation, it may be hard to ®nd

Fig. 9. Task distribution e€ect on productivity.

 S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419
quali®ed engineers and thus more e€ort will be needed
to train them. In this model, Trainer per New is set
to 0.1 which means, on the average, each new hire
consumes, in training overhead, the equivalent of 10%
of an experienced employee's time for the duration of
the training or assimilation period. This is formulated
as
Daily MP f training ˆ WFNEW*
Trainer per New Daily MP f training
ˆ Daily manpower for training …A:2†
Hiring of WFNEW has a ceiling since they need
WFEXP to train them. As such, it is restricted by the
number of WFEXP. In the model, The maximum
number of new hires per experienced sta€ (MNHPXS)
is set to 5.
CeilNew ˆ EquivFullExp*Trainer p New …A:3†
Where CeilNew is the ceiling on new hires and
EquivFullExp is the full time equivalent experienced
work force. EquivFullExp is introduced since one sta€
may be allocated to handle more than one project at
the same time.
EquivFullExp ˆ WFEXP*ADMPPS …A:4†
Where ADMPPS = average daily manpower per
sta€. A value of 0.5 for ADMPPS means one person
is only working half time for the project or is handling
two projects at the same time.
Fig. 10. The e€ect of overtime on productivity.
413
Appendix B. Experienced work force
The experienced work force is written as:
WFEXP ˆ INT…WFEXP †
‡dt…ExpHire ‡ AssimRt ÿ ExpTr ÿ QuitRt† …A:5†
where INT(WFEXP) is the initial number of work
force experienced (people), ExpHire is the experienced
work force hire rate (people/day), ExpTr is the
experienced work force transfer rate (people/day) and
QuitRt is the experienced work force quit rate (people/
day).
The transfer rate of experienced work force is
formulated as:
ExpTr ˆ MIN…WFEXP, TrRt ÿ NewTr† …A:6†
By including NewTr in Eq. (A.6), the transferring of
people out of the project, when there is a manpower
surplus, will start with WFNEW.
Hiring of new or experienced work force is a€ected
by market conditions. When demand is high, experi-
enced work force shortage will occur. In this case,
usually only new work force member can be employed.
This market condition is formulated as a table func-
tion. Its shape can be adjusted to re¯ect the market
condition when the project is on-going. Fig. 5 depicts
a scenario where initially all of the hired work force
are experienced and sometime later only half of them
can be hired.
414 S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419
Appendix C. The manpower allocation sector
This sector is shown in Fig. 6. Full-time equivalent
daily manpower (FullTimeEqvDailyMP) available for
the project is the product of TotWF and ADMPPS.
ADMPPS can have values between 0 and 1 depending
on management decision to assign a sta€ fully to
one project or more. Some part of the available man-
power will be consumed in guiding and training
(DailyMP f training). The daily manpower available
after training overhead is what is then allocated to
rework and design development.
From literature and the interviews conducted, there
were no records or exact ®gures on e€ort spent
for checking and rework in a project. Estimates by
some project engineers range from 5 to 15%. In
the model, the average manpower required to
check and rework a document needing rework
(ReworkMP p Doc) is assumed to be 5 man-days.
This value can be adjusted for di€erent projects. As
design errors are detected through checking, some
e€ort is allocated to correct them. The amount of
manpower for rework (DailyMP f Rework) is formu-
Fig. 11. The rework sector.
lated as a product of Rework Rate and Rework man-
power per document.
Appendix D. The design development sector
Fig. 7 illustrates this sector. The design development
process produces calculations, drawings, speci®cations,
estimation of material (bill of quantities) and cost and
some other documents. Physically, the work size of a
design project can be measured by the total number of
documents to be produced.
Design development productivity (DesignDevProd)
is a function of a complex set of factors. In this model,
it is formulated thus. Normal gross productivity is the
average rate at which documents are produced. It is
estimated by dividing total planned manhours for de-
sign development by total planned documents. Here,
the contribution of di€erent designers or drafters are
di€erentiated. It is simpli®ed in terms of average e€ort
needed per average document. In reality, there are
di€erent types of documents and each type requires
di€erent amount of e€ort of designers and drafters.
This normal gross productivity is then e€ected by the
S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419 415

Fig. 12. Desired rework delay.

Fig. 13. The controlling subsystem.

416 S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419
Fig. 14. Adjustment of job size.
fraction of experienced work force, task distribution
e€ect and communication.
The productivity of an experienced worker is
superior to that of a new worker. Here it is assumed
that the productivity of an experienced work force is
twice that of a new work force. The e€ect of the frac-
tion of experience is, therefore, formulated as a graph
function to capture this assumption as in Fig. 8.
Task distribution e€ect has substantial in¯uence on
productivity. The value of the design productivity rate
is not constant throughout the project time. Usually,
in the middle of a project, there will be more parallel
activities and similar tasks to do which need less e€ort.
Since productivity is here de®ned as the number of
documents produced per man-day, then at this particu-
lar time the productivity rate will be higher. Task dis-
tribution e€ect increases normal gross productivity
when there are repetitive works and will have no e€ect
through the end of project due to lack of similar work
and parallel activities. This is illustrated in Fig. 9.
Communication losses is the average team member's
drop in productivity below the normal productivity
as a result of additional team communication, where
communication includes verbal communication, docu-
mentation and other additional work due to interfaces.
This happen when the team size is bigger than what is
actually required. This communication overhead varies
with the project size. It depends on the normal size of
the project team. Normal size of project team is
de®ned as total number of people needed in a project.
Communication losses is really a square function of
total people involved. Here it is assumed that when
the size of the project team is twice that of a normal
one, there is a 10% loss in total productivity.
Communication losses or overhead then is formulated
as follows:
CommunicationOH ˆ NormalComLoss
…TotWF=NormalTeamSize†2 …A:7†
The design development rate is determined by
designers' productivity and is increased when designers
work overtime. Longer hours spent on the project by
the design team will result in more work being done,
but the work done per unit of time decreases due to
fatigue e€ect. This overtime e€ect on the productivity
 S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419
Fig. 15. Percent of work underestimation discovered.
is formulated as:
OVTEffect ˆ OVTEffectfunction
‰NormalWorkHour ‡ OvertimeŠ=
NormalWorkHour …A:8†
Where NormalWorkHour is the normal working hours
per day (8 h) and OVTE€ect function is a graph func-
tion shown in Fig. 10.
Appendix E. The rework sector
Design quality assurance includes two distinct and
complementary methodologies. The ®rst is designing a
coherent, complete, unambiguous and non-con¯icting
set of requirements. The second is review and checking
of the design. Errors, however, will still occur due to
human inability to perform with perfection. The for-
mer methodology will e€ect the normal fraction satis-
factory of the drawings produced. The later will e€ect
the discovery and rework rate of drawings needing
rework.
It is assumed that at the beginning, the fraction of
documents needing rework is larger and as the work is
progressing, the fraction satisfactory will be higher due
to the team's better knowledge of the work (Fig. 11).
New work force members do not only have lower
productivity but are also more prone to errors. As
such, a high fraction of new work force will increase
the errors produced. It is assumed that new people are
417
twice more prone to errors than experienced work
force. Normal fraction satisfactory then is adjusted by
the work force mix multiplier function which has the
same shape as in Fig. 8.
There are two types of documents being produced
depending on the fraction satisfactory. These are docu-
ments needing rework and those not needing rework.
Documents needing rework are not discovered initially
because it takes time to detect them. After documents
needing rework are discovered, they accumulate into
documents to rework (DocToRework). This stock is
depleted through rework rate.
When an error is detected and rework is needed,
usually it is not immediately done. This delay depends
on the schedule pressure and urgency of other projects
in the company. The delay is longer at the beginning
but shorter towards the end of a project. This is then
formulated as a graph function a€ected by perceived
progress as shown in Fig. 12.
Appendix F. Details of the controlling subsystem.
Figs. 13 and 14 show the details of the controlling
subsystem. Measurement of design work is dicult
because design is a creative process that involves ideas,
calculation, evaluation of alternatives and other tasks
that are not physically measurable quantities.
Considerable time and cost are expended in performing
these tasks before end results such as drawings, speci®-
cations, reports, etc. (which are measurable quantities
418 S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419
of work) are ever seen. Due to this intangible char-
acters of design, and especially in the early phase,
progress is measured by the rate of expenditure of
resources rather than by some count of accomplish-
ments. Only towards the end of the project can the
real progress design be assessed more accurately.
To capture this phenomenon, the assumed develop-
ment productivity (AssumeProd) is formulated as
the weighted average of perceived development pro-
ductivity (PercvProductivity) and projected develop-
ment productivity (Projected Productivity) as
AssumeProd ˆ ProjectedProductivity*…WTPJDP †
‡PercvProductivity*…1 ÿ WTPIDP † …A:9†
WTPJDP is a weighting factor, varying from 1 at the
beginning of the project to 0 at the end of the develop-
ment phase.
In the early phase, man-days perceived still needed
for new documents (MDNeeded f NewDoc) is equal
to man-days perceived remaining for new documents
(MD f NewDoc). So, projected productivity can
be calculated as documents perceived remaining
(DocPercvRemain) divided by man-day perceived
remaining for new documents (MD f NewDoc).
Perceived productivity (PercvProductivity) is de®ned
as cumulative documents developed not needing
rework (CumDocNotNeedRework) divided by cumu-
lative development man-days (CumDev MD). Total
man-days perceived still needed for new docu-
ments (MD StillNeeded) is the summation of
MDNeeded f NewDoc and MD f Rework.
The discovery rate of work underestimation here is
e€ected by a graph function which shows that at
the beginning only a small percentage of the under-
estimation is realized and when more work is done, a
higher percentage of underestimation is recognized (see
Fig. 15). When this happens, the size of the job is
adjusted. The additional e€ort for this discovered
underestimation is calculated based on the assumed
development productivity. The job size in man-days
(JBSZMD) is further adjusted due to the e€ort spent
for rework.
References
[1] Barrie D, Paulson BC. Professional Construction
Management. McGraw Hill, New York, 1992.
[2] Sawczuk B. The management of the design process. In
Architectural Management, ed. M. P. Nicholson. E&FN
Spon's, London, 1992.
[3] Coles EJ. Planning building design. In Architectural
Management, ed. M. P. Nicholson. E&FN Spon's,
London, 1992.
[4] Richardson GP, Pugh AL. III, Introduction to SD model-
ing with DYNAMO. MIT Press, Cambridge, MA, 1981.
[5] Chang CL, Ogunlana SO, Saeed K. Construction Project
management: A system dynamic model. System
Dynamics `91. Bangkok, 1991, pp. 108±115.
[6] Stermann JD. System dynamics modeling for project
management. Paper on World Wide Web page,
Directors, Sloan School of Management, 1992.
[7] Richardson G. Feedback Thought in Social Science and
Systems Theory. University of Pennsylvania Press,
Philadelphia, 1991.
[8] Rodrigues A, Bowers J. System dynamics in project man-
agement: A comparative analysis with traditional
methods. System Dynamics Review 1996;12(2):121±39.
[9] Roberts E. The Dynamics of Research and Development.
Harper and Row, U.S.A., 1964.
[10] Kelly TJ. The Dynamics of R&D Project Management.
MITMS Management, 1970, p. 300.
[11] Jessen SA. Can project dynamics be modeled? Proc. 1988
Int. Conf. Syst. Dynam. Soc. 1988, pp. 171±187.
[12] Keloharju R, Wolstenholme EF. A case study in system
dynamics optimization. J. Opl. Res. Soc. 1989;40:221±30.
[13] Abdel-Hamid TK. Understanding the 90% syndrome in
software project management: A simulation case study.
J. Syst. Soft. 1988;8:319±30.
[14] Abdel-Hamid TK. The dynamics of software project
stang: A system dynamics based simulation approach.
IEEE Trans. Software Eng. 1989;15:109±19.
[15] Abdel-Hamid TK. Investigating the impacts of manage-
rial turnover/succession on software project performance.
J. Man. Inf. Systems 1992;9:127±44.
[16] Abdel-Hamid TK. A multi-project perspective of single-
project dynamics. J. Syst. Software 1993;22:151±65.
[17] Abdel-Hamid TK, Madnick SE. The elusive silver lining:
How we fail to learn from software development failures.
Sloan Management Review, 1990, Fall, 39±48.
[18] Abdel-Hamid TK, Madnick SE. Software Project
Dynamics: An Integrated Approach. Prentice Hall, New
Jersey, 1991.
[19] Barlas Y, Bayraktutar I. An interactive simulation game
for software project management (SOFTSIM). Proc.
Syst. Dyn. 1992, pp. 59-68.
[20] Smith BJ, Nguyen H, Vidale RF. Death of a software
manager: How to avoid career suicide through dynamic
software process modeling. American Programmer
1993;3(5):10±17.
[21] Chichakly KJ. The bifocal vantage point: Managing soft-
ware projects from a system thinking perspective.
American Programmer 1993;6(5):18±25.
[22] Lin CY. Walking on battle®elds: Tools for strategic soft-
ware management. American Programmer 1993;6(5):33±
40.
[23] Aranda RR, Fiddaman T, Oliva R. Quality microworlds:
Modeling the impact of quality initiatives over the soft-
ware product life cycle. American Programmer
1993;6(5):52±61.
[24] Cooper KG, Mullen TW. Swords and plowshares: The
rework cycles of defense and commercial software devel-
opment projects. American Programmer 1993;6(5):41±51.
[25] Pugh Roberts Associates, PA Consulting Group,
PMMS-Program Management Modeling System Pugh
Roberts Associates, U.S.A., 1993.
 S. Ogunlana et al. / Computers and Structures 67 (1998) 401±419
[26] Saeed K. Contract design for large scale civil works pro-
jects or sowing seeds for harvesting court battles.
Presented at Towards the new millenium: Living, learn-
ing and working. 1994 Annual Conference of the World
Future Society. Cambridge, MA, U.S.A., July 24±26,
1994.
[27] Huot JC, Sylvestre Y. An application of SD to the con-
struction of a major building. System Dynamics `85, Vol.
1. Colorado, U.S.A., 1985, pp. 384-409.
[28] Rodrigues A, Bowers J. The role of system dynamics in
project management: A comparative analysis with tra-
ditional models. In System Dynamics: Methodo-
419
logical and Technical Issues, Proceedings of System
Dynamics `94. Sterling, Scotland, 1994, pp. 214±225.
[29] Rodrigues A, Bowers J. The role of system dynamics in
project management. International Journal of Project
Management 1996;14(4):213±20.
[30] Lim J. Management of civil engineering design projects:
A SD model. MEng. Thesis No. St-94-10, Asian Institute
of Technology, Bangkok, Thailand, 1994.
[31] Birnberg HG. Project Management for Small Design
Firms. McGraw Hill, New York, 1992.
[32] Oberlender GD. Project Management of Engineering and
Construction. McGraw Hill, Singapore, 1993.