Key Challenges of System Dynamics Implementation in Project ...

Available online at www.sciencedirect.com

ScienceDirect Procedia - Social and Behavioral Sciences 230 (2016) 22 – 30

3rd International Conference on New Challenges in Management and Organization: Organization and Leadership, 2 May 2016, Dubai, UAE

Key challenges of system dynamics implementation in project management David Rumesera,*, Margaret Emsleyb a

b

School of Mechanical, Aerospace, and Civil Engineering, University of Manchester, Pariser Building D2 F Floor, Manchester M13 9PL, UK School of Mechanical, Aerospace, and Civil Engineering, University of Manchester, Pariser Building E24 E Floor, Manchester M13 9PL, UK

Abstract System dynamics can fail to make an impact in projects, particularly due to challenges in the implementation phase. Ensuring successful implementation is therefore essential. This can be done by first identifying the implementation challenges. By conducting expert validation sessions, this paper suggests that the challenges are due to lack of understanding and trust in the model itself. Eleven root causes of these challenges are identified by applying Ishikawa’s fishbone method. They can be categorized into three main categories: mental model shifting, engaging stakeholders and leading changes, and explaining and credibly implementing the model. These are all related with managing people. © 2016 2016The TheAuthors. Authors. Published Elsevier © Published by by Elsevier Ltd.Ltd. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the Ardabil Industrial Management Institute. Peer-review under responsibility of the Ardabil Industrial Management Institute Keywords: System dynamics; project management; implementation challenges; stakeholder involvement; trust; understanding

1. Introduction The most decisive yet challenging factor of System Dynamics (SD) application in project management (PM) is how project managers successfully implement an SD model output in their projects. Repenning and Sterman (2002) describe two case studies where SD successful application relies on the effectiveness of its implementation stage (i.e. how the model output should be grasped by the decision makers and disseminated). Similarly, Größler (2007) analyzes two case studies where SD projects failed to make an impact. He concludes that even a well-built SD model may provide little or even no impact when it is not properly implemented due to lack of key project stakeholders’

* Corresponding author. Tel.: +44-770-860-5829 E-mail address: [email protected]

1877-0428 © 2016 The Authors. Published by Elsevier Ltd. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the Ardabil Industrial Management Institute doi:10.1016/j.sbspro.2016.09.004

David Rumeser and Margaret Emsley / Procedia - Social and Behavioral Sciences 230 (2016) 22 – 30

