Printer Friendly

Negotiating the computer contract.

Negotiating the Computer Contract

The new automated system has been working for one week. Your trained operating staff are pleased with the hardware performance; however, it has not yet processed 30,000 records with more than a 75 percent accuracy rate. Your organization was looking for a 99.5 percent accuracy rate within "X" seconds.

You call the vendor; the vendor's response is, "The system is working, correct?" "But," you say, "the sales rep guaranteed..." "Do you have it in writing?" "No, but..." There are no "buts," unless your contract with the vendor contained performance acceptance provisions.

The above scenario can be avoided if you take an active part in negotiating your computer contract. Even in today's sophisticated business world, most contracts for the acquisition of automated systems are not negotiated to the extent that they should be. Much of the dissatisfaction that occurs with the installation and use of automated systems in the customer's environment can be attributed to a contract that does not reflect the organization's requirements.

An analysis of a number of standard contracts reveals the following general characteristics. * Your costs may be increased at any time by the vendor with only a minimum of notice. Costs are sometimes decreased by the vendors. * The liability of the vendor is minimal (at best) and nonexistent (at worst). * The vendor has the right to determine when your system is operational and functioning (according to its specifications), even though the system might not actually be functioning according to your expectations. * The vendor has the authority to assign its rights and responsibilities to another party, but your organization has no similar rights unless approved by the vendor. * Delivery dates are not clearly defined, and the system may be delivered before your facility is prepared to install it, or it may be delivered after a critical deadline has already passed.

It is quite possible that no serious problem will arise when your system is installed, or during the time you use it, whether you negotiate your contract or not. Unfortunately, problems often do arise, even for the largest company. By negotiating a comprehensive contract and by conducting a thorough acquisition process, you and your organization will minimize adverse possibilities.

Acceptance testing

The single contract provision that is perhaps more important than any other is the acceptance testing provision. The primary point of acceptance testing is to provide a reasonable period of time during which the new system, including all associated hardware and other services, must operate according to some predefined standard of performance. The standard of performance usually addresses a minimum amount of work to be processed with a minimum of data errors in a pre-established period of time.

Four items to address specifically in the contract are that: * Acceptance is based on the requirements and expectations that you have identified in your planning process. Emphasis is placed on volumes of work, accuracy, interface capabilities, speed of processing, and compatibility with other components. * The test is conducted for a reasonable period of time to detect any deficiencies in the operation of the system. * The test is conducted by your employees using actual data supplied by your organization (for example, your own record formats, historical files). * Your organization retains the right to terminate the contract with no monetary obligation whatsoever if the system does not perform according to the predefined standards.

Acceptance testing provisions are even more essential in contracts requiring the development of customized software applications based on your particular requirements. The acceptance testing provision is probably the only "make or break" provision in most contractual agreements. If any vendor refuses to consider it, it might be wise to consider another source for your system.


The area of vendor warranties has always been one of the most difficult to effectively negotiate in any contract for an automated system. Considering the problems that a malfunctioning system can cause to a management firm heavily dependent on the system's successful operation, it is easy to understand why vendors are not too eager to make specific commitments.

Although the exact language differs among vendors, the intent is always the same: to reduce the vendor's responsibilities to a minimum.

Fortunately for the customer, some recent legal decisions have provided assistance by overturning the disclaimer provisions of the standard contract. These decisions have indicated that vendors do have a professional responsibility to propose systems that function in accordance with the unique requirements of each customer. This has not always been the result, however, and it is far better to negotiate provisions that either directly eliminate the restrictive provisions or effectively render them useless by clearly defining what your performance expectations are.

If you have conducted a comprehensive planning process, you can utilize that information as the basis for your desired performance expectations. If the vendor has made any statements (in its response to your RFP, in side letters, or the promises of salespeople), these should be included to demonstrate that the vendor did indeed have a knowledge of your specific requirements.

There are at least seven types of warranties that could be encountered in the negotiation of a systems agreement. The complexity of your system, however, will determine which ones are required. These are: * Warranty of operation. These warranties provide your organization with the vendor's assurance that its products will function with a minimum of problems and that your specific information and reporting requirements will be adequately addressed. Properly drafted, the warranty language should require the vendor to remedy any problems that might develop, at no cost to you, for a stated period of time. * Warranty of fitness for a particular purpose. Warranties of software ownership and of original development guarantee that your software vendor has not plagiarized your program and owns the right to sell or license it. The warranty of original development guarantees that the software is new work, not a modification of an existing program.

