Systems Failure Litigation: Lessons Learned

[Adapted from Patterns in IT Litigation: Systems Failure (1976-2000)]

Having reviewed these cases and the patterns they exhibit, some practical suggestions come to mind.

Lesson 1: Get expert legal and IT guidance before signing anything.

Most of the legal pitfalls in IT business deals are well documented. Too often though, clients, vendors, and manufacturers sign contracts and agreements without having them reviewed by lawyers who understand IT-specific pitfalls. This may seem obvious, yet case after case in the survey focuses on the terms of signed agreements and the efforts by parties on one or both sides to find promises and protections that the courts find were never put in writing.

It’s also a good idea to run the agreement past technical people in relevant IT departments. For vendors and manufacturers, such people are likely to point out “overly enthusiastic” promises that the vendor might have difficulty keeping. For clients, such people can help spot flaws in technical commitments that relate to what is to be delivered and when.

Lesson 2: Specify critical terms and articulate protections before agreeing to a sale of goods or services.

In many of the cases we surveyed, one side or the other ended up losing because the parties failed to define important technical terms with sufficient specificity. When reaching agreement on what will be delivered and when, parties should endeavor to define clearly and in detail key terms. These include the various types of quality assurance (QA) that will be performed, the IT requirements that will need to be met for the client accepting the system, and the process for having the vendor/manufacturer deal with defects that show up after acceptance.

IT quality assurance aspects and activities that you could define and agree upon might include: expertise; guidelines and standards; metrics (measurements of progress); quality reviews; the various forms of testing; defect management; configuration management; and product release cycles, including technical support, maintenance, and upgrades.

Likewise, a good starting point for defining acceptance criteria is the list of quality attributes given earlier: reliability, performance, functionality, compatibility, lifespan, deployment, support, and cost. If both sides have a clear, written understanding in advance of what the system will and won’t do in each of those areas, the project has a higher chance of success.

Lesson 3: Act quickly when problems arise.

The foundation of both the “Faulty Towers” and “Never-ending Story” patterns is the client’s willingness to let the situation drag out for months or even years in spite of apparent repeated failures on the part of the vendor/manufacture to deliver or perform.

Why does this so often happen? Three factors, individually or combined, underlie this unwillingness to pull the plug on a project. First, the client may have a substantial monetary investment in the project and sees going forward as a better option than pulling out. Second, the executives and managers within the client firm who made the decision to acquire or develop the system in the first place often have a strong professional and personal interest in seeing it go forward and not having their original support for the project held against them. Third, migration off old systems that has already occurred may make going back difficult.

Even so, letting such projects go ahead as they are is almost always the worst decision. Case after case, both in our survey and in software engineering literature, shows that without direct and dramatic intervention, the client will end up spending more time and money in a project that in the end fails anyway. Instead, the client should document clearly the problems and attendant risks and consequences, then review them internally to determine the best course: proceed ahead, redirect the project (such as by scaling it back or changing the requirements), or cancel the project altogether. The client should then work with the vendor/manufacturer to achieve the desired goal.

Lesson 4: Remember that new technology entails risks.

The phrase “new technology” here refers to either relatively new commercial IT system offerings from a commercial vendor or manufacturer, or custom IT systems being built specifically for the client. While many IT system project failures stem from mismanagement or simple human failings, some founder on genuine technical issues: that which is being attempted may just not be feasible. Adele Goldberg, an IT software pioneer, has said, “Only optimists build complex systems.” One might amend that to read “build or buy”, but the corollary is that it is often optimists who end with project failures. Some healthy skepticism and caution, as well as a sober realization that large, complex IT projects have a high rate of late delivery or failure, should be taken into account when planning and negotiating the acquisition of such systems.

Conclusions

Most of the observations and recommendations made in this paper are common sense. That said, we have to ask ourselves why such common sense is so often set aside or ignored. The court documents and other literature on these cases don’t spell it out, but professional experience suggests that it largely boils down to human failings, ranging from naïveté to dishonesty.

The patterns of litigation involving information technology are readily identified. Judicious thought, consultation, and agreement on detailed terms, especially before entering into a legal agreement, will go a long ways to avoiding those patterns, reducing the risk of or need for a lawsuit. And that, in the end, is better for all parties involved.

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.