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 South-
Eastern 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 38 percent have failed. This is at least worrying as large software

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: simvrh@gmail.com (S.L.R. Vrhovec).
URL: http://simvrh.wordpress.com/.
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,

http://dx.doi.org/10.1016/j.ijproman.2015.03.007
0263-7863/00/© 2015 Elsevier Ltd. APM and IPMA. All rights reserved.
 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 organiza-
tional 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 project-
specific 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 intro-
duced. 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 pros-
pect 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 S.L.R. Vrhovec et al. / International Journal of Project Management 33 (2015) 1262–1273
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 stake-
holders with complex interrelationships and diverse back-
grounds (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 environ-
ment as well (de Carvalho and Rabechini Junior, 2015; Liu and
Wang, 2014; Sanderson, 2012; Söderlund and Maylor, 2012).
2.2. Resistance to change
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 informa-
tion 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 conno-
tation (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).
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 manifes-
tations, 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 manage-
ment 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.3. Resistance checklist
Theoretical explanations of stakeholder resistance and
checklists can be found in information systems research.
Theoretical explanations provide an insight into the stake-
holder 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. Re-
sistance 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 procedurali-
zation, 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.
 S.L.R. Vrhovec et al. / International Journal of Project Management 33 (2015) 1262–1273 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).
Past outcomes 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).
Perceived threats 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 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).
Direct costs 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).
Capabilities gaps 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).
Collective action problems 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).
Myopia 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 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).
Reactive mindset Stakeholders may resist if the believe that obstacles are inevitable
Long and Spurlock (2008), Pardo del Val and Martínez Fuentes (2003), Rumelt (1995).
Incommensurable beliefs 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).
Groupthink 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).
Speed and complexity 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).
Lack of perceived value 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).

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 S.L.R. Vrhovec et al. / International Journal of Project Management 33 (2015) 1262–1273
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 organiza-
tional 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 deter-
mined root causes may significantly change the management
actions during and after the software project with reference
to effective risk management.
Fig. 1. Organizational risk diagnosing (ORD) framework.
3. Research method
An explanatory case study was used as research approach
due to several reasons. First, the complex interaction of dif-
ferent 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 implemen-
tation 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 require-
ments which had to be later synchronized with the business
 S.L.R. Vrhovec et al. / International Journal of Project Management 33 (2015) 1262–1273 1267

