Client Alert: The 8 Gotchas of Technology Contracting - Part 1

This is the 1^st of 4 installments on tips when contracting for technology products and services.

Every business runs at least in part on technology – and, when contracting for technology products and services, the “gotchas” don’t discriminate based on size or industry.

Contracts for providing and obtaining technology establish important, often long-term relationships.  When they involve mission-critical products and services, the impact of a flawed contract can be devastating.  Imagine, for example, if it became impossible for a company’s customers or representatives to place orders.  Or imagine if a company invested in new infrastructure and hired new personnel, only to have a related software implementation fail.

Although buyers and users are more directly affected than sellers and providers, all parties can benefit from avoiding these gotchas.

1^st Gotcha:  Using the Wrong Agreement to Structure the Deal

You’re not contracting for a widget or simple service.  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 many 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 covered (or should be covered) could be for one or, more likely, a combination of the following:

• software licenses
• electronic payment
• development
• customization
• configuration
• implementation
• hosting
• maintenance and support
• websites
• databases
• hardware

Ancillary agreements could include agreements for:

• non-disclosure
• escrow
• open-source code
• and many others

Unlike other industries in which products and services don’t change as often or as quickly, technology businesses that draft form agreements have to pedal hard to stay up to speed with new technologies.  To keep up, busy vendors frequently take an older form and try to adapt it for a new or different product or service, often with confusing results. 

When the sales talks are over and you receive documents for the first time, you shouldn’t assume that the form contract and its attachments reflect your deal.  While there may be overlap between the old and new technologies, the differences can be critical.  Both parties are ill-served by such a form.

For example, what started as a form software license for on-site use by the licensee could have morphed into a form for Software-as-a-Service: the latter usually provides for related database hosting services, requires commitments on uptime, and has a different fee model and different remedies if problems occur.  Complicating this, the buzzwords change.  For example, today’s ubiquitous references to “the Cloud” have replaced earlier equivalents of “SaaS” and “ASP” from just a few years ago.

A true master agreement can often bear the load of a variety of technology services and products, but only if accompanied by statements of work detailing terms for particular services and by order forms or appendices describing terms for particular products.  Negotiating tip: In the heat of negotiations and project deadlines, it’s harder to react to what’s not covered at all than it is to react to what’s covered.

Often there’s a mix of related products and services from different providers that needs to be coordinated – a customer may be buying hardware through Reseller X, obtaining licensed software from Vendor Y, and having Contractor Z provide installation and on-going support service.  An agreement or set of agreements that fails to address all of these is inadequate.  One reseller, vendor or contractor may take the lead during negotiations, but there’s often “no one throat to choke” if there are multiple agreements with different entities and something goes wrong.

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?  Too often, the answer to the 1^st question is “no,” and the answer to 2^nd question is “not really.”  These aren’t good answers if there’s a later dispute and, even if there’s no dispute, could complicate day-to-day operations and expectations.

A good rule of thumb is that a college-educated person, who hasn’t been privy to what’s been promised in sales meetings or been involved in the negotiations, should be able to read your final contract and generally understand your deal. 

Think of it this way:  This 1^st gotcha will get you if you fail to answer initial, basic questions:  What is it, and does the agreement reflect that?

2^nd Gotcha:  Not Making Specifications Enforceable

Parties 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 specifics on the functions, features, response times, conditions, and requirements that the parties discussed aren’t reflected in the written documents, then they’re likely not enforceable.  Nearly every contract has a clause stating that nothing outside of that written contract can add to or affect the written terms. The prior significant scoping and negotiations efforts and related assurances don’t matter much at that point. 

What to do:

1. Attach any important conditions and specs from the pre-agreement process to the final agreement, or identify and expressly incorporate them.  Beware: This often creates some awkwardness and tension in the process if a party isn’t willing to stand behind the sales puffery or a party has unrealistic wish-lists. 
2. 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.  Don’t forget to address what happens if website versions change over time. 
3. Define specifications or label them, and then properly reference them.  For example, a broad definition of “specifications” might be “means the technical and functional descriptions, requirements, and specifications describing any deliverables and their operation, as set forth in the attached Work Statement or in documents referenced and incorporated therein.”  Or a more specific one might be, for example, an “Attachment on Features and Functionalities” that was culled from the RFP documents.  In the terms and conditions, be exact in how and when these are referenced.

Here’s why this is critical:  Specifications are criteria used for important payment obligations and for remedies associated with milestones, testing and acceptance, and performance warranties.  You may trust the salesperson or executive you are dealing with during the negotiation phase, but that person may not be with the company or in that position when it comes time to interpret what ought to be a spec-driven provision in the agreement.

Think of it this way:  This 2^nd gotcha will get you if you fail to answer the question:  What is it supposed to do?

________

Look for the NEXT installments coming soon on the remaining Gotchas of Technology Contracting:

3^rd – Scope Creep and Billing Surprises

4^th – Paying for Non-Performance

5^th – Getting Lost in the “Bermuda Triangle” of Representations, Indemnities, and Limitations of Liability

6^th – Allowing Intellectual Property and Confidential Information to Escape

7^th – Inadequately Covering Data Security Standards

8^th – Missing Important Exit Strategies

  

For more information, please contact Craig R. Auge at crauge@vorys.com or 614.464.5684.