Industrial Management & Data Systems

Management of risks in information technology projects

David Baccarini, Geoff Salm, Peter E.D. Love,
Article information:
To cite this document:
David Baccarini, Geoff Salm, Peter E.D. Love, (2004) "Management of risks in information technology projects", Industrial
Management & Data Systems, Vol. 104 Issue: 4, pp.286-295, https://doi.org/10.1108/02635570410530702
Permanent link to this document:
https://doi.org/10.1108/02635570410530702
Downloaded on: 13 February 2019, At: 19:44 (PT)
References: this document contains references to 62 other documents.
To copy this document: permissions@emeraldinsight.com
The fulltext of this document has been downloaded 13083 times since 2006*
Users who downloaded this article also downloaded:
Downloaded by VIT University At 19:44 13 February 2019 (PT)

(2008),"Risk management in a multi-project environment: An approach to manage portfolio risks", International Journal of
Quality &amp; Reliability Management, Vol. 25 Iss 1 pp. 60-71 <a href="https://doi.org/10.1108/02656710810843586">https://
doi.org/10.1108/02656710810843586</a>
(2007),"Managing risk in software development projects: a case study", Industrial Management &amp; Data Systems, Vol. 107
Iss 2 pp. 284-303 <a href="https://doi.org/10.1108/02635570710723859">https://doi.org/10.1108/02635570710723859</a>

Access to this document was granted through an Emerald subscription provided by emerald-srm:534948 []
For Authors
If you would like to write for this, or any other Emerald publication, then please use our Emerald for Authors service
information about how to choose which publication to write for and submission guidelines are available for all. Please visit
www.emeraldinsight.com/authors for more information.
About Emerald www.emeraldinsight.com
Emerald is a global publisher linking research and practice to the benefit of society. The company manages a portfolio of
more than 290 journals and over 2,350 books and book series volumes, as well as providing an extensive range of online
products and additional customer resources and services.
Emerald is both COUNTER 4 and TRANSFER compliant. The organization is a partner of the Committee on Publication Ethics
(COPE) and also works with Portico and the LOCKSS initiative for digital archive preservation.

*Related content and download information correct at time of download.


