As appeared in the ABA Corporate Counsel Newsletter, April 2010.

For organizations buying or licensing new IT systems, this article gives contracting tips to help make the process a success

The successful implementation of an information technology (“IT”) system can provide extraordinary benefits for all organizations, including accessibility of organizational information, error reduction, greater efficiency, and financial savings. However, along with potential benefits, such implementations also have limitations and risks that must be addressed in any project or operation for it to succeed.

To realize the potential benefits while minimizing negative risks, organizations must be sure to make the wisest possible decisions when purchasing IT systems and associated services. Without smart decision-making at the beginning of a new project or operation, an organization is likely to have a troubled or failing project within one year to 18 months.

This article gives some key guidelines for organizations to follow when purchasing or licensing IT systems or services. It suggests ways for organizations to avoid pitfalls along the way and also gives remedies for problems, should they occur. While the article cannot address all the issues an organization may face in buying or licensing its technology, the suggestions below are consistently followed in the field. Technology projects can face numerous difficulties. Organizations that follow these suggestions, however, will have a much greater chance of success with their projects than those that do not.

1. Decide Whether to Build or License the IT System

Most organizations first define their “business” needs by identifying operations that require automation and then face the daunting task of determining which IT product or service can best meet those needs. Moreover, the organization must decide up front if it needs or wants to develop and own customized software or if a license will suffice. Unless the agreement specifies that the developer has transferred its ownership rights to the organization, the developer owns the software and the organization has only the licensed rights described in the agreement. If an organization does not own the software, it potentially could lose the rights it has under the license and/or be required to pay additional license fees whenever it expands the IT system to new sites or affiliates. If the developer is willing to give the organization some special benefit, such as a reduced price or a royalty from the developer’s licensing of the software to other parties, the developer may keep ownership of the custom software. If the organization agrees to this structure, it should insist on receiving an irrevocable (nonterminable), perpetual, worldwide, royalty-free license to use, reproduce, distribute, demonstrate, modify, and prepare derivative works based on the software for the organization’s (and, if needed, its affiliates') business purposes. Of course, the organization also must also determine whether the price for the product or service is appropriate.

2. The Organization Should Pay Only for Deliverables That Work

When developing software or providing other services or products, vendors usually ask to be paid a large percentage of the contract price up front (when the contract is signed). Under such an arrangement, the rest is then paid either monthly, based on services provided, or on delivery of the product. Despite pressure from the vendor to choose this option, the organization should try to pay only for acceptable deliverables and services, with payments made after the organization is sure that products and services meet agreed-upon requirements.

In drafting such a contract, there is usually some compromise between the vendor’s need to have some funds for technology as soon as possible—for paying hardware suppliers, for example—and the organization’s need to pay for actual products and to retain some funds until the product has been successfully tested. Since many organizations do not pay on contract execution as a policy, some amounts are typically paid after delivery and installation of a deliverable; organizations should retain a significant percentage of the total price, however, until the acceptance of deliverables or services. An additional percentage should be withheld until the entire system has performed successfully for 60 or 90 days after its acceptance. To further control costs, the organization should explore fixed fee pricing with respect to the deliverables and the services provided. Some organizations also seek to cap the vendor's expenses as a percentage of the total price.

3. The Organization Should Perform Its Own Acceptance Tests

IT systems often have serious limitations or fundamental flaws when first installed. A organization should therefore test new systems to confirm that they operate according to all necessary specifications. Typically, the organization’s right to test technology to confirm that it works correctly is omitted from a standard vendor contract. Although vendors prefer to have organizations accept and pay for installed systems without independent testing, organizations should perform their own tests on systems after they are installed to confirm their acceptability. The tests should be independently developed by the organization or a technical consultant to ensure that they are comprehensive and objective. In cases where the vendor develops the acceptance criteria and tests as separate deliverables in a large development contract, the organization needs to confirm that the system will be adequately tested for functionality and capability.

The acceptance tests should have defined periods for testing corrections of failures and retesting the system as a whole. For maximum flexibility and accuracy, the testing and correction periods for each deliverable should be delineated in a comprehensive work plan. This plan should also have a drop-dead date (a date by which the system must work in accordance with its specifications). If the technology does not work by the drop-dead date, the organization should have the option to terminate the contract, in whole or in part, or to require the vendor to continue to fix and retest the technology. If the organization decides to terminate the contract, the vendor must remove the technology and repay any money the organization has spent for the returned technology.

4. Specifications for Acceptance and Warranty Performance Should Be Objective and Absolute

Every system has written specifications or standards. System specifications should be defined as thoroughly and clearly as possible, because they will serve as objective performance standards for several aspects of the contract. These specifications set the standards that must be met before acceptance of the technology; they will also be included in the warranty, which should provide that the technology will continue to operate in accordance with the established specifications.

System specifications should include standard, published user and technical documentation, as well as all documents and standards relied upon by the organization in making its purchase decision. These additional documents should include requests for proposals, vendor proposals, brochures, and other standards that the technology must meet.

When developing or purchasing new computer systems from vendors, organizations often have the data from their old, legacy systems converted for use on their new systems. For an organization that does so, the converted data should be a separate deliverable if the vendor performs the conversion process. Specifications should in all cases include the successful processing of the converted data by the new system.

If the vendor is hosting the organization's data or if the organization accesses servers controlled by the vendor instead of downloading software on the organization's systems, the organization should include detailed performance standards as part of its system specifications. One performance standard is response time, which is the amount of time a system needs to perform a certain task: processing data online, retrieving data from a database, moving from one screen to another, or printing out a report. System availability, or uptime, is another performance standard. This measures the time that a system is fully operational. Again, the specifications should state that system availability will be at least 98% during the measurable period that the system is in use with permitted downtime for maintenance that occurs for a limited period of time outside of normal business hours. The contract should require the system to meet each response time performance standard. As discussed in more detail below, it is also important to have either service credits or liquidated damages tied to the vendor's failure to achieve such performance standards.

5. Acceptance or Warranty Standards Should Not Include Hedges

To soften their obligations to the organization, vendors typically ask organizations to accept systems that work “substantially” or “materially” in accordance with the specifications. Allowing such qualifiers or hedges into an objective standard, however, will severely limit the likelihood that the organization will receive the system it thinks it has purchased or licensed. Such hedges can also lead to arguments about what a system must do to meet standards substantially. It is smarter and safer to keep standard objectives, without qualifiers. Furthermore, acceptance of deliverables should be left to the discretion of the organization and its determination that the deliverables meet the acceptance criteria or specifications.

6. A Warranty Is a Promise That the Vendor Must Keep

For technology purchases, the most important warranty is that the system will operate in accordance with the established specifications. The warranty may be limited to a certain period, such as one year from acceptance of the entire system for large purchases.

The standard remedy for a breach of warranty is for the vendor to repair or replace the system, in part or in whole, at no additional cost so that the system operates in accordance with the specifications. (The warranty should require more than “reasonable efforts” or “best efforts” to repair.) Although vendors usually do not charge separately for their warranty services, costs for these services are bundled into the overall system cost.

If a vendor cannot satisfy its warranty obligations, the organization should have the right to terminate the agreement and receive a full refund. The repair, replacement, and refund remedies, however, should not be the exclusive remedies for a breach of warranty, because the organization is likely to incur more financial harm than can be covered by the refund of amounts previously paid. The organization should therefore be entitled to pursue other remedies, such as receiving its actual damages.

The vendor should warrant that the system being purchased by or developed for the organization will comply with all federal, state, county, and local regulations, statutes, guidelines, and codes. It is also important for the vendor to guarantee that the system will contain no viruses, malicious code, bombs, or disabling devices.

7. The Vendor Should Provide a Firm Schedule for Performance of All Obligations

A successful project will have a detailed work or project plan for the entire system, including a subplan for each subsystem that the organization intends to install. The plan should contain firm dates, developed in cooperation with the vendor, for such important events as delivery, installation, conversion, the beginning of acceptance testing, and project completion.

Although vendors do not want to be held to firm deadlines and try to have the schedule include estimated dates, organizations should be able to receive definite schedules from vendors, provided that the dates are reasonably negotiated. Once a schedule is set, the contract should state that time is of the essence for the performance of the vendor’s obligations to ensure that the dates are firm and that the project will proceed on schedule. If the vendor needs some flexibility—for minor events that do not affect a key date, for example—a “best efforts” requirement may be set for certain events. In such cases, the organization should always be sure to add a deadline and a “time is of the essence” standard for the specific dates that the vendor must meet.

8. The Organization and the Vendor Must Manage The Project Carefully

Unmanaged projects fail. Both the organization and the vendor must carefully manage their parts of the project. This means that the organization cannot abdicate full responsibility to the vendor, even if the vendor claims to be an expert and promises to be able to complete the project as stipulated in the contract. The organization has to fulfill its obligations actively, and it has to make sure that the vendor does the same. Project managers should be identified in the contract or statement of work and the vendor should be required to notify the organization if the vendor is not receiving adequate support or assistance from the organization's personnel.

Organization management tasks include requiring the vendor to stay on schedule every day, or update the schedule in an acceptable way; attend meetings; provide weekly and monthly reports; fully staff the project; make decisions in a timely manner; stay within the scope of the project; perform change orders as needed; and perform its other obligations. Without constant vigilance and full support and oversight from the highest level of organization management, the project will flounder and ultimately fail.

9. The Organization Should Negotiate the Terms of Maintenance Services When Purchasing Technology

Vendors often wait until after a system is installed and operational to negotiate terms of maintenance and support services. If the organization allows the vendor to wait until after the system is operational and in the warranty period, the organization will lose its negotiating leverage and much of its ability to determine the terms for maintenance and support.

The organization should negotiate maintenance terms at the time of purchase, when it will be able to obtain significant support concessions. (A year or more later, the organization will not have as strong a bargaining position.) Since maintenance agreements generally cost 15 to 20 percent of the initial purchase price and since organizations effectively repurchase the technology as five years of use, maintenance agreements are as important as the purchase agreements.

Descriptions of maintenance and support should be as detailed as possible. They should include clear definitions of failures that require maintenance services, vendor response times to standard telephone inquiries, caps on price increases, training levels required of technicians providing maintenance support, levels of support to be provided in the event of a total system crash, credits for failures to respond in a timely manner to maintenance requests, and access to a toll-free support number that is available 24 hours a day, 365 days a year.

If the vendor operates the system or the organization’s equipment does not change, the same performance standards should apply during the maintenance period as during the warranty period. Other warranty standards, such as the lack of disabling devices, should also apply during the entire maintenance period.

10. The Contract Should Anticipate and Describe Remedies

Technology projects do not always proceed as planned. When the projects falter or fail and organizations must attempt to resolve differences with vendors, they turn to their contracts for possible remedies. Remedies are designed to compensate an organization for harm caused by a vendor or to provide an organization with solutions for problems with a vendor. Remedies are not always easy to exercise, and they do not always solve the real problems that an organization is experiencing. Typical remedies in large technology agreements include free hardware for performance standard failures, termination for default or convenience, and software escrows. These and other remedies are described in detail below.

Liquidated damages are damages that are enumerated in the agreement for specific failures. The vendor may have to pay a certain amount of money for each day it fails to achieve system acceptance past the agreed-upon date or a fee for each failure to meet a response time performance standard. Liquidated damages are generally required to be compensatory, not punitive, so they should reflect the foreseeable amount of harm that the organization will suffer as a result of the vendor’s performance failure. Although the prospect of having to pay liquidated damages may theoretically cause a vendor to perform as required, an organization often does not truly have the option of demanding these payments because the organization, or an event outside the vendor’s control, has caused the vendor to not perform its obligations. Organizations that include liquidated damages in their contracts should be aware of this fact and realize that they must perform their own tasks on time and only impose liquidated damages when appropriate.

Most organizations exercise the common-sense remedy of temporarily withholding payments from nonperforming vendors until they perform all of their obligations up to standard. Sometimes an organization may even withhold payments for acceptable work if the vendor is in default of another obligation. Unless this withholding remedy is included in the contract, the organization may place itself in breach of the contract by not making payments to the vendor for acceptable work. Such withholding should therefore be included in the contact as a standard remedy.

A setoff is the permanent reduction of payments that would otherwise be made to a vendor. The reduction is made based on the organization’s reasonable estimate of how much it has been harmed by the vendor’s breach of contract. A setoff can be a useful way to compensate an organization for the harm it has suffered, although the vendor is almost certain to contest the reduction. The organization should only exercise setoffs in appropriate circumstances.

If the vendor is not performing its obligations as required by the contract, the organization should notify the vendor of its defaults. If the vendor does not them correct its failure to perform within the period specified in the contract, the organization should be entitled to terminate the contract and pursue its available remedies, including recovering monetary damages. Although termination is a severe remedy and should only be used when a project has completely failed, it is sometimes the only practical solution.

There will always be situations where an organization determines that it has to terminate a contract, but lacks sufficient cause to pursue a termination for default. Reasons for such a situation could include unexpected internal policy changes or shifts in organization management. Given that such situations can occur, the contract should include a provision that allows the organization to terminate the contract for any reason upon a specified number of days’ notice to the vendor. The contract should define a process for paying the vendor appropriate amounts (for example, for work accepted by the organization prior to the date of termination). The organization should avoid paying the vendor for all work performed at the vendor’s hourly rates, or even the reasonable value for the work, because the total amount may exceed the contract price.

Organizations also often require vendors to place the source code for licensed software into independent, third-party escrow arrangements so that the organizations can obtain copies of the source code under certain situations – for example, if the vendor stops providing support services or enters bankruptcy proceedings. The contract should delineate these “release” events and the rights that the organization has to the source code (for example, the right to modify and reproduce it for the organization’s internal purposes).

The contract should also provide for termination assistance from the vendor following termination or expiration of the contract so that the vendor will be required to provide reasonable assistance in transitioning the system to internal resources or a replacement vendor. This provision can be highly useful if the vendor would otherwise be uncooperative following an acrimonious termination.

11. The Contract Should Include Appropriate Indemnifications from the Vendor.

When one party gives another an indemnity, it is equivalent to making a promise to fully compensate the other party for harm it suffers, such as property damage, injury, or death. In arrangements with vendors that are installing sophisticated technology and using licensed software or creating custom software to operate the equipment, indemnifications against infringement or misappropriation of intellectual property are increasingly critical. Such indemnification should not be limited to United States intellectual property laws only, but should be worldwide and survive termination. In some contracts and depending on the sensitivity of the information available to the vendor, the organization receives general indemnifications against harm caused by the vendor’s acts or omissions (or by its negligence or willful misconduct), against the vendor’s disclosure of the organization’s confidential information, and against the system’s failure to meet all applicable statutes, regulations and guidelines.

12. Vendors Should Agree to Strong Confidentiality and Security Obligations

Prior to negotiating an agreement for the procurement of an IT system, the organization should determine whether the vendor will have access to sensitive personal information that may be subject to consumer privacy laws such as state security breach laws, the Gramm-Leach-Bliley Act (“GLBA”) or The Health Insurance Portability and Accountability Act (“HIPAA”). If the vendor will have access to the personal information of Massachusetts residents, extensive security obligations including encryption requirements will need to be included in the contract. Confidentiality, privacy and security provisions should include mitigation and indemnity clauses that survive any disclaimers and termination provisions in the contract. The confidentiality provisions also should include an appropriate definition of the information to be protected, background checks of vendor personnel if the vendor will have access to sensitive personal information, the standard of care to be used, a limitation on the purposes for which the confidential information may be used, and a clear statement of who will retain property rights in the information. In addition, a contract should contain specific notification requirements in the event that a party improperly publishes or discloses confidential information and should entitle the injured party to immediate injunctive relief without requiring a cure period. Furthermore, in the event of a security breach attributable to the vendor or its personnel, the vendor should be required to reimburse the organization for all costs arising from such breach including the costs of a forensic analysis, remediation and notification costs and fraud monitoring for the affected individuals.

13. Damages Disclaimers and Limitations Must Be Carefully Crafted

A damages disclosure is a provision that allows an organization to disclaim responsibility for consequential damages, among others. Damages limitations impose a total cap on damages recoverable under the contract. Organizations can usually include these provisions for themselves (or ask the provisions to be made mutual) whereas vendors typically include damages disclaimers and damages limitations for themselves.

If these provisions are included for the vendor, the vendor should still be liable for damages arising from its indemnification obligations, breaches of its obligations to protect the organization’s confidential information, and administrative and actual costs resulting form reprocurements. If the organization agrees to grant the vendor damages disclaimers or limitations, the contract should establish them clearly and then indicate that the provisions are not applicable to the types of damages described above that the organization wants to exclude form the provision. If the vendor cannot be held liable for the types of indemnification and other damages outlined above, the organization can end up being responsible for significant amounts of damages caused by the vendor.

14. The Organization Should Use Its Own Contract and Control Its Editing During Negotiations.

Every model contract has thousands of biases and presumptions that are, realistically, impossible to balance fully in negotiations. Instead of trying to edit the vendor’s model contract, the organization should use its own model contract. The organization should get comments in writing from the vendor about proposed contract revisions, agree to acceptable changes, and negotiate final terms carefully. As is true of model contracts, the language describing agreed-upon changes will have subtle biases, and the organization will want to control the drafting of new provisions and revisions.

Conclusion

Organizations purchasing or licensing and implementing new technology face a long and often difficult task. Before making the commitment to buy or license a new technology, organizations should obtain all possible protections, being sure to describe and detail them clearly in the contract. If its system fails, an organization should be sure that, when it rushes to the file to grab the contact, it will have a document that will provide solutions to its problems.