involvement. Größler’s (2007) finding supports Forrester’s (1994) statement in which many SD projects failed to reach their potential due to their failure to gain necessary support. However, Größler’s (2007) work does not further analyze the root causes which underpin project stakeholders’ lack of involvement the implementation phase. This research, therefore, continues Größler’s (2007) work. It aims to ensure successful implementation of SD in PM by identifying the root causes and therefore the main challenges. This is done by applying a ‘root causes identification’ method called the Fishbone diagram, which was first developed by Kaoru Ishikawa in a quality management context (Wong, 2011). Based on the root causes, the main implementation challenges are proposed. 2. Literature Review Project management (PM) is essential because all organizations, either small or large, are involved in the application of new undertakings (Camilleri, 2011). Most projects, however, are underperformed. For instance, Reichelt’s and Lyneis’ (1999) work shows that in a sample of 10 large, complex development projects (i.e. aerospace, shipbuilding and civil construction projects) the average budget overrun was 86 per cent, and schedule overrun was 55 per cent. Lyneis, Cooper, and Els (2001) argues that one major reason underlying this is that most PM methods and concepts view projects partially, while they are actually complex systems. This is perfectly illustrated in Repenning’s and Sterman’s (2001) statement: “[…] it’s not just a tool problem, any more than it’s a human resources problem or a leadership problem. Instead it is a systemic problem that is created by the interaction of tools, equipment, workers and managers.” Consequently, there is a need for an approach that is able to model this complex and systemic problem, which is what ‘System Dynamics’ (SD) is (Sterman, 2002). One area where SD has been most successfully applied is project management (Lyneis et al., 2001). There are many stories of SD successful application in PM. Godlewski, Lee, and Cooper (2012), for instance, claim that SD helps a large construction company called Fluor Corporation (Fluor) to gain business benefit of more than $800 million since 2005. Another example is Litton Industries, Inc. (Litton) whose benefit is estimated between $170-350 million from the use of SD (Cooper, 1980). Although SD application in PM is perceived as successful, a relatively small percentage of projects have used SD (Lyneis and Ford, 2007). Lyneis and Ford (2007) propose three approaches to increase SD application in PM: x Publishing more success stories, particularly in PM literature x Making SD models easier and less expensive to develop x Attempting to better integrate SD models with traditional PM tools In addition, ensuring its successful application is also liable to increase SD applications in PM. Based on marketing’s post-purchase actions theory (Kotler, 2000), if customers (or in this case, project managers) are satisfied (i.e. if SD success in their projects is ensured) they will tend to use it again (thus making SD application sustainable) and promote it to their colleagues (thus increasing the use of SD in PM). Adding to this, since some SD projects failed to make an impact (Größler, 2007), ensuring SD successful implementation is crucial. This cannot be done without identifying the main challenges of SD implementation in PM, which is the focus of this research. 3. Method 3.1. Expert validation sessions: purposes and definitions Assimilating both theoretical and practical views is a crucial issue in this research. To do this, the authors applied a method called Expert Validation Sessions (EVS) where theoretical information from the literature is validated by a review panel or experts as in the systematic review method (Tranfield, Denyer, & Smart, 2003). However, there are some issues which are not discussed yet in the literature, thus the role of experts in this particular case is more to give insights and to share their experiences rather than to validate the literature.

23

24

David Rumeser and Margaret Emsley / Procedia - Social and Behavioral Sciences 230 (2016) 22 – 30

3.2. Profile of experts The term “experts” described here are those who have applied SD in projects. This is necessary in order to gain practical views and experiences and use them to validate and provide new insights to the literature. There are four SD practitioners who participated in the sessions (i.e. Expert 1, Expert 2, Expert 3, and Expert 4). Additionally, the authors also collected information from a professor in a UK university who was involved in an SD research. He provided some interesting insights regarding SD strategic nature and its practicality in PM. These experts were then asked to answer several questions relevant to the literature. These questions focus on their experiences in implementing SD in PM and key implementation challenges. The interviews were conducted individually via Skype, phone call, or face–to-face meeting. In the sessions, the authors were free to alter the questions based on his prior literature studies as the experts tended to give different emphasizes for different questions. 4. Findings and discussion Based on the expert validation sessions (EVS), two potential causes were found that could hinder key project stakeholders’ involvement in implementing SD: x They do not understand the value of SD x They have a lack of confidence in the model 4.1. Lack of understanding of the value of system dynamics When asked why most project managers do not use SD in their projects, Expert 1 suggested that it is because they have not been given the opportunity to see the value of SD. There are four potential causes which underpin people’s limited understanding concerning SD value (see Fig. 1.): x x x x

Lack of SD awareness (a) One time use of SD (b) Perception that SD is impractical (c) Lack of a sense of belonging with the model (d)

David Rumeser and Margaret Emsley / Procedia - Social and Behavioral Sciences 230 (2016) 22 – 30

Fig. 1. Fishbone diaagram to analyze th he possible causes of o lack of understandding of SD values1

