Pattern: Faulty Towers

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

Summary: The client buys the system from the vendor. The client then claims that the system is defective, i.e., it has errors during operation, crashes, and so on. The vendor makes attempts to repair it, allegedly with limited and unsatisfactory success. In some cases, the client ends up returning the system and acquiring a new one from a different vendor.

Causes: Unfortunately, quality standards among IT systems and projects vary widely. For reasons outside of the scope of this paper, IT manufacturers often develop, vendors often sell, and clients often buy IT systems with quality problems that most people wouldn’t accept in a minor household appliance, much less a software and/or hardware system costing hundreds, thousands, or millions of dollars. Likewise, the hidden and intricate nature of most IT systems—in particular, the ethereal nature of software—can hide defects and their root causes, even from IT professionals.

At the same time, there are cases where it appears that the client is claiming unacceptable defects in order to get out of a lease, contract, or other payment agreement. But what constitutes “acceptable” quality? No IT system, however well engineered, is perfect in all aspects, and the costs associated with increasing quality rise sharply after a certain level of quality is reached.

Recommendations: All parties to the IT project should agree ahead of time to specific expectations, promises, and contingencies regarding each of the areas of quality given above. For example, the system specifications should include not just the required functionality, but should also spell out any performance requirements or constraints, compatibility requirements, anticipated lifespan, and acceptable levels of defects.

Both parties should also clearly and unambiguously define key terms, conditions, and activities such as the meaning of “beta testing” or the standards for judging whether the client has accepted the system. In the IT world, accepting a system can occur at many different times, such as when it has passed a series of agreed-upon tests (“acceptance testing”) and has been in operation for a certain period of time with no serious defects appearing. If all parties are not willing or able to do so, that’s a strong warning sign that a dispute may well emerge. However, chances are the exercise of creating such a document will in itself flush out potential problem areas well in advance of any signing, payment, or delivery.

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.