Making Sense of IS Project Stories

Making Sense of IS Project Stories

DOI: 10.4018/978-1-5225-7362-3.ch101
OnDemand:
(Individual Chapters)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

Stories of failure make a compelling read. However, researchers with a keen interest in information systems failures face a double challenge. Not only is it difficult to obtain intimate details about the circumstances surrounding such failures, but there is also a dearth of information about the type of methods and approaches that can be utilized to collect, describe, and disseminate such information. The purpose of this chapter is to highlight some of the available approaches and to clarify and enhance the methodological underpinning available to researchers. The chapter begins by framing IS project failures in context, before highlighting the role of forensic failure investigation and the typical tools employed in gathering information. It encourages a move from case studies to case histories to capture the essence, dynamics, and complexities of failure stories. It concludes by introducing a new range of ante-narrative approaches that represent future developments in the study of IS failures, enabling a richer interpretation of linked factors that underpin IS failures.
Chapter Preview
Top

Background

The popular computing literature is awash with stories of IS project failures and their adverse impacts on individuals, organisations, and societal infrastructure. Indeed, contemporary software development practice is still characterised by runaway projects, late delivery, exceeded budgets, reduced functionality and questionable quality that often translate into cancellations, reduced scope and significant re-work cycles (Dalcher, 1994). The net result is an accumulation of waste typically measured in financial terms. For example, in 1995 failed US projects cost $81 billion, with an additional $59 billion of overspend, totalling $140 billion (Standish 2000). Jones contended that the average US cancelled project was a year late, having consumed 200% of its expected budget at the point of cancellation (Jones 1994). MacManus and Wood-Harper (2007) reported that the cost of software project failure across the European Union in 2004 was €142 billion. More recently, a McKinsey-Oxford survey of more than 5,400 software projects revealed that half of all projects significantly fail on budgetary assessment, while 17 per cent of projects actually threaten the very existence of the company, with the average project running 45 per cent over budget and seven per cent behind schedule, while delivering 56 per cent less functionality than predicted (Bloch et al., 2013).

IS failure investigations start with extensive attempts to collate relevant evidence. However, in most cases the researcher is exposed to specific information post-hoc, i.e. once the failure is well established and well publicised and the participants have had a chance to rationalise their version of the story. Most of the available sources are therefore already in place and will have been set up by agencies other than the researcher.

The purpose of a forensic investigation is to explain a given failure by using available information and evidence. The term Forensic is derived from the Latin 'Forensis', which is to do with making public. Forensic Science is the applied use of a body of knowledge or practice in determining the cause of death. Nowadays extended to include any skilled investigation into how a crime was perpetrated. Forensic systems engineering is the post-mortem analysis and study of project, product, artefact or service shortfalls and failures, which aims to uncover systemic and underpinning causes (Dalcher, 1994). The work involves a detailed investigation of a product or service, the underpinning project, its environment, decisions taken, politics, human errors and the relationship between subsystems. The work draws upon a multidisciplinary body of knowledge and assesses the project from several directions and viewpoints. The aim of forensic analysis is to improve the understanding of failures, their background and the dynamics that lead to them. The concept of systems is a central tool for understanding the delicate relationships and their implications in the overall project environment.

Key Terms in this Chapter

Case Study: Investigation of phenomena in naturalistic setting, conducted in order to enable an in depth analysis of that phenomena.

Storytelling: A method of communicating and sharing ideas, experiences and knowledge in a specific context.

Challenged Projects: Partially successful completed and approved projects which are late, over budget, and have fewer features and functions than originally specified. The degree of challenge depends on the way constrains are applied and interpreted within the organisation and the priorities and tolerance available in any particular area.

Antenarrative: The fragmented and messy and dynamic stories of real life in their original context before a clear narrative is developed to explain away a certain aspect.

Failed Projects: Projects that are: cancelled before completion, are never implemented or are scrapped following installation. May also apply to projects that involve significant litigation.

Complete Chapter List

Search this Book:
Reset