If your organization has inadvertently acquired a copied program, you may be required to remove it from your system or to pay another license fee to that original vendor. Although you would then have good cause for legal action against the guilty vendor, any attempts to collect may be futile if the vendor declares bankruptcy or just disappears. * Warranty of compatibility. The warranty of compatibility provides assurance that any new items you acquire will operate in conjunction with existing equipment you have in operation. Any promises of the new vendor concerning equipment compatibility must be thoroughly documented. * Warranty of new equipment or used equipment. If you are purchasing equipment as new, the vendor should guarantee that you are not being sold used items. Such a warranty is also important in qualifying for an investment tax credit. If used equipment is purchased, the vendor must guarantee that the equipment is operational and that it will qualify for a maintenance agreement.

Equipment maintenance

At one time or another, virtually every piece of equipment that you install will develop a problem that requires the provision of maintenance services.

The contractual terms governing the provision of maintenance can best be negotiated before you sign any contract for the acquisition of any new equipment. Your organization retains the negotiating advantage at that time because the vendor is still hopeful of completing the sale of the equipment. (Note: This situation occurs only when you intend to acquire both from the same vendor.) The worst time to attempt negotiations is after a system has been installed.

There are a variety of maintenance plans available to meet the special needs of any user. They can all be categorized in one of the following ways: * On-site repair by vendor personnel. * Off-site repair by vendor personnel. * Off-site repair at a centralized depot repair service to which you send malfunctioning equipment.

It is to your definite advantage to negotiate a maintenance agreement that clearly defines costs, responsibilities, personnel qualifications, response time, operating levels of performance, and continuing services before you sign.


of documentation

Almost all standard vendor contracts contain language that excludes any document or verbal statement that is not specifically incorporated in the contract. The purpose of this is two-fold: * to eliminate the possibility of any overzealous representations (either verbal or written) that might be provided to your organization by the vendor's salesperson; and * to expressly limit the vendor's responsibilities to those mentioned in the standard contract.

Since your decision to acquire a particular system has, in all probability, been directly influenced by vendor representations, it is essential that all pertinent statements be incorporated by reference or by attachment in the contract. Some examples are: * your "request for proposal" (RFP) submitted to the vendor; * the vendor's response to your RFP; * any specifications and performance sheets supplied by the vendor as an inducement to acquire its system; * all written documents between the parties which allude to services to be provided prices to be charged, and other items; and * summaries in writing of any verbal statements made by vendor representatives. For example, if free training was promised, but is not mentioned in any written document, list it in a "letter of understanding," and include that letter as a part of the contract.

Risk of loss or damage/insurance

The availability of insurance protection is simply a mandatory item in today's business environment. When applied to the system automation process, there are various types that provide financial protection against physical destruction, loss of data, personal injury, and theft.

Whatever the circumstances, you should always ensure that your organization does not pay for more insurance than is absolutely necessary and that you do not assume any risks that are not consistent with obligations you normally would accept for other areas of your business operation.

Some standard vendor contracts state that the risk of loss passes to you when the product leaves the vendor's shipping point. What happens if the product is destroyed in an accident? Should you be responsible? No! Ideally, you should not assume any liability for risk of loss until after the acceptance test has been passed Until then, the vendor should be responsible for all insurance costs to protect it.

If you rent or lease equipment, the vendor should provide all required insurance, as it is the actual owner of the equipment. Some contracts require that the agency renting or leasing the equipment provide that insurance.

On a third-party financing agreement for the installment purchase of equipment, insurance levels should be based on the "fair market value," and not the "original value" of the equipment. Since equipment has traditionally declined in value, there is no valid reason to maintain the additional coverage on the equipment. However, because the financing source wants to guarantee that all funds due under the contract can be recovered, this provision may therefore be difficult to modify.

Adequate levels of insurance should also be maintained by the vendor as a provision of conducting business with your organization. After all, the vendor's employees might very easily damage a component of the system, cause accidental injury to a person, or cause a loss of data through negligent software program modifications. Again, you should not be responsible.


The impact that unanticipated delays can have on the successful implementation of a computer system can be serious. Include language in the final contract that spells out as clearly as possible delay situations and actions that may be taken when they occur.

