management of risks in information systems

Management ofrisks in informationtechnology projects

David Baccarini

Geoff Salm and

Peter E.D. Love

The authors

David Baccarini is at the Faculty of the Built Environment, Artand 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 InformationSystems, Edith Cowan University, Joondulap, Australia.

Keywords

Risk management, Project management, Information services

Abstract

Information technology (IT) projects are renowned for their highfailure rate. Risk management is an essential process for thesuccessful delivery of IT projects. In-depth interviews with ITprofessionals from leading firms in Western Australia wereundertaken to determine how IT risks were managed in theirprojects. The respondents ranked 27 IT risks in terms of likelihoodand consequences to identify the most important risks. The topfive risks, in order, were: personnel shortfalls; unreasonableproject schedule and budget; unrealistic expectations;incomplete requirements; and diminished window ofopportunity due to late delivery of software. The respondentsoverwhelmingly applied the treatment strategy of risk reductionto manage these risks. Furthermore, these strategies wereprimarily project management processes, rather than technicalprocesses. This demonstrates that project management is a riskmanagement strategy. Scope, quality management, and humanresource management were solutions applied to several risks. Inparticular, managing stakeholders’ expectations is a specific risktreatment that helps to manage several key IT risks.

Electronic access

The Emerald Research Register for this journal isavailable atwww.emeraldinsight.com/researchregister

The current issue and full text archive of this journal isavailable atwww.emeraldinsight.com/0263-5577.htm

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 outcomewould be widely

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

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

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.

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 andHsieh, 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


Volume 104 · Number 4 · 2004 · 286-295

287

(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

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

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).




Volume 104 · Number 4 · 2004 · 286-295

288

(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):

(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

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 tomore 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).




Volume 104 · Number 4 · 2004 · 286-295

289

. 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.

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

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 projectmanagement 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




Volume 104 · Number 4 · 2004 · 286-295

290

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

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

Table I IT risk rankings

Percentage of respondents TotalIT 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,233Unreasonable project schedule and budget 46 0 0 28 6 6 6 0 0 100 1172Unrealistic expectations (salesperson over soldproduct) 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,022Diminished window of opportunity due to latedelivery 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 922Poor production system performance 17 6 0 33 6 0 22 0 6 100 893Poor leadership (project manager and/or steeringcommittee) 22 0 0 39 0 0 28 11 0 100 893

Inadequate user documentation100 28 33 0 6 17 0 0 0 17 100 889Lack of agreed-to user acceptance testing andsignoff criteria 23 12 0 23 12 0 18 12 0 100 888

Inadequate third party performance (contractornot fit for purpose) 17 0 0 33 11 0 17 11 0 100 879

Politically motivated collection of unrelatedrequirements 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 793Lack of single point accountability 33 0 6 0 6 0 39 11 6 100 783Corporate culture not supportive 23 12 0 6 18 0 12 18 12 100 737Technical limitations of solution reached orexceeded 17 0 0 22 11 0 28 17 6 100 733

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




Volume 104 · Number 4 · 2004 · 286-295

291

Table II IT risk treatment strategies

Risk event Strategy Percent

Inadequate third party performance Screen contractors upfrontMonitor contractor performanceRetain right to remove unfit contractor

833922

Litigation in protecting intellectual property Consultative engagementContract conditions

8372

Friction between clients and contractors Consider personal attributesMonitor contractor performanceManage the relationship

402222

Diminished window of opportunity due to late delivery of software Sound project planning and schedule managementManage expectationsObtain management support

403322

Harmful competitive actions Develop customer relationshipMaintain market entry barrier

3939

Software no longer needed Establish sound business requirementsManage key stakeholders

7828

Personnel shortfalls Plan for resourcesProcure external partiesPlan contingency optionsChange project management objectives

40392828

Poor quality of staff Assess project staff capability 72Corporate culture not supportive Manage stakeholders

Apply political influenceObtain executive management support

402828

Lack of executive support Market the projectEngage management early

3339

Politically motivated collection of unrelated requirements Clear scope definitionConsult with key stakeholders

4033

