Simulation of a Distributed Design Project
Sampsa Ruutu (1), Peter Y lén (2), Mikko Laine (3)
(1) VTT Technical Research Centre of Finland
P.O. Box 1000, FI-02044 VTT, Finland
+358 40 7202883
sampsa.ruutu@vtt.fi
(2) VTT Technical Research Centre of Finland
P.O. Box 1000, FI-02044 VTT, Finland
+358 40 5077474
peter.ylen@vtt.fi
(3) Poyry Industry Oy
Jaakonkatu 3 (P.O. Box 4), FI-01621 Vantaa, Finland
+358 50 3123685
mikko.laine@poyry.com
Abstract
Dissemination of system dynamics to project management practitioners is not as
widespread as its use for project management theory building within the system dynamics
community. This article presents a decision support and training project model built for a
global consulting and engineering company. The simulation model comprises the most
important work phases within the detail engineering phase of a large investment project in
three offices. The model was validated using data from several past projects and in
workshops with the company. A user interface was built to aid dissemination and use of the
model. The purpose of the model is the bottleneck analysis and simulation of an ongoing
engineering project, as well as the simulation of quality, scheduling, and profitability issues
when outsourcing parts of the detail plant engineering.
Keywords: distributed project, system dynamics, simulation, decision support, design
service
Introduction
Projects have many interdependent components making them dynamically complex. In
addition to the numerous work phases performed internally, supplier and customer
information has to be managed as well. System dynamics models of project work are
typically based on some form of the “rework cycle” (Cooper 1980, Abdel-Hamid 1984,
Ford & Sterman 1998) in which errors in project work generate rework slowing down
progress. These models also include feedbacks and unintended consequences from
managerial decision making, such as changes in personnel resources, overtime and faster
work, deadline changes, and managerial forecasting of performance. While system
dynamics has been widely and successfully used to model project work, there is still much
work to be done in disseminating theory built using system dynamics to project
management practitioners. (Lyneis & Ford 2007).
The propagation of errors between work phases (Ford & Sterman 1998) and the distinction
between rework due to errors and due to external change requests (Park & Pefia-Mora
2003) have been presented in the system dynamics literature. In this paper, we distinguish
between three types of rework: errors generated in a particular work phase, errors inherited
from upstream work phases, and change requests because of quality problems in the
external purchase process. We find this categorization useful in pinpointing the causes of
problems in particular work phases. This distinction is important because of the
fundamental attribution error: it is helpful to show that the reason for rework is in the
process, not in employees working on a particular work phase.
Dividing work into various offices around the world has many benefits, such as work load
balancing and the ability to use cost effective resources and local know-how. However,
geographical distances between offices slow down communication because of slow data
comnections and time differences. Information delays due to slow data connections vary
between few hours to weeks, and information delays due to time differences depend on the
direction of information flow. Employees from different cultures also behave differently,
which needs to be considered in distributed projects. For example, cultures differ in the
degree employees make independent decisions without supervisor guidance and how they
evaluate tradeoffs between schedules and work quality.
While these issues are important, to our knowledge they have not been addressed in the
system dynamics literature. In this paper, we model employee differences in different
offices by taking into account different experience levels, productivities, work qualities
when prerequisite information is not available, and price levels. We also model the effect of
distributed work to employee productivities.
Problem definition and scope
This article presents a system dynamics simulation model done for Poyry, a global
consulting and engineering company focusing on the energy, industry, urban & mobility,
water & environment, and management consulting sectors, with operations in 50 countries.
The company is interested in developing project management support tools for large
distributed investment projects. The purpose is to use the model in the bottleneck analysis
and simulation of an ongoing engineering project, as well as in the simulation of quality,
scheduling, and profitability issues when outsourcing parts of the detail plant engineering.
The focus of the model is in the detail engineering phase of an investment project preceding
the construction phase. The scope of the model is one project and the time horizon
approximately two years. In the beginning of a project, a start-up date for a factory plant is
set. This date is fixed, and must not depend on how well the planning and construction
phases are implemented.
Insufficient data being the most common cause for errors and incompatibilities in design,
one aim for the simulation model is to show the effects of delayed customer and supplier
data. It is common for Péyry’s clients and suppliers to underestimate the effects of small
changes which can cause dramatic effects to the whole project, including large costs in the
construction phase. The simulation model can also be used for pricing change orders in the
future.
Six engineering disciplines are included in the model: process, instructions and standards,
mechanical, piping, electrical, and automation. The process design phase, which includes
procurement services affecting the client’s purchase process, is the first part in detail
engineering and provides base information for all other disciplines. Each discipline is
divided into 2-5 sub disciplines constituting 22 individual work phases, and the workforce
is divided along the engineering disciplines. In real life there are still many more disciplines
and work phases in a typical project. For example, one real project had 22 main disciplines
and a total of 184 sub disciplines. The scheduled start and end of each work phase are based
on real projects. The final deadline of the whole project is kept constant, but deadlines of
individual work phases can be postponed if there is too much schedule pressure.
In the model, work hour costs of the different engineering disciplines constitute the costs of
the project. Work hour price levels depend on the engineering discipline, office, and the
overall experience of the employees. A normal work week is assumed to consist of 40 work
hours, and overtime hours are assumed to cost the same as normal work hours. The
purchase process and supplier data acquisition are assumed to generate no work costs.
Workers generate costs as long as they are resourced to the project, ie. until a particular
workforce discipline at a particular office has finished its work.
Work phases and workforce
The amount of work in each work phase is estimated based on the number of deliverables,
such as the number of documents or database entries. The work units depend on the
engineering discipline. Péyry has adopted several Key Performance Indicators (KPIs) to
measure productivities in different engineering disciplines and sub disciplines, and KPI
values have been measured in earlier projects. The KPI values describe the number of hours
required to finish one unit of work and depend on the discipline, overall experience of
workers, and the office to which a work phase is assigned. The estimated number of
workers needed for a particular work phase can be calculated based on the amount of work,
KPIs, and project scheduling.
The required work rate for a particular discipline at an office depends on the ratio of work
left and time remaining to the deadline. The required workforce, which is calculated based
on the required work rate and estimated productivities, influences worker allocation to the
project. The use of overtime work is dependent on the required work rate, normal work
rate, and the available workforce, and can change more rapidly than the workforce.
Workers in each discipline are assumed to be able to work on all sub disciplines within a
discipline, but not on sub disciplines outside the discipline. Worker experience is modelled
along two dimensions: overall experience and project experience. Both dimensions can
have three values: novice, intermediate, or expert. Overall experience refers to the general
competence level that accumulates through multiple projects, and stays constant throughout
the simulation that encompasses only one project. The project experience of workers on the
other hand changes throughout the simulation. Since all projects are somewhat different,
even overall experts need some time to adjust to the intricacies of a new project. This is
why the project experience of all workers is set to novice at the start of the simulation.
Also, if new workers join the project at a later time, they begin as project novices. As time
progresses, workers become project intermediates and project experts. The higher the
overall experience level of the workers, the faster this progression is.
Project novices and intermediates need guidance from experts. This lowers the amount of
time experts can use to their actual work, effectively lowering their productivities.
Intermediate employees can help novices in simple tasks, but the final decisions are made
by the experts because of their higher knowledge. Overall, the workforce model (Figure 1)
has similarities with Oliva & Sterman’s (2010) experience chain and learning curve model.
ALLOCATION
TIME
Workforce ‘Trairfagin
Worktorcee | hoon
Deviation from Alocation raising TRAINING TIME OF
planned personnel mix \ \ PROJECT DEADLINE
Workforce ‘TrainingTime
<RecuiredW orkforce> Reallocation REALLOCATION
x —" TIME
3 Workiorce total
reallocation ae
tid \ Total work force per
overall experience group
DisciplineA tO fiiceReady
Figure 1 Workforce
Each office is assumed to have a fixed proportion of the overall experience groups, as well
as a fixed number of total available employees in each discipline during the course of one
project. Employee productivities as well as abilities to work based on incomplete
prerequisite information differ significantly.
Work rates
Workers are allocated to individual work phases based on the required work rate (work
units/week) of a particular phase. The required work rate is the ratio of active work ina
phase (i.e. not completed work that is scheduled to start) and the time left until deadline.
The workforce can be allocated entirely to the task with the highest required work rate,
proportionally to different phases based on their respective required work rates, or as a
weighted average of the highest priority task and proportional allocation. To model delays
in the allocation process, exponential smoothing is used to obtain the actual allocation.
The work rate (work units/week) of a particular phase depends on the number of employees
allocated to the work phase and their productivities. The productivity of novices is lower
than that of experts, and novices also require expert guidance which takes experts’ time
away from actual work. The use of overtime can increase work rate on the short run, but
prolonged overtime decreases productivity. The communication delay within distributed
projects is also included in the model. The work rate is lower when the proportion of
prerequisites done in other offices is higher.
Figure 2 shows the work rate of two sub disciplines, M40 and M50, and how the allocation
of workers to each phase changes throughout the simulation.
Work rate
@ M50
= M40
-13-7 -1 5 11.17 23 29 35 41 47 53 59 65 71 77 83 89 95
Week
Figure 2 Work rate for two work phases
Task concurrence and prerequisites
Prerequisites refer to data and work phases that must be sufficiently completed to proceed
in a further work phase. Prerequisites between phases are modelled using three
“prerequisite matrixes” (Figure 3): the limit 0%, limit 50%, and limit 100% matrixes. The
limit 0% matrix defines the proportion of preceding phases that needs to be completed to
start the following phase. The limit 50% and limit 100% matrixes define the proportion of
work that needs to be finished to complete half and completely finish the following phase,
respectively. As such, the prerequisite matrixes are similar to design structure matrixes.
Prerequisite phases (j)
Internal work | Purchase process j Supplier data
phases I phases I acquisition
1/2|/..Jnf1]2[.]nl1]2 n
T T T
Internal 21x i x
work 1 0 1
phases x | x ! [xx x
n x xX I LX x
Se ee ee a 4-----------=--------4
Purchase ZX dX ! !
2 'x !
process 1 1 0
phases x 1x 1
n x} x q
ns i Te] ff | po
Supplier data 2 I 3% I
1 1
acquisition ave 0 1x] x I 0
n ix[x x]
Figure 3 Prerequisite matrix
To calculate the possible completion of a following phase, piecewise linear functions are
used to interpolate between the three values defined by the prerequisite matrixes (Figure 4).
If a phase has multiple prerequisites, the possible completion for the following phase is the
minimum of individual limits. The shapes of the prerequisite limit functions are different.
Sometimes all the data is required already in the beginning of the work phase; sometimes
only a small part of it is required immediately and the majority only at the end. Ford &
Sterman (1998) have used a similar approach to model prerequisites in product
development. The main difference in our approach is the use of prerequisite matrixes to
handle numerous prerequisites and to generate the prerequisite functions.
100%
50%
Phase completion possible
== Prerequisite 2
Prerequisite 1
0%
0%
Limit Limit
0% 0%
Current
completion
Current
completion
Prerequisite completion
Figure 4 Prerequisite function
Purchase process and supplier data acquisition
The quality and timeliness of the purchase process and supplier data, which influence work
phases dependent on supplier data, depend on the competencies of the suppliers and the
client. The purchase process is assumed to start as scheduled. Supplier data acquisition
follows the purchase process with a delay, after the prerequisites defined in the prerequisite
matrixes have been met.
Purchase to Purchase in Purchase
be started |" Purchase start rate L-PMgess | purchase Leompleted
completion
Supplier data Supplier data pp| Preinary Vendor data
notreaty [purse may [2 Be acautedProinieay dem | Yemor deta [~paftaia[_complete
acquisition rate acquisition rate
Figure 5 Purchase process and supplier data acquisition
Clients and suppliers have a rating in Péyry’s system. The closer the partner's working
culture is to Poyry’s, the smoother the communication. A long common history of working
together makes collaboration easier.
After a client decides to order a certain part from a supplier, the supplier is required to
deliver preliminary data in approximately a week. The preliminary data are usually based
on a similar earlier project and are not totally accurate, but can be used to begin design
work. The final data are delivered in a few months. The supplier's know-how and
experience affect the amount of deviations delivered within the data, the general precision
of the data, and their timeliness.
Errors and rework
A rework cycle where different work phases are modelled using arrays (Vensim®
subscripts) is used in the model (Figure 6). In the model, errors are grouped into three
categories: errors generated in a particular work phase, errors propagated from other work
phases, and errors resulting from the purchase process. It is normal to have some errors
generated in work phases, but the use of overtime and by the lack of prerequisite
information increase the number of errors.
WorkToBeDone |___~se
>
Original WorkRate | work
Original | Complete
[=| WoikToBeDone
EnviConection | — WorkRate cl
sis
~— “detected
Ose] mos
TableForEnrorDetection Enor | Undetected
Generation
AverageEnor Rae
DetectionTime
~~ betectedPhasetiros
by type
Unidetected envi left
after phase error detection
DetectedPhaseEnors ’
ct ' ProportionOf Detected
on DERE gs Reworko? — Propagated
Propagation> a CompletedW ork Emors by type
DetectedPropagatedErors
Figure 6 Rework cycle
The simulation of a complex detail engineering project did not at first yield realistic results
using the values in the prerequisite matrixes that were collected. A solution to the problem
was found from the real world: when data is not available but engineering needs to progress
to keep the schedule, experienced engineers use heuristics, or educated guesses and
intuitive judgment. These decisions may prove correct or incorrect when data later become
available, depending not only on luck but also on the skill and experience of the engineer.
The accuracy of the heuristics increases with experience as engineers are able to use tacit
knowledge gained in earlier projects. Heuristic accuracies also depend on the composition
of the work team. If there are enough experts in the team, novice workers do not have to
resort to their own less accurate heuristics. Heuristic accuracies also depend on the office
due to different working standards and cultures.
Let n,, nz, 3 be the numbers of overall novices, intermediates, and experts in a work team,
P12 the number of needed intermediates per novice, p,3 the number of needed experts per
novice when enough intermediates are available, p}, the number of needed experts per
novice when enough intermediates are not available, and p23 the number of needed experts
per intermediate worker. The proportion of the different experience groups using different
heuristic accuracies is seen in Table 1, where a, = min (1,"2-) is the proportion of
a is
"ny (D132 +43 (1-@2))+n2 P23
the proportion of novices and intermediates with enough expert guidance.
novices with enough intermediate guidance and a3 = min(1
Table 1 Heuristic accuracies of workers
Using novice Using intermediate Using expert
heuristic heuristic heuristic
Proportion of novices | 1 — max(a2,a@3) max(az,a3) — a3 Qs
Proportion of intermediates l-a, a
Proportion of experts 1
The number of errors propagated from earlier work phases depends on the proportion of
work that has to be redone in the earlier phase as well as the extent the later phase is
dependent on the earlier phase, defined in the limit 100% prerequisite matrix.
The number of errors resulting from the purchase process depends on the client’s and
suppliers’ know how. Additional delays in the purchase process that are not taken into
account in project scheduling also cause of errors since workers lack information in phases
dependent on supplier data. Purchase errors are also propagated to other work phases.
Model validation
Our simulation modelling project team consisted of VTT’s system dynamics researchers as
well as global discipline leaders from Péyry’s Engineering Centre. An iterative modelling
approach was adopted (Sterman 2000). Since Poyry did not have prior experience in using
system dynamics modelling, the first goal was to increase understanding of the benefits and
limitations of business process simulation using a hands-on group model building approach
to simulation. The team gathered together once or twice a month for 3-4 hours meetings to
discuss the simulation model. In between the meetings the researchers refined the model
according to requirements from the previous meeting, and Poyry’s team debugged, tested,
and commented the model.
The workshop sessions were used to define the model boundary and to validate the
structure and behaviour of the model. Many of the generic structures in the model have
been published and previously validated in the system dynamics literature, such as the
rework cycle, the effect of overtime to quality and productivity, and the human resource
dynamics related to training novice workers (Lyneis & Ford 2007, Oliva & Sterman 2010).
Some company specific policies also emerged from the interviews and workshops, such as
the use of heuristics when prerequisite information is not available, and these were included
in the model. Compared to many existing and published system dynamics models, the
model presented in this article is more detailed as it includes 22 different work phases and 3
offices.
We used partial model testing to see how the behaviour of the model changed when some
parts of the model (such as error generation and the effect of overtime on quality and
productivity) were removed. We also used other standard model validation tests, such as
extreme condition and dimensional consistency testing (Sterman 2000).
Data for the simulation model were gathered from Péyry’s past projects. The projects
differed in terms of the offices used and delays in supplier and client data. It was useful to
obtain data both from successful and less successful projects to be able to include the
causes for failures in the model. The model was calibrated to replicate the behaviour of real
life projects in different scenarios. Péyry has previously collected data on many of the
parameters in the model, such as the productivities of different employees, amounts of
work in different work phases and the timeline of the project. Data regarding other
parameters, such as the prerequisite limits between work phases, were not previously
available in numeric format. These were either elicited during the simulation workshops or
gathered internally by Poyry in between the meetings by interviewing their domain experts.
Much of the data are confidential and are therefore not presented in this article.
The modelling went through multiple iterations during which corrections and additions
were made. We used Vensim® to build the simulation model. We also built a MS Excel®
user interface from which the model could be run. This allowed easy distribution of the
model and user interface to people who did not have experience of system dynamics nor
Vensim® installed on their computers. It was very useful that multiple people could test the
model by themselves and point out limitations that could then be corrected in the next
iteration phase. Also, since it was possible to change model parameters using the Excel®
user interface, Poyry’s employees could tune parameters by themselves, making the
validation process faster.
User interface and simulation results
From the user interface, the user can select the office for each of the 22 work phases
(Figure 7) and test the effects of uncertainties related to the purchase process (Figure 8) to
the implementation of the project in different scenarios.
Figure 8 Purchase process uncertainties
Figure 9 shows the simulation results of the following variables:
- Full costs: Engineering disciplines’ work hour costs.
- Discipline stage: Proportion of work completed in the engineering disciplines.
- Discipline work hours: Either the work hours as a proportion of planned hours or their
absolute values are shown in the user interface.
- Work distribution: Work in the project is categorized into original work, corrective work
due to errors in the same work phase, corrective work due to errors in earlier phases, and
corrective work due to errors in the purchase process.
Some values are hidden from Figure 9 due to the confidentiality of the data.
Figure 10 shows the work distribution of each individual work phase.
Full Costs (M€)
Discipline stage
Discipline work hours
|Show proportion of planned hours
Reset original scope
20%
Run simulation
Original
wErors
1m Propagated|
Purchase
Figure 9 Simulation results: expenses, work progress, work hours, and work distribution
@ Original work m™ Phase errors m Propagated errors O Purchase errors
100 %
90 %
80 %
70%
60%
50%
40%
30 %
20%
10%
0%
Figure 10 Simulation results: W ork distribution of individual work phases
The Excel® user interface allowed Péyry’s analysts to visualize the simulation results in
different formats and use the results for further spreadsheet analyses. For example, Poyry’s
analysts have added a time schedule comparing planned and simulated work hours (Figure
11), where the planned schedule in shown in grey and simulated schedule in green or red,
depending on whether the work is completed on time or not.
Timeline
pros
P20
P30
P40
820
B30
OO"
v0 ——————
do —
uso ————
_—7
£20 ————
E40 —<—
E70 —
_
be lL
vo ——
r10.12 ——
20 <<
130 =
140 ———=
10 | ——<
Figure 11 Time schedule comparison between planned and simulated
We performed a Monte Carlo sensitivity analysis to test the effect of uncertainties in the
purchase process to the work hours in the whole project. The model was simulated 1000
times using Latin hypercube sampling for parameters in Table 2.
Table 2 Sensitivity analysis parameters
Parameter | Distribution
Client know how ~ Uniform(1,5)
Client timeliness (additional delay) | ~ Uniform(0,12)
Supplier know how ~ Uniform(1,5)
Preliminary supplier data delay ~ Uniform(0,10)
Final supplier data delay ~ Uniform(5,20)
Figure 12 shows the results of the sensitivity analysis. The work hours are shown as a
proportion of planned hours.
Current
50% 75% (IN 95% (100%
“Work hours project %"
2
945 15.25 43.5 71.75 100
Time (Week)
Figure 12 Sensitivity analysis for uncertainties in the purchase process
Discussion and conclusions
The system dynamics model presented in this article is sufficiently detailed to be used in
real life project management as a tool to understand the interconnections between internal
engineering disciplines, offices, and work phases, as well as external clients and suppliers.
Late information from the client or suppliers can be shown to create problems throughout
the project. The model can also be used to study the effects of a distributed project
implementation to quality, scheduling, and profitability. The model also shows the
development of some variables, such as the number of undetected errors, which cannot be
measured in real life.
Since cultural differences are an important factor when implementing a project in multiple
locations around the world, future work should concentrate on modelling the effects of
cultural differences in more detail. Differences in values and norms often cause
communication difficulties and misunderstandings regarding work practices when people
from different cultures interact. Phillipson & Schlingensiepen (2009) have built on
Hofstede’s (2001) framework of cultural differences and have used national, personal, and
organizational dimensions in predicting potential problems between employees using
Bayesian networks. However, this kind of analysis has not to our knowledge been
integrated with system dynamics modelling.
Our aim in the future is to use the system dynamics model together with other project
management tools to aid decision making in the following areas:
e Resource optimization in a distributed project: Finding the best number of
employees of different experience groups in different offices to implement a project
within a given time frame.
e Reacting to project changes such as delayed purchases: With a simulation
model, the impact of different policies during an ongoing project can be tested in
order to take the best course of action in real life.
e New clients and suppliers: Based on Péyry’s experience, the co-operation between
new partners can sometimes be very challenging. Simulation modelling can help in
doing proper risk analyses in these situations.
e Finding bottlenecks: The simulation model can be used to identify critical
bottlenecks in project working methods and scheduling.
e Schedule optimization in a project: One very useful feature for a complex project
would be schedule optimization based on the total cost of engineering or the quality
of engineering.
e Multiple projects: Péyry is always working with several simultaneous projects,
which may cause difficulties in personnel resourcing. The ultimate goal is to be able
to simulate a multi-project situation with external disturbances in one or more
projects, and to be able to simulate and optimize the resourcing and scheduling of
the projects.
Currently, Vensim® was used to implement the system dynamics model. The aim in the
future is to develop the model further using the Simantics System Dynamics software
(http://www.simantics.org), an open source tool supporting modularity and easy
maintainability of complex models (Lempinen et al. 2011).
References
Abdel-Hamid, T. K. 1984. The dynamics of software development project management: an
integrative system dynamics perspective. PhD thesis, MIT Sloan School of
Management.
Cooper, K. G. 1980. Naval ship production: a claim settled and a framework built.
Interfaces 10, no. 6: 20-36.
Ford, D. N., and J. D. Sterman. 1998. Dynamic modeling of product development
processes. System Dynamics Review 14, no. 1: 31-68.
Hofstede, G. 2001. Culture’s Consequences: Comparing values, Behaviors, Institutions,
and Organizations Across Nations. Thousand Oaks: Sage Publications.
Lempinen, T., S. Ruutu, T. Karhela, and P. Ylén. 2011. Open Source System Dynamics
with Simantics and OpenModelica. To be presented at the 2011 Conference of the
System Dynamics Society, Washington D.C.
Lyneis, J. M., and D. N. Ford. 2007. System dynamics applied to project management: a
survey, assessment, and directions for future research. System Dynamics Review 23,
no. 2-3: 157-189.
Oliva, R., and J. D. Sterman. 2010. Death Spirals and Virtuous Cycles: Human Resource
Dynamics in Knowledge-Based Services. In Handbook of Service Science, ed. P. P.
Maglio, J. Spohrer, and C. Kieliszewski, 321-358. New Y ork: Springer.
Park, M., and F. Pena-Mora. 2003. Dynamic change management for construction:
introducing the change cycle into model-based project management. System Dynamics
Review 19, no. 3: 213-242.
Phillipson, J., and J. Schlingensiepen. 2009. Cultural support during product engineering in
international collaborations. In ICC ME’ 09 - International Conference on
Collaborative Mechatronic Engineering Proceedings.
Sterman, J. D. 2000. Business dynamics: Systems thinking and modeling for a complex
world. Boston: Irwin McGraw-Hill.
