Management of risks in information technology projects

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/220672176 Management of risks in information technology projects Article in Industrial Management & Data Systems · May 2004 DOI: 10.1108/02635570410530702 · Source: DBLP CITATIONS READS 110 2,290 3 authors, including: David Baccarini Peter E.D Love 25 PUBLICATIONS 1,068 CITATIONS 535 PUBLICATIONS 9,950 CITATIONS Curtin University SEE PROFILE Curtin University SEE PROFILE Some of the authors of this publication are also working on these related projects: Data Science and Cost Overrun Causation on Infrastructure Projects View project Decommissioning in the North Sea View project All content following this page was uploaded by Peter E.D Love on 27 April 2014. The user has requested enhancement of the downloaded file. All in-text references underlined in blue are added to the original document and are linked to publications on ResearchGate, letting you access and read them immediately. Introduction 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. 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 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 286 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 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. 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 highlevel 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 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. 287 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 (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). 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 (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). 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 clientbased object-oriented applications, clientserver 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. 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 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 nonlinear values for consequences reflect organisations’ typical desire to avoid highimpact 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). 289 . 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 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 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 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 Table I IT risk rankings IT risks Personnel shortfalls (insufficient human resources) Unreasonable project schedule and budget Unrealistic expectations (salesperson over sold product) Incomplete requirements Diminished window of opportunity due to late delivery of software Continuous changes to requirements by client Poor production system performance Poor leadership (project manager and/or steering committee) Inadequate user documentation100 Lack of agreed-to user acceptance testing and signoff criteria Inadequate third party performance (contractor not fit for purpose) Politically motivated collection of unrelated requirements Lack of executive support Lack of single point accountability Corporate culture not supportive Technical limitations of solution reached or exceeded Inappropriate user interface Litigation in protecting intellectual property Application (software) not fit for purpose Gold plating (over specification) Friction between clients and contractors Lack of formal change management process Developing wrong software functionality Poor quality of staff Harmful competitive actions Software no longer needed Failure to review daily progress Distribution as a % of the total Percentage of respondents MPHC MPMC MPLC LPHC 17 6 0 6 28 6 6 6 LPMC 0 0 LPLC 6 0 Total % 100 100 Score 1,233 1172 6 11 0 11 6 0 100 100 1,128 1,022 0 0 0 0 17 22 0 6 0 6 0 6 100 100 100 1,006 922 893 0 17 0 0 28 0 11 0 0 17 100 100 893 889 23 12 0 18 12 0 100 888 0 33 11 0 17 11 0 100 879 6 0 0 12 0 0 6 0 11 29 0 6 22 6 6 18 0 0 0 0 17 34 39 12 17 6 11 18 0 6 6 12 100 100 100 100 833 793 783 737 0 0 0 11 6 17 6 11 0 0 6 17 7 0 0 0 0 6 0 0 0 0 0 0 6 1 22 22 17 28 28 11 22 22 11 7 22 0 19 11 28 11 0 17 28 17 0 22 7 6 22 12 0 6 0 0 0 11 0 0 6 0 6 6 1 28 6 11 39 6 6 28 40 33 7 28 6 18 17 22 22 11 11 11 17 11 6 30 6 11 11 6 0 17 6 17 6 6 6 11 20 28 33 8 100 100 100 100 100 100 100 100 100 100 100 100 100 733 733 706 693 689 661 640 611 606 480 389 393 HPHC 67 46 HPMC 0 0 HPLC 0 0 33 39 17 17 0 0 28 17 0 6 0 0 39 39 17 6 11 6 0 17 0 17 6 33 33 6 6 22 28 0 33 0 0 39 6 23 12 0 17 0 28 18 33 23 17 17 22 6 11 11 6 0 11 20 0 0 23 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 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 Table II IT risk treatment strategies Risk event Inadequate third party performance Litigation in protecting intellectual property Friction between clients and contractors Diminished window of opportunity due to late delivery of software Harmful competitive actions Software no longer needed Personnel shortfalls Poor quality of staff Corporate culture not supportive Lack of executive support Politically motivated collection of unrelated requirements Inadequate user documentation Application (software) not fit for purpose Poor production system performance Technical limitations of solution reached or exceeded Incomplete requirements Inappropriate user interface Unreasonable project schedule and budget Continuous changes to requirements by the client Lack of agreed-to user acceptance and signoff criteria Failure to review daily progress Lack of single point accountability Poor leadership Developing wrong software functionality Lack of formal change management process Gold plating (over specification) Unrealistic expectations Strategy Screen contractors upfront Monitor contractor performance Retain right to remove unfit contractor Consultative engagement Contract conditions Consider personal attributes Monitor contractor performance Manage the relationship Sound project planning and schedule management Manage expectations Obtain management support Develop customer relationship Maintain market entry barrier Establish sound business requirements Manage key stakeholders Plan for resources Procure external parties Plan contingency options Change project management objectives Assess project staff capability Manage stakeholders Apply political influence Obtain executive management support Market the project Engage management early Clear scope definition Consult with key stakeholders Develop clear requirements definition Build documentation throughout the PLC Assign a document writing specialist Develop clear requirements definition Perform group reviews Obtain progressive signoff of milestones Conduct comprehensive testing in near production conditions Conduct proof of concept testing Development conducted in near production conditions Develop strong technical design Obtain clear scope specification and signoff Liaise with stakeholders Liaise with users Adopt standards for interface design Make tradeoffs between cost, time and scope Manage expectations Enforce formal change management process Ensure key project documentation is signed off Consult/educate user in change management practice Consult/train the user in test design Monitor project daily, if required Create a consultative environment Project manager is held accountable Roles and responsibilities clearly defined Project sponsor/owner is accountable Establish clear communication and escalation hierarchy Appoint an experienced project manager Establish steering committee selection process and operational guidelines Utilise established communication and escalation hierarchy Conduct group reviews Develop clear requirements definition Obtain signoffs of milestones Implement a formal change management system Educate users on the change management process Monitor and review development to baseline design Strict adherence to requirements definition Screen proposals Develop clear requirements definition Manage customer expectations Test validity of vendor claims 292 Percent 83 39 22 83 72 40 22 22 40 33 22 39 39 78 28 40 39 28 28 72 40 28 28 33 39 40 33 39 33 28 40 33 28 33 33 22 72 67 40 83 33 72 28 78 40 22 100 33 22 33 33 28 22 33 39 33 78 39 33 78 22 40 33 33 33 28 28 1 Personnel shortfalls 2 Unreasonable project schedule and budget 3 Unrealistic expectations 3 Incomplete requirements 4 Diminished window of opportunity due to late delivery of software 6 Continuous changes to requirements by client 7 Poor production system performance 8 Poor leadership 9 Inadequate user documentation Plan for resources Procure external parties Plan contingency options Change PM objectives Make tradeoffs between cost, time and scope Manage expectations Screen proposals Clear requirements definition Manage customer expectations Test validity of vendor claims Clear scope specification and sign-off Liaise with stakeholders Sound planning and schedule management Manage expectations Obtain management support Formal change management process Ensure key project documentation is signed off Consult/educate user in change management practice Comprehensive testing in near production conditions Conduct proof of concept testing Development conducted in near production conditions Appoint an experienced project manager Committee selection process and operational guidelines Utilise communication and escalation hierarchy Monitor leadership effectiveness Clear requirements definition Build documentation throughout project life-cycle Assign a document writing specialist Consult/train the user in test design 10 Lack of agreed user acceptance testing and sign-off criteria Percentage Treatment Project management (PMBOK) 40 39 28 28 72 28 33 33 28 28 67 40 40 33 22 78 33 22 33 33 22 33 39 33 22 39 33 28 40 Reduction Transfer Reduction Reduction Retention Reduction Reduction Reduction Reduction Reduction Reduction Reduction Reduction Reduction Reduction Reduction Transfer Reduction Reduction Reduction Reduction Reduction Reduction Reduction Retention Reduction Reduction Transfer Reduction Time/human resources Procurement Risk Integration/scope Integration/scope Quality/communication Scope/quality Scope/quality Quality/communication Quality Scope/quality Communication Time Quality/communication Human resources Scope/quality Quality Communication Quality/technical Quality/technical Quality/technical Human resources Human resources Communication/human resources Quality/human resources Scope/quality Quality/technical Human resources Quality/communication Industrial Management & Data Systems Risk treatment strategies Volume 104 · Number 4 · 2004 · 286-295 293 Risk Management of risks in IT projects Rank David Baccarini, Geoff Salm and Peter E.D. Love Table III Top ten risks treatment and project management processes 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 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 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 294 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, pp. 4-14. Hedelin, L. and Allwood, C.M. (2002), “IT and strategic decisionmaking”, 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. 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, SeptemberOctober, 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. 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. 295