Inadequate user documentation Develop clear requirements definitionBuild documentation throughout the PLCAssign a document writing specialist

393328

Application (software) not fit for purpose Develop clear requirements definitionPerform group reviewsObtain progressive signoff of milestones

403328

Poor production system performance Conduct comprehensive testing in near production conditionsConduct proof of concept testingDevelopment conducted in near production conditions

333322

Technical limitations of solution reached or exceeded Develop strong technical design 72Incomplete requirements Obtain clear scope specification and signoff

Liaise with stakeholders6740

Inappropriate user interface Liaise with usersAdopt standards for interface design

8333

Unreasonable project schedule and budget Make tradeoffs between cost, time and scopeManage expectations

7228

Continuous changes to requirements by the client Enforce formal change management processEnsure key project documentation is signed offConsult/educate user in change management practice

784022

Lack of agreed-to user acceptance and signoff criteria Consult/train the user in test design 100Failure to review daily progress Monitor project daily, if required

Create a consultative environment3322

Lack of single point accountability Project manager is held accountableRoles and responsibilities clearly definedProject sponsor/owner is accountableEstablish clear communication and escalation hierarchy

33332822

Poor leadership Appoint an experienced project managerEstablish steering committee selection process and operational guidelinesUtilise established communication and escalation hierarchy

333933

Developing wrong software functionality Conduct group reviewsDevelop clear requirements definitionObtain signoffs of milestones

783933

Lack of formal change management process Implement a formal change management systemEducate users on the change management process

7822

Gold plating (over specification) Monitor and review development to baseline designStrict adherence to requirements definition

4033

Unrealistic expectations Screen proposalsDevelop clear requirements definitionManage customer expectationsTest validity of vendor claims

33332828




Volume 104 · Number 4 · 2004 · 286-295

292

Table

IIIToptenrisks

treatm

entandprojectmanagem

entprocesses

Ran

kRisk

Risktrea

tmen

tstrategies

Percen

tage

Trea

tmen

tProject

man

agem

ent(PMBOK)

1Personnelshortfalls

Plan

forresources

Procureexternalparties

Plan

contingencyoptions

ChangePM

objectives

40 39 28 28

Reduction

Transfer

Reduction

Reduction

Time/human

resources

Procurem

ent

Risk

Integration/scope

2Unreasonableprojectscheduleandbudget

Maketradeoffsbetweencost,tim

eandscope

Manageexpectations

72 28

Retention

Reduction

Integration/scope

Quality/communication

3Unrealistic

expectations

Screen

proposals

Clear

requirementsdefinition

Managecustom

erexpectations

Testvalidity

ofvendor

claims

33 33 28 28

Reduction

Reduction

Reduction

Reduction

Scope/quality

Scope/quality


Quality

3Incompleterequirements

Clear

scopespecificationandsign-off

Liaise

with

stakeholders

67 40

Reduction

Reduction

Scope/quality

Com

munication

4Diminishedwindowof

opportunity

dueto

late

deliveryof

software

Soundplanning

andschedulemanagem

ent

Manageexpectations

Obtainmanagem

entsupport

40 33 22

Reduction

Reduction

Reduction

Time


Hum

anresources

6Continuous

changesto

requirementsby

client

Form

alchange

managem

entprocess

Ensure

keyprojectdocumentationissigned

off

Consult/educateuser

inchange

managem

entpractice

78 33 22

Reduction

Transfer

Reduction

Scope/quality

Quality

Com

munication

7Poor

productionsystem

performance

Com

prehensive

testinginnear

productionconditions

Conductproofof

concepttesting

Developmentconductedinnear

productionconditions

33 33 22

Reduction

Reduction

Reduction

Quality/technical

Quality/technical

Quality/technical

8Poor

leadership

Appoint

anexperienced

projectmanager

Com

mittee

selectionprocessandoperationalguidelines

Utilisecommunicationandescalationhierarchy

Monitorleadership

effectiveness

33 39 33 22

Reduction

Reduction

Reduction

Retention

Hum

anresources

Hum

anresources

Com

munication/human

resources

Quality/human

resources

9Inadequate

user

documentation

Clear

requirementsdefinition