• Laack of system dyynamics awarenness On ne major reasonn why clients (ee.g. project man nagers) do not understand u the vvalue of SD is because b they sim mply do no ot know the metthod (see a. in Fig.1.). F Expert 2 commented thaat one practical challenge of SD D application inn PM is thaat a lot of peoplee in the projectss are not familiaar with SD and so they do not have a good sen nse of how to uuse it. Simillarly, Expert 3 stated: “the bigggest practical challenge is thhat people say, ’What the heck k is that? And why shoulld we use it?’” On ne of the reason ns behind the lacck of awarenesss is concerning the t term itself (see A1 in Fig.1.) Having workked in projeccts for many yeears, Expert 4 described d his op pinion regardinng the subject: ““If you were to o walk into any […] projecct management professional orrganizations, an nd you used thee words ‘system m dynamics’, I would w speculatee that less th han 10 per centt of the people in that audience would even know k what you were talking ab bout.” Moreoveer, he suggeested that Systeem Dynamics is i a ‘scary term m’ for project managers, m and suggested usin ng the term ‘prroject simullation’ would bee much more accceptable for theem. An nother potential cause that undeerpins the lack of awareness is project manageers’ perception that there is notthing wrong g with their pro ojects (see A2 inn Fig.1.). Experrt 4 argued thatt one reason behhind SD successful implementation at a company was the company’ss financial issues could not be b addressed byy other techniq ques. This validdates nd Chapman’s (1998) ( argumen nt in which SD implementation i is usually driveen by an undesirrable Forreester’s (1994) an system m behavior (i.e.. troubled projeccts in this case), which needs too be corrected. • On ne-time use of system s dynamiccs An nother reason which w may causee project managers’ lack of undderstanding of thhe value of SD is they only usee it in a sing gle project (see b. in Fig.1.). This restricts SD D value as it is most m effective w when it is part of o a system that is in an onngoing learning process – prior SD models and d practices couldd give a basis foor designing futture projects (Lyyneis et al.,, 2001). The tenndency to use SD S only in one project could be driven by maanagers’ short-teerm view (see B B1 in Fig.1.). At Du Pontt, SD model output was succcessfully implemented to impprove the comp panies’ maintennance performance (Repennning & Sterm man, 2001). However, it wass then removedd due to a sho ort-term cost-saaving m team member expresssed his disappointment regardding this: “As soon s as you geet the mentaality. An SD modelling

1

T causes written in The n purple are potentiial root causes

25

26

David Rumeser and Margaret Emsley / Procedia - Social and Behavioral Sciences 230 (2016) 22 – 30

problems down, people will be taken away from the effort and the problems will go back up” (Repenning & Sterman, 2001). Aside from managers’ short-term view, a tendency to use SD only in one project is possibly due to the fact that it is often not institutionalized in the project-based organization (Größler, 2007). Without being institutionalized (i.e. supported by formal training and official recognition), SD tends to be used on a one-time basis with limited value. Institutionalizing SD (see B2 in Fig. 1.), however, is a challenging process as it needs to be incorporated into the company’s culture (Expert 1). Adding to this, Expert 4 suggested that a company’s culture of openness towards newer techniques is the key to their successful application of SD (see B2a in Fig.1.). Expert 4 described this as a major driver of the company’s SD implementation. Stakeholder management (SM) failure (see B2b in Fig.1.) is another possible cause of one-time use of SD in projects (Größler, 2007). SD will not be institutionalized in project-based organizations unless project key stakeholders believe in the method. This notion is reflected in Expert 3’s statement in the interview: “You need to have kind of top management support for the project, so you need to have somebody really pushing the project through and basically believing [...] that system dynamics might be a good method to use for that.” The next and final cause which may underpin the one-time use of SD in projects is the lack of leadership (see B2c in Fig.1.). Größler (2007) described a case study where SD successful implementation in one project was not continued in other projects. This is because the project manager of the former project changed to a new job role, her successor did not know about the model, and most employees did not grasp the basis of SD-based policy changes which occurred. This lack of influence and communication is arguably an issue of leadership (Maxwell, 1998).

• The perception that system dynamics is impractical Another reason which could cause project stakeholders not to see SD value is their perception that SD is impractical (see c. in Fig.1.). A professor in a UK university stated: “I think [SD is] more powerful […] to build [as] an intellectual argument than as a tool […] to do things for doers (i.e. project managers).” In practice, however, this is not the case, as stated by Expert 4: “Project managers […] used [SD] day-in and day-out to make decisions about how many people to bring on the project, what happens to my productivity if I do strategy A versus strategy B. If I implement this change […] my engineer has said they want to implement, what are the consequences [for] the project? It’s not some high-level, strategic analysis that’s done once and then put […] in a file cabinet never to be seen again […].” • Lack of a sense of belonging with the model The last potential reason that may cause project stakeholders’ lack of understanding on SD value is they do not have enough sense of ownership towards the model (Coyle, 1996) – see d. in Fig. 1. There are two possible causes that underpin this. First is stakeholder management failure (see D1 in Fig.1.), where clients (or key stakeholders) are not engaged in the model (Größler, 2007). They do not invest their time and effort in the model development, or in some cases they do not know anything about the model development. This may result in no implementation at all. The second cause is too much reliance on external consultants (see D2 in Fig. 1.). This is not a conducive situation, particularly in PM practice, as Expert 4 stated in the interview: “[Project managers] don’t like people on their project that they don’t control, fiddling around with their projects. There is an anti-consultant culture in project managers. They don’t like consultants.” 4.2. Lack of confidence in the system dynamics model The second possible reason that may cause key project stakeholders to not take any action regarding the SD model output is that they do not have enough confidence in the model (Sterman, 2006). To understand the

David Rumeser and Margaret Emsley / Procedia - Social and Behavioral Sciences 230 (2016) 22 – 30

underrlying causes unnderpinning thiis challenge, a Fishbone diagrram (see Fig.2.)) is developed. The possible ddirect causees are: x Laack of the SD model m transparenncy (a) x Prior beliefs (b) olitical issues (c) x Po

