Management of risks in information systems
Upcoming SlideShare
Loading in...5
×
 

Management of risks in information systems

on

  • 515 views

 

Statistics

Views

Total Views
515
Views on SlideShare
515
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Management of risks in information systems Management of risks in information systems Document Transcript

  • 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 ITrisks 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 Introduction Information technology (IT) is one of the fastest growing industries in developed countries (Hartman and Ashrafi, 2002). IT projects can implement a rapidly expanding range of equipment, applications, services, and basic technologies that provide information to support the operation, management, analysis and decision-making functions within an organisation (Gunton, 1993; Keen, 1994; Hoepleman et al., 1997; Wang, 2001; Yang, 2001). In 1999, the Standish Group International study of 7,400 IT projects revealed that 34 per cent were late or over budget, 31 per cent were abandoned, scaled back or modified, and only 24 per cent were completed on time and on budget (Cunningham, 1999). Examples of high profile IT project failures reported in the literature include the American Airlines Corporation AMR Information Services (AMRIS), London Ambulance System, the Wessex Health Service RISP (Regional Information Systems Plan, London Stock Exchange’s Transfer and Automated Registration of Uncertified Stock (TAURUS) system, FoxMeyer Drug Co., Mandata Human Resource System and the Californian State Automated Child System (SACSS) (Sauer, 1993; Beynon-Davis, 1995; Remenyi, 1999; Willcocks and Graeser, 2001). One consistent factor influencing project outcomes are the various risks associated with initiating and implementing IT projects (Jiang and Klein, 2001; Willcocks and Graeser, 2001). In particular, the OTR Group (1992) found that only 30 per cent of organisations applied risk analysis in their IT investment and project management processes. Likewise, Willcocks (1996) found organisations undertook little formal risk analysis, except when undertaking financial calculations. Evidence indicates that risks in IT projects are not effectively managed and, as a results their lack of identification and management during a project’s life-cycle can contribute to their failure (Willcocks and Griffiths, 1997; Hedelin and Allwood, 2002). Given the high failure rates associated with IT projects, it is prudent for organisations to improve their ability to manage their IT risks so that projects can be delivered successfully (Gobeli et al., 1998; Willcocks and Graeser, 2001; Jiang and Klein, 2001; Hartman and Ashrafi, 2002). In this paper, those IT project risks considered most important in terms of their likelihood and consequences and specific risk treatment strategies that can be used to manage IT project risks are identified by practising IT project managers in Australia. The findings presented will enable IT project managers to better understand the key risks in their projects and appropriate risk treatment strategies to manage these risks. While the research was conducted in an Australian context, it is envisaged that the research outcome would be widely 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 and Hsieh, 1994). . Poor quality of staff. Standard of work is poor owing to lack of ability, training, motivation and experience of staff Management of risks in IT projects David Baccarini, Geoff Salm and Peter E.D. Love Industrial Management & Data Systems 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). Management of risks in IT projects David Baccarini, Geoff Salm and Peter E.D. Love Industrial Management & Data Systems 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 to more than 77 years. Data were obtained by means of structured interviews. The research used a combined research methodology of quantitative (rating risks) and qualitative questions (risk treatment strategies). All but two respondents allowed the interviews to be taped. All taped interviews were fully transcribed. The questionnaire was pre-tested on two project managers, who had over 30 years of collective experience in IT projects, and minor amendments made. Following the transcription of all responses, each qualitative question was analysed and responses were sorted into themes. This process is a valid way of drawing conclusions from the data collected (Miles and Huberman, 1993). The research instrument used in the interviews contained the following sections: . Demographic information. This was background and experience of respondents. . Rating risks. A list of 27 risks, derived from the literature, was provided to the respondents who were asked to rate each risk in terms of likelihood (high/medium/low) and consequence (high/medium/low). These responses were converted into numeric values to allow ranking of risks. The values allocated were: probability values: high ¼ 3, medium ¼ 2, low ¼ 1; consequence values: high ¼ 5; medium ¼ 3; low ¼ 1. The non- linear values for consequences reflect organisations’ typical desire to avoid high- impact risks (PMI, 2000). Research shows that the severity of the potential consequences of a risk produces a greater concern than its probability in evaluating the overall level of risk (Kahneman and Tversky, 1982). For example, a low-probability/high-consequence risk is typically considered as being higher than a high-probability/low-consequence risk. The score for each risk was calculated as follows: ((probability*consequence*percentage value of respondents selecting this combination). Management of risks in IT projects David Baccarini, Geoff Salm and Peter E.D. Love Industrial Management & Data Systems 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 project management and product processes. For example, developing and implementing testing can be viewed both as a technical process and also a quality control process. The risks ranked third, fourth and fifth in this survey have not been ranked highly in comparison to previous studies (e.g. Boehm, 1989): . Unrealistic expectations. It is only in more recent times that meeting client expectations has been emphasised as a key criterion for project success (e.g. PMI, 2000). Consequently, the risk of unrealistic expectations has grown in importance and needs to be managed by quality, scope and communications management. . Incomplete requirements. There is an acute awareness nowadays of the importance of fully defining clients’ requirements early in the project to help achieve project success. Therefore, it is not surprising that incomplete requirements is seen as an important risk, requiring scope, quality and communications management. . Diminished window of opportunity owing to late delivery of software. A critical issue with many projects nowadays is the need to reach the market before competitors. Consequently, missing a window of opportunity is a high risk and requires good time management. This was not a high-ranking risk by Boehm (1989) when speed to market was of lesser importance compared to today’s relatively turbulent and dynamic markets. Risk treatment strategies The respondents were asked to describe what strategies they would take to manage risks that they rated as medium or high for both likelihood and consequences. Table II shows the responses, which provide a rich and valuable array of risk treatment strategies (the results record responses supported by at least four of the 18 respondents, i.e. 22+ per cent). It shows that for approximately half the risks Management of risks in IT projects David Baccarini, Geoff Salm and Peter E.D. Love Industrial Management & Data Systems 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 Total IT risks HPHC HPMC HPLC MPHC MPMC MPLC LPHC LPMC LPLC % Score Personnel shortfalls (insufficient human resources) 67 0 0 17 6 0 6 0 6 100 1,233 Unreasonable project schedule and budget 46 0 0 28 6 6 6 0 0 100 1172 Unrealistic expectations (salesperson over sold product) 33 17 0 28 0 0 6 0 6 100 1,128 Incomplete requirements 39 17 0 17 6 0 11 11 0 100 1,022 Diminished window of opportunity due to late delivery of software 39 6 0 17 33 0 0 0 6 100 1,006 Continuous changes to requirements by client 39 11 17 6 6 0 17 6 0 100 922 Poor production system performance 17 6 0 33 6 0 22 0 6 100 893 Poor leadership (project manager and/or steering committee) 22 0 0 39 0 0 28 11 0 100 893 Inadequate user documentation100 28 33 0 6 17 0 0 0 17 100 889 Lack of agreed-to user acceptance testing and signoff criteria 23 12 0 23 12 0 18 12 0 100 888 Inadequate third party performance (contractor not fit for purpose) 17 0 0 33 11 0 17 11 0 100 879 Politically motivated collection of unrelated requirements 28 6 0 11 22 0 17 17 0 100 833 Lack of executive support 18 0 0 29 6 0 34 6 6 100 793 Lack of single point accountability 33 0 6 0 6 0 39 11 6 100 783 Corporate culture not supportive 23 12 0 6 18 0 12 18 12 100 737 Technical limitations of solution reached or exceeded 17 0 0 22 11 0 28 17 6 100 733 Inappropriate user interface 17 0 0 22 28 6 6 22 0 100 733 Litigation in protecting intellectual property 22 0 0 17 11 0 11 22 17 100 706 Application (software) not fit for purpose 6 11 0 28 0 0 39 11 6 100 693 Gold plating (over specification) 11 6 6 28 17 0 6 11 17 100 689 Friction between clients and contractors 11 17 0 11 28 11 6 11 6 100 661 Lack of formal change management process 6 6 0 22 17 0 28 17 6 100 640 Developing wrong software functionality 0 11 0 22 0 0 40 11 6 100 611 Poor quality of staff 11 0 0 11 22 6 33 6 11 100 606 Harmful competitive actions 20 0 0 7 7 0 7 30 20 100 480 Software no longer needed 0 6 0 22 6 6 28 6 28 100 389 Failure to review daily progress 0 17 6 0 22 6 6 11 33 100 393 Distribution as a % of the total 23 7 1 19 12 1 18 11 8 100 Management of risks in IT projects David Baccarini, Geoff Salm and Peter E.D. Love Industrial Management & Data Systems Volume 104 · Number 4 · 2004 · 286-295 291
  • Table II IT risk treatment strategies Risk event Strategy Percent Inadequate third party performance Screen contractors upfront Monitor contractor performance Retain right to remove unfit contractor 83 39 22 Litigation in protecting intellectual property Consultative engagement Contract conditions 83 72 Friction between clients and contractors Consider personal attributes Monitor contractor performance Manage the relationship 40 22 22 Diminished window of opportunity due to late delivery of software Sound project planning and schedule management Manage expectations Obtain management support 40 33 22 Harmful competitive actions Develop customer relationship Maintain market entry barrier 39 39 Software no longer needed Establish sound business requirements Manage key stakeholders 78 28 Personnel shortfalls Plan for resources Procure external parties Plan contingency options Change project management objectives 40 39 28 28 Poor quality of staff Assess project staff capability 72 Corporate culture not supportive Manage stakeholders Apply political influence Obtain executive management support 40 28 28 Lack of executive support Market the project Engage management early 33 39 Politically motivated collection of unrelated requirements Clear scope definition Consult with key stakeholders 40 33 Inadequate user documentation Develop clear requirements definition Build documentation throughout the PLC Assign a document writing specialist 39 33 28 Application (software) not fit for purpose Develop clear requirements definition Perform group reviews Obtain progressive signoff of milestones 40 33 28 Poor production system performance Conduct comprehensive testing in near production conditions Conduct proof of concept testing Development conducted in near production conditions 33 33 22 Technical limitations of solution reached or exceeded Develop strong technical design 72 Incomplete requirements Obtain clear scope specification and signoff Liaise with stakeholders 67 40 Inappropriate user interface Liaise with users Adopt standards for interface design 83 33 Unreasonable project schedule and budget Make tradeoffs between cost, time and scope Manage expectations 72 28 Continuous changes to requirements by the client Enforce formal change management process Ensure key project documentation is signed off Consult/educate user in change management practice 78 40 22 Lack of agreed-to user acceptance and signoff criteria Consult/train the user in test design 100 Failure to review daily progress Monitor project daily, if required Create a consultative environment 33 22 Lack of single point accountability Project manager is held accountable Roles and responsibilities clearly defined Project sponsor/owner is accountable Establish clear communication and escalation hierarchy 33 33 28 22 Poor leadership Appoint an experienced project manager Establish steering committee selection process and operational guidelines Utilise established communication and escalation hierarchy 33 39 33 Developing wrong software functionality Conduct group reviews Develop clear requirements definition Obtain signoffs of milestones 78 39 33 Lack of formal change management process Implement a formal change management system Educate users on the change management process 78 22 Gold plating (over specification) Monitor and review development to baseline design Strict adherence to requirements definition 40 33 Unrealistic expectations Screen proposals Develop clear requirements definition Manage customer expectations Test validity of vendor claims 33 33 28 28 Management of risks in IT projects David Baccarini, Geoff Salm and Peter E.D. Love Industrial Management & Data Systems Volume 104 · Number 4 · 2004 · 286-295 292
  • TableIIIToptenriskstreatmentandprojectmanagementprocesses RankRiskRisktreatmentstrategiesPercentageTreatmentProjectmanagement(PMBOK) 1PersonnelshortfallsPlanforresources Procureexternalparties Plancontingencyoptions ChangePMobjectives 40 39 28 28 Reduction Transfer Reduction Reduction Time/humanresources Procurement Risk Integration/scope 2UnreasonableprojectscheduleandbudgetMaketradeoffsbetweencost,timeandscope Manageexpectations 72 28 Retention Reduction Integration/scope Quality/communication 3UnrealisticexpectationsScreenproposals Clearrequirementsdefinition Managecustomerexpectations Testvalidityofvendorclaims 33 33 28 28 Reduction Reduction Reduction Reduction Scope/quality Scope/quality Quality/communication Quality 3IncompleterequirementsClearscopespecificationandsign-off Liaisewithstakeholders 67 40 Reduction Reduction Scope/quality Communication 4DiminishedwindowofopportunityduetolatedeliveryofsoftwareSoundplanningandschedulemanagement Manageexpectations Obtainmanagementsupport 40 33 22 Reduction Reduction Reduction Time Quality/communication Humanresources 6ContinuouschangestorequirementsbyclientFormalchangemanagementprocess Ensurekeyprojectdocumentationissignedoff Consult/educateuserinchangemanagementpractice 78 33 22 Reduction Transfer Reduction Scope/quality Quality Communication 7PoorproductionsystemperformanceComprehensivetestinginnearproductionconditions Conductproofofconcepttesting Developmentconductedinnearproductionconditions 33 33 22 Reduction Reduction Reduction Quality/technical Quality/technical Quality/technical 8PoorleadershipAppointanexperiencedprojectmanager Committeeselectionprocessandoperationalguidelines Utilisecommunicationandescalationhierarchy Monitorleadershipeffectiveness 33 39 33 22 Reduction Reduction Reduction Retention Humanresources Humanresources Communication/humanresources Quality/humanresources 9InadequateuserdocumentationClearrequirementsdefinition Builddocumentationthroughoutprojectlife-cycle Assignadocumentwritingspecialist 39 33 28 Reduction Reduction Transfer Scope/quality Quality/technical Humanresources 10Lackofagreeduseracceptancetestingandsign-offcriteriaConsult/traintheuserintestdesign40ReductionQuality/communication Management of risks in IT projects David Baccarini, Geoff Salm and Peter E.D. Love Industrial Management & Data Systems 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 project staffing: a systems dynamics based simulation approach”, IEEE Transactions in Software Engineering, Vol. 15, pp. 109-19. Abdel-Hamid, T.K. and Madnick, S.E. (1991), Software Project Dynamics: An Integrated Approach, Prentice-Hall, Englewood Cliffs, NJ. Barki, H. and Hartwick, J. (1989), “Rethinking the concept of user involvement”, MIS Quarterly, Vol. 13 No. 1, pp. 43-63. Baronas, A.M.K. and Louis, M.R. (1988), “Restoring a sense of control during implementation: how user involvement leads to system acceptance”, MIS Quarterly, Vol. 12 No. 1, pp. 111-23. Bennatan, E.M. (2002), On Time Within Budget: Software Project Management Practices and Techniques, Wiley, New York, NY. Beynon-Davis, P. (1995), “Information systems failure: the case of the London Ambulance Service’s computer aided despatch project”, European Journal of Information Systems, Vol. 4, pp. 171-84. Boehm, B.W. (1989), Software Risk Management, IEEE, Computer Society Press, Washington, DC. Carter, B., Hancock, T., Morin, J. and Robins, N. (1993), Introducing RISKMAN: The European Project Risk Management Methodology, NCC Blackwell, Oxford. Chapman, R.J. (1998), “Effectiveness of working group risk identification and assessment techniques”, International Journal of Project Management, Vol. 16 No. 6, pp. 333-43. Clancy, T. (1995), “Chaos – IT development projects”, available at: www.standishgroup.com/msie.htm (accessed 24 August 2000). Conroy, G. and Soltan, H. (1998), “ConSERV, a project specific risk management concept”, International Journal of Project Management, Vol. 16 No. 6, pp. 353-66. Cooper, K.G. (1993), “The rework cycle: benchmarking for the project manager”, Project Management Journal, Vol. 24 No. 1, pp. 17-22. Cunningham, M. (1999), “It’s all about the business”, Inform, Vol. 13 No. 3, p. 83. Czuchry, A.J. and Yasin, M.M. (2003), “Managing the project management process”, Industrial Management & Data Systems, Vol. 103 No. 1, pp. 39-46. Davis, G.B. and Olson, M.H. (1984), Management Information Systems, Conceptual Foundations, Structure, and Development, 2nd ed., McGraw-Hill, New York, NY. Engming, L. and Hsieh, C.T. (1994), “Seven deadly risk factors of software development projects”, Journal of Systems Management, Vol. 36 No. 6, pp. 38-42. Fuerst, W.L. and Cheney, P.H. (1982), “Factors affecting the perceived utilization of computer-based decision support systems in the oil industry”, Decision Sciences, Vol. 13 No. 3, pp. 443-69. Ginzberg, M.J. (1981), “Early diagnosis of MIS implementation failure: promising results and unanswered questions”, Management Science, Vol. 27 No. 3, pp. 349-78. Glass, R.L. (1998), Software Runaways, Prentice-Hall and Yourdon Press, Englewood Cliffs, NJ. Gobeli, D.H., Koenig, H.F. and Bechinger, I. (1998), “Managing conflict in software development teams: a multilevel analysis”, Journal of Product Innovation Management, Vol. 14 No. 4, pp. 323-34. Gunton, T. (1993), A Dictionary of Information Technology and Computer Science, 2nd ed., TJ Press, Cornwall. Hartman, F. and Ashrafi, R.A. (2002), “Project management in the information systems and information technologies Management of risks in IT projects David Baccarini, Geoff Salm and Peter E.D. Love Industrial Management & Data Systems 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. 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, September- October, pp. 142-50. Maish, A.M. (1979), “A user’s behaviour toward his MIS”, MIS Quarterly, Vol. 3 No. 1, pp. 39-42. Mak, S., Wong, J. and Picken, D. (1998), “The effect on contingency allowances of using risk analysis in capital cost estimating: a Hong Kong case study”, Construction Management and Economics, Vol. 16 No. 6, pp. 615-9. Miles, M.B. and Huberman, A.M. (1993), Qualitative Data Analysis: An Expanded Source Book, Sage, Beverly Hills, CA. Nelson, R. and Cheney, P. (1987), “Training end-users: an exploratory study”, MIS Quarterly, Vol. 11 No. 3, pp. 437-49. Project Management Institute (PMI) (2000), Project Management Body of Knowledge (PMBOK) – 2000 Exposure Draft, PMI, Pennsylvania, PA. Pritchard, C.L. (1997), Risk Management – Concepts and Guidance, ESI International, Arlington, VA. Remenyi, D. (1999), Stop IT Project Failures through Risk Management, Computer Weekly Series, Butterworth Heinemann, Oxford. Sarantakos, S. (1998), Social Research, 2nd ed., Macmillan, Melbourne. Sauer, C. (1993), Why Information Systems Fail: A Case Study Approach, Alfred Waller, Henley-on-Thames. Shand, R.M. (1993), “User manuals as project management tools: part 1 – theoretical background”, IEEE Transactions on Professional Communication, Vol. 37 No. 2, pp. 74-80. 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. Management of risks in IT projects David Baccarini, Geoff Salm and Peter E.D. Love Industrial Management & Data Systems Volume 104 · Number 4 · 2004 · 286-295 295