process department who had ownership over the business 4. Results and discussion
processes.
Data triangulation is used in this study to assure case study 4.1. Risk factors
validity and to provide confirmatory data (Molineux, 2013).
Different types of data and data provided by different stake- This subsection presents the results of the resistance
holders were compared against each other to ensure consistency checklist survey and the focus groups. The initial resistance
of the results (de Bakker et al., 2011; Molineux, 2013). Data checklist evaluation was done in a survey. The results are
was collected in open-ended interviews (Ahn et al., 2010), presented in Table 2.
surveys, focus groups (Ahn et al., 2010), and by documentation Based on the results of the survey, risk factors were
produced by the project, such as project reports and documen- categorized into four groups according to effect and probability
tation from the risk management process. means for all risk factors (effect mean = 0.17, probability
To assure reliability, a case study protocol was prepared mean = − 0.17) as presented in Table 3. For example, risk
(Yin, 2009). It included research questions, methods and factor “Past outcomes” has above mean effect (effect = 0.80)
procedures for data collection, and data analysis guidelines. We and below mean probability (probability = − 0.25). Therefore,
interviewed the project manager, the chief training officer, the it is categorized as high effect and low probability.
chief business analyst, and the chief information officer at Categorized risk factors were an input to the focus groups
various project milestones. In total, eleven interviews were that had to interpret them. Summarized and consolidated dif-
conducted. They varied in duration from 0.5 to 1.5 hours. ferent stakeholder interpretations are presented in the following
Additionally, a survey using the resistance checklist was paragraphs. First, risk factors with high effect and probability
conducted to assess probability and effect of risk factors. The were interpreted. The key users, the business process manage-
subjects of the survey were the 20 project team members. After ment and the loan officers stated that incommensurable beliefs
an explanation of the resistance checklist and effect measure- stem from a lack of knowledge of the IT personnel about the
ment items by the researchers, the respondents were asked to bank’s business processes that manifested itself from the start
complete the survey. The survey included a single-item of the project. The key users complained “We had to explain
measure for each of the resistance checklist items’ (see the business process over and over again“, which prolonged the
Table 1) probability and a multiple-item measure for their business process analysis considerably. Even so, they claimed
effect. The effect construct included 12 items building on the that the first prototypes presented to them were inadequate
well-established four-dimensional project success construct because the IT personnel did not sufficiently understand the
proposed by Atkinson (1999) which was further adapted to business processes. The IT personnel however complained that
include the findings of the DeLone and McLean Model of the key users were giving superficial descriptions of business
Information Systems Success (DeLone and McLean, 2003). processes. Also, in their opinion the key users tended to change
The effect measurement items included: time, cost, quality, their descriptions during the programming phase long after the
intention to use, user satisfaction, added value, strategic goals, business process analysis had been completed. Regarding
organizational learning, employee development, customer satisfac- groupthink, the business process management explained that
tion, satisfaction of suppliers, and satisfaction of owners. A the IT personnel tried to change the business processes during
reliability analysis was performed on the effect construct using the the business process analysis phase. They believed that they
Cronbach’s alpha method. Cronbach’s alpha values for different were not competent enough to propose a redesign of business
resistance checklist items varied from 0.817 (lack of top processes. The key users took a similar posture by stating that
management commitment) to 0.973 (capabilities gaps) which “They are just creating unnecessary work for us.” The IT
signifies high reliability (Chow and Cao, 2008; Markelj and personnel however explained that the key users and business
Bernik, 2014). A seven-point Likert scale (−3 = I strongly
disagree, 3 = I strongly agree) was used to assess all measurement
Table 2
items. The results of the survey were presented to five focus groups Initial risk assessment.
of four representing the five identified key stakeholders. First, each
Risk factor Effect Probability
focus group developed its own set of root causes based on the
survey results. Next, all developed sets of root causes were Incommensurable beliefs 0.87 0.20
Groupthink 0.80 0.10
presented to other focus groups. Finally, the focus groups began an
Speed and complexity 0.51 1.90
inter-group discussion resembling the Delphi method on possible Lack of top management commitment 0.92 − 0.20
root causes based on the presented sets. After the first iteration, Past outcomes 0.80 − 0.25
consensus on the underlying causes has already been achieved Myopia 0.66 − 0.85
therefore the process was not repeated. Reactive mindset 0.57 − 0.30
Conservatism 0.14 − 0.10
For validation, the conclusions on the root causes were
Lack of perceived value − 0.16 0.25
discussed with the management board comprising of the chief Collective action problems − 1.00 0.65
information officer, the chief manager of the project manage- Perceived threats − 0.36 − 1.20
ment office, the project manager, the chief business analyst, the Organizational politics − 0.76 − 0.65
chief end-user training officer, the chief software architect, and Direct costs − 0.60 − 1.15
Capabilities gap 0.00 − 0.80
the chief software designer.
1268 S.L.R. Vrhovec et al. / International Journal of Project Management 33 (2015) 1262–1273
Table 3
Categorized risk factors.
Effect Probability Risk factors
High High Incommensurable beliefs
Groupthink
Speed and complexity
High Low Lack of top management
commitment
Past outcomes
Myopia
Reactive mindset
Low High Conservatism
Lack of perceived value
Collective action problems
Low Low 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 pre-
conceived 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
 S.L.R. Vrhovec et al. / International Journal of Project Management 33 (2015) 1262–1273
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
Fig. 2. Risk factors diagnosis.
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 docu-
mentation 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
1270 S.L.R. Vrhovec et al. / International Journal of Project Management 33 (2015) 1262–1273
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, per-
ceived 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 differ-
ent 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.
 S.L.R. Vrhovec et al. / International Journal of Project Management 33 (2015) 1262–1273
Conflict 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 risk-
option 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 systems-
driven 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 S.L.R. Vrhovec et al. / International Journal of Project Management 33 (2015) 1262–1273
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/1467-
6486.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/0021-
9010.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 perfor-
mance. 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 1273

economic and organizational factors of IT deployment in enterprises and IT Marjan Krisper is Associate Professor at University of Ljubljana, Faculty of
projects success criteria. His research has appeared in journals such as Computer and Information Science. He received the MSc from University of
Technological and Economic Development of Economy, Journal of Systems Ljubljana, Slovenia, and the PhD from University of Belgrade, Yugoslavia. He
and Software, Computer Science and Information Systems, Economic and was Chair of Information Science and Head of Information Systems Laboratory
Business Review for Central and South-Eastern Europe and others. at University of Ljubljana, Faculty of Computer and Information Science. His
research interests include information systems, information systems develop-
ment methodologies, information systems strategic planning, enterprise
Damjan Vavpotič is Assistant Professor at the Faculty of Computer and architecture and electronic business. He is a charter member of Association
Information Science at the University of Ljubljana and a member of the for Information Systems and a member of Slovenian Informatics Society.
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.