Patterns in IT Systems Failure Litigation: Introduction
[Adapted from Patterns in IT Litigation: Systems Failure (1976-2000)]
Progress, far from consisting in change, depends on retentiveness…Those who cannot remember the past are condemned to repeat it.
— George Santayana, Life of Reason
Few professions appear to embody the quote above as the history of development projects using information technology: computer hardware, software, data, networks, and all the other bits that go into such systems. That so many IT systems development efforts are inadequate, unacceptable, late or cancelled altogether has become cliché. However, the common factors that lead to IT systems failures have been well documented for over three decades. Classic software engineering works by Brooks, Weinberg, Yourdon, DeMarco, Gilb, Lister, and a host of others have spelled out the core issues that continue to plague IT development efforts in the 21st Century.
It shouldn’t be surprising, then, that a survey of litigation involving information technology from 1976 to 2000 likewise shows a remarkable consistency in the events and causes that lead to such legal action. The majority of these cases fall into the “systems failure” category: the computer software and/or hardware sold by one party to another either fails to work acceptably or never works at all. Analysis of the events and causes behind these systems failure cases yields a small set of consistent, repeating patterns. Parties entering into agreements about buying and/or developing information technology—which today means virtually every business or organization—should use these patterns as guideposts and warning flags to avoid the time and expense of litigation.
In these series of posts, we’ll lay out the patterns and issues commonly encountered in these cases, then make recommendations on how to reduce the likelihood and impact of such failures and the possible resulting litigation. Note, however, that these posts does not constitute legal advice; for that, see a professional.
One principal source of information in conducting this survey was the monthly periodical Computer Law and Tax Reports (“CLTR”). Staff at PricewaterhouseCoopers collected and reviewed data on cases cited in CLTR over a 25-year period beginning in 1976. We used additional sources to identify other cases and to supplement information gleaned from CLTR, including the yearly Overviews of Computer Case Law Developments and searches for computer-related cases on the CCH, Westlaw, and Lexis databases. However, we must point out that such a survey is neither exhaustive nor definitive. Because there are few standard legal keywords for such cases, blind searching for filings is difficult and yields little. Also, our own experience suggests that the majority of these cases settle before coming to trial or even before a summary judgment is issued.
Within these cases, we focused on those that fell under our classification of systems failure, that is, where one party believed that it had not received the promised benefits—in functionality, performance, and/or reliability—from the IT systems received from another party, if indeed those systems were ever delivered. We collected the information on such cases into a custom database.
The Core Issue: Quality
Gerald Weinberg defines quality as “value to some person(s).” When it comes to information technology, where one party (“vendor”) is to deliver some combination of IT products (“system”) to another party (“client”), there are several core quality values that must be addressed:
- Reliability: the system must carry out its functions without causing unacceptable errors or having an unacceptable downtime.
- Performance: the system must complete its various operations within timespans acceptable to the client.
- Functionality: the system must offer sufficient usable features to meet the client’s needs.
- Compatibility: the system must interact effectively with existing IT systems, including appropriate external systems under the control of other entities.
- Lifespan: the system must continue to offer acceptable reliability, performance, and functionality over a sufficient period of time to warrant the cost to the client, including in many cases having the ability to grow with the client.
- Deployment: the vendor must deliver and deploy the system, and the client receive its benefits (reliability, performance, and functionality), in a timeframe acceptable to the client.
- Support: the system must have the capability to be upgraded and repaired over time.
- Cost: the cumulative expense of developing, deploying, upgrading, and maintaining the system must appear to be justified in the eyes of the client.
The key word in these definitions is “acceptable”. Most IT systems failure cases surveyed involved claims by the client that one or more of these values were not acceptable for the system in question.
Patterns in IT Systems Failure Litigation
The systems failure cases we found fit with little effort into six overlapping patterns. For the sake of simplicity and consistency in describing these patterns, some standard terms will be used:
- Systems – the specific software, hardware, and/or other IT components in question.
- Manufacturer – the party that builds and/or develops the system or some of its components.
- Vendor – the party that sells and integrates the system (often the same as the manufacturer).
- Client – the party that purchases and uses the system.
The patterns shown aren’t mutually exclusive; in some cases, two or even three apply, and in other cases it’s a toss up as to which to select (for example, “Faulty Towers” v. “Never-ending Story”). More importantly, these few patterns can be used to describe virtually every case we found. They are presented below in roughly the order of frequency of occurrence within the survey results.
Finally, it’s worth noting that these patterns per se are not unique to information technology; these same problems arise in other areas of commerce. IT lends its flavor in the inherent challenges and instabilities of IT development projects, the lack of professional standards and practices, and the common misunderstandings and lack of information concerning IT found from time to time in intelligent and educated business professionals.
[end of extract]