Management of
risks in information
technology projects
David Baccarini
Geoff Salm and
Peter E.D. Love
The authors
David Baccarini is at the Faculty of the Built Environment, Art
and Design, Curtin University of Technology, Perth, Australia.
Geoff Salm is at Dimension Data, West Perth, Australia.
Peter E.D. Love is at the School of Management Information
Systems, Edith Cowan University, Joondulap, Australia.
Downloaded by VIT University At 19:44 13 February 2019 (PT)
Keywords
Risk management, Project management, Information services
Abstract
Information technology (IT) projects are renowned for their high
failure rate. Risk management is an essential process for the
successful delivery of IT projects. In-depth interviews with IT
professionals from leading firms in Western Australia were
undertaken to determine how IT risks were managed in their
projects. The respondents ranked 27 IT risks in terms of likelihood
and consequences to identify the most important risks. The top
five risks, in order, were: personnel shortfalls; unreasonable
project schedule and budget; unrealistic expectations;
incomplete requirements; and diminished window of
opportunity due to late delivery of software. The respondents
overwhelmingly applied the treatment strategy of risk reduction
to manage these risks. Furthermore, these strategies were
primarily project management processes, rather than technical
processes. This demonstrates that project management is a risk
management strategy. Scope, quality management, and human
resource management were solutions applied to several risks. In
particular, managing stakeholders’ expectations is a specific risk
treatment that helps to manage several key IT risks.
Electronic access
The Emerald Research Register for this journal is
available at
www.emeraldinsight.com/researchregister
The current issue and full text archive of this journal is
available at
www.emeraldinsight.com/0263-5577.htm
Industrial Management & Data Systems
Volume 104 · Number 4 · 2004 · pp. 286-295
q Emerald Group Publishing Limited · ISSN 0263-5577
DOI 10.1108/02635570410530702
286
Introduction
Information technology (IT) is one of the fastest
growing industries in developed countries (Hartman
and Ashrafi, 2002). IT projects can implement a
rapidly expanding range of equipment, applications,
services, and basic technologies that provide
information to support the operation, management,
analysis and decision-making functions within an
organisation (Gunton, 1993; Keen, 1994;
Hoepleman et al., 1997; Wang, 2001; Yang, 2001).
In 1999, the Standish Group International study of
7,400 IT projects revealed that 34 per cent were late
or over budget, 31 per cent were abandoned, scaled
back or modified, and only 24 per cent were
completed on time and on budget (Cunningham,
1999). Examples of high profile IT project failures
reported in the literature include the American
Airlines Corporation AMR Information Services
(AMRIS), London Ambulance System, the Wessex
Health Service RISP (Regional Information Systems
Plan, London Stock Exchange’s Transfer and
Automated Registration of Uncertified Stock
(TAURUS) system, FoxMeyer Drug Co., Mandata
Human Resource System and the Californian State
Automated Child System (SACSS) (Sauer, 1993;
Beynon-Davis, 1995; Remenyi, 1999; Willcocks and
Graeser, 2001). One consistent factor influencing
project outcomes are the various risks associated
with initiating and implementing IT projects (Jiang
and Klein, 2001; Willcocks and Graeser, 2001). In
particular, the OTR Group (1992) found that only
30 per cent of organisations applied risk analysis in
their IT investment and project management
processes. Likewise, Willcocks (1996) found
organisations undertook little formal risk analysis,
except when undertaking financial calculations.
Evidence indicates that risks in IT projects are not
effectively managed and, as a results their lack of
identification and management during a project’s
life-cycle can contribute to their failure (Willcocks
and Griffiths, 1997; Hedelin and Allwood, 2002).
Given the high failure rates associated with IT
projects, it is prudent for organisations to improve
their ability to manage their IT risks so that projects
can be delivered successfully (Gobeli et al., 1998;
Willcocks and Graeser, 2001; Jiang and Klein, 2001;
Hartman and Ashrafi, 2002). In this paper, those IT
project risks considered most important in terms of
their likelihood and consequences and specific risk
treatment strategies that can be used to manage IT
project risks are identified by practising IT project
managers in Australia. The findings presented will
enable IT project managers to better understand the
key risks in their projects and appropriate risk
treatment strategies to manage these risks. While the
research was conducted in an Australian context, it is
envisaged that the research outcome would be widely
 Management of risks in IT projects
David Baccarini, Geoff Salm and Peter E.D. Love
applicable in other locations. Prior to the
presentation of the research, a review of IT project
risk management, in particular the range of risks and
the options for their management, are presented.
Management of risk in IT projects
Every human endeavour involves risk (Wider and
Davis, 1998). Projects are unique undertakings
which involve a degree of uncertainty and are
inherently risky (Chapman, 1998; Conroy and
Soltan, 1998; Mak et al., 1998; PMI, 2000;
Czuchry and Yasin, 2003). Risk in projects can be
defined as the chance of an event occurring that is
likely to have a negative impact on project
objectives and is measured in terms of likelihood
and consequence (Wideman, 1992; Carter et al.,
1993; Chapman, 1998). Risk management is an
essential practice in achieving the successful
Downloaded by VIT University At 19:44 13 February 2019 (PT)
delivery of IT projects (Tuman, 1993; Remenyi,
1999). More specifically, it consists of the
following processes (Standards Australia, 1999):
(1) establish the context;
(2) identify risks;
(3) analyse risks;
(4) evaluate risks;
(5) treat risks;
(6) monitor and review; and
(7) communicate and consult.
The treatment of risk involves the determination of
the most appropriate strategies for dealing with its
occurrence (Standards Australia, 1999).
According to Zhi (1994), there are four main
strategies for responding to project risks:
(1) Avoidance – not undertaking the activity that
gives rise to risk.
(2) Reduction – reduce the probability of a risk
event occurring, and/or the impact of that
event. Risk reduction is the most common of
all risk-handling strategies (Pritchard, 1997).
(3) Transfer – transfer of risk in whole or part to
another party.
(4) Retention – accept risk and therefore the
consequences should it eventuate.
McFarlan (1981) suggested that projects fail due to
lack of attention to individual project risks, aggregate
risk of portfolio of projects and the recognition that
different types of projects require different types of
management. Yet, IT risk management is either not
undertaken at all or is very poorly performed by
many, if not most organisations (Remenyi, 1999). A
reason for this is that focusing on potential problems
may be viewed as being negative. However,
management often wants to instil a positive attitude
towards the implementation of IT, as it is often
viewed as “flagship” for change and subsequent
process improvement within organizations.
287
Industrial Management & Data Systems
Volume 104 · Number 4 · 2004 · 286-295
Risks in IT projects
Identifying the risks associated with the
implementation of IT can be a major challenge for
managers, as there are numerous ways in which it
can be described and categorised. Risks vary in
nature, severity and consequence, so it is
important those that are considered to be high-
level risks are identified, understood and managed.
Of the most common IT risks, 27 have been
identified from the literature. Each is described
below and structured into the following categories
(Standards Australia, 1999):
(1) Commercial and legal relationships:
.
Inadequate third party performance. The
contractor selected is not fit for the
purpose of the project. The contractor is
unable to provide a solution that meets
time, cost, quality and performance
objectives (Krasner, 1998).
. Litigation in protecting intellectual property.
Inadequate protection of software at the
start of the project results in competitors
taking advantage through copying,
resulting in high litigation cost, and loss of
market potential (Krasner, 1998).
.
Friction between clients and contractors.
Personal antagonism or enmity can occur
between clients and software contractors as
a result of misunderstandings,
unanticipated changes in the scope of the
contract, missed or delayed delivery, or
some other item of dispute that polarises
clients and contractors into opposing
camps (Jones, 1993).
(2) Economic circumstances:
.
Changing market conditions. Business return
on investment in IT can be eroded owing
to changing consumer market conditions
or advancements in software engineering
(Jones, 1993; King, 1994).
.
Harmful competitive actions. Competitors
may build software solutions more quickly,
with greater functionality at cheaper cost,
and aggressively deploy the final product
within the same market space (Thomsett,
1989; Jones, 1993).
.
Software no longer needed. Software is
developed that is prematurely terminated
because its value or impact exceeds what
management are prepared to absorb
(Engming and Hsieh, 1994).
(3) Human behaviour:
.
Personnel shortfalls. Inability to complete
work assigned owing to insufficient staff
(Abdel-Hamid, 1989; Abdel-Hamid and
Madnick, 1991; Engming and Hsieh, 1994).
.
Poor quality of staff. Standard of work is
poor owing to lack of ability, training,
motivation and experience of staff
 Management of risks in IT projects
David Baccarini, Geoff Salm and Peter E.D. Love
(Cooper, 1993; Yoon et al., 1994). This
lack of experience can extend to hardware,
operating systems, database management
systems, and other software (Fuerst and
Cheney, 1982; Nelson and Cheney, 1987).
(4) Political circumstances:
.
Corporate culture not supportive. Corporate
culture may be project adverse owing to
other hidden agendas, factions within the
company, organisational culture under
continuous change or threat of change, and
other internal priorities. This results in
weak management support for the project
and consequential failure of not meeting
objectives (Leitheiser and Wetherbe, 1986;
Engming and Hsieh, 1994; Irani and Love,
2001).
.
Lack of executive support. Project is
disrupted from achieving its objectives
owing to management playing politics
Downloaded by VIT University At 19:44 13 February 2019 (PT)
within and between departments or
external agents (Leitheiser and Wetherbe,
1986). Furthermore, users may not
support the project if they perceive that
there is a lack of top-level management
sponsorship (Barki and Hartwick, 1989).
.
Politically-motivated collection of unrelated
requirements. Owing to political motivations
within the organisation a number of
unrelated requirements are grouped in an
all-encompassing project which becomes
difficult to manage and meet objectives
(Krasner, 1998).
(5) Technology and technical issues:
.
Inadequate user documentation. Users are
unable to fully utilise new IT as it was
intended owing to poor user
documentation (Boehm, 1989).
.
Application software not fit for purpose. There
can be a perception among users that the
software provided does not directly help
them with completing day-to-day tasks.
This can lead to low user satisfaction
(Baronas and Louis, 1988).
.
Poor production system performance. The
selected software architecture/platform
does not meet the purpose for which it was
intended, resulting in a system being
released into production which is
excessively slow or has major operational
problems (Jones, 1993; Glass, 1998).
.
Technical limitations of solution reached or
exceeded. A technical limitation is
encountered during software development
resulting in time delays to the project while
a work-around solution is determined. In
extreme cases, a solution may not be
found. The result is either cancellation of
the project or re-starting with a more viable
288
Industrial Management & Data Systems
Volume 104 · Number 4 · 2004 · 286-295
technical solution (Boehm, 1989; Jones,
1993).
.
Incomplete requirements. Insufficient
information has been obtained in the
analysis phase, resulting in construction of
a solution that does not meet project
objectives (Shand, 1993; Engming and
Hsieh, 1994).
.
Inappropriate user interface. The software
user interface selected or developed fails to
meet user requirements (Jones, 1993;
King, 1994).
(6) Management activities and controls:
.
Unreasonable project schedule and budget. The
project is unable to realise its objectives
owing to unrealistic restrictions placed on
the projects budget, schedule, quality or
level of performance (King, 1994; Krasner,
1998). A project failing to meet its
committed deliverables or is significantly
over budget can be terminated (Boehm,
1989; King, 1994; Turner, 1999).
.
Continuous changes to requirements by client.
Stakeholders (includes users) continuously
make changes to software functionality
throughout the project life-cycle (Jones,
1993; King, 1994; Clancy, 1994).
.
Lack of agreed-to user acceptance testing and
signoff criteria. The project close-out can be
delayed owing to an unclear understanding
of what constitutes sign-off and final
solution delivery (Boehm, 1989).
.
Failure to review daily progress. Manager
fails to review the progress of daily
deliverables resulting in project slippage
(Clancy, 1994; Yourdon, 1996).
.
Lack of single point accountability. It is
typical of large software projects to have
many team leaders but no single point of
responsibility for deliverables, resulting in
the project failing to meet its objectives
(Fuerst and Cheney, 1982; Thomsett,
1995).
.
Poor leadership. The project manager and/
or steering committee is not committed to
solving problems and providing direction
to the project team (King, 1994; Clancy,
1994).
.
Developing wrong software functionality.
Design and construction of software may
not meet the purpose for which it is
intended (Boehm, 1989).
.
Lack of formal change management process.
Project progress is hindered owing to ad
hoc changes to system specification without
a formal review of technical and project
impact (Jones, 1993; Davis and Olson,
1984; Cunningham, 1999).
 Management of risks in IT projects
David Baccarini, Geoff Salm and Peter E.D. Love
(7) Individual activities:
.
Gold plating (over specification). The team is
focussed on analysing and generating
excessive levels of detail losing sight of the
project’s objectives (Boehm, 1989; Turner,
1999; Cunningham, 1999).
.
Unrealistic expectations (salesperson over sells
product). Items promised for delivery to
individuals by the vendor may be over sold
and unrealistic (Maish, 1979; Ginzberg,
1981; Thomsett, 1995).
A wide and diverse range of IT project risks have
been identified. However, a ranking of the most
serious risks is needed so that they can be
managed, if they should eventuate. In addition,
types of risk treatment options are needed by IT
project managers to manage risks that could hinder
project performance. There are two processes
within a project (PMI, 2000; Thomsett, 2001):
Downloaded by VIT University At 19:44 13 February 2019 (PT)
(1) Project management processes. These describe,
organise and complete the work of the project.
The project management processes are
applicable to most projects and include the
management of scope, cost, time, quality, risk
communications, human resources, and
procurement.
(2) Product processes. These are the technical
processes that specify and create the project’s
product and vary with the nature of the
project, e.g. construction, information
systems, events, and new product
development. Technical management requires
a detailed understanding of the technical
processes of the product, and involves the
provision of expert assistance to the technical
team and the detailed quality assurance of the
technical deliverables.
The range of risk described previously can affect
either of these processes.
Research methodology
The research sample selected for the study
consisted of IT professionals from the State of
Western Australia, and was derived from a
combination of purposive and snowball sampling.
Purposive sampling allows the researcher to select
suitable respondents who have the knowledge of
the research topic so that it would be of most
benefit to the study exercise (Sarantakos, 1998).
Snowball sampling begins with asking a few
respondents to recommend others who would be
able to add value to the research and are
subsequently interviewed (Sarantakos, 1998).
This allows the best respondents to be selected
based on their knowledge of the topic, their
289
Industrial Management & Data Systems
Volume 104 · Number 4 · 2004 · 286-295
availability and the researcher’s belief in their
suitability for inclusion in the study. This sample
selection was based on the following parameters:
.
Project managers actively involved in software
development projects with a minimum of two
years’ experience.
.
Divergent software projects including client-
based object-oriented applications, client-
server PC solutions, Web development,
mainframe-based applications, and personal
digital assistant technologies.
.
Private and public sector companies and
corporations within the Perth metropolitan
area, ranging in size from four employees to
several hundred and with business experience
extending from two years to more than 77 years.
Data were obtained by means of structured
interviews. The research used a combined research
methodology of quantitative (rating risks) and
qualitative questions (risk treatment strategies).
All but two respondents allowed the interviews to
be taped. All taped interviews were fully
transcribed. The questionnaire was pre-tested on
two project managers, who had over 30 years of
collective experience in IT projects, and minor
amendments made. Following the transcription of
all responses, each qualitative question was
analysed and responses were sorted into themes.
This process is a valid way of drawing conclusions
from the data collected (Miles and Huberman,
1993). The research instrument used in the
interviews contained the following sections:
.
Demographic information. This was
background and experience of respondents.
.
Rating risks. A list of 27 risks, derived from the
literature, was provided to the respondents who
were asked to rate each risk in terms of
likelihood (high/medium/low) and
consequence (high/medium/low). These
responses were converted into numeric values
to allow ranking of risks. The values allocated
were: probability values: high ¼ 3,
medium ¼ 2, low ¼ 1; consequence values:
high ¼ 5; medium ¼ 3; low ¼ 1. The non-
linear values for consequences reflect
organisations’ typical desire to avoid high-
impact risks (PMI, 2000). Research shows that
the severity of the potential consequences of a
risk produces a greater concern than its
probability in evaluating the overall level of risk
(Kahneman and Tversky, 1982). For example,
a low-probability/high-consequence risk is
typically considered as being higher than a
high-probability/low-consequence risk. The
score for each risk was calculated as follows:
((probability*consequence*percentage value
of respondents selecting this combination).
 Management of risks in IT projects
David Baccarini, Geoff Salm and Peter E.D. Love
.
Risk treatment. Each respondent who rated a
risk as medium or high for both likelihood and
consequences was requested to describe
suitable actions to manage the risk.
A sample of 18 IT personnel was selected,
dominated by IT project managers. Each of the IT
project managers was invited to rank each of the
listed risks and offer treatment strategies. Opinions
about risk in IT projects were also obtained.
Results and discussion
The sample had a mean of ten years’ work
experience which implies that they had
considerable knowledge of the IT project
management process. Key project risks and
treatment strategies ranked by respondents are
presented and discussed below.
Downloaded by VIT University At 19:44 13 February 2019 (PT)
Key IT project risks
One of the objectives of this study was to identify IT
project risks considered most important in terms of
their likelihood and consequences. Table I presents
the scores and consequent ranking for the 27 risks
identified in the literature. Here, three dominant
risk ratings emerge of all responses: high
probability/high consequence (23 per cent),
medium probability/high consequence (19 per
cent), and low probability/high consequence (18
per cent). Therefore, 60 per cent of IT risks have
high consequences. This suggests that IT projects
are high-risk ventures and perhaps contributes
towards their high failure rate. It is significant that
“personnel shortfalls” and “unrealistic schedule
and budget” have identified as the primary causes of
risk in the literature (Boehm, 1989). Considering
the findings presented in Table I the project
manager can reasonably expect these particular
risks to exist and have high consequences.
Therefore, the project manager must have effective
project management processes in place:
.
The inability to complete work assigned owing
to insufficient staff should be managed by
human resource management and
procurement management. Today, many
organisations are flat and lean, with many
competencies outsourced, so it is not
unexpected that personnel shortfalls are the
highest ranked risk.
.
The risk of unreasonable schedule and budget
needs to be managed by a combination of time
and cost planning to verify what is a
reasonable baseline; integration management
in terms of achieving the appropriate balance
between time, cost and scope/quality; and
client expectations management to ensure that
the client is made aware of the effect of
290
Industrial Management & Data Systems
Volume 104 · Number 4 · 2004 · 286-295
unreasonable schedule and budget. It is not
unexpected that unrealistic budget and
schedule is ranked as the second highest risk,
as it reflects the perennial tension within
projects to balance the triple constraints.
In Table I, it is worth noting that two other risks
were highly ranked by the literature and this
research: “continuous changes to requirements by
the client” and “poor production system
performance”. The project management
implications for managing these risks are:
.
Continuous changes to requirements by the client
– this requires change control process for
scope and quality management.
.
Poor production system performance – interestingly,
the treatments for this risk are a combination of
both project management and product processes.
For example, developing and implementing
testing can be viewed both as a technical process
and also a quality control process.
The risks ranked third, fourth and fifth in this
survey have not been ranked highly in comparison
to previous studies (e.g. Boehm, 1989):
.
Unrealistic expectations. It is only in more
recent times that meeting client expectations
has been emphasised as a key criterion for
project success (e.g. PMI, 2000).
Consequently, the risk of unrealistic
expectations has grown in importance and
needs to be managed by quality, scope and
communications management.
.
Incomplete requirements. There is an acute
awareness nowadays of the importance of fully
defining clients’ requirements early in the project
to help achieve project success. Therefore, it is
not surprising that incomplete requirements is
seen as an important risk, requiring scope,
quality and communications management.
.
Diminished window of opportunity owing to late
delivery of software. A critical issue with many
projects nowadays is the need to reach the
market before competitors. Consequently,
missing a window of opportunity is a high risk
and requires good time management. This
was not a high-ranking risk by Boehm (1989)
when speed to market was of lesser
importance compared to today’s relatively
turbulent and dynamic markets.
Risk treatment strategies
The respondents were asked to describe what
strategies they would take to manage risks that they
rated as medium or high for both likelihood and
consequences. Table II shows the responses, which
provide a rich and valuable array of risk treatment
strategies (the results record responses supported
by at least four of the 18 respondents, i.e. 22+ per
cent). It shows that for approximately half the risks
 Management of risks in IT projects Industrial Management & Data Systems
David Baccarini, Geoff Salm and Peter E.D. Love Volume 104 · Number 4 · 2004 · 286-295

Table I IT risk rankings

Percentage of respondents Total
IT risks HPHC HPMC HPLC MPHC MPMC MPLC LPHC LPMC LPLC % Score
Personnel shortfalls (insufficient human resources) 67 0 0 17 6 0 6 0 6 100 1,233
Unreasonable project schedule and budget 46 0 0 28 6 6 6 0 0 100 1172
Unrealistic expectations (salesperson over sold
product) 33 17 0 28 0 0 6 0 6 100 1,128
Incomplete requirements 39 17 0 17 6 0 11 11 0 100 1,022
Diminished window of opportunity due to late
delivery of software 39 6 0 17 33 0 0 0 6 100 1,006
Continuous changes to requirements by client 39 11 17 6 6 0 17 6 0 100 922
Poor production system performance 17 6 0 33 6 0 22 0 6 100 893
Poor leadership (project manager and/or steering
committee) 22 0 0 39 0 0 28 11 0 100 893
Inadequate user documentation100 28 33 0 6 17 0 0 0 17 100 889
Lack of agreed-to user acceptance testing and
signoff criteria 23 12 0 23 12 0 18 12 0 100 888
Inadequate third party performance (contractor
not fit for purpose) 17 0 0 33 11 0 17 11 0 100 879
Politically motivated collection of unrelated
requirements 28 6 0 11 22 0 17 17 0 100 833
Lack of executive support 18 0 0 29 6 0 34 6 6 100 793
Lack of single point accountability 33 0 6 0 6 0 39 11 6 100 783
Downloaded by VIT University At 19:44 13 February 2019 (PT)

Corporate culture not supportive 23 12 0 6 18 0 12 18 12 100 737

Technical limitations of solution reached or
exceeded 17 0 0 22 11 0 28 17 6 100 733
Inappropriate user interface 17 0 0 22 28 6 6 22 0 100 733
Litigation in protecting intellectual property 22 0 0 17 11 0 11 22 17 100 706
Application (software) not fit for purpose 6 11 0 28 0 0 39 11 6 100 693
Gold plating (over specification) 11 6 6 28 17 0 6 11 17 100 689
Friction between clients and contractors 11 17 0 11 28 11 6 11 6 100 661
Lack of formal change management process 6 6 0 22 17 0 28 17 6 100 640
Developing wrong software functionality 0 11 0 22 0 0 40 11 6 100 611
Poor quality of staff 11 0 0 11 22 6 33 6 11 100 606
Harmful competitive actions 20 0 0 7 7 0 7 30 20 100 480
Software no longer needed 0 6 0 22 6 6 28 6 28 100 389
Failure to review daily progress 0 17 6 0 22 6 6 11 33 100 393
Distribution as a % of the total 23 7 1 19 12 1 18 11 8 100

there is one strongly favoured treatment, whereas
the remaining risks have two or more treatments
with similar support. This indicates that there is
not one solution for managing any particular risk
and the project manager must be aware of the
possible need to implement two or more
treatments for one risk. Table III categorises, for
the top ten ranked risk, the treatment strategy into
avoidance, reduction, transfer or acceptance and
indicates that risk:
.
reduction is the overwhelmingly favoured
treatment strategy, which supports the literature;
.
acceptance was not proposed as a treatment
strategy, perhaps because it is typically used
for low risks; and
.
transfer was not proposed as a treatment
strategy. This may be because IT project
managers are given direct responsibility to
manage the risk using in-house organisational
resources.
There are two processes within a project; namely,
project management and product (PMI, 2000).
The former describes, organises and completes the
work of the project; while the latter relates to the
291
technical processes that specify and create the
project’s product and vary with the nature of the
project. Table III demonstrates that the majority of
treatment strategies are related to project
management processes rather that product
processes. This supports the observation that most
software problems are of a management,
organisational or behavioural nature, not technical
(Hartman and Ashrafi, 2002). The survey provides
a valuable insight, in that it highlights the
importance of project management as the key
solution to managing many project risks. In
particular, Table III also indicates that some
project management processes are risk treatments
for many high-ranked risks:
.
scope/quality management – e.g. requirements
definition, screen proposals;
.
communication management – e.g. managing
expectations, vendor relationships, liaising
with stakeholders; and
.
human resource management – e.g. plan for
personnel resources, experienced project manager.
Managing the expectations of stakeholders is a
critical risk management strategy which should be
 Management of risks in IT projects Industrial Management & Data Systems
David Baccarini, Geoff Salm and Peter E.D. Love Volume 104 · Number 4 · 2004 · 286-295

Table II IT risk treatment strategies

Risk event Strategy Percent
Inadequate third party performance Screen contractors upfront 83
Monitor contractor performance 39
Retain right to remove unfit contractor 22
Litigation in protecting intellectual property Consultative engagement 83
Contract conditions 72
Friction between clients and contractors Consider personal attributes 40
Monitor contractor performance 22
Manage the relationship 22
Diminished window of opportunity due to late delivery of software Sound project planning and schedule management 40
Manage expectations 33
Obtain management support 22
Harmful competitive actions Develop customer relationship 39
Maintain market entry barrier 39
Software no longer needed Establish sound business requirements 78
Manage key stakeholders 28
Personnel shortfalls Plan for resources 40
Procure external parties 39
Plan contingency options 28
Change project management objectives 28
Poor quality of staff Assess project staff capability 72
Corporate culture not supportive Manage stakeholders 40
Downloaded by VIT University At 19:44 13 February 2019 (PT)

Apply political influence 28

Obtain executive management support 28
Lack of executive support Market the project 33
Engage management early 39
Politically motivated collection of unrelated requirements Clear scope definition 40
Consult with key stakeholders 33
Inadequate user documentation Develop clear requirements definition 39
Build documentation throughout the PLC 33
Assign a document writing specialist 28
Application (software) not fit for purpose Develop clear requirements definition 40
Perform group reviews 33
Obtain progressive signoff of milestones 28
Poor production system performance Conduct comprehensive testing in near production conditions 33
Conduct proof of concept testing 33
Development conducted in near production conditions 22
Technical limitations of solution reached or exceeded Develop strong technical design 72
Incomplete requirements Obtain clear scope specification and signoff 67
Liaise with stakeholders 40
Inappropriate user interface Liaise with users 83
Adopt standards for interface design 33
Unreasonable project schedule and budget Make tradeoffs between cost, time and scope 72
Manage expectations 28
Continuous changes to requirements by the client Enforce formal change management process 78
Ensure key project documentation is signed off 40
Consult/educate user in change management practice 22
Lack of agreed-to user acceptance and signoff criteria Consult/train the user in test design 100
Failure to review daily progress Monitor project daily, if required 33
Create a consultative environment 22
Lack of single point accountability Project manager is held accountable 33
Roles and responsibilities clearly defined 33
Project sponsor/owner is accountable 28
Establish clear communication and escalation hierarchy 22
Poor leadership Appoint an experienced project manager 33
Establish steering committee selection process and operational guidelines 39
Utilise established communication and escalation hierarchy 33
Developing wrong software functionality Conduct group reviews 78
Develop clear requirements definition 39
Obtain signoffs of milestones 33
Lack of formal change management process Implement a formal change management system 78
Educate users on the change management process 22
Gold plating (over specification) Monitor and review development to baseline design 40
Strict adherence to requirements definition 33
Unrealistic expectations Screen proposals 33
Develop clear requirements definition 33
Manage customer expectations 28
Test validity of vendor claims 28

292
 Downloaded by VIT University At 19:44 13 February 2019 (PT)

Table III Top ten risks treatment and project management processes
Rank Risk Risk treatment strategies Percentage Treatment Project management (PMBOK)
1 Personnel shortfalls Plan for resources 40 Reduction Time/human resources
Procure external parties 39 Transfer Procurement
Plan contingency options 28 Reduction Risk
Change PM objectives 28 Reduction Integration/scope
2 Unreasonable project schedule and budget Make tradeoffs between cost, time and scope 72 Retention Integration/scope
Manage expectations 28 Reduction Quality/communication
3 Unrealistic expectations Screen proposals 33 Reduction Scope/quality
Management of risks in IT projects

Clear requirements definition 33 Reduction Scope/quality

Manage customer expectations 28 Reduction Quality/communication
David Baccarini, Geoff Salm and Peter E.D. Love

Test validity of vendor claims 28 Reduction Quality

3 Incomplete requirements Clear scope specification and sign-off 67 Reduction Scope/quality
Liaise with stakeholders 40 Reduction Communication
4 Diminished window of opportunity due to late delivery of software Sound planning and schedule management 40 Reduction Time

293
Manage expectations 33 Reduction Quality/communication
Obtain management support 22 Reduction Human resources
6 Continuous changes to requirements by client Formal change management process 78 Reduction Scope/quality
Ensure key project documentation is signed off 33 Transfer Quality
Consult/educate user in change management practice 22 Reduction Communication
7 Poor production system performance Comprehensive testing in near production conditions 33 Reduction Quality/technical
Conduct proof of concept testing 33 Reduction Quality/technical
Development conducted in near production conditions 22 Reduction Quality/technical
8 Poor leadership Appoint an experienced project manager 33 Reduction Human resources
Committee selection process and operational guidelines 39 Reduction Human resources
Utilise communication and escalation hierarchy 33 Reduction Communication/human resources
Monitor leadership effectiveness 22 Retention Quality/human resources
9 Inadequate user documentation Clear requirements definition 39 Reduction Scope/quality
Build documentation throughout project life-cycle 33 Reduction Quality/technical
Assign a document writing specialist 28 Transfer Human resources
Industrial Management & Data Systems
Volume 104 · Number 4 · 2004 · 286-295

10 Lack of agreed user acceptance testing and sign-off criteria Consult/train the user in test design 40 Reduction Quality/communication
 Management of risks in IT projects
David Baccarini, Geoff Salm and Peter E.D. Love
addressed. Project success in IT projects is
increasingly being defined in terms of not only
achieving time, cost and quality objectives, but also
meeting stakeholders’ expectations; in particular,
the client/user (e.g. Bennatan, 2002). The
intangible and complex nature of IT projects
makes expectations management difficult, but it is
necessary for managing several risks that occur in
IT projects.
Conclusion
A challenge facing IT project managers is to
identify potential risks and adopt appropriate
actions. The literature review identifies a list of 27
risks in IT projects. The two highest ranked risks,
both in the literature and this survey, were
Downloaded by VIT University At 19:44 13 February 2019 (PT)
“personnel shortfalls” and “unrealistic schedule
and budget”. Furthermore, three other risks were
prevalent in this research:
(1) unrealistic expectations;
(2) incomplete requirements; and
(3) diminished window of opportunity owing to
late delivery of software.
This strongly indicates that IT project managers
should be highly sensitive to these risks on their
projects. The overwhelming treatment strategy is
risk reduction using project management
processes. Prevalent project management
processes for high ranked risks are scope/quality
management, stakeholder management and
human resource management. In particular,
managing stakeholders’ expectations will provide
a solution to managing several high-ranking IT
project risks. The research found that most of the
strategies for managing risks entail the application
of project management. So IT project managers
need to be aware that project management is the
key strategy for managing risks, and very few IT
risks have to do with technical issues. The
propensity of IT project managers to become
immersed in technical aspects of their projects
means that the effective management of IT risks
will be impeded. The findings reported can be
used as a checklist of important risks and a rich
and diverse range of treatment strategies that IT
project managers should consider for effective
risk management. Understanding the critical role
of project management as a key and
encompassing strategy for managing IT project
risks is a necessity for project success. In
particular, expectations management is a specific
strategy that would provide efficient and effective
risk management.
294
Industrial Management & Data Systems
Volume 104 · Number 4 · 2004 · 286-295
References
Abdel-Hamid, T.K. (1989), “The dynamics of software project
staffing: a systems dynamics based simulation approach”,
IEEE Transactions in Software Engineering, Vol. 15,
pp. 109-19.
Abdel-Hamid, T.K. and Madnick, S.E. (1991), Software Project
Dynamics: An Integrated Approach, Prentice-Hall,
Englewood Cliffs, NJ.
Barki, H. and Hartwick, J. (1989), “Rethinking the concept of
user involvement”, MIS Quarterly, Vol. 13 No. 1, pp. 43-63.
Baronas, A.M.K. and Louis, M.R. (1988), “Restoring a sense of
control during implementation: how user involvement
leads to system acceptance”, MIS Quarterly, Vol. 12 No. 1,
pp. 111-23.
Bennatan, E.M. (2002), On Time Within Budget: Software Project
Management Practices and Techniques, Wiley, New York,
NY.
Beynon-Davis, P. (1995), “Information systems failure: the case
of the London Ambulance Service’s computer aided
despatch project”, European Journal of Information
Systems, Vol. 4, pp. 171-84.
Boehm, B.W. (1989), Software Risk Management, IEEE,
Computer Society Press, Washington, DC.
Carter, B., Hancock, T., Morin, J. and Robins, N. (1993),
Introducing RISKMAN: The European Project Risk
Management Methodology, NCC Blackwell, Oxford.
Chapman, R.J. (1998), “Effectiveness of working group risk
identification and assessment techniques”, International
Journal of Project Management, Vol. 16 No. 6, pp. 333-43.
Clancy, T. (1995), “Chaos – IT development projects”,
available at: www.standishgroup.com/msie.htm
(accessed 24 August 2000).
Conroy, G. and Soltan, H. (1998), “ConSERV, a project specific
risk management concept”, International Journal of
Project Management, Vol. 16 No. 6, pp. 353-66.
Cooper, K.G. (1993), “The rework cycle: benchmarking for the
project manager”, Project Management Journal, Vol. 24
No. 1, pp. 17-22.
Cunningham, M. (1999), “It’s all about the business”, Inform,
Vol. 13 No. 3, p. 83.
Czuchry, A.J. and Yasin, M.M. (2003), “Managing the project
management process”, Industrial Management & Data
Systems, Vol. 103 No. 1, pp. 39-46.
Davis, G.B. and Olson, M.H. (1984), Management Information
Systems, Conceptual Foundations, Structure, and
Development, 2nd ed., McGraw-Hill, New York, NY.
Engming, L. and Hsieh, C.T. (1994), “Seven deadly risk factors of
software development projects”, Journal of Systems
Management, Vol. 36 No. 6, pp. 38-42.
Fuerst, W.L. and Cheney, P.H. (1982), “Factors affecting the
perceived utilization of computer-based decision support
systems in the oil industry”, Decision Sciences, Vol. 13
No. 3, pp. 443-69.
Ginzberg, M.J. (1981), “Early diagnosis of MIS implementation
failure: promising results and unanswered questions”,
Management Science, Vol. 27 No. 3, pp. 349-78.
Glass, R.L. (1998), Software Runaways, Prentice-Hall and
Yourdon Press, Englewood Cliffs, NJ.
Gobeli, D.H., Koenig, H.F. and Bechinger, I. (1998), “Managing
conflict in software development teams: a multilevel
analysis”, Journal of Product Innovation Management,
Vol. 14 No. 4, pp. 323-34.
Gunton, T. (1993), A Dictionary of Information Technology and
Computer Science, 2nd ed., TJ Press, Cornwall.
Hartman, F. and Ashrafi, R.A. (2002), “Project management in
the information systems and information technologies
 Management of risks in IT projects
David Baccarini, Geoff Salm and Peter E.D. Love
industries”, Project Management Journal, Vol. 33 No. 3,
pp. 4-14.
Hedelin, L. and Allwood, C.M. (2002), “IT and strategic decision-
making”, Industrial Management & Data Systems, Vol. 102
No. 3, pp. 125-39.
Hoepleman, J.P., Mayer, R. and Wagner, J. (1997), Elsevier’s
Dictionary of Information Technology, Elsevier Science,
Amsterdam.
Irani, Z. and Love, P.E.D. (2001), “The propagation of technology
management taxonomies for evaluating information
systems”, Journal of Management Information Systems,
Vol. 17 No. 3, pp. 161-77.
Jiang, J.J. and Klein, G. (2001), “Software project risks and
development focus”, Project Management Journal, Vol. 32
No. 1, pp. 3-9.
Jones, C. (1993), Assessment and Control of Software Risks,
Prentice-Hall, Englewood Cliffs, NJ.
Kahneman, D. and Tversky, A. (1982), “The psychology of
preferences”, Scientific American, January, pp. 160-73.
Keen, P.G.W. (1994), Every Manager’s Guide to Information
Technology: A Glossary of Key Terms and Concepts for
Today’s Business Leader, 2nd ed., Harvard Business School
Press, Boston, MA.
Downloaded by VIT University At 19:44 13 February 2019 (PT)
King, J. (1994), “Sketchy plans, politics stall software
development”, Computer World, Vol. 29 No. 24, p. 81.
Krasner, H. (1998), “Looking over the legal edge of unsuccessful
software projects”, Cutter IT Journal, Vol. 11 No. 3,
pp. 11-22.
Leitheiser, R.L. and Wetherbe, J.C. (1986), “Service support
levels: an organized approach to end-user computing”,
MIS Quarterly, Vol. 10 No. 3, pp. 337-9.
McFarlan, F.W. (1981), “Portfolio approach to information
systems”, Harvard Business Review, Vol. 142, September-
October, pp. 142-50.
Maish, A.M. (1979), “A user’s behaviour toward his MIS”,
MIS Quarterly, Vol. 3 No. 1, pp. 39-42.
Mak, S., Wong, J. and Picken, D. (1998), “The effect on
contingency allowances of using risk analysis in capital
cost estimating: a Hong Kong case study”, Construction
Management and Economics, Vol. 16 No. 6, pp. 615-9.
Miles, M.B. and Huberman, A.M. (1993), Qualitative Data
Analysis: An Expanded Source Book, Sage, Beverly Hills,
CA.
Nelson, R. and Cheney, P. (1987), “Training end-users: an
exploratory study”, MIS Quarterly, Vol. 11 No. 3,
pp. 437-49.
Project Management Institute (PMI) (2000), Project
Management Body of Knowledge (PMBOK) – 2000
Exposure Draft, PMI, Pennsylvania, PA.
Pritchard, C.L. (1997), Risk Management – Concepts and
Guidance, ESI International, Arlington, VA.
Remenyi, D. (1999), Stop IT Project Failures through Risk
Management, Computer Weekly Series, Butterworth
Heinemann, Oxford.
Sarantakos, S. (1998), Social Research, 2nd ed., Macmillan,
Melbourne.
Sauer, C. (1993), Why Information Systems Fail: A Case Study
Approach, Alfred Waller, Henley-on-Thames.
Shand, R.M. (1993), “User manuals as project management
tools: part 1 – theoretical background”, IEEE Transactions
on Professional Communication, Vol. 37 No. 2, pp. 74-80.
295
Industrial Management & Data Systems
Volume 104 · Number 4 · 2004 · 286-295
Standards Australia (1999), Risk Management, AS/NZS
3360:1999, Standards Australia, Strathfield.
Thomsett, R. (1989), Third Wave Project Management – A
Handbook for Managing Complex Information Systems for
the 1990s, Yourdon Press, Englewood Cliffs, NJ.
Thomsett, R. (1995), Project Pathology: Causes, Patterns and
Symptoms of Project Failure – Training Notes Project Risk
Management, Thomsett Company, London.
Thomsett, R. (2001), “Extreme project management”, Executive
Report Abstracts, Vol. 2 No. 2.
Tuman, J. (1993), “Project management decision-making and
risk management in a changing corporate environment”,
Project Management Institute 24th Annual Seminar/
Symposium, Vancouver, 17-19 October, pp. 733-9.
Turner, R.J. (1999), The Handbook of Project Based Management,
2nd ed., McGraw-Hill, Cambridge.
Wang, S. (2001), “Designing information systems for
e-commerce”, Industrial Management and Data Systems,
Vol. 101 No. 6, pp. 304-15.
Wideman, R.M. (1992), Project and Program Risk Management –
A Guide to Managing Risks and Opportunities, Project
Management Institute, Pennsylvania, PA.
Wider, C. and Davis, B. (1998), “False starts – strong finishes”,
Information Week, Vol. 7 No. 11, pp. 41-53.
Willcocks, L. (1996), Investing in Information Systems:
Evaluation and Management, Thomson Business Press/
Chapman & Hall, London.
Willcocks, L. and Griffiths, C. (1997), “Management and risk in
major information technology projects”, in Willcocks, L.,
Feeny, D. and Iseli, G. (Eds), Managing IT as a Strategic
Resource, McGraw-Hill, Maidenhead.
Willcocks, L. and Graeser, J. (2001), Delivering IT and E-business
Value, Computer Weekly Series, Butterworth and
Heinemann, Oxford.
Yang, Y.H. (2001), “Software quality management and ISO 9000
implementation”, Industrial Management & Data
Systems, Vol. 101 No. 7, pp. 329-38.
Yoon, Y., Guimaraes, T. and O-Neal, Q. (1994), “Exploring the
factors associated with expert systems success”, MIS
Quarterly, Vol. 19 No. 1, pp. 83-106.
Yourdon, E. (1996), “Tools and processes for death march
projects”, Cutter IT Journal – Application Development
Strategies, Vol. 8 No. 12, pp. 27-35.
Zhi, H. (1994), “Risk management for overseas construction
projects”, International Journal of Project Management,
Vol. 13 No. 3, pp. 231-7.
Further reading
Bailey, R. (1996), “Approving system projects. Eight questions an
executive should ask”, PM Network, Vol. 10 No. 5,
pp. 21-4.
Gibbs, W. (1994), “Software’s chronic crisis”, Scientific
American, Vol. 271 No. 3, pp. 86-95.
Ward, J.A. (1994), “Productivity through project management:
controlling the project variables”, Information Systems
Management, Vol. 11 No. 1, pp. 16-21.
 This article has been cited by:

1. Darryl Carlton, Konrad Peszynski. Situational Incompetence: The Failure of Governance in the Management of Large Scale IT
Projects 224-244. [Crossref]
2. Juan Andrés González Correa, Sandra Liliana Sánchez Castañeda, Deisy Aydee Velandia Quintero, Germán Eduardo Giraldo.
2018. Identification and Analysis of Project Management Success Factors in Information Technology SMEs. International Journal
of Information Technology Project Management 9:4, 73-90. [Crossref]
3. GangulyKunal, Kunal Ganguly, RaiSiddharth Shankar, Siddharth Shankar Rai. 2018. Evaluating the key performance indicators
for supply chain information system implementation using IPA model. Benchmarking: An International Journal 25:6, 1844-1863.
[Abstract] [Full Text] [PDF]
4. RajagopalanJayaraman, Jayaraman Rajagopalan, SrivastavaPraveen Kumar, Praveen Kumar Srivastava. 2018. Introduction of a new
metric “Project Health Index” (PHI) to successfully manage IT projects. Journal of Organizational Change Management 31:2,
385-409. [Abstract] [Full Text] [PDF]
5. ShishodiaAnjali, Anjali Shishodia, DixitVijaya, Vijaya Dixit, VermaPriyanka, Priyanka Verma. 2018. Project risk analysis based
on project characteristics. Benchmarking: An International Journal 25:3, 893-918. [Abstract] [Full Text] [PDF]
6. Yinan Guo, Jianjiao Ji, Junhua Ji, Dunwei Gong, Jian Cheng, Xiaoning Shen. 2018. Firework-based software project scheduling
method considering the learning and forgetting effect. Soft Computing 37. . [Crossref]
7. Kunal Ganguly, R. K. Padhy. 2018. Analyzing the Risks in Supply Chain Information System Implementations. Information
Downloaded by VIT University At 19:44 13 February 2019 (PT)

Resources Management Journal 31:2, 1-23. [Crossref]

8. Franciane Freitas Silveira, Rosária de F. S. Macri Russo, Irapuan Glória Júnior, Roberto Sbragia. 2018. Systematic Review of Risks
in Domestic and Global IT Projects. Journal of Global Information Management 26:1, 20-40. [Crossref]
9. NyameboameJoseph, Joseph Nyameboame, HaddudAbubaker, Abubaker Haddud. 2017. Exploring the impact of outsourcing on
organizational performance. Journal of Global Operations and Strategic Sourcing 10:3, 362-387. [Abstract] [Full Text] [PDF]
10. Sevilay Demirkesen, Beliz Ozorhon. 2017. Measuring Project Management Performance: Case of Construction Industry.
Engineering Management Journal 29:4, 258-277. [Crossref]
11. Diane Aparecida dos Reis Silva, Diego Honorato Clemente, José Daniel Rodrigues Terra, Karyn Martinelli Lopes, Marly Monteiro
de Carvalho, André Leme Fleury, Eduardo de Senzi Zancul, Roberto Marx. 2017. Aspectos comportamentais na gestão de
projetos: uma análise bibliométrica (1988-2014). Gestão & Produção 24:1, 178-200. [Crossref]
12. Daranee Pimchangthong, Veera Boonjing. 2017. Effects of Risk Management Practice on the Success of IT Project. Procedia
Engineering 182, 579-586. [Crossref]
13. Hamed Taherdoost, Abolfazl Keshavarzsaleh, Chen Wang. 2016. A retrospective critic Re-Debate on Stakeholders’ resistance
checklist in software project management within multi-cultural, multi-ethnical and cosmopolitan society context: The Malaysian
experience. Cogent Business & Management 3:1. . [Crossref]
14. Sandra Miranda Neves, Carlos Eduardo Sanches da Silva. 2016. Gestão de riscos aplicada a projetos de desenvolvimento de
software em empresas de base tecnológica incubadas: revisão, classificação e análise da literatura. Gestão & Produção 23:4, 798-814.
[Crossref]
15. James L. Vesper, Ümit Kartoğlu, Jan Herrington, Thomas C. Reeves. 2016. Incorporating risk assessment into the formative
evaluation of an authentic e-learning program. British Journal of Educational Technology 47:6, 1113-1124. [Crossref]
16. Ofira Shmueli, Nava Pliskin, Lior Fink. 2016. Can the outside-view approach improve planning decisions in software development
projects?. Information Systems Journal 26:4, 395-418. [Crossref]
17. StandingOliver, Oliver Standing, StandingSusan, Susan Standing, KordtEric, Eric Kordt. 2016. Explaining attribution in
information technology projects. Journal of Systems and Information Technology 18:2, 216-227. [Abstract] [Full Text] [PDF]
18. S. L. R. Vrhovec. Responding to stakeholders' resistance to change in software projects — A literature review 1157-1161.
[Crossref]
19. Blessing Javani, Pantaleo Mutajwaa Daniel Rwelamila. 2016. Risk management in IT projects – a case of the South African public
sector. International Journal of Managing Projects in Business 9:2, 389-413. [Abstract] [Full Text] [PDF]
20. Malgorzata Plaza. 2016. Balancing the costs of human resources on an ERP project. Omega 59, 171-183. [Crossref]
21. Ewa Ziemba, Iwona Kolasa. Risk Factors Relationships for Information Systems Projects – Insight from Polish Public
Organizations 55-76. [Crossref]
 22. Vincent Van Peteghem, Mario Vanhoucke. 2015. Influence of learning in resource-constrained project scheduling. Computers &
Industrial Engineering 87, 569-579. [Crossref]
23. Simon L.R. Vrhovec, Tomaž Hovelja, Damjan Vavpotič, Marjan Krisper. 2015. Diagnosing organizational risks in software
projects: Stakeholder resistance. International Journal of Project Management 33:6, 1262-1273. [Crossref]
24. Arthur Ahimbisibwe, Robert Y Cavana, Urs Daellenbach. 2015. A contingency fit model of critical success factors for software
development projects. Journal of Enterprise Information Management 28:1, 7-33. [Abstract] [Full Text] [PDF]
25. Ofira Shmueli, Nava Pliskin, Lior Fink. 2015. Explaining over-requirement in software development projects: An experimental
investigation of behavioral effects. International Journal of Project Management 33:2, 380-394. [Crossref]
26. Brian Dempsey, Joe McDonagh. Integrating Process Inquiry and the Case Method in the Study of Information Systems Failure
475-493. [Crossref]
27. David Brookfield, Denis Fischbacher-Smith, Faizul Mohd-Rahim, Halim Boussabaine. 2014. Conceptualising and responding
to risk in IT projects. Risk Management 16:3, 195-230. [Crossref]
28. Abdulaziz I. Almajed, Pam Mayhew. An empirical investigation of IT project success in developing countries 984-990. [Crossref]
29. Sandra Miranda Neves, Carlos Eduardo Sanches da Silva, Valério Antonio Pamplona Salomon, Aneirson Francisco da Silva, Bárbara
Elizabeth Pereira Sotomonte. 2014. Risk management in software projects through Knowledge Management techniques: Cases
in Brazilian Incubated Technology-Based Firms. International Journal of Project Management 32:1, 125-138. [Crossref]
30. Basit Shahzad, Abass Md Said. 2014. Identification and Quantitative Analysis of Project Success Factors for Large Scale Projects.
International Journal of Knowledge Society Research 5:1, 83-95. [Crossref]
Downloaded by VIT University At 19:44 13 February 2019 (PT)

31. Morteza Ghobakhloo, Sai Hong Tang. 2013. The role of owner/manager in adoption of electronic commerce in small businesses.
Journal of Small Business and Enterprise Development 20:4, 754-787. [Abstract] [Full Text] [PDF]
32. Paul L. Bannerman. Barriers to Project Performance 4324-4333. [Crossref]
33. J.M. Verner, L.M. Abdullah. 2012. Exploratory case study research: Outsourced project failure. Information and Software
Technology 54:8, 866-886. [Crossref]
34. Louay Karadsheh, Samer Alhawari, Amine Nehari Talet. 2012. The Support of Knowledge Process to Enhance Risk Analysis in
Jordanian Telecommunication Companies. Journal of Information & Knowledge Management 11:02, 1250013. [Crossref]
35. Davide Aloini, Riccardo Dulmin, Valeria Mininno. 2012. Risk assessment in ERP projects. Information Systems 37:3, 183-199.
[Crossref]
36. Petronnell Sehlola, Tiko Iyamu. 2012. Assessment of Risk on Information Technology Projects Through Moments of
Translation. International Journal of Actor-Network Theory and Technological Innovation 4:2, 32-43. [Crossref]
37. Veronica S. Moertini. 2012. Managing Risks at the Project Initiation Stage of Large IS Development for HEI: A Case Study in
Indonesia. The Electronic Journal of Information Systems in Developing Countries 51:1, 1-23. [Crossref]
38. Samer Alhawari, Louay Karadsheh, Amine Nehari Talet, Ebrahim Mansour. 2012. Knowledge-Based Risk Management
framework for Information Technology project. International Journal of Information Management 32:1, 50-65. [Crossref]
39. Arpita Sharma, Aayushi Gupta. 2012. Impact of organisational climate and demographics on project specific risks in context to
Indian software industry. International Journal of Project Management 30:2, 176-187. [Crossref]
40. Petronnell Sehlola, Tiko Iyamu. 2012. Assessment of Risk on Information Technology Projects Through Moments of
Translation. International Journal of Actor-Network Theory and Technological Innovation 4:3, 1-12. [Crossref]
41. Antonio Juarez Alencar, Erica Castilho Grão, Eber Assis Schmitz, Alexandre Luis Correa, Otavio H Figueiredo. 2012. Evaluating
the Efficiency in which Risk is Managed in a Portfolio of IT Projects: A Data Envelopment Analysis Approach. Journal of
Software 7:1. . [Crossref]
42. Veronica S. Moertini, Tety Yuliaty, Wisnu Rumono, Buddy S. Tjhia. 2012. The Academic MIS Model Used in Higher Education
to Resolve Typical Problems in Indonesia. International Journal of Information Systems in the Service Sector 4:1, 67-82. [Crossref]
43. Hussam Eldin I. Agha. Risk Management and Business Processes Reengineering, Success Drivers for ERP Projects 146-184.
[Crossref]
44. Morteza Ghobakhloo, Tang S.H.. 2011. Barriers to Electronic Commerce Adoption Among Small Businesses in Iran. Journal
of Electronic Commerce in Organizations 9:4, 48-89. [Crossref]
45. Jacques Sauve, Magno Queiroz, Antao Moura, Claudio Bartolini, Marianne Hickey. 2011. Prioritizing Information Technology
Service Investments under Uncertainty. IEEE Transactions on Network and Service Management 8:3, 259-273. [Crossref]
46. Kaizer Boikanyo Ratsiepe, Rashad Yazdanifard. Poor Risk Management as One of the Major Reasons Causing Failure of Project
Management 1-5. [Crossref]
 47. R.D. Choudhari, D.K. Banwet, M.P. Gupta. 2011. Assessment of risk in e-governance projects: an application of product moment
correlation and cluster analysis techniques. Electronic Government, an International Journal 8:1, 85. [Crossref]
48. Karel de Bakker, Albert Boonstra, Hans Wortmann. 2010. Does risk management contribute to IT project success? A meta-
analysis of empirical evidence. International Journal of Project Management 28:5, 493-503. [Crossref]
49. Vishanth Weerakkody, Zahir Irani. 2010. A value and risk analysis of offshore outsourcing business models: an exploratory study.
International Journal of Production Research 48:2, 613-634. [Crossref]
50. Malgorzata Plaza, Ojelanki K. Ngwenyama, Katrin Rohlf. 2010. A comparative analysis of learning curves: Implications for new
technology implementation management. European Journal of Operational Research 200:2, 518-528. [Crossref]
51. Magno Queiroz, Antao Moura, Jacques Sauve, Claudio Bartolini, Marianne Hickey. A framework to support investment decisions
using multi-criteria and under uncertainty in IT service portfolio management 103-110. [Crossref]
52. Stacie Petter, Adriane B. Randolph. 2009. Developing Soft Skills to Manage User Expectations in IT Projects: Knowledge Reuse
among IT Project Managers. Project Management Journal 40:4, 45-59. [Crossref]
53. David C. Chou, Amy Y. Chou. 2009. Information systems outsourcing life cycle and risks analysis. Computer Standards &
Interfaces 31:5, 1036-1043. [Crossref]
54. Theodosios Tsiakis, Panagiotis Katsaros. Hands on Dependability Economics 117-121. [Crossref]
55. Mira Kajko-Mattsson, Jan Lundholm, Jonas Norrby. Insight into Risk Management in Five Software Organizations 321-326.
[Crossref]
56. Stacie Petter. 2008. Managing user expectations on software projects: Lessons from the trenches. International Journal of Project
Downloaded by VIT University At 19:44 13 February 2019 (PT)

Management 26:7, 700-712. [Crossref]

57. Jinmei Huai. Mitigating Outsourcing Risk through Relational Contract 1-4. [Crossref]
58. Weiyong Zhang, Xiaobo Xu. 2008. Six Sigma and Information Systems Project Management: A Revised Theoretical Model.
Project Management Journal 39:3, 59-74. [Crossref]
59. Malgorzata Plaza, Katrin Rohlf. 2008. Learning and performance in ERP implementation projects: A learning-curve model for
analyzing and managing consulting costs. International Journal of Production Economics 115:1, 72-85. [Crossref]
60. Malgorzata Plaza. 2008. Team performance and information system implementation. Information Systems Frontiers 10:3, 347-359.
[Crossref]
61. Antonio Juarez Alencar, Leoncio Teixeira Cruz, Eber Assis Schmitz, Armando Leite Ferreira. Using a novel approach to cluster
analysis to gain new valuable insights into software-project risk management 51-60. [Crossref]
62. Rodney A. Stewart. 2008. A framework for the life cycle management of information technology projects: ProjectIT. International
Journal of Project Management 26:2, 203-212. [Crossref]
63. Zheng Qin, Qingchen Shang. Risk Management in IT Project's Establishment 278-278. [Crossref]
64. Davide Aloini, Riccardo Dulmin, Valeria Mininno. 2007. Risk management in ERP project introduction: Review of the literature.
Information & Management 44:6, 547-567. [Crossref]
65. Vasja Vehovar, Dušan Lesjak. 2007. Characteristics and impacts of ICT investments: perceptions among managers. Industrial
Management & Data Systems 107:4, 537-550. [Abstract] [Full Text] [PDF]
66. Wai Peng Wong, Kuan Yew Wong. 2007. Supply chain performance measurement system using DEA modeling. Industrial
Management & Data Systems 107:3, 361-381. [Abstract] [Full Text] [PDF]
67. Prasanta Kumar Dey, Jason Kinch, Stephen O. Ogunlana. 2007. Managing risk in software development projects: a case study.
Industrial Management & Data Systems 107:2, 284-303. [Abstract] [Full Text] [PDF]
68. Gunter Seidel. 2007. Management großer IT-Programme. HMD Praxis der Wirtschaftsinformatik 44:1, 103-111. [Crossref]
69. Hazel Taylor. 2006. Risk Management and Problem Resolution Strategies for it Projects: Prescription and Practice. Project
Management Journal 37:5, 49-63. [Crossref]
70. Craig Standing, Andrew Guilfoyle, Chad Lin, Peter E.D. Love. 2006. The attribution of success and failure in IT projects.
Industrial Management & Data Systems 106:8, 1148-1165. [Abstract] [Full Text] [PDF]
71. J.-L. Hou, S.-T. Yang. 2006. Technology-mining model concerning operation characteristics of technology and service providers.
International Journal of Production Research 44:16, 3345-3365. [Crossref]
72. Eugenia Y. Huang, Shu‐Chiung Lin. 2006. How R&D management practice affects innovation performance. Industrial
Management & Data Systems 106:7, 966-996. [Abstract] [Full Text] [PDF]
 73. Jamshed J. Mistry. 2006. Differential impacts of information technology on cost and revenue driver relationships in banking.
Industrial Management & Data Systems 106:3, 327-344. [Abstract] [Full Text] [PDF]
74. John Seydel. 2006. Data envelopment analysis for decision support. Industrial Management & Data Systems 106:1, 81-95.
[Abstract] [Full Text] [PDF]
75. Peter E.D. Love, Zahir Irani, Craig Standing, Chad Lin, Janice M. Burn. 2005. The enigma of evaluation: benefits, costs and
risks of IT in Australian small–medium-sized enterprises. Information & Management 42:7, 947-964. [Crossref]
76. Sangkyun Kim, Choon Seong Leem. 2005. Enterprise security architecture in business convergence environments. Industrial
Management & Data Systems 105:7, 919-936. [Abstract] [Full Text] [PDF]
77. Mohammed H.A. Tafti. 2005. Risks factors associated with offshore IT outsourcing. Industrial Management & Data Systems
105:5, 549-560. [Abstract] [Full Text] [PDF]
78. Dušan Lesjak, Vasja Vehovar. 2005. Factors affecting evaluation of e‐business projects. Industrial Management & Data Systems
105:4, 409-428. [Abstract] [Full Text] [PDF]
79. Hazel Taylor. Vendor vs. Client Risks in Outsourced IT Projects 322-345. [Crossref]
80. Morteza Ghobakhloo, Tang S.H.. Barriers to Electronic Commerce Adoption Among Small Businesses in Iran 252-295.
[Crossref]
81. Tiko Iyamu, Petronnell Sehlola. Information and Communication Technology Projects and the Associated Risks 100-114.
[Crossref]
Downloaded by VIT University At 19:44 13 February 2019 (PT)