DATA CENTERS

8 Gotchas Of Technology Contracting

IT projects often involve multiple legal contracts for technology and services. Avoid these "gotchas" to ensure smooth agreements and relationships.

Photo source: Striatic via Flickr

Gotcha #1: Using The Wrong Agreement To Structure The Deal

There are many different types of technology products and services, and the form and coverage of technology agreements vary in crucial ways. Not starting from the right deal structure causes delays and unnecessary attorney fees, among other problems. Document titles for technology agreements are often misleading and may not be consistent with the basic nature of the transactions. For example, it may be called a "license," "platform agreement," "consulting contract," or "master agreement," but what's actually covered is a combination of particular products and services. Sometimes the forms themselves can be woefully outdated, causing confusion. And often there's a mix of related products and services from different providers that needs to be coordinated.

Look and ask questions on two levels: 1) Are you satisfied that the products and services are fully described? and 2) Do the business and legal provisions pertain to those products and services? If you fail to answer yes to either question, your agreement is not adequate.

First make sure you understand the goals of your transaction, and then prepare the right documents to support those goals.

Parties typically begin their negotiations for technology products and services by swapping emails, having meetings and calls, viewing demos, and possibly exchanging a Request for Proposal and a Response. And then the draft agreement comes. If the expected specifics on the functions, features, response times, conditions, and requirements that the parties discussed aren't fully reflected in the written documents, then they're likely not enforceable.

Attach any important conditions and specs from the pre-agreement process to the final agreement, or identify and expressly incorporate them. If there are documentation, rules, conditions of use, user manuals or parameters that are intended to be a part of the deal but are only described at the vendor's website, print them out and attach them to the final agreement.

Define specifications or label them, and then properly reference them in the agreement.

Meeting specifications and satisfying requirements are the criteria that should be used for important payment obligations and for remedies associated with milestones, testing and acceptance, and performance warranties.

Once services begin, additional work is often desired by a customer or simply discovered as necessary. With multiple stakeholders, multi-layered projects, on-the-spot decisions and frequent adjustments, technology projects are often afflicted by scope creep and billing surprises.

Highly susceptible to being over-budget and late, IT projects often grow, unofficially and slowly. Typically, neither the provider nor the customer ends up happy. Alleviate these ill effects by following a written change-management process that addresses who tenders change requests, how long they are reviewed, and who approves them. Systematically documenting additions and changes clarifies helps parties avoid later disputes.

Written change orders that are mutually agreed to by both parties are the tech industry's means to document new or different services, timelines and fees. Sometimes parties may agree to a less formal process, such as the exchange of clear emails between authorized representatives.

Even if you've avoided the first three gotchas, you still need to measure and pay or get paid for performance. Customers should avoid paying for non-performance, and providers should avoid over-promising.

For technology services: A typical short commitment is that the provider will provide the services "exercising due care and in a good, workmanlike manner." But that commitment may be too simplistic for complex projects. In addition, both parties need to think about whether to stipulate what corrective actions will be taken and what remedies will be available for performance failures.

For technology products: The parties should also have specifications to use for criteria. Whether hourly rate or fixed fee, parties often tie payment obligations to achieving milestones or testing acceptance. Another variation is retainage withholding some portion from each invoice until some final event or acceptance occurs.

For repeatable, measurable services: Another way to measure performance is by service levels. These need to fit the facts, and there's no one-size-fits-all. To be meaningful to a customer, performance needs to be regularly reported and remedies need to be specified, such as credits, refunds, or rights to terminate. These remedies may apply to acute one-time service-level failures, consecutive failures, or some aggregation of types of failures.

You'll need a map to navigate through the Legal Bermuda Triangle of three key, interrelated provisions in nearly every technology agreement: representations, indemnities, and limitations of liability.

Corner 1 -- representations: Customers should strongly consider asking their vendors, providers and contractors to commit that the technology product or service being provided won't infringe a third-party's intellectual property; it has rights to grant any licenses; it will comply with all applicable laws; and it has appropriate data security, if any important data is being exchanged or hosted.

Corner 2 -- indemnity and defense: Think of the indemnity provision like a type of insurance for the more important risks. It can cover damages, losses and even attorneys' fees associated with breaches of representations (like those listed above) or other specified events.

Corner 3 -- limitations of liabilityand exceptions: Typically one of the more heated parts of a negotiation, limitations of liability provisions don't have to be in agreements but they almost always are. Commercial parties can agree, upfront in their agreement, that their liability is capped at some dollar amount. The other common limitation is an express exclusion of certain types of damages.

After these are established, the parties rightfully wrangle over exceptions to these limitations, such as instances in which an indemnity obligation applies or confidentiality obligations are breached.

IP and confidential information are the "crown jewels" of companies providing or obtaining technology products and services. Copyrights, patents, trademarks, trade secrets (customer lists, for example), and data can be proactively protected in your agreements.

And you can "lose" IP by never owning in the first place. For example, a customer wanting to own the IP created by a contractor, such as copyright in software developments, will need an express written assignment from the contractor.

Confidential information must be protected with non-disclosure commitments, but you need to expressly restrict how the other party can use your information as well.

Companies that are subject to specific legal and industry data protection and security standards must ensure that their service providers are meeting those same standards.

The types of data, where the data resides, and who will touch the data are critical elements in determining the type and level of security needed. You'll also need to ensure industry and governmental regulations and standards are met. Consider obtaining from the providers their relevant audit results, reports, certifications and other commitments to evaluate their ability to comply with security requirements.

Few like to plan for the end of a contract before it even begins. But walking through exit strategies and covering termination scenarios and being sure the contract reflects those are critical both to avoiding having to stay in a bad contract and, once terminated, easing later transitions to new technology.

Specific technology products and services concerns that complicate the end of contracts include: software that's licensed perpetually, but supported on an annual basis; subscription models (such as many Cloud, SaaS, and ASP models) that have annual or monthly terms; services that terminate based on service-level failures; and "master" agreements with other components that should continue. Data is another consideration. When the agreement is over, determine whether data will be destroyed or returned (and in what format), and how that will be handled.

Lindsay, thanks for your comment. I agree this is really practical advice. Especially because for technical projects, often the people making the agreements aren't aware of all the legal details that should be covered. I know I've been in that position before and signed a contract I wasn't 100% sure of :P

This is clear, comprehensive contract guidance. There are so many ways organizations can trip up when it comes to contracts. I like the advice about having a written change mangement process to combat scope creep, and also the tip on avoiding the "legal Bermuda Triangle."

Agreed, the SLA is where all the action takes place, this is why it is important to have all aspects covered. Create a blank SLA and go through points 1 to 8, once point 8 is complete, review the entire SLA again to find conflicting situations.

If the Cloud service provider is a large player that delivers services to SMB, then the SMB might not have the necessary scale to negotiate a change. In this case, the client can begin by reviewing the SLA and enable only those functions that are required. The plus point is that a client might find a function that they did not know existed. Often times, it is best to deal with a large provider, if things become complicated for the business to handle, then a contractor can be hired.

Brian, you raise an important point about SMBs that may not have the resources for full contract negotiation. I also wonder how often organizations run into "click wrap" agreements that don't leave room for changes.