Fig. 2. Fishhbone diagram to annalyze the possible causes c of key project stakeholders’ lacck of confidence in the t model1

ncy with the system dynamics model • Laack of transparen Du ue to its aim to model m complexxity, SD is at risk of providing a ‘black box’ m model that lacks transparency (ssee a. in Fig g.2.). This coulld cause key prroject stakehold ders to not trustt the model outpput (Sterman, 2006). 2 Althoughh the modeeler can simplifyy the model, theey would face an nother risk doinng so: when the model is not co omplex enough, they do no ot capture the accurate a compleexity of a real project even iff used appropriiately (Vidal & Marle, 2008). The challeenge, therefore, is to find an opptimal model, so that it is undeerstandable and adequately represents the projject’s compplexity. Th here are two possible causes thhat may underpiin the perceptioon that the SD m model is too com mplex (see A1 in in Fig.2.). First, formall traditional SD D modelling too ols are too com mplex and inacccessible to all (see ( A1a in Figg.2.), pt the trained an nalysts (Stermaan, 1992). Although modern SD S software alllows project maanagers or team ms to excep particcipate more in the modelling process, creatin ng a user-frienndly SD model in a PM conteext remains to be a challeenge. This is vaalidated by Exppert 4’s comment regarding the key to successsfully apply SD D in PM: “The […] tool is designed sp pecifically to be b used by peeople who weere not trainedd in System Dynamics D but were wledgeable projeect participants […].” know Th he second possiible cause behiind the percepttion that the SD D model is tooo complex is sttakeholders’ lim mited know wledge regarding g the model. The T audiences (i.e. ( stakeholderr) have differennt knowledge levels l regardingg the modeel (see A1b in Fig.2.). F Their lim mited knowledg ge regarding SD D complex equattions could be a barrier for theem in accep pting the validity y of the model (Howick, ( 2003)). Consequently, the challenge iis not only to deesign a user-frieendly modeel output (i.e. sim mulations), but also to explain them to differennt stakeholders. • Prior beliefs

1

T causes written inn purple are potentiial root causes The

27

28

David Rumeser and Margaret Emsley / Procedia - Social and Behavioral Sciences 230 (2016) 22 – 30

Project participants may doubt the model because of their prior beliefs (see b in Fig.2.), which are opposed by the counter-intuitive solution SD often suggests (see B1 in Fig.2.). Forrester (1994) suggests that in many cases, SDbased solutions are tough to implement as the implementation “involves reversing deeply embedded policies and strongly held emotional beliefs.” Due to the counter-intuitive nature of the suggestions, convincing project stakeholders to implement them is arguably challenging (Lyneis & Ford, 2007). There are two causes that may contribute to SD perceived counter-intuitive nature. First, people tend to think short-term (see B1a in Fig.2.) while SD supports long-term strategic decisions. In many cases, the SD model deals with a worse-before-better solution (Repenning & Sterman, 2001). Second, people have a tendency to associate cause and effect with time and space, which is called ‘attribution error’ (see B1b in Fig.2.). For instance, realizing their project is late, project managers may decide to allocate more resources or use overtime as they blame the timeand-space related causes (e.g. the number of workers or working hours is not sufficient). However, the root causes that should be solved may be something completely different (e.g. stress, fatigue, and lack of motivation). • Political issue The SD model is at risk of plaguing management and political practice (Forrester, 1994). This ‘political’ issue may cause project participants to lose their confidence in the model (see c. in Fig.2). The notion is validated by Expert 4: “I think the last hurdle to overcome […] is giving people confidence that […] the mathematics [was] not going to be gained […] to produce the results that one wanted, rather than the results that were driven by the data.” The authors identify two possible drivers which could underpin this issue. First, project participants may have different and sometimes conflicting interests with each other (see C1 in Fig.2.). As an example, in a typical contractor-client dispute, the contractor employs an SD expert to quantify a significant loss they experienced due to their client’s default (Stephens, Graham, & Lyneis, 2005). Often, the opposing party (i.e. the client) will also appoint another SD expert to provide analysis which refutes his opponent’s. This ‘expert war’ is usually done by claiming that parameters and assumptions are ‘cooked’ to deliver a preselected output (Sterman, 2006). The second reason which could cause political issue is subjective factors (i.e. soft factors) included in the model (see C2 in Fig.2.). These hard-to-quantify factors (Rodrigues & Bowers, 1996) are potential triggers to plague management practice since they could be manipulated subjectively (see C2a in Fig.2.). Furthermore, a tendency to start SD modelling from scratch, which is also known as a ‘blank paper problem’ (Coyle, 1996), may contribute to this danger (see C2b in Fig.2.). In some cases, there is no standard equation or relationship that can be applied in each project due to the project’s uniqueness or the company’s one-time use of the model. 4.3. Summary of findings Eleven unique root causes to the key challenges of SD implementation in PM are identified. The challenges can be classified into 3 main categories: mental model shifting, stakeholder and change management, model explanation and credibility (see Table 1). The fact that most of the root causes fall into the first two categories (i.e. mental model shifting, and stakeholder and change management) shows that the main challenges in SD implementation in PM are more about the people than the technicalities of the model. The last category (i.e. model explanation and credibility) also deals with how the model convinces people to implement changes. This confirms Forrester’s (1994) work which stresses the importance of leadership and communication skills in the implementation stage. Table 1. Key Challenges in System Dynamics Implementation in Project Management Categories

Identified Challenges in Implementing System Dynamics (SD) in Project Management

Mental model shifting

1. To cope with the perception that there is nothing wrong with the project 2. To cope with project managers’ perception of SD as a ‘scary’ term 3. To change project stakeholders’ short-term view regarding the use of SD as a one-time solution 4. To change the perception that SD is not practical

David Rumeser and Margaret Emsley / Procedia - Social and Behavioral Sciences 230 (2016) 22 – 30

5. To cope with project participants’ attribution error Stakeholder and change management

6. To incorporate SD into the organization’s culture 7. To engage key stakeholders (or key project decision makers) in implementing SD model output 8. To lead and disseminate the changes suggested by SD model output 9. To restrict the role of SD consultants and expand the role of project managers and other stakeholders

Model explanation and credibility

10. To explain the model clearly to different audiences 11. To use the model objectively to avoid bias due to conflict of interest

5. Conclusion This research exists to answer the following question: how to make system dynamics application in project management successful? The authors’ approach is to identify the main implementation challenges. Previous work has identified a direct cause underpinning implementation failure, which is limited support from project key stakeholders in the implementation stage. Building on this, the authors analyze the root causes on stakeholders’ lack of involvement, which are then used as a basis to identify the main challenges. The findings of this paper suggest that lack of understanding and trust in the model are key challenges, and the underlying causes for these challenges are related with people (i.e. mental model shifting, stakeholder and change management, and model explanation and credibility). Therefore, to implement system dynamics successfully in project management, more focus should be given to managing the people (i.e. project stakeholders) than managing model technicalities. To complement this research, the authors are currently conducting another research in identifying the key success factors in system dynamics implementation in project management. This aligns with the main theme of this research (i.e. making system dynamics application in project management successful). Acknowledgements The authors gratefully acknowledge Indonesia Endowment Fund for Education (Lembaga Pengelola Dana Pendidikan / LPDP) for sponsoring this research. Also, the authors would like to acknowledge System Dynamics practitioners and a professor who contributed in the Expert Validation Sessions. References Camilleri, E. (2011). Project success: critical factors and behaviours. GB: Gower. 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(4), 235-247. Cooper, K. G. (1980). Naval Ship Production: A Claim Settled and a Framework Built. Interfaces, 10(6), 20-36. Coyle, R. G. (1996). System Dynamics Modelling: A Practical Approach. London: Chapman & Hall. Forrester, J. W. (1994). System dynamics, systems thinking, and soft OR. System Dynamics Review, 10(2-3), 245-256. Godlewski, E., Lee, G., & Cooper, K. (2012). System Dynamics Transforms Fluor Project and Change Management. Interfaces, 42(1), 17-32. Größler, A. (2007). System dynamics projects that failed to make an impact. System Dynamics Review, 23(4), 437-452. 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(3), 222-229. Kotler, P. (2000). Marketing Management. Millennium Edition: Prentice Hall PTR. 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(3), 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(2-3), 157-189. Maxwell, J. C. (1998). The 21 Irrefutable Laws of Leadership. Nashville, Tenessee: Thomas Nelson, Inc. Reichelt, K., & Lyneis, J. (1999). The dynamics of project performance: benchmarking the drivers of cost and schedule overrun. European Management Journal, 17(2), 135-150. Repenning, N., & Sterman, J. (2001). Nobody Ever Gets Credit for Fixing Problems that Never Happened: - Creating and Sustaining Process Improvement. California management review, 43(4), 64. Rodrigues, A., & Bowers, J. (1996). System dynamics in project management: A comparative analysis with traditional methods. System Dynamics Review, 12(2), 121-139.

29

30

David Rumeser and Margaret Emsley / Procedia - Social and Behavioral Sciences 230 (2016) 22 – 30 Stephens, C. A., Graham, A. K., & Lyneis, J. M. (2005). System dynamics modeling in the legal arena: meeting the challenges of expert witness admissibility. System Dynamics Review, 21(2), 95-95. Sterman, J. D. (1992). System Dynamics Modeling for Project Management: MIT Sloan School of Management. Sterman, J. D. (2002). Systems dynamics modeling: tools for learning in a complex world. Engineering Management Review, IEEE, 30(1), 42-42. Sterman, J. D. (2006). Business Dynamics: Systems Thinking and Modeling for a Complex World. McGraw-Hill College. Tranfield, D., Denyer, D., & Smart, P. (2003). Towards a Methodology for Developing Evidence-Informed Management Knowledge by Means of Systematic Review. British Journal of Management, 14(3), 207-222. Vidal, L.-A., & Marle, F. (2008). Understanding project complexity: implications on project management. Kybernetes, 37(8), 1094-1110. Wong, K. C. (2011). Using an Ishikawa diagram as a tool to assist memory and retrieval of relevant medical cases from the medical literature. Journal of medical case reports, 5, 120.