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.
Gotcha #2: Specifications Aren't Enforceable
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.
Gotcha #3: Scope Creep & Billing Surprises
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.
Gotcha #4: Paying For Non-Performance
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.
Gotcha #5: Getting Lost In The "Legal Bermuda Triangle"
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.
Gotcha #6: Loss Of IP Or Confidential Information
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.
Gotcha #7: Inadequate Data Security
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.
Gotcha #8: Missing Exit Strategies
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.