While most studies in IS success are interested in defining or measuring the success itself, there are also studies in IS failure that usually looked for factors or causes of the failure. This posting will discuss concepts of IS failure and the two main approaches used to define IS failure.
Information systems (IS) failures have been documented extensively in the literature. Research literature in recent years has attempted to explain the reasons for and the impacts of an IS failure within organisations (eg. Beynon-Davies 1999; Poon & Wagner 2001; Southon, Sauer & Dampney 1999). The problem with this type of research about IS failure is that it focuses mainly on the reasons for and impacts of the failure and little is revealed about what the organizations did to recover after the failure. Furthermore, most studies were conducted on larger corporations and only very few for SMEs (e.g. Lees & Lees 1987). Arguably, the impact of IS failure within SMEs could be as significant as within larger companies or sometimes even worse due to the SMEs’ limited resources (Fink 1998; Welsh & White 1981). Accordingly, action taken after an IS failure could be a critical point for SMEs.
IS failure is a complex phenomenon that is difficult to define. There have been a number of efforts to adequately define the concept of IS failure since 1970 (Beynon-Davies 1999). The term IS failure itself is often influenced by the perception of people who are involved in it (Jiang et al. 1999; Keil et al. 2000; Peterson et al. 2002; Poon & Wagner 2001). While one group of researchers perceive the notion of “failure” in IS as termination of a project due to an unbearable accumulation of flaws, others consider failure as the inability of an IS to meet its stakeholders’ expectations (Beynon-Davies 1999). A flaw is a condition that if accumulated might cause the system to fail, but it can be corrected at the later stage at a cost or accepted at a cost (Beynon-Davies 1999). Accordingly, different organisations will behave differently when coping with IS failure within their organisations. Many of the definitions of IS failure assume that technology is neutral and unproblematic (Mitev 2000) as stated by one summary that defined IS failure as (Wilson & Howcroft 2002):
‘System failure is constituted by the system not working properly: it does not perform as expected, it is not operational at the specified time and it cannot be used in the way intended’.
This definition, however, does not portray the full complexity of IS failure as a combination of technology and social issues.
Two approaches related IS failure to the social and organisational context (Beynon-Davies 1999), namely the concept of “expectation failure” (Lyytinen & Hirschheim 1987) that was later broadened by Lyytinen (1988) to distinguish between “development failure”, and “useage failure” with the concept of “termination failure” (Sauer 1993).
Lyytinen and Hirschheim (1987) identified four major categories of IS failure. Lyytinen (1988) argued that stakeholder groups might recognise failure in either the development or the use phase. In the development phase, the stakeholders try to fit the IS development process to their interests, while in the use phase the stakeholders endeavour to align the IS with their ongoing concerns. Ewusi-Mensah and Przasnyski (1994), while supporting Lyytinen’s idea, argued that IS failure is better defined as failure in IS usage or operation, whereas failure in the development of IS should be called project abandonment. The project abandonment itself can be categorised into three different types:
- Total abandonment is where all project activities are terminated completely before implementation.
- Substantial abandonment is where major modification occurs to the project that makes it significantly different from the original specification before implementation.
- Partial abandonment is where the original specification is reduced without resulting in major changes before implementation.
Sauer (1993) portrays IS development as an interaction of project organisation, supporters and IS arranged in a triangle shape. The project organisation depends on its supporters for the provision of support. Supporters depend on IS for benefits, and IS depends on the effort and expertise of the project organisation to sustain it. In this model, the IS development process is open to flaws, defined as an undesired problem that needs to be solved. The flaws need to be corrected within an acceptable cost range. When flaws are not adequately dealt with, they might reduce the capacity of the IS to serve its supporters and might introduce new flaws into the systems. At some stage the accumulation of flaws might trigger a decision to stop support and terminate the project. Accordingly, IS cannot be deemed a failure until the development or operation ceases and the supporters are dissatisfied because the IS no longer serves their interests. This is what Sauer referred to as termination failure.
Sauer’s definition of IS failure is somehow narrower than Lyytinen and Hirschheim’s that the failure is caused by an unbearable accumulation of flaws as a result of interactions between the three components of Sauer’s model. Even with a tolerable accumulation of flaws, IS failure still can occur when environment variables such as unfavourable government regulations or economic conditions influence the triangle interactions. Lyytinen and Hirschheim’s definition on the other hand provides a wider understanding of IS failure. The literature has shown the different definitions of failure and the stages where failures might occur (Ewusi-Mensah 1997; Lyytinen 1988; Lyytinen & Hirschheim 1987; Sauer 1993).
References:
Beynon-Davies, P. 1999, ‘Human Error and Information Systems Failure: The Case of The London Ambulance Service Computer-aided Despatch System Project’, Interacting with Computers, vol. 11, no. 6, pp. 699-720.
Ewusi-Mensah, K. 1997, ‘Critical Issues in Abandoned Information Systems Development Projects’, Communications of the ACM, vol. 40, no. 9, pp. 74-80.
Ewusi-Mensah, K. & Przasnyski, Z.H. 1994, ‘Factors Contributing to The Abandonment of Information Systems Development Projects’, Journal of Information Technology, vol. 9, no. 3, pp. 185-201.
Fink, D. 1998, ‘Guidelines for The Successful Adoption of Information Technology in Small and Medium Enterprises’, International Journal of Information Management, vol. 18, no. 4, pp. 243-253.
Jiang, J.J., Klein, G., Balloun, J.L. & Crampton, S.M. 1999, ‘Systems Analysts’ Orientations and Perceptions of System Failure’, Information and Software Technology, vol. 41, no. 2, pp. 101-106.
Keil, M., Wallace, L., Turk, D., Dixon-Randall, G. & Nulden, U. 2000, ‘An Investigation of Risk Perception and Risk Propensity on The Decision to Continue A Software Development Project’, The Journal of Systems and Software, vol. 53, no. 2, pp. 145-157.
Lees, J.D. & Lees, D.D. 1987, ‘Realities of Small Business Information System Implementation’, Journal of Systems Management, vol. 38, no. 1, pp. 6-13.
Lyytinen, K. 1988, ‘Expectation Failure Concept and Systems Analysts’ View of Information System Failure: Results of an Exploratory Study’, Information & Management, vol. 14, no. 1, pp. 45-56.
Lyytinen, K. & Hirschheim, R.A. 1987, ‘Information Systems Failure: A Survey and Classification of The Empirical Literature’, in P.I. Zorkoczy (ed.), Oxford Surveys in Information Technology, vol. 4, Oxford University Press, Oxford, pp. 257-309.
Mitev, N. 2000, ‘Toward Social Constructivist Understanding of IS Success and Failure: Introducing A New Computerized Reservation System’, in Proceedings of The 21st International Conference on Information Systems, eds S. Ang, H. Krcmar, W. Orlikowski, P. Weill & J.I. DeGross, Brisbane, Australia, pp. 84-93.
Peterson, D.K., Kim, C., Kim, J.H. & Tamura, T. 2002, ‘The Perception of Information Systems Designers from The United States, Japan, and Korea on Sucess and Failure Factors’, International Journal of Information Management, vol. 22, no. 6, pp. 421-439.
Poon, P. & Wagner, C. 2001, ‘Critical Success Factors Revisited: Success and Failure Cases of Information Systems for Senior Executives’, Decision Support Systems, vol. 30, no. 4, pp. 393-418.
Sauer, C. 1993, Why Information Systems Fail: A Case Study Approach, Alfred Waller, Henley-on-Thames.
Southon, G., Sauer, C. & Dampney, K. 1999, ‘Lessons from a Failed Information Systems Initiatives: Issues for Complex Organisations’, International Journal of Medical Informatics, vol. 55, no. 1, pp. 33-46.
Welsh, J.A. & White, J.F. 1981, ‘A Small Business Is Not a Little Big Business’, Harvard Business Review, vol. 59, no. 4, pp. 18-32.
Wilson, M. & Howcroft, D. 2002, ‘Re-conceptualising Failure: Social Shaping Meets IS Research’, European Journal of Information Systems, vol. 11, no. 4, pp. 236-250.