Key Success Factors in Implementing
System Dynamics in Project Management:
Coping with lack of understanding and trust
David Rumeser'*, Margaret Emsley!
Abstract
The main challenge of system dynamics (SD) implementation in project management
(PM) lies at its implementation stage. Moreover, SD tends to fail to make an impact
when there is a lack of support from key stakeholders. In a separate work, we identify
potential root causes to this and conclude that the main issue is a lack of understanding
and trust in the model. By interviewing SD practitioners, this research builds on these
findings as it identifies the key success factors to cope with the identified challenges.
The key success factors are: establishing SD education in project-based organizations,
using a more-familiar term (i.e. ‘project simulation’) to introduce the model, applying a
participative approach in model design, managing key project stakeholders, and
developing an independent modelling entity.
Keywords
System Dynamics, Project Management, Implementation Phase, Key Success Factors
1. Introduction
GréBler (2007) found that lack of clients’ (or key project stakeholders’) involvement is
a critical factor causing SD to fail to make an impact in projects. This supports
Forrester’s (1994) claim that, due to their failure in gaining support, many SD projects
failed to reach their potential. Nevertheless, GréBler’s (2007) work does not further
analyze the root causes which underpin this problem.
In a separate work (in progress), we applied Ishikawa’s root cause analysis to identify
the potential root causes of lack of project key stakeholders’ involvement in
implementing SD model output. Our findings suggest that lack of understanding and
trust in the model are the main reasons. Furthermore, we identify key implementation
challenges as follows:
* To shift the mental model of each project stakeholder (i.e. ‘nothing is wrong
with my project’ perception, attribution error, viewing system dynamics as a
short-term solution, a misunderstanding that system dynamics is impractical, not
familiar with the term ‘System Dynamics’).
* To manage change and engage stakeholders (i.e. system dynamics is not part of
the organization culture; counter-intuitive changes suggested by the model; lack
of sense of belonging towards the model).
¢ To explain the model clearly and to implement it with credibility (i.e. different
stakeholders have different levels of understanding towards the model; conflict
of interest and bias in model implementation)
' School of Mechanical, Aerospace, and Civil Engineering, The University of Manchester, UK
*Corresponding author (david.rumeser@postgrad.manchester.ac.uk)
Building on GréBler’s work (2007) and our work (in progress), this research aims to
ensure successful implementation of SD in PM by identifying the key success factors to
cope with the identified challenges.
2. Literature Review
2.1 The suitability of System Dynamics and Project Management: viewing a project as a
system
SD works well with project management since SD deals with systems (Forrester, 1961);
and projects are systems (Lyneis et al., 2001, Vidal and Marle, 2008). A system is ‘a
collection of parts that interact to achieve a collective goal‘ (Coyle, 1996).
Complementary to this, Vidal and Marle (2008) argue that the characteristics of projects
fit the nature of systems:
¢ They exist in a particular environment to achieve some objectives;
¢ They have an internal structure or parts, such as resources, workers, tools,
deliverables ete.
Furthermore, projects are often characterised by interrelationships between their parts
(Rodrigues and Bowers, 1996). For example, a project may involve many stakeholders
(e.g. project manager, architect, engineer) who work together as a team. Their success
depends on how well they relate to each other, in a way that what each of them
accomplishes is reliant on what the other members do (Chapman, 1998). This
characteristic fits well with that of a system in which parts are interrelated with one
another (Coyle, 1996).
Finally, like systems, projects consist of inputs and outputs. For example, in a
construction project, the inputs are project resources (e.g. staff, finance, plant) and the
outputs are completed projects (i.e. deliverables). Similarly with systems, they also have
processes (e.g. activities) and feedbacks (e.g. information feedbacks, rework cycle)
(Love et al., 2002).
2.2. Ensuring Successful System Dynamics Implementation in Project Management
Although SD is suitable to be implemented in PM and its implementation has many
success stories, SD has only been used in a relatively small percentage of projects
(Rumeser, 2012, Lyneis and Ford, 2007). Furthermore, ensuring successful
implementation of SD in PM is critical as several SD projects failed to make an impact
(GréBler, 2007). This motivates us to identify the key success factors of SD
implementation in PM, which is the aim of this research.
3. Method
We interviewed four SD practitioners (i.e. ‘experts’) to add practical insights to the
literature review. The questions were centered on the experience of these experts in
implementing SD in PM and the key success factors in its implementation. In the
interview sessions, different follow-up questions were asked of the different
interviewees depending on the emphasis of their answer to the general question and how
detailed their answer was. The interviews were done individually via Skype and phone
call. This method is selected as it is suitable for exploratory study (Hakim, 2000), which
is the nature of this research (i.e. exploring the key success factors). Moreover, expert
interviews are suitable for complementing insights provided by other methods (Flick,
2014). In this case, it is used to complement the insights obtained from reviewing the
literature.
The experts who participated in the interviews are as follows:
¢ Expert 1 has been involved in implementing SD as a client, working with SD
consultants in small and large SD projects.
¢ Sharon Els is a project manager and SD expert at PA Consulting Group. Her role
is as a consultant in SD projects.
¢ Scott T Johnson is the founder and president of a SD consulting company. One
of his vast experiences in implementing SD is as a member of a review board
that applied SD in assessing project performance.
¢ Andreas Gr6fler, a professor in the University of Stuttgart, has been involved in
SD projects in many companies as an academic advisor and as a consultant.
Aside from Expert 1, other respondents have given consent for the use of their real
names.
4. Findings and Discussion
We identify six key success factors that must be considered in ensuring successful
implementation of SD in PM:
¢ SD training in project-based organizations;
¢ Using a more familiar PM term (rather than ‘System Dynamics’) to introduce
the model;
¢ Implementing a more participative approach (including the development of a
user-friendly SD model);
¢ Managing key project stakeholders;
¢ Developing an independent modelling entity; and
¢ Identifying the kinds of projects that require system dynamics.
4.1. System Dynamics training in project-based organizations
The majority of the main challenges in SD implementation in PM are related to project
participants’ perception of change (or mental model shifting) which is an essential
requirement prior to the implementation stage (Sterman, 2006). In order to do this, SD
methodology should be supported by an education process, in which project participants
are trained intensively (Repenning and Sterman, 2001). In fact, this process tends to be
the most time- and effort-consuming one as Expert | stated:
“The cost of implementing System Dynamics on projects is relatively small. The cost of
educating people as to what you're doing, why you're doing it, why it’s good for them
to participate, and [...] the benefits [they] will have financially on the outcome of their
projects, are extensive.”
There are several ways to educate or train project participants. Fluor’s way is to conduct
an introductory course for managers, planners and executives — a multi-day training
course for those who are the direct users of the tool; and a course particularly for project
managers (Godlewski et al., 2012). This shows that Fluor communicated SD differently
to different audiences. Moreover, Fluor had also used the system in more than 100
projects, which implies Fluor’s SD educational approach is not only by theoretical
training, but also applied learning. Furthermore, the training can be done by displaying
simulation calculations and showing that they are not as complicated as perceived
(Expert | in the interview). This is necessary to increase the model’s transparency, and
thus the clients’ confidence in it.
Du Pont, on the other hand, educated its workers by conducting intensive interactive
workshops in which workers could play the SD simulation game to experience worse-
before-better dynamics (Repenning and Sterman, 2001). This resulted in a shift in the
workers’ perception, from a short-term into a long-term oriented view.
4.2. Using a more familiar term to introduce the model
As Expert | implied, the term to describe the method can make a difference to project
managers’ level of awareness towards it. In practice, ‘project simulation’ is more
welcomed than System Dynamics. However, this substitute term should be used for
introductory purposes only. Once project managers accept SD and grasp its nature, they
should realize that System Dynamics is a better term since it better explains the nature
of the model in that it captures a project’s behavior holistically and dynamically
(Andreas Gréfler in the interview).
4.3. Implementing a more participative approach
In order to make SD implementation work, GréBler (2007) proposes a new approach in
which implementation should be centered on the clients (i.e. project participants) rather
than the consultants. This is validated by Expert 1 who argues that in reality project
managers do not really like consultants ‘messing around’ with their projects.
Furthermore, he suggests that his company’s user-friendly SD software application is a
key to increasing their project managers’ participation, resulting in their staff not
needing to endure the anti-consultant culture. This also validates Sterman’s (1992) work
in which he argues that new software tools allow managers to participate more
intensively in model development as they make it possible for managers to use, test and
revise complex models.
Another function of user-friendly software tools is to disseminate the model’s output
throughout the organization (Repenning and Sterman, 2001). Du Pont, for instance,
thoroughly communicated the model’s output (from lowest grade hourly mechanic to
the regional vice president) by conducting simulation game workshops which 1200
people attended (Repenning and Sterman, 2001).
4.4. Managing key project stakeholders
Identifying and managing key stakeholders who have the authority to implement the
model is a crucial requirement in ensuring successful SD application in PM. This is
because those in authority, particularly top managers, can influence the company’s
openness culture (McKenna, 2006) towards a perceived new approach such as SD.
Validating the importance of key stakeholders’ involvement, GréBler’s (2007) case
study shows that without the support of key decision makers, a SD’s model will have
little or no impact on projects.
Coyle (1977) proposes several practical suggestions to manage key stakeholders in an
SD project. The first suggestion is to identify the key stakeholders (i.e. project
participants). This is shown in a real dispute resolution case within a construction
project between Ingalls and the US Navy. The SD model proposed by Ingalls (the
contractor) was discredited by the US Navy’s (the client’s) expert (Sterman, 2006). The
Navy claimed that the model was subjectively manipulated by the contractor and it was
a ‘garbage in, garbage out’ model. However, after the parties met and discussed the
model from high level issues to specific equations and parameters, the model was
revised and the case was successfully settled out of court. Sterman (2006) concluded
that the client should not only be Ingalls, but also the Navy and the court. This case
underlines the importance of identifying key stakeholders prior to model
implementation. Furthermore, they should not only be limited to proponents (i.e. the
ones who support the model’s output), but also opponents (i.e. the ones who oppose the
model’s output) (Coyle, 1977). Another lesson learned is that opening the model to
discussions and critiques or even debates (Forrester, 1994) could increase key project
stakeholders’ confidence in the model’s reliability.
The next practical suggestion in managing key stakeholders is to adjust the model’s
level of detail to be compatible with each stakeholder’s level of SD knowledge (Coyle,
1977). Regarding this, Howick (2003) suggests that the use of SD’s qualitative
modelling (i.e. influence diagram) is much more appropriate to explain to people with
little modelling expertise. However, her work tends to be more suitable in a litigation
context rather than PM since “projects are populated with people that are engineers.
They're used to working with numbers” (Expert 1). Adding to this, modern SD software
allows equations to be written using ‘friendly algebra’ (Sterman, 2002).
Supplementary to these two suggestions, Scott T Johnson (in the interview) proposed
the presence of an ‘interpreter’ role. An interpreter or model builder is ‘somebody who
can have one foot in the world of the modeler, and [...] has a deep understanding of
traditional project practices and tools.’ They have the ability to ‘translate’ a perceived-
as-complex SD model into more understandable PM language. Consequently, this could
increase key project stakeholders’ understanding, thus participation.
Fluor applied Johnson’s idea by training over 300 of their project managers to analyze
and interpret the SD model’s output and discuss the output with their clients (Godlewski
et al., 2012). In Fluor’s case, the project managers have an interpreter role in that they
translate the model’s technical result into practical suggestions which their clients
understand. This requires the creativity of the interpreter, either the consultant, the
project manager supported by their team, or both of them working together.
4.5. Developing an independent modelling entity
In order to cope with the perception that SD is done to support one party’s interest, the
existence of independent modelling entity should be considered. Fluor did this by using
an independent modelling team (i.e. not part of their project management team). This
aligns with Expert 1’s statement regarding how SD is implemented in his company:
“[...] in the [..] projects that we performed, we used a centralized modelling team [...].
Their objective was to create a simulation that accurately reflected the conditions on
the project, and so there was no bias [...]”.
4.6. Identifying the kinds of projects that require system dynamics
Not all projects require a formal SD method. In other words, knowing when to use SD
and when not to use it is also a key success factor in SD application in PM (Andreas
GréBler in the interview). To put it into PM context, one needs to know what types of
projects require SD and what types of projects do not.
Researchers (Rodrigues and Bowers, 1996, Chapman, 1998, Lyneis and Ford, 2007)
tend to agree that SD is most suitable to be used in complex projects. Nevertheless, they
tend not to clarify what extent of complexity makes a project viable for SD application.
This is because they do not explain which parameters can be used to measure projects’
complexity. Vidal and Marle (2008), however, proposed four parameters that could
influence project complexity (Figure 5.1).
Project Size
(e.g. largeness of capital Project Interdependency
investment, number of | (e.g. interconnectivity and
decisions to be made, number |) feedback loops in task and
of projects sharing their <_ project network)
resources)
Project
Complexity |
Project Variety
(e.g. diversity of staffs’
‘experience, variety of
stakeholders’ interests)
Elements of Context
(e.g. organisational degree of
innovation)
Figure 5.1 Parameters of project complexity (adapted from Vidal and Marle (2008))
The first factor which determines the level of project complexity, and thus SD viability,
is the size of the project (Vidal and Marle, 2008). This can be measured in many ways,
such as the size of capital investment (for example, Fluor used SD for projects from the
value of $10 million to more than $10 billion (Godlewski et al., 2012)), the number of
decisions to be made (e.g. overtime, schedule pressure, training, outsource, etc) (Syed et
al., 2010), the number of projects sharing the resources (for example, Abdel-Hamid
(1993) and Yaghootkar (2010) who analyze the use of SD in multi-project scenarios).
Complementary to this, Rodrigues and Bowers (1996b) argue that the use of SD is
limited to high-budget projects due to the high cost of employing highly skilled
modelers. This, however, is not always valid, since in some cases there are some project
members who can build the model themselves (Scott T Johnson in the interview).
Nevertheless, the time and cost needed to build the model from scratch (i.e. blank paper
problems) (Coyle, 1996) and the time and cost needed to educate users must be
considered in deciding whether or not SD should be used in a particular project.
Furthermore, a project’s complexity level and thus the viability of SD is also determined
by its degree of variety (Vidal and Marle, 2008). Love et al. (2002) underline the
increasing need for SD because of stakeholders’ variety in a design and construction
project. Their work suggests that construction project stakeholders (owner, contractor,
supplier, designer, subcontractor, etc.) are sources of design and construction change
(e.g. variation and rework). Therefore, the more varied they are, the more changes (or
dynamics) they tend to bring, thus the more significant SD application could be.
The third parameter which affects project complexity is its interdependency (Vidal and
Marle, 2008). This is illustrated in Sharon Els’ comment in the interview regarding
types of projects that require SD:
“SD lends itself to projects that have many separate parts and complex
interdependencies between those parts. To effectively integrate or synthesize all those
different pieces and how they will come together over time you have to look at the
timing of the work, changes to the work, the rework content, and how productivity is
changing over time. This is especially useful on complex and interdependent projects
like submarine projects, aerospace projects, nuclear power plants, and software
projects.”
This explains the fact that complex software development projects are one major area of
SD application (Rodrigues and Bowers, 1996).
Elements of context also determine the level of a project’s complexity (Vidal and Marle,
2008). Although each project is unique, the degree of its uniqueness is different from
the others. Since SD has the capability of coping with ‘blank paper problems’ (Coyle,
1996), an extremely unique project (in terms of level of innovation) tends to require SD
more than others. This explains Rodrigues’ and Bowers’ (1996b) finding which
suggests that SD is mostly applied in highly innovative development projects (e.g.
product and software development and research and development (R&D) projects).
To summarize, rather than abstractly saying SD is viable for complex projects as most
researchers do, the viability of SD’s formal use should be assessed based on at least four
more-specific criteria: size (capital investment size, number of decisions to be made and
number of projects sharing their resources), variety (diversity of staffs’ experience and
stakeholders’ interests), interdependencies (number of feedback loops occurring), and
elements of context (level of project uniqueness or innovation level). This means that
SD will only be viable if the project is large, diverse (includes varied entities),
interdependent and unique enough.
The way of thinking associated with SD’s informal use, however, can be applied in any
project. Scott T Johnson illustrated this in the interview:
“T think virtually every project can use the thinking associated with the System
Dynamics approach. As an example, if you have a very simple project that is going to
start and finish over a two-week period of time, the project manager could, for instance,
use their under ding of [...] ing rework to plan and execute even a simple
project.”
5. Conclusion
This research builds on the findings of another research in which we identify root causes
that underpin project stakeholders’ lack of understanding and trust in system dynamics.
In this research, we propose six key success factors of system dynamics implementation
in project management to cope with the identified challenges: establishing system
dynamics education in project-based organizations; using a more-familiar term (i.e.
‘projects simulation’) to introduce the model; applying a participative approach in
designing the model; identifying and managing key project stakeholders; and
developing an independent modelling entity. Additionally, one should assess each
project’s viability for system dynamics implementation as it will only be viable if the
project is large, diverse (includes varied entities), interdependent and unique enough.
Having said this, system dynamics concept of thinking can be applied to any project.
Although all of the key success factors proposed are presented in the context of project
management, not all of them are limited to project management practice. Some can be
considered when implementing SD in other fields. However, several success factors
such as:
¢ using the term ‘project simulation’ to introduce system dynamics; and
¢ identifying the kinds of projects that require system dynamics;
are specific to project management practice. Furthermore, the practical suggestions
proposed in each success factor are specific and should be applied when implementing
system dynamics in project management.
6. Acknowledgement
We would like to acknowledge Indonesia Endowment Fund for Education (Lembaga
Pengelola Dana Pendidikan / LPDP) as the main sponsor of this research. We would
also like to acknowledge Sharon Els, Scott T Johnson and Andreas Gré8ler for their
participation and important inputs in the interviews.
References
CHAPMAN, R. J. 1998. The role of system dynamics in understanding the impact of changes to
key project personnel on design production within construction projects. International
Journal of Project Management, 16, 235-247.
COYLE, R. G. 1977. Management system dynamics, Wiley.
COYLE, R. G. 1996. System Dynamics Modelling: A Practical Approach, London, Chapman &
Hall.
FLICK, U. 2014. An introduction to qualitative research, Los Angeles, Calif. ; London, Los
Angeles, Calif. ; London : SAGE.
FORRESTER, J. W. 1961. Industrial dynamics, [Cambridge, Mass., M.I.T. Press.
FORRESTER, J. W. 1994. System dynamics, systems thinking, and soft OR. System Dynamics
Review, 10, 245-256.
GODLEWSKI, E., LEE, G. & COOPER, K. 2012. System Dynamics Transforms Fluor Project and
Change Management. INTERFACES, 42, 17-32.
HAKIM, C. 2000. Research design : successful designs for social and economic research, London,
London : Routledge.
HOWICK, S. 2003. Using System Dynamics to Analyse Disruption and Delay in Complex Projects
for Litigation: Can the Modelling Purposes Be Met? The Journal of the Operational
Research Society, 54, 222-229.
LOVE, P. E. D., HOLT, G. D., SHEN, L. Y., LI, H. & IRANI, Z. 2002. Using systems dynamics to
better understand change and rework in construction project management systems.
International Journal of Project Management, 20, 425-436.
LYNEIS, J. M., COOPER, K. G. & ELS, S. A. 2001. Strategic management of complex projects: a
case study using system dynamics. System Dynamics Review, 17, 237-260.
LYNEIS, J. M. & FORD, D. N. 2007. System dynamics applied to project management: a survey,
assessment, and directions for future research. System Dynamics Review, 23, 157-189.
MCKENNA, E. F. 2006. Business Psychology and Organisational Behaviour: A Student's
Handbook, Psychology Press.
REPENNING, N. & STERMAN, J. 2001. Nobody Ever Gets Credit for Fixing Problems that Never
Happened: - Creating and Sustaining Process Improvement. California management
review, 43, 64.
RODRIGUES, A. & BOWERS, J. 1996. The role of system dynamics in project management.
International Journal of Project Management, 14, 213-220.
RUMESER, D. 2012. Promoting and Ensuring Successful Application of System Dynamics in
Project Management. Msc. Engineering Project Management, The University of
Manchester.
STERMAN, J. 2006. Business Dynamics: Systems Thinking and Modeling for a Complex World,
McGraw-Hill College.
STERMAN, J. D. 2002. Systems dynamics modeling: tools for learning in a complex world.
Engineering Management Review, IEEE, 30, 42-42.
SYED, A., ANDY, G., THERESE, L.-W., RICHARD, K., ALI, K. & MEHMOOD, A. 2010. The
importance of soft skills in complex projects. International Journal of Managing
Projects in Business, 3, 387-401.
VIDAL, L.-A. & MARLE, F. 2008. Understanding project complexity: implications on project
management. Kybernetes, 37, 1094-1110.
