Diagnosing organizational risks in software projects: Stakeholder ...

Available online at www.sciencedirect.com

ScienceDirect International Journal of Project Management 33 (2015) 1262 – 1273 www.elsevier.com/locate/ijproman

Diagnosing organizational risks in software projects: Stakeholder resistance Simon L.R. Vrhovec ⁎, Tomaž Hovelja, Damjan Vavpotič, Marjan Krisper University of Ljubljana, Faculty of Computer and Information Science, Ljubljana, Slovenia Received 8 August 2014; received in revised form 28 January 2015; accepted 16 March 2015 Available online 29 March 2015

Abstract Critical success and failure factors of software projects were extensively studied. However, software project risk management has rarely researched organizational risks even though most problems occur when the social aspects are not addressed. By employing the resistance to change theory, our paper develops an organizational risk diagnosing (ORD) framework in order to show how can organizational risks be better understood and managed. Organizational risk factors may have non-trivial underlying root causes. A failure to diagnose them may result in ineffective risk responses that address the symptoms. A case study of a loan application software project has been conducted in one of the biggest banks in SouthEastern Europe. An analysis of the risk management process in the studied case allows a better understanding of organizational risk management. © 2015 Elsevier Ltd. APM and IPMA. All rights reserved. Keywords: Software project; Stakeholder resistance; Risk management; Bank

1. Introduction Software project failure rates remain alarmingly high despite surging investments in information systems and their importance for contemporary organizations (Altuwaijri and Khorsheed, 2011; Baccarini et al., 2004; Bannerman, 2008; El Emam and Koru, 2008; Hong and Kim, 2002). According to the CHAOS Manifesto 2013 (The Standish Group, 2013), only 39 percent of software projects were successful, i.e., completed on-time and on-budget, with all features and functions as initially specified. Another 43 percent of projects were challenged, i.e., completed and operational but over-budget, over the time estimate, and offer fewer features and functions than originally specified. The remaining 18 percent of software projects have failed, i.e., they were cancelled prior to completion or delivered and never used. When considering only large software projects, only 10 percent were successful, 52 percent were challenged and ⁎ Corresponding author at: Večna pot 113, 1000 Ljubljana, Slovenia. Tel.: + 386 1 479 8297. E-mail address: [email protected] (S.L.R. Vrhovec). URL: http://simvrh.wordpress.com/.

http://dx.doi.org/10.1016/j.ijproman.2015.03.007 0263-7863/00/© 2015 Elsevier Ltd. APM and IPMA. All rights reserved.

38 percent have failed. This is at least worrying as large software projects failure may negatively affect the whole implementing enterprise (Bernroider et al., 2014; Hong and Kim, 2002; Lavbič et al., 2010). Software projects are high risk activities due to the rapid pace of technological changes and the organizational changes they may impose (Aloini et al., 2007; Altuwaijri and Khorsheed, 2011; Bannerman, 2008; Cule et al., 2000; Hong and Kim, 2002; Kwahk and Kim, 2007; Li et al., 2011) therefore risk management is essential for project success (Baccarini et al., 2004; Tiwana and Keil, 2004; Wallace et al., 2004). In the recent years, much has become known about why software projects fail (de Bakker et al., 2010). Several risk factors have been identified and joined into checklists and classification frameworks (Bannerman, 2008). Also, stepwise tasks for managing risks, also known as process models, are widespread in theory and practice (Aloini et al., 2012; Bannerman, 2008). However, software project risk management seems to be rather immature as risks are still not managed effectively (Aloini et al., 2007; Bannerman, 2008; de Bakker et al., 2010; Geraldi et al., 2011; Kappelman et al., 2006; Kutsch and Hall,

S.L.R. Vrhovec et al. / International Journal of Project Management 33 (2015) 1262–1273

2005; Osipova and Eriksson, 2013). In addition to technical risks, software projects are subjected to organizational risks since they affect or are affected by the way of doing things in an organization (Benaroch et al., 2006; Sanderson, 2012; Sharma and Gupta, 2012). These risks should not be overlooked as most problems occur when the social aspects are not addressed (Atkinson et al., 2006; Laumer, 2011). People are one of the greatest sources of uncertainty in any project undertaking therefore organizational risks are difficult to manage and knowledge of risks alone is not enough to contribute to project success (de Bakker et al., 2010; Thamhain, 2013). Nonetheless, organizational risk factors have been rarely researched (Aloini et al., 2007). Risk management research has only recently shown more interest in stakeholder-related processes and put an emphasis on “soft skills” as a complement to the “hard skills” (de Carvalho and Rabechini Junior, 2015; Söderlund and Maylor, 2012). Research shows that different stakeholder perspectives need to be considered in order to build the bigger picture and manage risks effectively (Hartono et al., 2014). Among the most prominent and well-researched organizational risks in software projects is resistance to change (Hong and Kim, 2002; Jiang et al., 2000; Kim, 2011; Kwahk and Kim, 2007; Laumer, 2011; Lundy and Morin, 2013; Meissonier and Houzé, 2010; Rivard and Lapointe, 2012; Žvanut et al., 2011). It has been thoroughly researched for over half of a century in managerial psychology and information systems research (Laumer, 2011; Oreg et al., 2011; Rivard and Lapointe, 2012). Resistance to change is a complex phenomenon and several sources of resistance which can be considered as risk factors have been identified in the literature. The success of resistance management depends on the ability to diagnose resistance, i.e., to distinguish symptoms from root causes (Fiedler, 2010; Laumer, 2011; Lundy and Morin, 2013; Rivard and Lapointe, 2012; Zander, 1950). The paper builds on the premise that organizational risks may not be managed effectively if one only focuses on projectspecific risks or uses existing risk management approaches, such as checklists and classification frameworks. Furthermore, improving the existing approaches by considering different stakeholder perspectives may not be enough if the stakeholders themselves do not distinguish the symptoms from the root causes. The purpose of this paper is to move beyond the limitations of existing risk management approaches and advance the diagnosing of root causes of organizational risks from multiple stakeholder perspectives. By employing the resistance to change theory we develop a new theoretical model – the organizational risk diagnosing (ORD) framework. The ORD framework attempts to identify in a novel way the non-trivial underlying root causes which organizational risk factors may have. This paper is structured as follows. First, extant work on software project risk management and resistance to change is summarized. The concept of stakeholder resistance is introduced. Next, the resistance checklist aggregating various works on resistance to change is developed. Afterwards, the proposed ORD framework is presented along with an application to the resistance context. A case study of a software project introducing

1263

