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 Contract
