Client Alert: The 8 Gotchas of Technology Contracting - Part 2
This is the 2nd 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.
A prior installment addressed the 1st Gotcha: Using the Wrong Agreement to Structure the Deal, and the 2nd Gotcha: Not Making Specifications Enforceable.
Here are two more gotchas:
3rd GOTCHA: SCOPE CREEP AND BILLING SURPRISES
Once services begin, additional work is often desired by a customer or simply necessary. By analogy, a homeowner adding on a new room should expect that it’ll cost more and take more time if, mid-way through the work, she wants the room to be larger than originally planned or if the contractor tears away a wall only to find, unexpectedly, sub-standard wiring or rotten wood.
With multiple stakeholders, multi-layered projects, on-the-spot decisions and frequent adjustments, technology projects are often afflicted by scope creep and billing surprises.
A customer asking for extra or new services may be an amicable, agreed-to scope change – but unmanaged scope change results in scope creep.
For example, scope creep can happen when:
- a development, implementation, or other project begins with a vague description of what’s entailed – and subsequent descriptions for additional work don’t refine or make the scope more clear, or
- unplanned, often small changes (which by themselves may be manageable) pile up and, in the aggregate, are detrimental to project success.
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. The customer faces paying more and running late. The provider may be forced to perform work for free to keep a customer happy or may not be able to start another project on time.
Providers wary of scope creep rarely do a large fixed-fee technology project without a number of written conditions and assumptions. Hourly-rate projects are less problematic for providers, but often there are a “fee estimate” and “target end date” that have solidified in the customer’s mind as the “final cost” and “deadline.”
Following a written change-management process alleviates some of the ill-effects. Addressing who tenders change requests, how long they are reviewed, who approves them, etc., are good practices. Systematically documenting additions and changes 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. If the parties have a statement-of-work-type document, then change orders act as amendments.
Think of it this way: This 3rd gotcha will get you if you fail to answer these questions: How has it changed, and have the changes and their consequences been documented?
4th GOTCHA: PAYING FOR NON-PERFORMANCE
Even if you’ve avoided the first three gotchas by using the right agreement to structure the deal, identified appropriate specifications and documented changes, you still need to measure 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 more needs to be considered:
- Both parties also need to think about whether to stipulate what corrective actions are taken and what remedies there’ll be for failures: for example, a provider shall promptly re-perform deficient services to meet this standard, or if it can’t then the provider will refund fees for that service.
- Providers may want to indicate (and customers consider carefully) an “exclusive” remedy.
- Customers paying hourly rates may want to add that there’s no extra charge for corrective actions.
- Both will want consider whether there’s also a right to terminate if problems aren’t corrected or can’t be reasonably corrected.
For technology products: The issues are similar, but the parties should also have (if they’ve avoided the 2nd gotcha) specifications to use for criteria. Using a provision such as “the products will substantially conform with all applicable specifications,” these criteria can apply:
- at critical “milestone” junctures in a project
- at a final testing of all deliverables
- after acceptance during a warranty period
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. For example:
- a website will be up 99.9% of the time (subject to important exceptions)
- severity-level 1 support questions will be answered within 1 hour, 95% of the time each month
- credit card authorizations will occur within 1.5 seconds, 99% of the time each day
- a technician will respond on site to fix the equipment within two hours and will repair within four hours
Like carrots and sticks, service levels can incent good performance or punish bad performance. 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. Practical tip: Even if these remedies aren’t enforced, customer executives can point to these when confronting a provider about poor performance to help get the provider’s attention.
Some final cautions – For projects involving products covered by one agreement and services by another provider's agreement:
- The provider of the product will not want to tie its performance commitments or the customer’s payment obligations to the service provider’s performance (and vice versa).
- The customer needs to evaluate the risks of one provider performing, but another not. A classic example is the customer entering a software license with Vendor A and paying fees, but then having Contractor B not be able to install and configure the software correctly. Even if there’s a remedy against the Contractor, you’ve already bought and paid for the Vendor’s software.
Think of it this way: This 4th gotcha will get you if you fail to answer these questions: Have performance standards been established, and, if so, what happens if they’re not met?
____________
The first installment addressed:
1st – Using the Wrong Agreement to Structure the Deal
2nd – Not Making Specifications Enforceable
Look for the NEXT installments coming soon on the remaining Gotchas of Technology Contracting:
5th – Getting Lost in the “Bermuda Triangle” of Representations, Indemnities, and Limitations of Liability
6th – Allowing Intellectual Property and Confidential Information to Escape
7th – Inadequately Covering Data Security Standards
8th – Missing Important Exit Strategies
For more information, please contact Craig R. Auge at crauge@vorys.com or 614.464.5684.