Builddocumentationthroughout

projectlife-cycle

Assignadocumentwritingspecialist

39 33 28

Reduction

Reduction

Transfer

Scope/quality

Quality/technical

Hum

anresources

10

Lack

ofagreed

user

acceptance

testingandsign-offcriteria

Consult/traintheuser

intestdesign

40Reduction





Volume 104 · Number 4 · 2004 · 286-295

293

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

“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.

References

Abdel-Hamid, T.K. (1989), “The dynamics of software projectstaffing: 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 ProjectDynamics: An Integrated Approach, Prentice-Hall,Englewood Cliffs, NJ.

Barki, H. and Hartwick, J. (1989), “Rethinking the concept ofuser involvement”, MIS Quarterly, Vol. 13 No. 1, pp. 43-63.

Baronas, A.M.K. and Louis, M.R. (1988), “Restoring a sense ofcontrol during implementation: how user involvementleads to system acceptance”, MIS Quarterly, Vol. 12 No. 1,pp. 111-23.

Bennatan, E.M. (2002), On Time Within Budget: Software ProjectManagement Practices and Techniques, Wiley, New York,NY.

Beynon-Davis, P. (1995), “Information systems failure: the caseof the London Ambulance Service’s computer aideddespatch project”, European Journal of InformationSystems, 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 RiskManagement Methodology, NCC Blackwell, Oxford.

Chapman, R.J. (1998), “Effectiveness of working group riskidentification and assessment techniques”, InternationalJournal 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 specificrisk management concept”, International Journal ofProject Management, Vol. 16 No. 6, pp. 353-66.

Cooper, K.G. (1993), “The rework cycle: benchmarking for theproject manager”, Project Management Journal, Vol. 24No. 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 projectmanagement process”, Industrial Management & DataSystems, Vol. 103 No. 1, pp. 39-46.

Davis, G.B. and Olson, M.H. (1984), Management InformationSystems, Conceptual Foundations, Structure, andDevelopment, 2nd ed., McGraw-Hill, New York, NY.

Engming, L. and Hsieh, C.T. (1994), “Seven deadly risk factors ofsoftware development projects”, Journal of SystemsManagement, Vol. 36 No. 6, pp. 38-42.

Fuerst, W.L. and Cheney, P.H. (1982), “Factors affecting theperceived utilization of computer-based decision supportsystems in the oil industry”, Decision Sciences, Vol. 13No. 3, pp. 443-69.

Ginzberg, M.J. (1981), “Early diagnosis of MIS implementationfailure: promising results and unanswered questions”,Management Science, Vol. 27 No. 3, pp. 349-78.

Glass, R.L. (1998), Software Runaways, Prentice-Hall andYourdon Press, Englewood Cliffs, NJ.

Gobeli, D.H., Koenig, H.F. and Bechinger, I. (1998), “Managingconflict in software development teams: a multilevelanalysis”, Journal of Product Innovation Management,Vol. 14 No. 4, pp. 323-34.

Gunton, T. (1993), A Dictionary of Information Technology andComputer Science, 2nd ed., TJ Press, Cornwall.

Hartman, F. and Ashrafi, R.A. (2002), “Project management inthe information systems and information technologies




Volume 104 · Number 4 · 2004 · 286-295

294

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. 102No. 3, pp. 125-39.

Hoepleman, J.P., Mayer, R. and Wagner, J. (1997), Elsevier’sDictionary of Information Technology, Elsevier Science,Amsterdam.

Irani, Z. and Love, P.E.D. (2001), “The propagation of technologymanagement taxonomies for evaluating informationsystems”, Journal of Management Information Systems,Vol. 17 No. 3, pp. 161-77.

Jiang, J.J. and Klein, G. (2001), “Software project risks anddevelopment focus”, Project Management Journal, Vol. 32No. 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 ofpreferences”, Scientific American, January, pp. 160-73.

Keen, P.G.W. (1994), Every Manager’s Guide to InformationTechnology: A Glossary of Key Terms and Concepts forToday’s Business Leader, 2nd ed., Harvard Business SchoolPress, Boston, MA.