new loan application software is presented and analyzed. The contributions of our research to risk management and resistance research are then discussed including the limitations of the study and further research opportunities. 2. Theoretical background 2.1. Software project risk management The ISO 31000 Standard defines risk as the “effect of uncertainty on objectives” (ISO, 2009). Even though they are commonly viewed from the narrow perspective of the negative side of the possible effect (Hartono et al., 2014), risks can have both a positive or a negative effect on a project when present (Benaroch et al., 2006; ISO, 2009; Wallace and Keil, 2004). In software projects, much work has been done on discovering risks, also known as risk factors (Benaroch et al., 2006). Other terms, such as “sources of risk”, “critical success factors”, “uncertainty factors “, “risk drivers” or “risk items”, can also be found in literature (Aloini et al., 2007; Bannerman, 2008; Tiwana and Keil, 2004). In some risk management fields, such as construction, risk factors are differentiated from risks. In contrast to established software project risk management where risk factors are usually directly related to their effects (Aloini et al., 2007; ISO, 2009), construction project risk factors do not affect the project directly but do so through risks (Tah and Carr, 2001). This distinction helps in risk evaluation because the risk factors are more concrete abstractions of a risk and define situations that can be individually assessed with a limited amount of vague information or facts (Tah and Carr, 2001). Three main approaches to software project risk management can be found in theory and practice (Bannerman, 2008; de Bakker et al., 2010): checklists, classification frameworks, and process models. Checklists are formed by joining risk factors that have been identified in past projects (de Bakker et al., 2010). Various checklists can be found in literature (Aloini et al., 2007; Schmidt et al., 2001). Risk factors in checklists are commonly a mixture of technical and organizational risks ordered by general risk probability in software projects (Aloini et al., 2007). Checklists are often comprised of too many potential risk factors to effectively identify and manage them (Bannerman, 2008; Cule et al., 2000). To deal with this issue, some risk factors can be grouped and managed together. Using the construction project risk management terminology, risk factors are grouped into risks using some classification framework according to different criteria, e.g., their perceived source (Baccarini et al., 2004; Bannerman, 2008; Cule et al., 2000; Keil et al., 1998; Liu and Wang, 2014; Wallace et al., 2004). Since checklists and classification frameworks are closely related, they both have the same drawback. Risk factors are generic and based on past research which raises the prospect that risk assessment may be biased or limited in scope (Bannerman, 2008). The third risk management approach is process models. Process models specify risk management activities which follow a general risk management process: establishing the context, risk identification, risk analysis, risk evaluation, risk treatment,

1264


communication and consultation, and monitoring and review (Aloini et al., 2012; Baccarini et al., 2004; Bandyopadhyay et al., 1999; Bannerman, 2008; de Bakker et al., 2012; ISO, 2009; Kwan and Leung, 2011). It is not uncommon to use all presented approaches combined, e.g., to use checklists or classification frameworks in risk identification (Bannerman, 2008; de Bakker et al., 2010). When combining these approaches, the focus is on project-specific risk factors rather than the top-ranked generic risk factors (de Bakker et al., 2010). To achieve this, free-format information generation techniques, such as brainstorming, may be employed (de Bakker et al., 2010). Until recently risk management research focused on “hard skills” centering around administrative tasks (Söderlund and Maylor, 2012). Software projects involve a variety of stakeholders with complex interrelationships and diverse backgrounds (de Carvalho and Rabechini Junior, 2015). Different stakeholders may have varying or even conflicting perspectives on risks (Hartono et al., 2014; Osipova and Eriksson, 2013; Saunders et al., 2015). As it became apparent that effective risk management requires broad involvement and collaboration of stakeholders, the focus of risk management research broadened to encompass the “soft skills” concerning the management of interpersonal relationships and the notion of project environment as well (de Carvalho and Rabechini Junior, 2015; Liu and Wang, 2014; Sanderson, 2012; Söderlund and Maylor, 2012).

User resistance manifest itself in various ways, such as inaction, distance, lack of interest, delay tactics, excuses, persistence of former behavior, withdrawal, voicing opposite points of view, asking others to intervene or forming coalitions (Lapointe and Rivard, 2005). In the most aggressive manifestations, user resistance seeks to be disruptive and may even be destructive, e.g., infighting, making threats, strikes, boycotts and sabotage (Lapointe and Rivard, 2005). Most resistance research focuses on resistance of the change recipients. However, research shows that other stakeholders may be contributing to resistance or resist themselves (Fiedler, 2010; Ford et al., 2008; Laumer, 2011; Markus, 1983; Nutt, 1998; Rivard and Lapointe, 2012; Sigala, 2013). Focusing on user resistance therefore may not be sufficient. The stakeholder theory may be applied to resistance to change theory to extend it. The stakeholder concept has its roots in strategic management and has already been applied to other research fields, such as project and portfolio management (Beringer et al., 2013). A software project stakeholder is any individual or group who can affect or is affected by a software project (de Bakker et al., 2011; Freeman, 2010). Different stakeholder views have to be considered in order to adequately analyze resistance (Beringer et al., 2013; Ford et al., 2008; Laumer, 2011). Therefore, we promote the concept of stakeholder resistance instead of the established but misleading term user resistance throughout this paper.

2.2. Resistance to change 2.3. Resistance checklist Lewin (1947) was one of the first researchers to use the term resistance to change defined as the force against change in organizations (Laumer, 2011). Resistance to change has been thoroughly studied both in managerial psychology and information systems research (Laumer, 2011). Managerial psychology research mostly focused on individuals and some researchers even considered resistance as a personal trait (Laumer, 2011; Oreg, 2003). Information system research focused on user resistance defined as opposition of an individual user or groups of users to change associated with a software project (Kim and Kankanhalli, 2009). User resistance may be present in before, during and/or after a software project (Kim and Kankanhalli, 2009; Meissonier and Houzé, 2010; Pardo del Val and Martínez Fuentes, 2003). Some authors even argue that user resistance is embedded in the change process and therefore inevitable (Ferneley and Sobreperez, 2006; Meissonier and Houzé, 2010). By itself, user resistance is neither positive nor negative even though it is commonly associated by a negative connotation (Ferneley and Sobreperez, 2006; Hultman, 2003; Lawrence, 1954; Rivard and Lapointe, 2012; van Offenbeek et al., 2013). On one hand, it can be destructive and consume excessive resources (Hong and Kim, 2002; Kim, 2011). On the other hand, there may be good reasons for user resistance. In such cases, user resistance can be constructive, e.g., if it reveals flaws of the new software (Ferneley and Sobreperez, 2006; Ford et al., 2008; Jiang et al., 2000; Kim and Kankanhalli, 2009; Lundy and Morin, 2013; Marakas and Hornik, 1996; Piderit, 2000). User resistance therefore needs adequate management whether it is positive or negative (Rivard and Lapointe, 2012).

Theoretical explanations of stakeholder resistance and checklists can be found in information systems research. Theoretical explanations provide an insight into the stakeholder resistance black-box (Rivard and Lapointe, 2012). Hirschheim and Newman (1988) state that resistance is a complex phenomenon which can have a variety of causes, such as innate conservatism, lack of felt need, and uncertainty. According to Joshi (1991) users evaluate the software project on the individual, peer group and organizational level. Resistance occurs when perceived inequity on either level of evaluation. Marakas and Hornik (1996) argue that perceived threats or stresses that an individual associates with a software project cause covert resistance. Martinko et al. (1996) posit that individuals make causal attributions of a software project based on internal and external influences. These attributions lead to expectations about future performance outcomes whichmay lead to resistance. Ferneley and Sobreperez (2006) identified four antecedent conditions to resistance, i.e., enforced proceduralization, organizational and personnel issues, discipline and non-engagement with the system, which may result in various kinds of workarounds. Kim and Kankanhalli (2009) argue that switching costs indirectly increase resistance by negatively impacting perceived value. Markus (1983) adopted a political perspective of the interaction theory and suggested that resistance is a result of conflict among groups who are vying for power. Lapointe and Rivard (2005) found that resistance is milder in the earlier stages of a software project. In these stages, resistance emerges as a combination of independent individual behaviors.