There are two general types of provisions that may be developed to address the problems of project delays. The first is liquidated damages. Most commonly these provide far the payment of an agreed amount of money when delays continue past a specific date; for example, "X" dollars for each day of delay beyond "Y" date. The primary purpose of a liquidated damages provision is to serve as a financial reminder to a vendor to adhere to the original schedule. All other things being equal, the project with a liquidated damages clause is more likely to get the vendor's attention.

Although the amount agreed to cannot be so extensive that it would be interpreted as a penalty payment (and thus possibly not enforceable), it must be sufficient to encourage the immediate action of the vendor and must also be related to the overall costs of the project.

The second provision to address the delay problem is that of contract termination. When you have negotiated a contract termination provision, you possess an excellent mechanism to minimize any deficiencies that might arise after the project has begun. The key to any termination for default clause is to list the causes for potential defaults and to document the vendor's responsibilities and your organization's rights.

It should be obvious, however, that to use either the liquidated damages clause or the termination for default provision, your organization must not be responsible for the delays. If you have not fully performed your responsibilities under the terms of the contract, the vendor may then have good cause to initiate some form of counteraction against you. That is perhaps the worst problem with provisions that are very specific; they sometimes cut both ways. Legal assistance should be sought to develop specific language in this area if you are not sure that you are adequately protected.

There is one other termination possibility for delays when neither party is at fault: the "force majeure" (or acts of God) provision. If, for example, a vendor's manufacturing ability is severely hampered due to fire, flood, or similar occurrence, neither party is at fault. Your organization however, might wish to obtain the desired products from another readily available source. The "force majeure" provision permits you to terminate the contract after a period of time specified in the contract has passed with no liability.

Termination for convenience

There are two types of termination for convenience: mutual termination and unilateral termination. The circumstances of each termination are very different, however.

When a termination for mutual convenience occurs, it is generally because both parties have agreed that the contractual relationship should no longer continue; therefore, it is essential that this agreement to mutually terminate be certified in writing, signed by the individuals with the authority to commit their respective organizations, and clearly specify that no further obligations remain.

Unilateral termination is a possibility that is not usually present in the standard vendor contract. When it is available, it usually belongs to the vendor and is associated with the nonpayment of funds by the customer (your organization). It is a particularly important provision, however, and should be a goal of your negotiation efforts, especially in any long-term project or in the development of customized software.

In a year's time, for example, the priorities of an organization might be modified due to management restructuring or changes in the market in which the organization operates. The "fantastic" system that you contracted for at that time may not be as important or pertinent today.

If a clearly defined termination for unilateral convenience clause exists, you can minimize further expenditures without risking the possibility of legal action being brought against your organization by the vendor for breach or default of contract. Of course, you will have to pay the vendor for work actually performed under the terms of the contract prior to the termination. Your organization may also wish to provide the vendor with a "goodwill" payment to retain that vendor's confidence for future projects.

There are some provisions that should survive the termination (or for that matter, the completion or expiration) of any contract. Such provisions are those that originally required confidentiality when the contract was in full force and effect. Generally, these include items such as confidentiality of customer information, any vendor/customer proprietary data or trade secrets, and vendor software source code. This is not an all-inclusive listing, and you might want to include anything that you think is necessary under the "survival upon completion" requirements. Again, try to think of the worst possible scenario and develop protective language.


There are hundreds of contractual issues that can be negotiated in any substantial procurement; my experience has demonstrated, however, that there are usually less than 20 items that affect the success or failure of an automated system. The emphasis is usually on the items that define price and performance responsibilities, such as an acceptance testing provision.

The primary goal of any contract negotiation is to eliminate problems common to standard contracts. In the process of addressing potential problem areas, you will hopefully be freed from a total reliance on strong legal language. Most vendors will abide by the terms of the agreements they negotiate with their customers, whether that negotiation results in the signing of the vendor's standard contract or a negotiated agreement protecting your interests.

However, careful wording of contract provisions in all vital areas helps ensure that both the contract negotiation and the long-term implementation and operation of the computer system are successful.
COPYRIGHT 1989 National Association of Realtors
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1989 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Nieman, William
Publication:Journal of Property Management
Date:Jan 1, 1989
Previous Article:Retaining tenants with the personal touch.
Next Article:Planning now for tenants with AIDS.

Terms of use | Copyright © 2016 Farlex, Inc. | Feedback | For webmasters