Professional Documents
Culture Documents
Management of Risks in Information Technology Projects: Industrial Management & Data Systems May 2004
Management of Risks in Information Technology Projects: Industrial Management & Data Systems May 2004
Management of Risks in Information Technology Projects: Industrial Management & Data Systems May 2004
net/publication/220672176
CITATIONS READS
171 10,326
3 authors, including:
David Baccarini
Curtin University
31 PUBLICATIONS 2,330 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
All content following this page was uploaded by David Baccarini on 11 October 2018.
(Cooper, 1993; Yoon et al., 1994). This technical solution (Boehm, 1989; Jones,
lack of experience can extend to hardware, 1993).
operating systems, database management .
Incomplete requirements. Insufficient
systems, and other software (Fuerst and information has been obtained in the
Cheney, 1982; Nelson and Cheney, 1987). analysis phase, resulting in construction of
(4) Political circumstances: a solution that does not meet project
.
Corporate culture not supportive. Corporate objectives (Shand, 1993; Engming and
culture may be project adverse owing to Hsieh, 1994).
other hidden agendas, factions within the .
Inappropriate user interface. The software
company, organisational culture under user interface selected or developed fails to
continuous change or threat of change, and meet user requirements (Jones, 1993;
other internal priorities. This results in King, 1994).
weak management support for the project (6) Management activities and controls:
and consequential failure of not meeting .
Unreasonable project schedule and budget. The
objectives (Leitheiser and Wetherbe, 1986; project is unable to realise its objectives
Engming and Hsieh, 1994; Irani and Love, owing to unrealistic restrictions placed on
2001). the projects budget, schedule, quality or
.
Lack of executive support. Project is level of performance (King, 1994; Krasner,
disrupted from achieving its objectives
1998). A project failing to meet its
owing to management playing politics
committed deliverables or is significantly
within and between departments or
over budget can be terminated (Boehm,
external agents (Leitheiser and Wetherbe,
1989; King, 1994; Turner, 1999).
1986). Furthermore, users may not .
Continuous changes to requirements by client.
support the project if they perceive that
Stakeholders (includes users) continuously
there is a lack of top-level management
make changes to software functionality
sponsorship (Barki and Hartwick, 1989).
throughout the project life-cycle (Jones,
.
Politically-motivated collection of unrelated
1993; King, 1994; Clancy, 1994).
requirements. Owing to political motivations .
Lack of agreed-to user acceptance testing and
within the organisation a number of
signoff criteria. The project close-out can be
unrelated requirements are grouped in an
delayed owing to an unclear understanding
all-encompassing project which becomes
difficult to manage and meet objectives of what constitutes sign-off and final
(Krasner, 1998). solution delivery (Boehm, 1989).
(5) Technology and technical issues:
.
Failure to review daily progress. Manager
.
Inadequate user documentation. Users are fails to review the progress of daily
unable to fully utilise new IT as it was deliverables resulting in project slippage
intended owing to poor user (Clancy, 1994; Yourdon, 1996).
documentation (Boehm, 1989).
.
Lack of single point accountability. It is
.
Application software not fit for purpose. There typical of large software projects to have
can be a perception among users that the many team leaders but no single point of
software provided does not directly help responsibility for deliverables, resulting in
them with completing day-to-day tasks. the project failing to meet its objectives
This can lead to low user satisfaction (Fuerst and Cheney, 1982; Thomsett,
(Baronas and Louis, 1988). 1995).
.
Poor production system performance. The
.
Poor leadership. The project manager and/
selected software architecture/platform or steering committee is not committed to
does not meet the purpose for which it was solving problems and providing direction
intended, resulting in a system being to the project team (King, 1994; Clancy,
released into production which is 1994).
excessively slow or has major operational .
Developing wrong software functionality.
problems (Jones, 1993; Glass, 1998). Design and construction of software may
.
Technical limitations of solution reached or not meet the purpose for which it is
exceeded. A technical limitation is intended (Boehm, 1989).
encountered during software development .
Lack of formal change management process.
resulting in time delays to the project while Project progress is hindered owing to ad
a work-around solution is determined. In hoc changes to system specification without
extreme cases, a solution may not be a formal review of technical and project
found. The result is either cancellation of impact (Jones, 1993; Davis and Olson,
the project or re-starting with a more viable 1984; Cunningham, 1999).
288
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
.
Risk treatment. Each respondent who rated a unreasonable schedule and budget. It is not
risk as medium or high for both likelihood and unexpected that unrealistic budget and
consequences was requested to describe schedule is ranked as the second highest risk,
suitable actions to manage the risk. as it reflects the perennial tension within
projects to balance the triple constraints.
A sample of 18 IT personnel was selected,
dominated by IT project managers. Each of the IT In Table I, it is worth noting that two other risks
project managers was invited to rank each of the were highly ranked by the literature and this
listed risks and offer treatment strategies. Opinions research: “continuous changes to requirements by
about risk in IT projects were also obtained. the client” and “poor production system
performance”. The project management
implications for managing these risks are:
.
Continuous changes to requirements by the client
Results and discussion – this requires change control process for
scope and quality management.
The sample had a mean of ten years’ work .
Poor production system performance – interestingly,
experience which implies that they had
considerable knowledge of the IT project the treatments for this risk are a combination of
management process. Key project risks and both project management and product processes.
treatment strategies ranked by respondents are For example, developing and implementing
presented and discussed below. testing can be viewed both as a technical process
and also a quality control process.
The risks ranked third, fourth and fifth in this
Key IT project risks
survey have not been ranked highly in comparison
One of the objectives of this study was to identify IT
project risks considered most important in terms of to previous studies (e.g. Boehm, 1989):
their likelihood and consequences. Table I presents
.
Unrealistic expectations. It is only in more
the scores and consequent ranking for the 27 risks recent times that meeting client expectations
identified in the literature. Here, three dominant has been emphasised as a key criterion for
risk ratings emerge of all responses: high project success (e.g. PMI, 2000).
probability/high consequence (23 per cent), Consequently, the risk of unrealistic
medium probability/high consequence (19 per expectations has grown in importance and
cent), and low probability/high consequence (18 needs to be managed by quality, scope and
per cent). Therefore, 60 per cent of IT risks have communications management.
high consequences. This suggests that IT projects .
Incomplete requirements. There is an acute
are high-risk ventures and perhaps contributes awareness nowadays of the importance of fully
towards their high failure rate. It is significant that defining clients’ requirements early in the project
“personnel shortfalls” and “unrealistic schedule to help achieve project success. Therefore, it is
and budget” have identified as the primary causes of not surprising that incomplete requirements is
risk in the literature (Boehm, 1989). Considering seen as an important risk, requiring scope,
the findings presented in Table I the project quality and communications management.
manager can reasonably expect these particular .
Diminished window of opportunity owing to late
risks to exist and have high consequences. delivery of software. A critical issue with many
Therefore, the project manager must have effective projects nowadays is the need to reach the
project management processes in place: market before competitors. Consequently,
.
The inability to complete work assigned owing missing a window of opportunity is a high risk
to insufficient staff should be managed by and requires good time management. This
human resource management and was not a high-ranking risk by Boehm (1989)
procurement management. Today, many when speed to market was of lesser
organisations are flat and lean, with many importance compared to today’s relatively
competencies outsourced, so it is not turbulent and dynamic markets.
unexpected that personnel shortfalls are the
highest ranked risk. Risk treatment strategies
.
The risk of unreasonable schedule and budget The respondents were asked to describe what
needs to be managed by a combination of time strategies they would take to manage risks that they
and cost planning to verify what is a rated as medium or high for both likelihood and
reasonable baseline; integration management consequences. Table II shows the responses, which
in terms of achieving the appropriate balance provide a rich and valuable array of risk treatment
between time, cost and scope/quality; and strategies (the results record responses supported
client expectations management to ensure that by at least four of the 18 respondents, i.e. 22+ per
the client is made aware of the effect of cent). It shows that for approximately half the risks
290
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
there is one strongly favoured treatment, whereas technical processes that specify and create the
the remaining risks have two or more treatments project’s product and vary with the nature of the
with similar support. This indicates that there is project. Table III demonstrates that the majority of
not one solution for managing any particular risk treatment strategies are related to project
and the project manager must be aware of the management processes rather that product
possible need to implement two or more processes. This supports the observation that most
treatments for one risk. Table III categorises, for software problems are of a management,
the top ten ranked risk, the treatment strategy into organisational or behavioural nature, not technical
avoidance, reduction, transfer or acceptance and (Hartman and Ashrafi, 2002). The survey provides
indicates that risk: a valuable insight, in that it highlights the
.
reduction is the overwhelmingly favoured importance of project management as the key
treatment strategy, which supports the literature; solution to managing many project risks. In
.
acceptance was not proposed as a treatment particular, Table III also indicates that some
strategy, perhaps because it is typically used project management processes are risk treatments
for low risks; and for many high-ranked risks:
.
transfer was not proposed as a treatment .
scope/quality management – e.g. requirements
strategy. This may be because IT project definition, screen proposals;
managers are given direct responsibility to .
communication management – e.g. managing
manage the risk using in-house organisational expectations, vendor relationships, liaising
resources. with stakeholders; and
.
human resource management – e.g. plan for
There are two processes within a project; namely,
personnel resources, experienced project manager.
project management and product (PMI, 2000).
The former describes, organises and completes the Managing the expectations of stakeholders is a
work of the project; while the latter relates to the critical risk management strategy which should be
291
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
292
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
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 Industrial Management & Data Systems
David Baccarini, Geoff Salm and Peter E.D. Love Volume 104 · Number 4 · 2004 · 286-295
industries”, Project Management Journal, Vol. 33 No. 3, Standards Australia (1999), Risk Management, AS/NZS
pp. 4-14. 3360:1999, Standards Australia, Strathfield.
Hedelin, L. and Allwood, C.M. (2002), “IT and strategic decision- Thomsett, R. (1989), Third Wave Project Management – A
making”, Industrial Management & Data Systems, Vol. 102 Handbook for Managing Complex Information Systems for
No. 3, pp. 125-39. the 1990s, Yourdon Press, Englewood Cliffs, NJ.
Hoepleman, J.P., Mayer, R. and Wagner, J. (1997), Elsevier’s Thomsett, R. (1995), Project Pathology: Causes, Patterns and
Dictionary of Information Technology, Elsevier Science, Symptoms of Project Failure – Training Notes Project Risk
Amsterdam. Management, Thomsett Company, London.
Irani, Z. and Love, P.E.D. (2001), “The propagation of technology Thomsett, R. (2001), “Extreme project management”, Executive
management taxonomies for evaluating information Report Abstracts, Vol. 2 No. 2.
systems”, Journal of Management Information Systems, Tuman, J. (1993), “Project management decision-making and
Vol. 17 No. 3, pp. 161-77. risk management in a changing corporate environment”,
Jiang, J.J. and Klein, G. (2001), “Software project risks and Project Management Institute 24th Annual Seminar/
development focus”, Project Management Journal, Vol. 32 Symposium, Vancouver, 17-19 October, pp. 733-9.
No. 1, pp. 3-9. Turner, R.J. (1999), The Handbook of Project Based Management,
Jones, C. (1993), Assessment and Control of Software Risks, 2nd ed., McGraw-Hill, Cambridge.
Prentice-Hall, Englewood Cliffs, NJ. Wang, S. (2001), “Designing information systems for
Kahneman, D. and Tversky, A. (1982), “The psychology of e-commerce”, Industrial Management and Data Systems,
preferences”, Scientific American, January, pp. 160-73. Vol. 101 No. 6, pp. 304-15.
Keen, P.G.W. (1994), Every Manager’s Guide to Information Wideman, R.M. (1992), Project and Program Risk Management –
Technology: A Glossary of Key Terms and Concepts for A Guide to Managing Risks and Opportunities, Project
Today’s Business Leader, 2nd ed., Harvard Business School Management Institute, Pennsylvania, PA.
Press, Boston, MA. Wider, C. and Davis, B. (1998), “False starts – strong finishes”,
King, J. (1994), “Sketchy plans, politics stall software Information Week, Vol. 7 No. 11, pp. 41-53.
development”, Computer World, Vol. 29 No. 24, p. 81. Willcocks, L. (1996), Investing in Information Systems:
Krasner, H. (1998), “Looking over the legal edge of unsuccessful Evaluation and Management, Thomson Business Press/
software projects”, Cutter IT Journal, Vol. 11 No. 3, Chapman & Hall, London.
pp. 11-22. Willcocks, L. and Griffiths, C. (1997), “Management and risk in
Leitheiser, R.L. and Wetherbe, J.C. (1986), “Service support major information technology projects”, in Willcocks, L.,
levels: an organized approach to end-user computing”, Feeny, D. and Iseli, G. (Eds), Managing IT as a Strategic
MIS Quarterly, Vol. 10 No. 3, pp. 337-9. Resource, McGraw-Hill, Maidenhead.
McFarlan, F.W. (1981), “Portfolio approach to information Willcocks, L. and Graeser, J. (2001), Delivering IT and E-business
systems”, Harvard Business Review, Vol. 142, September-
Value, Computer Weekly Series, Butterworth and
October, pp. 142-50.
Heinemann, Oxford.
Maish, A.M. (1979), “A user’s behaviour toward his MIS”,
Yang, Y.H. (2001), “Software quality management and ISO 9000
MIS Quarterly, Vol. 3 No. 1, pp. 39-42.
implementation”, Industrial Management & Data
Mak, S., Wong, J. and Picken, D. (1998), “The effect on
Systems, Vol. 101 No. 7, pp. 329-38.
contingency allowances of using risk analysis in capital
Yoon, Y., Guimaraes, T. and O-Neal, Q. (1994), “Exploring the
cost estimating: a Hong Kong case study”, Construction
factors associated with expert systems success”, MIS
Management and Economics, Vol. 16 No. 6, pp. 615-9.
Quarterly, Vol. 19 No. 1, pp. 83-106.
Miles, M.B. and Huberman, A.M. (1993), Qualitative Data
Yourdon, E. (1996), “Tools and processes for death march
Analysis: An Expanded Source Book, Sage, Beverly Hills,
projects”, Cutter IT Journal – Application Development
CA.
Nelson, R. and Cheney, P. (1987), “Training end-users: an Strategies, Vol. 8 No. 12, pp. 27-35.
exploratory study”, MIS Quarterly, Vol. 11 No. 3, Zhi, H. (1994), “Risk management for overseas construction
pp. 437-49. projects”, International Journal of Project Management,
Project Management Institute (PMI) (2000), Project Vol. 13 No. 3, pp. 231-7.
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 Further reading
Management, Computer Weekly Series, Butterworth
Heinemann, Oxford. Bailey, R. (1996), “Approving system projects. Eight questions an
Sarantakos, S. (1998), Social Research, 2nd ed., Macmillan, executive should ask”, PM Network, Vol. 10 No. 5,
Melbourne. pp. 21-4.
Sauer, C. (1993), Why Information Systems Fail: A Case Study Gibbs, W. (1994), “Software’s chronic crisis”, Scientific
Approach, Alfred Waller, Henley-on-Thames. American, Vol. 271 No. 3, pp. 86-95.
Shand, R.M. (1993), “User manuals as project management Ward, J.A. (1994), “Productivity through project management:
tools: part 1 – theoretical background”, IEEE Transactions controlling the project variables”, Information Systems
on Professional Communication, Vol. 37 No. 2, pp. 74-80. Management, Vol. 11 No. 1, pp. 16-21.
295