This article originally appeared in the January 2003 issue of The Rational Edge E-zine on-line magazine, copyright 2002-2003 IBM and Max Wideman.

The Rational Unified Process (RUP) is a rigorous software development process advocated by the Rational Software Corporation.

The downloadable PDF file of the paper on this site is the one prepared by the Rational Edge editorial staff with the special assistance of Ms Marlene Ellin.

Published here September, 2003.

PART III | Recap | Variables Involved in Forming a Contract
Selecting the Optimum Form and Type for Your Contract
Negotiating a Warranty | PART V

Negotiating a Warranty

In Part III of this series, we listed "software warranty" as an item to include in the head contract for a software project. The warranty deserves special mention, because it comes into play during the vexing period when software development is nearly complete and the dreaded "acceptance testing" process is under way. In "traditional" contracting it is common for the buyer to expect, and the seller to provide, a warranty on the materials and equipment supplied as part of the final product. In practice, warranty requirements are many and varied, but the most common requirement is that any defects in materials or equipment discovered during the warranty period will be fixed or replaced. Warranty periods for "tangible products" are typically one year.

An expectation of warranty is not unreasonable in the case of software development, except that the nature of software is a little different from that of material products. Software doesn't break or wear out in the same sense; it fails because of coding errors, or "bugs," attributable to latent defects that were either always present or introduced during correction of final functional deficiencies. The problem is that some defects may have been introduced as a result of the acquirer's request for an enhancement -- especially if the request came late in the development cycle.

There is no sure-fire way to resolve the discord that can arise in such situations. But provisions for compromises can be negotiated and written into the head contract. For example: perhaps a warranty period of short duration, such as three months, would be reasonable. During this time, the acquirer would be expected to thoroughly test the software for performance; after that period, any "fixing" would be at the acquirer's expense, at specified rates -- perhaps at-cost rates. Late changes might be specifically excluded from the warranty because there is a much higher risk of errors at a late stage, and on the grounds that the change should either have been identified sooner or held over until the next upgrade.

Another possibility is to include only a very modest warranty in the head contract and then negotiate a separate service and upgrade agreement as the project's final contract work order. As much as anything, a successful warranty period is a reflection of the trust and confidence that the two parties have built up in an honest effort to produce the product they originally agreed upon.

Next month, in Part Five of this series, we will describe how the workflow for acquisition activities fits into the Rational Unified Process.

Selecting the Optimum Form and Type for Your  Selecting the Optimum Form and Type for Your Contract

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page