Risk Profiles in Individual Software Development and Packaged Software Implementation Projects: A Delphi Study at a German-Based Financial Services Company

Risk Profiles in Individual Software Development and Packaged Software Implementation Projects: A Delphi Study at a German-Based Financial Services Company

Stefan Hoermann, Michael Schermann, Marco Aust, Helmut Krcmar
DOI: 10.4018/978-1-5225-0196-1.ch072
OnDemand:
(Individual Chapters)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

The aim of this paper is to compare risk profiles of individual software development (ISD) and packaged software implementation (PSI) projects. While researchers have investigated risks in either PSI projects or ISD projects, an integrated perspective on how the risk profiles of these two types of information system (IS) projects differ is missing. To explore these differences, this work conducted a Delphi study at a German-based financial services company. The results suggest that: First, ISD projects seem to be more heterogeneous and face a larger variety of risks than the more straightforward PSI projects. Second, ISD projects seem to be particularly prone to risks related to sponsorship, requirements, and project organization. Third, PSI projects tend to be predominantly subject to risks related to technology, project planning, and project completion. Finally, in contrast to available lists of risks in IS projects and irrespective of the project type, the paper found a surprisingly high prominence of technology and testing-related risks.
Chapter Preview
Top

1. Introduction

Although the discipline of information systems (IS) project management has matured considerably over the last decades, a lot of IS projects still face time, quality and budget issues. Failure rates of IS projects range from 23% to 68% – even in the optimistic case of 23% a high number for a professional discipline (Sauer et al., 2007; The Standish Group International, 2010). As successful IS project managers tend to be good at managing risks (Boehm, 1991) project risk management has increasingly gained importance among practitioners and academics (Bannerman, 2008).

Project risk management typically comprises the two phases of risk analysis (the identification, the assessment and the prioritization of possible events that pose a threat to project success) and risk control (the planning of responses, risk resolution and continuous monitoring) (Charette, 1996; Heemstra et al., 1996). Studies on project risk management in the IS discipline tend to focus on the first phase, and, in particular, on risk identification. In this regard, researchers have devised various generic lists of risks or checklists (Alter et al., 1978; Barki et al., 1993; Boehm, 1991; McFarlan, 1981; Moynihan, 1997; Zmud, 1980) to guide IS project managers in identifying and analyzing potential threats to IS project success. More recently, researchers have started to acknowledge that there is no one-size-fits-all risk profile for IS projects. Existence and importance of risks seem to vary depending on contextual, project-related, or individual characteristics. In this regard, researchers have analyzed how the cultural and socioeconomic (Mursu et al., 2003; Schmidt et al., 2001) context, a project’s outsourcing location (Nakatsu et al., 2009), an individual’s role in a project (Keil et al., 2002; Liu et al., 2010), and how his or her experience (Du et al., 2007; Warkentin et al., 2009) influence the existence and importance of IS project risks. Existing studies tend to either subsume various project activities under the general category of IS projects or exclusively focus on either individual software development (ISD) projects or packaged software implementation (PSI) projects. An integrated perspective on how risk profiles of these two types of information system (IS) projects differ is missing.

We argue that besides the mentioned contextual, project-related and individual characteristics, a main factor affecting a project’s risk profile is the type of project that is being analyzed. The development of individual software differs considerably from the implementation of packaged software in terms of the project lifecycle and the intensity of the relationship between client and vendors (Lucas et al., 1988; Markus et al., 2000). With regard to the project lifecycle, individually developed software is typically designed to fit a company’s extant business processes, which puts considerable emphasis on requirements analysis. The implementation of packaged software, in contrast, oftentimes comes with major business process changes as tailoring the software package to extant processes is difficult and only possible to some extent. With regard to the client-vendor relationship, individual software development projects are frequently limited to the short- or medium-term. On the contrary, the implementation of packaged software oftentimes means long-term relationships between clients and vendors in order to maintain and update the software.

Complete Chapter List

Search this Book:
Reset