Whether requiring assistance for Y2K compliance, computer network development, or accounting or inventory systems, virtually every company will, at some time, require the services of a technical consultant or system developer.
Technology systems have become the lifeblood of business operations, and failed or inadequate systems can have a dramatic effect on a firm’s bottom line, unless you take the right precautions from the beginning.
Although not a panacea, well-drafted agreements as part of a systematic approach to the implementation of new technology can help minimize both the likelihood of a catastrophic system failure and the resulting harm.
Agreements that address such technology services should not be drafted in a vacuum, however. Technology agreements are most effective if they reinforce sound technology practices, rather than pose unrealistic or unworkable terms. A contract that articulates the parties’ responsibilities with respect to each step minimizes the risk of protracted and costly disputes because it will require the parties to create benchmarks as the project proceeds.
A well-structured contract, moreover, makes clear that both the designer or consultant and the client bear responsibilities for the success of a project. The duties of the consultant are self-evident. The client, however, must recognize its obligation to provide clear directions respecting its requirements for the proposed system, and the risks (and, possibly, additional cost) associated with changing the project mid-stream.
Contract structure
The starting point for developing the parties’ respective obligations is an understanding of the basic structure of the deal. Do the parties contemplate services to be provided on an hourly or time-and-materials basis, or do they contemplate the delivery of specified software, systems, or other materials? The structure of the deal will affect a variety of contract terms, such as warranties, remedies, termination requirements, etc.
From the client’s standpoint, a contract based on “deliverables” has much to commend it. Payments can be structured to assure progress of the work until completion. In addition, the agreement itself (and supporting materials) enables the client to assess the consultant’s performance.
In general, time-and-materials contracts make most sense with respect to projects of indeterminate scope and duration. Confidentiality, termination, and nonsolicitation are often among the key terms of such agreements with employees.
Key terms
Once the parties have established the structure of their relationship with respect to contracts for deliverables, the agreement should address the following:
Timing of payments and project acceptance. In general, contracts for deliverables provide for a schedule of payments based on the date of delivery and/or “acceptance” of the project (or portions thereof). To avoid disputes over the date payments become due, agreements should clearly articulate the terms for completion of the assignment. Often, a software agreement will allow for payments to become due only after the project is “accepted” by the client after having the opportunity to test it.
Ownership of work and intellectual property. The pricing of a deliverable may depend on whether full ownership will be transferred to the client or just a license. (Under a license arrangement, the consultant would generally be able to sell the same deliverable to other clients.)
Project assumptions/change of scope. Perhaps the greatest source of disputes between technology suppliers and clients stems from their different, but unstated, views on the underlying project assumptions and the pricing that results. The best way to avoid such disputes is to require the parties expressly to identify the assumptions or conditions that form the basis for the project’s pricing. Moreover, the agreement should provide a mechanism for revising the pricing if the assumptions are not met.
The only effective way to avoid disputes over responsibility for project changes is to address them as they arise. The agreement should require all project changes to be agreed upon in writing. Work performed absent such an agreement should be presumed covered under the initial terms of the deal.
Warranties. Most agreements disclaim implied warranties of merchantability and fitness for a particular purpose because they may impose uncertain duties on the consultant. The warranty is often tied to meeting performance specifications identified in the agreement itself. Such a warranty reiterates the need for a clear documentation of specifications for the project.
Take, for instance, potential Y2K liabilities. Because of the substantial liabilities that may arise in connection with date changes related to Year 2000, every technology agreement should specifically address the warranties that will, or will not, be granted with respect to Year 2000.
Non-solicitation. Most businesses are keenly aware of the shortage of qualified technical personnel. To prevent a business from using a consulting engagement as a recruiting tool, most consulting firms require a clause prohibiting the client from hiring or soliciting members of the consultant’s staff. Although such nonsolicitation clauses are generally straightforward, care should be taken to avoid loopholes. For example, clauses should preclude the firms from employing or hiring the subject personnel as independent contractors.
Overall, a well-drafted agreement will reinforce an efficient working relationship between a technology consultant and the client. Although disputes are sometimes unavoidable, a clear statement of the parties’ respective duties can reduce the time and expense needed to obtain a resolution.
Gary Kaplan is a partner in the law firm of Reed Smith Shaw & McClay LLP. He has represented and counseled clients on matters concerning antitrust, international trade, intellectual property, government contracts, securities and economic regulation.