King, J. (1994), “Sketchy plans, politics stall softwaredevelopment”, Computer World, Vol. 29 No. 24, p. 81.

Krasner, H. (1998), “Looking over the legal edge of unsuccessfulsoftware projects”, Cutter IT Journal, Vol. 11 No. 3,pp. 11-22.

Leitheiser, R.L. and Wetherbe, J.C. (1986), “Service supportlevels: an organized approach to end-user computing”,MIS Quarterly, Vol. 10 No. 3, pp. 337-9.

McFarlan, F.W. (1981), “Portfolio approach to informationsystems”, 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 oncontingency allowances of using risk analysis in capitalcost estimating: a Hong Kong case study”, ConstructionManagement and Economics, Vol. 16 No. 6, pp. 615-9.

Miles, M.B. and Huberman, A.M. (1993), Qualitative DataAnalysis: An Expanded Source Book, Sage, Beverly Hills,CA.

Nelson, R. and Cheney, P. (1987), “Training end-users: anexploratory study”, MIS Quarterly, Vol. 11 No. 3,pp. 437-49.

Project Management Institute (PMI) (2000), ProjectManagement Body of Knowledge (PMBOK) – 2000Exposure Draft, PMI, Pennsylvania, PA.

Pritchard, C.L. (1997), Risk Management – Concepts andGuidance, ESI International, Arlington, VA.

Remenyi, D. (1999), Stop IT Project Failures through RiskManagement, Computer Weekly Series, ButterworthHeinemann, Oxford.

Sarantakos, S. (1998), Social Research, 2nd ed., Macmillan,Melbourne.

Sauer, C. (1993), Why Information Systems Fail: A Case StudyApproach, Alfred Waller, Henley-on-Thames.

Shand, R.M. (1993), “User manuals as project managementtools: part 1 – theoretical background”, IEEE Transactionson Professional Communication, Vol. 37 No. 2, pp. 74-80.

Standards Australia (1999), Risk Management, AS/NZS3360:1999, Standards Australia, Strathfield.

Thomsett, R. (1989), Third Wave Project Management – AHandbook for Managing Complex Information Systems forthe 1990s, Yourdon Press, Englewood Cliffs, NJ.

Thomsett, R. (1995), Project Pathology: Causes, Patterns andSymptoms of Project Failure – Training Notes Project RiskManagement, Thomsett Company, London.

Thomsett, R. (2001), “Extreme project management”, ExecutiveReport Abstracts, Vol. 2 No. 2.

Tuman, J. (1993), “Project management decision-making andrisk 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 fore-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, ProjectManagement 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 inmajor information technology projects”, in Willcocks, L.,Feeny, D. and Iseli, G. (Eds), Managing IT as a StrategicResource, McGraw-Hill, Maidenhead.

Willcocks, L. and Graeser, J. (2001), Delivering IT and E-businessValue, Computer Weekly Series, Butterworth andHeinemann, Oxford.

Yang, Y.H. (2001), “Software quality management and ISO 9000implementation”, Industrial Management & DataSystems, Vol. 101 No. 7, pp. 329-38.

Yoon, Y., Guimaraes, T. and O-Neal, Q. (1994), “Exploring thefactors associated with expert systems success”, MISQuarterly, Vol. 19 No. 1, pp. 83-106.

Yourdon, E. (1996), “Tools and processes for death marchprojects”, Cutter IT Journal – Application DevelopmentStrategies, Vol. 8 No. 12, pp. 27-35.

Zhi, H. (1994), “Risk management for overseas constructionprojects”, International Journal of Project Management,Vol. 13 No. 3, pp. 231-7.

Further reading

Bailey, R. (1996), “Approving system projects. Eight questions anexecutive should ask”, PM Network, Vol. 10 No. 5,pp. 21-4.

Gibbs, W. (1994), “Software’s chronic crisis”, ScientificAmerican, Vol. 271 No. 3, pp. 86-95.

Ward, J.A. (1994), “Productivity through project management:controlling the project variables”, Information SystemsManagement, Vol. 11 No. 1, pp. 16-21.




Volume 104 · Number 4 · 2004 · 286-295

295