1265

Table 1 Resistance checklist. Source of resistance

Description

Lack of top management commitment

Management should establish and clearly follow a vision of supporting and encouraging the change. If other stakeholders do not perceive the management as following the formal vision associated with the new software, they are unlikely to be its willing advocates Aloini et al. (2012), Baccarini et al. (2004), Hirschheim and Newman (1988), Lundy and Morin (2013), Pardo del Val and Martínez Fuentes, (2003), Rumelt (1995). Outcomes of past software projects influence the expectations about the current software project which then drive individuals’ affective and behavioral reactions to it. For example, users might refuse to accept undesired information due to hubris or it may derive from fear of repeating a bad experience with an unsuccessful past software project Martinko et al. (1996), Pardo del Val and Martínez Fuentes, (2003), Rumelt (1995). Individuals may associate a change and the uncertainties it brings with different kinds of threats. For example, stakeholders may resist because they fear uncertainty, losing their jobs, being transferred away from their friends, losing status, or sacrificing past investments Hirschheim and Newman (1988), Jiang et al. (2000), Kim and Kankanhalli (2009), Lapointe and Rivard (2005), Lawrence (1954), Long and Spurlock (2008), Lundy and Morin (2013), Marakas and Hornik (1996), Pardo del Val and Martínez Fuentes (2003), Rumelt (1995), Vrhovec et al. (2014). Organizational politics are among the most prominent sources of resistance. For example, the software project may cause a redistribution of resources which could affect the balance of power among various interest groups in the organization Altuwaijri and Khorsheed, (2011), Baccarini et al. (2004), Ferneley and Sobreperez (2006), Hirschheim and Newman (1988), Jiang et al. (2000), Lapointe and Rivard (2005), Markus (1983), Pardo del Val and Martínez Fuentes (2003), Rumelt (1995). A temporal disruption of day-to-day work, temporally increased risk of organizational failure and excess effort directly related to the software project Long and Spurlock (2008), Lundy and Morin (2013), Pardo del Val and Martínez Fuentes (2003), Rumelt (1995). The gap between the tasks that need to be performed and the competencies and capabilities of users (Fiedler (2010), Long and Spurlock (2008), Lundy and Morin (2013), Ocepek et al. (2013), Pardo del Val and Martínez Fuentes (2003), Rumelt (1995). Refusal of users to fully use the new software or identify with it due to the difficulty of deciding who is going to move first or general apathy Ferneley and Sobreperez (2006), Pardo del Val and Martínez Fuentes (2003), Rumelt (1995). Inability of the management to look into the future with clarity due to the expected dominance of short-term goals over long-term goals Pardo del Val and Martínez Fuentes (2003), Rumelt (1995). Conservatism manifests itself as resistance when the new software enforces changed work processes and structures as users prefer to stay with the way of doing things to which they are accustomed to Ferneley and Sobreperez (2006), Hirschheim and Newman (1988), Hong and Kim (2002), Jiang et al. (2000), Lundy and Morin (2013), Pardo del Val and Martínez Fuentes (2003), Rumelt (1995). Stakeholders may resist if the believe that obstacles are inevitable Long and Spurlock (2008), Pardo del Val and Martínez Fuentes (2003), Rumelt (1995). A strong disagreement between groups about the nature of the problem and its consequent alternative solutions Atkinson et al. (2006), Hartono et al. (2014), Pardo del Val and Martínez Fuentes (2003), Rumelt (1995). Peer pressure and restricted thinking that groups impose, rejecting or even punishing ideas and information that deviate too much from those generally accepted in the group Eckhardt et al. (2009), Ferneley and Sobreperez (2006), Pardo del Val and Martínez Fuentes (2003), Rumelt (1995). Fast and complex changes in the enterprise’s environment that inhibit the ability of the enterprises to analyze the situation properly Pardo del Val and Martínez Fuentes (2003), Rumelt (1995). Stakeholders may resist if benefits of the new software are relatively low compared to benefits of the old software resulting in dulled motivation for change Fiedler (2010), Joshi (1991), Kim and Kankanhalli (2009), Long and Spurlock (2008), Lundy and Morin (2013), Pardo del Val and Martínez Fuentes (2003), Rumelt (1995).

Past outcomes

Perceived threats

Organizational politics

Direct costs

Capabilities gaps

Collective action problems

Myopia Conservatism

Reactive mindset Incommensurable beliefs

Groupthink

Speed and complexity Lack of perceived value

In later stages of a software project, however, resistance may strengthen if individual behaviors converge. Additionally, the object of resistance is not always the new software. If the balance of power between interest groups is disrupted due to the software project, the object may switch from the new software to

new software significance or even to the new software change agents. Stakeholder resistance has been compared to the symptoms of a bodily disease and checklists may help to diagnose it (Lawrence, 1954; Rivard and Lapointe, 2012). In this paper, we

1266


adopted Rumelt’s checklist which has also been empirically tested (Pardo del Val and Martínez Fuentes, 2003; Rumelt, 1995). We adapted Rumelt’s checklist as presented in Table 1 to include the complementary findings.

2.4. Towards an organizational risk diagnosing (ORD) framework The main premise of this paper is that some organizational risk factors may be symptoms with root causes that are not trivial to determine. If risk factors are not properly diagnosed, risk responses may therefore just address the symptoms while leaving the underlying causes intact. In turn, this may lead to ineffective risk responses and hinder the success of risk management. To address these issues, the organizational risk diagnosing (ORD) framework is proposed. For easier understanding, the ORD framework is applied to the resistance context developed throughout the paper. The resulting ORD framework is presented in Fig. 1. First, stakeholder resistance can be considered as a software project risk (Fiedler, 2010; Vrhovec and Rupnik, 2011). Next, sources of this risk can be considered as risk factors. Finally, a variety of root causes may be underlying these risk factors. These causes may be project-specific and therefore cannot be predetermined. In contrast to the traditional software project risk management theory, we argue that it is vital that organizational risk factors are first diagnosed in order to determine the underlying root causes. Adequately determined root causes may significantly change the management actions during and after the software project with reference to effective risk management.

3. Research method An explanatory case study was used as research approach due to several reasons. First, the complex interaction of different stakeholders and new software can be best analyzed with a case study (Trkman and Trkman, 2014; Vavpotič and Hovelja, 2012). Next, case study is the most suitable research approach for investigating contemporary events with no control over the environment (de Bakker et al., 2011; Trkman and Trkman, 2009; Yin, 2009). Finally, case study is particularly appropriate for studying software development and implementation in natural organizational settings (Bansler and Havn, 2004; Darke et al., 1998; Trkman and Trkman, 2014). The unit of analysis of the case study was a software project in one of the biggest banks in South-Eastern Europe. This bank competes in several national markets (e.g., Austria, Italy, Slovenia, Germany, and Serbia) and from this point of view can be considered a typical bank for the region. The new loan application software that was implemented in the studied project replaced a legacy core banking system. The software project duration was 14 months and it primarily affected approximately 300 loan officers. Five key stakeholders were identified: project management, business process management, IT personnel, key users, and loan officers. The project was managed by a project manager and his staff from the project management office with the help of the chief training officer from the IT department. The project team additionally included the IT personnel from the IT department. Key users were also assigned to the project however they were not officially part of the project team. They were selected among loan officers by their superiors. The project team gathered requirements directly from the key users. This included business processes requirements which had to be later synchronized with the business

Fig. 1. Organizational risk diagnosing (ORD) framework.


process department who had ownership over the business processes. Data triangulation is used in this study to assure case study validity and to provide confirmatory data (Molineux, 2013). Different types of data and data provided by different stakeholders were compared against each other to ensure consistency of the results (de Bakker et al., 2011; Molineux, 2013). Data was collected in open-ended interviews (Ahn et al., 2010), surveys, focus groups (Ahn et al., 2010), and by documentation produced by the project, such as project reports and documentation from the risk management process. To assure reliability, a case study protocol was prepared (Yin, 2009). It included research questions, methods and procedures for data collection, and data analysis guidelines. We interviewed the project manager, the chief training officer, the chief business analyst, and the chief information officer at various project milestones. In total, eleven interviews were conducted. They varied in duration from 0.5 to 1.5 hours. Additionally, a survey using the resistance checklist was conducted to assess probability and effect of risk factors. The subjects of the survey were the 20 project team members. After an explanation of the resistance checklist and effect measurement items by the researchers, the respondents were asked to complete the survey. The survey included a single-item measure for each of the resistance checklist items’ (see Table 1) probability and a multiple-item measure for their effect. The effect construct included 12 items building on the well-established four-dimensional project success construct proposed by Atkinson (1999) which was further adapted to include the findings of the DeLone and McLean Model of Information Systems Success (DeLone and McLean, 2003). The effect measurement items included: time, cost, quality, intention to use, user satisfaction, added value, strategic goals, organizational learning, employee development, customer satisfaction, satisfaction of suppliers, and satisfaction of owners. A reliability analysis was performed on the effect construct using the Cronbach’s alpha method. Cronbach’s alpha values for different resistance checklist items varied from 0.817 (lack of top management commitment) to 0.973 (capabilities gaps) which signifies high reliability (Chow and Cao, 2008; Markelj and Bernik, 2014). A seven-point Likert scale (−3 = I strongly disagree, 3 = I strongly agree) was used to assess all measurement items. The results of the survey were presented to five focus groups of four representing the five identified key stakeholders. First, each focus group developed its own set of root causes based on the survey results. Next, all developed sets of root causes were presented to other focus groups. Finally, the focus groups began an inter-group discussion resembling the Delphi method on possible root causes based on the presented sets. After the first iteration, consensus on the underlying causes has already been achieved therefore the process was not repeated. For validation, the conclusions on the root causes were discussed with the management board comprising of the chief information officer, the chief manager of the project management office, the project manager, the chief business analyst, the chief end-user training officer, the chief software architect, and the chief software designer.

1267

4. Results and discussion 4.1. Risk factors This subsection presents the results of the resistance checklist survey and the focus groups. The initial resistance checklist evaluation was done in a survey. The results are presented in Table 2. Based on the results of the survey, risk factors were categorized into four groups according to effect and probability means for all risk factors (effect mean = 0.17, probability mean = − 0.17) as presented in Table 3. For example, risk factor “Past outcomes” has above mean effect (effect = 0.80) and below mean probability (probability = − 0.25). Therefore, it is categorized as high effect and low probability. Categorized risk factors were an input to the focus groups that had to interpret them. Summarized and consolidated different stakeholder interpretations are presented in the following paragraphs. First, risk factors with high effect and probability were interpreted. The key users, the business process management and the loan officers stated that incommensurable beliefs stem from a lack of knowledge of the IT personnel about the bank’s business processes that manifested itself from the start of the project. The key users complained “We had to explain the business process over and over again“, which prolonged the business process analysis considerably. Even so, they claimed that the first prototypes presented to them were inadequate because the IT personnel did not sufficiently understand the business processes. The IT personnel however complained that the key users were giving superficial descriptions of business processes. Also, in their opinion the key users tended to change their descriptions during the programming phase long after the business process analysis had been completed. Regarding groupthink, the business process management explained that the IT personnel tried to change the business processes during the business process analysis phase. They believed that they were not competent enough to propose a redesign of business processes. The key users took a similar posture by stating that “They are just creating unnecessary work for us.” The IT personnel however explained that the key users and business Table 2 Initial risk assessment. Risk factor

Effect

Probability

Incommensurable beliefs Groupthink Speed and complexity Lack of top management commitment Past outcomes Myopia Reactive mindset Conservatism Lack of perceived value Collective action problems Perceived threats Organizational politics Direct costs Capabilities gap

0.87 0.80 0.51 0.92 0.80 0.66 0.57 0.14 − 0.16 − 1.00 − 0.36 − 0.76 − 0.60 0.00

0.20 0.10 1.90 − 0.20 − 0.25 − 0.85 − 0.30 − 0.10 0.25 0.65 − 1.20 − 0.65 − 1.15 − 0.80

1268


Table 3 Categorized risk factors. Effect

Probability

Risk factors

High

High

High

Low

Low

High

Low

Low

Incommensurable beliefs Groupthink Speed and complexity Lack of top management commitment Past outcomes Myopia Reactive mindset Conservatism Lack of perceived value Collective action problems Perceived threats Organizational politics Direct costs Capabilities gap

process management just wanted them to mindlessly replicate the existing business processes in the new software. An additional complaint of the IT personnel was that the key users were a priori negatively biased towards any proposed changes during the business process analysis. The loan officers did not address the described conflict. Instead, they complained that they were poorly informed about the project. Their preconceived negative opinion was based on their fear that the project would trivialize the loan application process to the extent that “Even tellers could do it.” Loan officers with opposing ideas were peer-pressured into changing their views or isolated which suppressed the positive opinions among loan officers about the project. Interpreting speed and complexity, the key users criticized the pace of work of the IT personnel by stating “It takes ages to implement a single checkbox!” The project management and IT personnel however attributed this to the European Central Bank (ECB) for overloading them with fast changing regulations that had to be implemented in the new software. During the course of the project ECB required that additional restrictions and fail safes to be added to the new software. To make matters even more problematic, these new restrictions were not part of a single package but were released over several weeks. Next, risk factors with high effect and low probability were interpreted. The key users were of the opinion that the bank’s official strategy is not updated often enough which in their opinion clearly shows the lack of top management commitment to the project. They complained that it takes too much effort to submit and implement an idea that is yet to become a part of the bank’s official strategy. For this reason, they never felt fully engaged in the project. When interpreting past outcomes, the loan officers pointed out that the middle managers ignored the project and refused to actively engage in it. In their opinion, they had a generally negative attitude towards the project because of bad experiences related to the introduction of the legacy core banking system. When considering myopia, all stakeholders highlighted the dominance of the short-term goals over the long-term goals. An interesting saying describing the situation has spread in the bank: “The bank is like a train that runs on a railroad which is being build right in front of it and

dismantled behind it.” The project management explained that in their view the problems are being solved with short-term and superficial quick-fixes instead of solutions that would address the real problems. The IT personnel additionally complained that they spend a lot of energy on solutions that do not bring significant long-term benefits to the bank, which decreases their motivation to work on the project. Two interpretations of reactive mindset were emphasized. The IT personnel brought up the issues with the legacy core banking system. In the past, the IT personnel were very accommodating to the business demands. The result was a very complex software environment consisting of hundreds of software applications in several programming languages. Such software environment was a challenge to maintain. A large part of the IT personnel accepted such environment as normal. For this reason, it is not hard for them to a priori accept new demands in the project especially since this means additional paid work hours. The key users also considered the project in conflict with their interests. Not only that they did not receive any additional remuneration for their work on the software project, they also lost their variable performance bonus from their regular assignments. Since the key users believed this issue was inevitable, this significantly lowered their motivation to engage the project. Afterwards, risk factors with low effect and high probability were interpreted. Concerning conservatism, the loan officers explained that the new software makes them more error-prone, which is one of the criteria the management uses to compile the lay-off list that is a part of the post-financial crisis downsizing plan. The downsizing plan had already reduced the workforce by approximately 15 percent. Thus, the loan officers attempted to defend the current way of doing things to minimize the threat of making errors. This in turn impeded good collaboration of loan officers with the project team. It also increased the loan officers’ dislike of new technologies because, as they stated, “At present, it is hard to see over the edge of one’s cubical.” When interpreting lack of perceived value, the loan officers and key users remarked that the new loan application system will be beneficial as it will be more centralized. However, they also mentioned that the value of such centralized system would be diminished if the improvements and bug-fixes would only be locally applicable as they have been in the past. The question whether middle managers were sufficiently informed on the project as they show apathy towards it arose when loan officers interpreted collective action problems. However, this was not considered as an important issue since the middle managers were not opposing the project. Finally, risk factors with low effect and low probability were interpreted. Stakeholders addressed these risk factors and confirmed the evaluation done by the survey. However, no interpretations were provided since all stakeholders considered them as not present in the studied project. 4.2. Diagnosing risk factors Each stakeholder group presented their interpretation to the others. The results of the inter-group discussion are presented in this subsection. Four root causes have been identified


underlying some of the risk factors as presented on Fig. 2. The root causes are elaborated in the following paragraphs. Organizational issues have been identified as the first root cause. This root cause was underlying five risk factors: lack of top management commitment, past outcomes, myopia, reactive mindset, and conservatism. Organizational issues encompass the problems that four different stakeholders need to work with. In the current organization, the key users never felt fully engaged in the project because “It takes too much effort to realize an idea that is not already a part of the strategy.” Additionally, the key users do not fully commit to the project because their involvement in it directly reduces the variable part of their salary. The IT personnel need to deal with the tendency of the business to push the short-term goals at the expense of the long-term ones. In their opinion, this not only negatively affects the long-term quality of the new software but also hinders the development of new banking products. Another organizational issue was identified involving the middle management. When the loan officers presented their interpretation of past outcomes, the business process management openly opposed it. Instead, they proposed that middle management’s apathy may stem from overload with daily routine tasks. The project management confirmed this assumption by stating that the middle management was significantly overworked due to a recent downsizing plan. As a consequence, the project was seen as a workforce drain that hindered their day-to-day work. The downsizing plan also caused a final organizational issue involving the loan officers. New software was being introduced to them in an environment where each mistake could put them on the lay-off list. It is therefore not a surprise that they tried to defend the way of doing things they were accustomed to. Struggle for power was identified as the second root cause. It described how the IT personnel, the key users, and the business process management were vying for power. Struggle for power was underlying two risk factors: incommensurable beliefs, and groupthink. The conflicts between the IT personnel on one side, and the key users and the business process management on the other over who has the right to propose

1269

changes to business processes have their roots in the desire of these stakeholders to be in control of the business process redesign. The discussion showed that there is little willingness of both sides for compromise and to accept the reasoning of the other. The business process management and the key users justified their current dominant status through tradition. In contrast, the IT personnel felt that their status was not being recognized because they were prevented from modifying the business processes. As the third root cause, threats to status were identified. This root cause is also underlying two risk factors: groupthink, and reactive mindset. The loan officers and the IT personnel perceived that their status has been threatened. The loan officers were concerned that the new software will enable employees with a lower status than themselves, such as tellers, to conduct the loan applications without any significant training. They considered this as a direct threat to their status and worth. One of the main goals of the software project was to simplify the complex software environment. Some of the IT personnel considered this to be in direct conflict with their interest and status. Even though they realize that the current software environment is too complex, the IT personnel still take professional pride in the fact that they can implement all business requests not considering the consequences for the software environment. Communication issues were identified as the last root cause. It underlies two risk factors: groupthink, and speed and complexity. Communication issues predominantly affected the loan officers. They were informed about the project and its benefits through routine daily bank-wide newsletters. However, this communication channel proved ineffective as most loan officers ignored or missed the positive information about the project. The effectiveness of these newsletters was reduced due to information overload. On a typical day, up to five newsletters each consisting of one to five A4 pages plus attached documentation were sent. As a result, an environment was created where preconceived negative attitudes towards the project and its team were spread through unfounded rumors. Communication

Fig. 2. Risk factors diagnosis.

1270


issues between the project management and the IT personnel on one side, and the key users on the other were also identified. The key users did not understand the reasons for seemingly long IT personnel response times. The project management and the IT personnel apparently failed to communicate the reasons to them. 4.3. Analysis and discussion With the application of the ORD framework we showed how organizational risks can be better understood. The results of the case study show that risk factors may indeed have non-trivial underlying root causes. For eight risk factors out of fourteen resistance checklist items, four root causes have been identified nd analyzed: organizational issues, struggle for power, threats to status, and communication issues. The analysis of the root causes and their relations to risk factors raised several interesting questions. In our case, the use of the checklist approach to risk management would very likely be ineffective. For example, struggle for power was one of the identified root causes. Although this is an example of the organizational politics risk factor, both the survey and the individual stakeholder focus groups failed to detect it. Struggle for power surfaced only after interpretations of different stakeholders were put together. Similarly, perceived threats were initially not detected but the threats to status were identified as one of the root causes. These findings seem to be in line with the study of de Bakker et al. (2011) who reported that risk management activities which are meeting different stakeholder views, such as risk identification, create awareness and a common view among stakeholders. However, the possible implications of our case go another step further. Our findings suggest that looking at an issue from different stakeholder viewpoints and just aggregating the pieces of information does not necessarily unfold all the details. A key step in creating awareness may be the “brainstorming effect” that took effect during the inter-group discussion. During the case study, a stakeholder that was not participating in risk management activities has been identified. The project management initially did not consider the middle management as one of the key stakeholders. The middle management was first mentioned in loan officers’ interpretations. When presented with them, both the business process management and project management quickly discharged their interpretations since they believed that they saw the bigger picture themselves. Even though some organizational issues addressed the middle management, they were not directly included into the risk management process as this was not deemed necessary. Instead, the project management and the business process management devoted themselves to consider them more in further risk management activities. The proposed resistance checklist was compared against the results of the study. Risk identification using the resistance checklist proved only partially effective as the stakeholders misjudged the significance of at least two risk factors. This observation coincides with extant research on stakeholder resistance which considers it a complex phenomenon that is a

challenge to diagnose (Fiedler, 2010; Hultman, 2003; Laumer, 2011). Hultman (2003) even suggests that all conclusions need to be regarded as hypotheses, open to modification if new information is revealed. As such, the resistance checklist may only be one of the tools needed to adequately diagnose stakeholder resistance. The results of its use may be used in further resistance diagnosing activities preferably including various stakeholders, such as the inter-group discussion that we employed in our case.

5. Conclusion The challenge of the management of organizational risks has its roots in one of the greatest sources of uncertainty in any project undertaking – people. This paper makes a number of theoretical and practical contributions to the understanding of this field. The first contribution is theoretical. We attempt to advance the understanding of organizational risks by proposing the ORD framework. The ORD framework posits that some organizational risk factors may be symptoms with root causes that are not trivial to determine. Therefore, organizational risks need to be diagnosed in order to identify the underlying root causes. Our case study showed that only risk responses addressing these root causes may be truly effective. The second contribution is practical. We demonstrated how to use the proposed ORD framework to diagnose the risk of resistance to change. Similarly, the framework could be used to diagnose other organizational risks. The ORD framework has however an important limitation which needs to be noted. It relies on stakeholders providing their own views and opinions. If some of the key stakeholders refuse to cooperate or do not cooperate faithfully in risk management, its effectiveness may be hindered. The third contribution is theoretical. This paper updates Rumelt’s resistance checklist based on a review of both managerial psychology and information systems research. The proposed resistance checklist consolidates into a common framework the various aspects of stakeholder resistance that have been researched. The fourth contribution is practical. We demonstrated how to use the proposed resistance checklist. It has proved to be an effective tool for early resistance identification. Nevertheless, the derived conclusions should be regarded as hypotheses that need further investigation to confirm or reject them. This paper has some limitations the readers should note. A single case study was conducted thus caution is needed when generalizing its results. The selected case was a single project in a large bank where various stakeholders were present. Other organizational settings, such as smaller organizations with fewer stakeholders, may produce different results. The case study exposed software development methodology flaws regarding the communication of the project team with other project stakeholders. Additional research on improving these issues would be valuable. In our study, only the resistance risk was considered. Research considering other organizational risks would also be beneficial.


Conﬂict of interest There is no conflict of interest. References Ahn, M.J., Zwikael, O., Bednarek, R., 2010. Technological invention to product innovation: A project management approach. Int. J. Proj. Manag. 28, 559–568. http://dx.doi.org/10.1016/j.ijproman.2009.11.001. Aloini, D., Dulmin, R., Mininno, V., 2007. Risk management in ERP project introduction: Review of the literature. Inf. Manag. 44, 547–567. http://dx. doi.org/10.1016/j.im.2007.05.004. Aloini, D., Dulmin, R., Mininno, V., 2012. Risk assessment in ERP projects. Inf. Syst. 37, 183–199. http://dx.doi.org/10.1016/j.is.2011.10.001. Altuwaijri, M.M., Khorsheed, M.S., 2011. InnoDiff: A project-based model for successful IT innovation diffusion. Int. J. Proj. Manag. 30, 37–47. http://dx. doi.org/10.1016/j.ijproman.2011.04.007. Atkinson, R., 1999. Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria. Int. J. Proj. Manag. 17, 337–342. http://dx.doi.org/10.1016/S0263-7863(98)00069-6. Atkinson, R., Crawford, L., Ward, S., 2006. Fundamental uncertainties in projects and the scope of project management. Int. J. Proj. Manag. 24, 687–698. http://dx.doi.org/10.1016/j.ijproman.2006.09.011. Baccarini, D., Salm, G., Love, P.E.D., 2004. Management of risks in information technology projects. Ind. Manag. Data Syst. 104, 286–295. http://dx.doi.org/10.1108/02635570410530702. Bandyopadhyay, K., Mykytyn, P.P., Mykytyn, K., 1999. A framework for integrated risk management in information technology. Manag. Decis. 37, 437–444. Bannerman, P.L., 2008. Risk and risk management in software projects: A reassessment. J. Syst. Softw. 81, 2118–2133. http://dx.doi.org/10.1016/j.jss. 2008.03.059. Bansler, J.P., Havn, E., 2004. Exploring the role of network effects in IT implementation: The case of knowledge repositories. Inf. Technol. People 17, 268–285. http://dx.doi.org/10.1108/09593840410554184. Benaroch, M., Lichtenstein, Y., Robinson, K., 2006. Real options in information technology risk management: An empirical validation of riskoption relationships. MIS Q. 30, 827–864. Beringer, C., Jonas, D., Kock, A., 2013. Behavior of internal stakeholders in project portfolio management and its impact on success. Int. J. Proj. Manag. 31, 830–846. http://dx.doi.org/10.1016/j.ijproman.2012.11.006. Bernroider, E.W.N., Wong, C.W.Y., Lai, K., 2014. From dynamic capabilities to ERP enabled business improvements: The mediating effect of the implementation project. Int. J. Proj. Manag. 32, 350–362. http://dx.doi.org/ 10.1016/j.ijproman.2013.05.006. Chow, T., Cao, D.-B., 2008. A survey study of critical success factors in agile software projects. J. Syst. Softw. 81, 961–971. http://dx.doi.org/10.1016/j. jss.2007.08.020. Cule, P., Schmidt, R., Lyytinen, K., Keil, M., 2000. Strategies for Heading Off is Project Failure. Inf. Syst. Manag. 17, 61–69. http://dx.doi.org/10.1201/ 1078/43191.17.2.20000301/31229.8. Darke, P., Shanks, G., Broadbent, M., 1998. Successfully completing case study research: combining rigour, relevance and pragmatism. Inf. Syst. J. 8, 273–289. http://dx.doi.org/10.1046/j.1365-2575.1998.00040.x. De Bakker, K., Boonstra, A., Wortmann, H., 2010. Does risk management contribute to IT project success? A meta-analysis of empirical evidence. Int. J. Proj. Manag. 28, 493–503. http://dx.doi.org/10.1016/j.ijproman.2009.07. 002. De Bakker, K., Boonstra, A., Wortmann, H., 2011. Risk management affecting IS/IT project success through communicative action. Proj. Manag. J. 42, 75–90. http://dx.doi.org/10.1002/pmj.20242. De Bakker, K., Boonstra, A., Wortmann, H., 2012. Risk managements’ communicative effects influencing IT project success. Int. J. Proj. Manag. 30, 444–457. http://dx.doi.org/10.1016/j.ijproman.2011.09.003. de Carvalho, M.M., Rabechini Junior, R., 2015. Impact of risk management on project performance: the importance of soft skills. Int. J. Prod. Res. 53, 321–340. http://dx.doi.org/10.1080/00207543.2014.919423.

1271

DeLone, W.H., McLean, E.R., 2003. The DeLone and McLean Model of Information Systems Success: A Ten-Year Update. J. Manag. Inf. Syst. 19, 9–30. Eckhardt, A., Laumer, S., Weitzel, T., 2009. Who influences whom? Analyzing workplace referents’ social influence on IT adoption and non-adoption. J. Inf. Technol. 24, 11–24. http://dx.doi.org/10.1057/jit.2008.31. El Emam, K., Koru, A.G., 2008. A replicated survey of IT software project failures. IEEE Softw. 25, 84–90. Ferneley, E.H., Sobreperez, P., 2006. Resist, comply or workaround? An examination of different facets of user engagement with information systems. Eur. J. Inf. Syst. 15, 345–356. http://dx.doi.org/10.1057/palgrave. ejis.3000629. Fiedler, S., 2010. Managing resistance in an organizational transformation: A case study from a mobile operator company. Int. J. Proj. Manag. 28, 370–383. http://dx.doi.org/10.1016/j.ijproman.2010.02.004. Ford, J.D., Ford, L.W., D’Amelio, A., 2008. Resistance to change: the rest of the story. Acad. Manag. Rev. 33, 362–377. Freeman, R.E., 2010. Strategic management: A stakeholder approach. Cambridge University Press, Cambridge, UK. Geraldi, J.G., Kutsch, E., Turner, N., 2011. Towards a conceptualisation of quality in information technology projects. Int. J. Proj. Manag. 29, 557–567. http://dx.doi.org/10.1016/j.ijproman.2010.06.004. Hartono, B., Sulistyo, S.R., Praftiwi, P.P., Hasmoro, D., 2014. Project risk: Theoretical concepts and stakeholders’ perspectives. Int. J. Proj. Manag. 32, 400–411. http://dx.doi.org/10.1016/j.ijproman.2013.05.011. Hirschheim, R., Newman, M., 1988. Information Systems and User Resistance: Theory and Practice. Comput. J. 31, 398–408. Hong, K.-K., Kim, Y.-G., 2002. The critical success factors for ERP implementation: an organizational fit perspective. Inf. Manag. 40, 25–40. http://dx.doi.org/10.1016/S0378-7206(01)00134-3. Hultman, K., 2003. Resistance to change, managing. In: Bidgoli, H. (Ed.), Encyclopedia of information systems. Academic Press, San Diego, pp. 693–705. ISO, 2009. ISO 31000:2009, risk management – principles and guidelines. International Standards Organisation, Geneva. Jiang, J.J., Muhanna, W.A., Klein, G., 2000. User resistance and strategies for promoting acceptance across system types. Inf. Manag. 37, 25–36. http:// dx.doi.org/10.1016/S0378-7206(99)00032-4. Joshi, K., 1991. A model of Users’ perspective on change: the case of information systems technology implementation. MIS Q. 15, 229–242. http://dx.doi.org/10.2307/249384. Kappelman, L.A., McKeeman, R., Zhang, L., 2006. Early warning signs of IT project failure: The dominant dozen. Inf. Syst. Manag. 23, 31–36. http://dx. doi.org/10.1201/1078.10580530/46352.23.4.20060901/95110.4. Keil, M., Cule, P.E., Lyytinen, K., Schmidt, R.C., 1998. A framework for identifying software project risks. Commun. ACM 41, 76–83. Kim, H.-W., 2011. The effects of switching costs on user resistance to enterprise systems implementation. IEEE Trans. Eng. Manag. 58, 471–482. Kim, H.-W., Kankanhalli, A., 2009. Investigating user resistance to information systems implementation: A status quo bias perspective. MIS Q. 33, 567–582. Kutsch, E., Hall, M., 2005. Intervening conditions on the management of project risk: Dealing with uncertainty in information technology projects. Int. J. Proj. Manag. 23, 591–599. http://dx.doi.org/10.1016/j.ijproman. 2005.06.009. Kwahk, K.-Y., Kim, H.-W., 2007. Managing readiness in enterprise systemsdriven organizational change. Behav. Inf. Technol. 27, 79–87. http://dx.doi. org/10.1080/01449290701398475. Kwan, T.W., Leung, H.K.N., 2011. A risk management methodology for project risk dependencies. IEEE Trans. Softw. Eng. 37, 635–648. http://dx. doi.org/10.1109/TSE.2010.108. Lapointe, L., Rivard, S., 2005. A multilevel model of resistance to information technology implementation. MIS Q. 29, 461–491. Laumer, S., 2011. Why Do people reject technologies – a literature-based discussion of the phenomena “resistance to change”. ECIS 2011 Proceedings. Information Systems and Managerial Psychology Research. Lavbič, D., Vasilecas, O., Rupnik, R., 2010. Ontology-based multi-agent system to support business users and management. Technol. Econ. Dev. Econ. 16, 327–347. http://dx.doi.org/10.3846/tede.2010.21.

1272


Lawrence, P.R., 1954. How to deal with resistance to change. Harv. Bus. Rev. 32, 49–57. Lewin, K., 1947. Frontiers in group dynamics: concept method and reality in social science; social equilibria and social change. Hum. Relations 1, 5–41. http://dx.doi.org/10.1177/001872674700100103. Li, Y., Yang, M.-H., Klein, G., Chen, H.-G., 2011. The role of team problem solving competency in information system development projects. Int. J. Proj. Manag. 29, 911–922. http://dx.doi.org/10.1016/j.ijproman.2010.09. 004. Liu, S., Wang, L., 2014. Understanding the impact of risks on performance in internal and outsourced information technology projects: The role of strategic importance. Int. J. Proj. Manag. 32, 1494–1510. http://dx.doi.org/ 10.1016/j.ijproman.2014.01.012. Long, S., Spurlock, D.G., 2008. Motivation and stakeholder acceptance in technology-driven change management: implications for the engineering manager. Eng. Manag. J. 20, 30–36. Lundy, V., Morin, P., 2013. Project leadership influences resistance to change: the case of the Canadian public service. Proj. Manag. J. 44, 45–64. http:// dx.doi.org/10.1002/pmj.21355. Marakas, G.M., Hornik, S., 1996. Passive resistance misuse: Overt support and covert recalcitrance in IS implementation. Eur. J. Inf. Syst. 5, 208–219. http://dx.doi.org/10.1057/ejis.1996.26. Markelj, B., Bernik, I., 2014. Safe use of mobile devices arises from knowing the threats. J. Inf. Secur. Appl. http://dx.doi.org/10.1016/j.jisa.2014.11.001. Markus, M.L., 1983. Power, politics, and MIS implementation. Commun. ACM 26, 430–444. Martinko, M.J., Henry, J.W., Zmud, R.W., 1996. An attributional explanation of individual resistance to the introduction of information technologies in the workplace. Behav. Inf. Technol. 15, 313–330. Meissonier, R., Houzé, E., 2010. Toward an “IT Conflict-Resistance Theory”: action research during IT pre-implementation. Eur. J. Inf. Syst. 19, 540–561. http://dx.doi.org/10.1057/ejis.2010.35. Molineux, J., 2013. Enabling organizational cultural change using systemic strategic human resource management – a longitudinal case study. Int. J. Hum. Resour. Manag. 24, 1588–1612. http://dx.doi.org/10.1080/ 09585192.2012.723022. Nutt, P.C., 1998. Leverage, resistance and the success of implementation approaches. J. Manag. Stud. 35, 213–240. http://dx.doi.org/10.1111/14676486.00091. Ocepek, U., Bosnić, Z., Šerbec, I.N., Rugelj, J., 2013. Exploring the relation between learning style models and preferred multimedia types. Comput. Educ. 69, 343–355. http://dx.doi.org/10.1016/j.compedu. 2013.07.029. Oreg, S., 2003. Resistance to change: developing an individual differences measure. J. Appl. Psychol. 88, 680–693. http://dx.doi.org/10.1037/00219010.88.4.680. Oreg, S., Vakola, M., Armenakis, A.A., 2011. Change Recipients’ reactions to organizational change: a 60-year review of quantitative studies. J. Appl. Behav. Sci. 47, 461–524. http://dx.doi.org/10.1177/ 0021886310396550. Osipova, E., Eriksson, P.E., 2013. Balancing control and flexibility in joint risk management: Lessons learned from two construction projects. Int. J. Proj. Manag. 31, 391–399. http://dx.doi.org/10.1016/j.ijproman.2012.09.007. Pardo del Val, M., Martínez Fuentes, C., 2003. Resistance to change: a literature review and empirical study. Manag. Decis. 41, 148–155. http://dx. doi.org/10.1108/00251740310457597. Piderit, S.K., 2000. Rethinking Resistance and Recognizing Ambivalence: A Multidimensional View of Attitudes toward an Organizational Change. Acad. Manag. Rev. 25, 783–794. http://dx.doi.org/10.2307/259206. Rivard, S., Lapointe, L., 2012. Information technology Implementers’ responses to user resistance: nature and effects. MIS Q. 36, 897–920. Rumelt, R.P., 1995. Inertia and transformation. In: Montgomery, C.A. (Ed.), Resources in an evolutionary perspective: towards a synthesis of evolutionary and resource-based approaches to strategy. Kluwer Academic Publishers, Norwell, Mass., pp. 101–132. Sanderson, J., 2012. Risk, uncertainty and governance in megaprojects: A critical discussion of alternative explanations. Int. J. Proj. Manag. 30, 432–443. http://dx.doi.org/10.1016/j.ijproman.2011.11.002.

Saunders, F.C., Gale, A.W., Sherry, A.H., 2015. Conceptualising uncertainty in safety-critical projects: A practitioner perspective. Int. J. Proj. Manag. 33, 467–478. Schmidt, R., Lyytinen, K., Keil, M., Cule, P., 2001. Identifying software project risks: an international Delphi study. J. Manag. Inf. Syst. 17, 5–36. Sharma, A., Gupta, A., 2012. Impact of organisational climate and demographics on project specific risks in context to Indian software industry. Int. J. Proj. Manag. 30, 176–187. http://dx.doi.org/10.1016/j. ijproman.2011.05.003. Sigala, M., 2013. Examining the adoption of destination management systems: An inter-organizational information systems approach. Manag. Decis. 51, 1011–1036. http://dx.doi.org/10.1108/MD-11-2012-0800. Söderlund, J., Maylor, H., 2012. Project management scholarship: Relevance, impact and five integrative challenges for business and management schools. Int. J. Proj. Manag. 30, 686–696. http://dx.doi.org/10.1016/j. ijproman.2012.03.007. Tah, J.H.M., Carr, V., 2001. Knowledge-based approach to construction project risk management. J. Comput. Civ. Eng. 15, 170–177. Thamhain, H., 2013. Managing risks in complex projects. Proj. Manag. J. 44, 20–35. http://dx.doi.org/10.1002/pmj.21325. The Standish Group, 2013. CHAOS Manifesto 2013. Think big, act small. Tiwana, A., Keil, M., 2004. The one-minute risk assessment tool. Commun. ACM 47, 73–77. Trkman, M., Trkman, P., 2009. A wiki as intranet: a critical analysis using the Delone and McLean model. Online Inf. Rev. 33, 1087–1102. http://dx.doi. org/10.1108/14684520911011025. Trkman, M., Trkman, P., 2014. Actors’ misaligned interests to explain the low impact of an information system – A case study. Int. J. Inf. Manag. 34, 296–307. http://dx.doi.org/10.1016/j.ijinfomgt.2013.10.004. Van Offenbeek, M., Boonstra, A., Seo, D., 2013. Towards integrating acceptance and resistance research: evidence from a telecare case study. Eur. J. Inf. Syst. 22, 434–454. http://dx.doi.org/10.1057/ejis.2012.29. Vavpotič, D., Hovelja, T., 2012. Improving the evaluation of software development methodology adoption and its impact on enterprise performance. Comput. Sci. Inf. Syst. 9, 165–187. http://dx.doi.org/10.2298/ CSIS110503072V. Vrhovec, S., Rupnik, R., 2011. A model for resistance management in IT projects and programs. Electrotech. Rev. 78, 73–78. Vrhovec, S.L.R., Trkman, M., Kumer, A., Krisper, M., Vavpotič, D., 2014. Outsourcing as an economic development tool in transition economies: scattered global software development. Inf. Technol. Dev. http://dx.doi.org/ 10.1080/02681102.2013.874316. Wallace, L., Keil, M., 2004. Software project risks and their effect on outcomes. Commun. ACM 47, 68–73. Wallace, L., Keil, M., Rai, A., 2004. Understanding software project risk: a cluster analysis. Inf. Manag. 42, 115–125. http://dx.doi.org/10.1016/j.im. 2003.12.007. Yin, R.K., 2009. Case study research: design and methods. 4th ed. Sage Publications, Thousand Oaks, California http://dx.doi.org/10.1097/FCH. 0b013e31822dda9e. Zander, A., 1950. Resistance to change – its analysis and prevention. Adv. Manag. J. 15, 9–11. Žvanut, B., Pucer, P., Ličen, S., Trobec, I., Plazar, N., Vavpotič, D., 2011. The effect of voluntariness on the acceptance of e-learning by nursing students. Nurse Educ. Today 31, 350–355. http://dx.doi.org/10.1016/j. nedt.2010.07.004.

Simon L. R. Vrhovec is PhD Student at University of Ljubljana. His research interests include software project management, stakeholder resistance to change, agile methods, global software development, information security, and enterprise architecture.

Tomaž Hovelja is Assistant Professor at the Faculty of Computer and Information Science at the University of Ljubljana. He received bachelor's degree, master’s degree and his PhD in Business Administration from the Economic Faculty at the University of Ljubljana. His research areas are social,

S.L.R. Vrhovec et al. / International Journal of Project Management 33 (2015) 1262–1273 economic and organizational factors of IT deployment in enterprises and IT projects success criteria. His research has appeared in journals such as Technological and Economic Development of Economy, Journal of Systems and Software, Computer Science and Information Systems, Economic and Business Review for Central and South-Eastern Europe and others.

Damjan Vavpotič is Assistant Professor at the Faculty of Computer and Information Science at the University of Ljubljana and a member of the Information Systems Laboratory at the same university. His research interests include information systems development methodologies, IS methodology evaluation and adoption, and evaluation of e-learning and IT in pedagogical processes. His research has appeared in journals such as Information and Software Technology, Nurse Education Today, Informatica, Computer Science and Information Systems, Electronics and Electrical Engineering, and in proceedings of many international conferences.

1273

Marjan Krisper is Associate Professor at University of Ljubljana, Faculty of Computer and Information Science. He received the MSc from University of Ljubljana, Slovenia, and the PhD from University of Belgrade, Yugoslavia. He was Chair of Information Science and Head of Information Systems Laboratory at University of Ljubljana, Faculty of Computer and Information Science. His research interests include information systems, information systems development methodologies, information systems strategic planning, enterprise architecture and electronic business. He is a charter member of Association for Information Systems and a member of Slovenian Informatics Society.