Delivery vs. Installation vs. Successful Acceptance Testing

When should Customer be expected to pay for the new system?  (For this discussion, let's assume the system is a somewhat customized mix of hardware and software.)

When the system is ordered?  Perhaps, particularly if vendor is a reseller who must pay suppliers for the components.  Vendors may balk at fronting lots of money for customers.  The same analysis applies to paying upon delivery.  

But customer is left with a significant exposure.  What if some of the software disks are corrupted, or the hardware contains defective components?  Such deficiencies may not be detected until the system is assembled, installed and turned on.  Let's assume that when the power switch is thrown, something goes ZAP!! and a cloud of smoke rises from the system cabinet.  In an ideal world we would expect vendor to step up, identify the problem and make it right.  But we do not live in an ideal world and vendor may have moved on to the next project.  Requests for assistance might be met with suggestions that the problem resulted from user error, or recommendations to take up the question with the manufacturer.  (In fairness to vendors, we must acknowledge that some errors or failures may indeed be caused by the users.)  If vendor and manufacturers have been paid in full, customer has little leverage, little opportunity to compel them to pay attention. 

Which leads us to payments on the "installment plan": a portion upon order, a portion upon delivery and the bulk upon successful acceptance testing.  If a substantial portion of the contract price is held back until testing is complete, vendor will not lose interest in the project. 

Of course, vendors will not agree to large hold-backs if customer may arbitrarily decide not to pay.  It would not be good business to allow customer to refuse to pay simply because customer doesn't like the final product or now believes it "doesn't work."  As a result, to be successful, hold backs must be tied to testing standards that are mutually agreed and which can be objectively measured.  In that way, vendor and customer are both protected - customer can withhold payment if the system does not "work," while vendor must be paid if it does.

Some Shameless Self Promotion

DID YOU KNOW THAT:

The State of Wisconsin has written off $100 million in IT contracts?

Barnes and Noble is being sued for allegedly breaching a confidentiality agreement relating to its new electronic text reading device (the “Nook”)?

Novell and SCO have been involved in litigation regarding ownership of the Unix operating system since January of 2004?

Each of these is an example of a no-win situation. Reputations will be damaged, time and business opportunity will be lost. No one will be significantly better off when the dust settles (except perhaps for the lawyers handling the cases).

Yet such disputes and losses are not inevitable. We can train your personnel to negotiate and draft IT, IP and nondisclosure agreements that are clear, effective and which help ensure the success of the underlying projects. We call them “Contracts That Work.”

Topics include:

• Protection of trade secrets
• Proper identification and use of confidential information
• Ownership of intellectual property
• Payment schedules that help ensure performance
• Avoiding “project creep”
• Securing the rights that you need
• Getting the “best price”
• Avoiding unexpected delays and unforeseen charges

Sessions are limited to fifteen participants and can be tailored to address the specific needs of individual companies or units.

Contact us at thomasj.hall@gmail.com

About Tom Hall:

Tom Hall is formerly Of Counsel in the Nashville office of Baker, Donelson, Bearman, Caldwell & Berkowitz, PC. He was a member of the firm's business and technology practice group. He has over twenty years experience, both with law firms and as in-house legal counsel. He therefore possesses a unique understanding of the legal and business issues involved in IP and IT transactions.

Tom is co-author of three books on IT and IP matters:

Application Service Provider and Software as a Service Agreements Line By Line
Patent License Agreements Line By Line
Joint Development Agreements Line By Line

(All written with Kelly L. Frey, Sr. and published by Aspatore.)

Steps Towards a Successful ASP, Part 1

The Application Service Provider ("ASP") model has many attractions:

• Someone else pays for the hardware, software, maintenance, updates, etc.
• Subscriber pays a fraction of the total cost of implementation.
  
• Competition gives each provider an incentive to continually improve their offerings.

But there are also potential down sides. Someone else controls the:

• Hardware
• Software
• Personnel
• Security
• Back up
• Disaster recovery

If your ASP crashes, will it take along your critical processes?

Setting aside the worst case, there are other reasons an ASP may be unsuitable.

• A third part will be given access to subscriber's data.
• The services offered may not precisely meet subscriber's business needs or processes. Because many ASP business models are based on standardization and volume, provider may be unwilling to offer custom solutions for individual subscribers. In that event, is it cost effective for subscriber to revise its policies and practices to accommodate the proposed application?
  
• Provider, not subscriber, controls when and how changes to the application are made. If changes effect the "look and feel" of the application, subscriber may encounter unexpected costs and delays for re-training personnel. Alternatively, subscriber may not want the added features, and extra cost, of Version X +1, while provider may not want to continue to support Version X.
  
• In general, neither provider nor subscriber controls the transmission lines, creating an exposure - interruption - that neither party can fully control.
• Quitting a provider can be problematic. For example, will the provider simply block subscriber's access to the application or provide transition assistance. If assistance is provided, what will it cost?

Some of these concerns can be addressed through careful contracting, some cannot. If granting provider access to subscriber's data violates privacy laws, or if provider's business model does not allow for needed customization, no amount of brilliant lawyering will make the deal work.

What then, are the foundations of a successful ASP project? A full answer would require a book (See shamless plug below), but I can address some highlights here.

1. Due Diligence

As mentioned, if provider's offerings do not meet subscriber's needs, the relationship will be rocky, at best. But diligence must extend beyond matching needs to services.

• Is provider financially sound?
• Are its personnel adequately trained?
• Does vendor have all the necessary permits and licenses?
• Does vendor implement appropriate physical and logical security?
• Are appropriate disaster recovery measures in place?

It is important that subscriber verify this information before signing the contract. Afterwards, one can always sue if, for example, there is a disaster and provider does not have in place the recovery safeguards required by the contract. Subscriber might well recover money damages, but those will be cold comfort if he/she has been put out of business.

2. Interim Remedies

In fiction, at least, the appropriate response to any business disagreement appears to be "So Sue Me!" A better approach might be to build in "safety valves" to permit discrete disagreements to be resolved without derailing the entire project. Examples would be meet and confer requirements, permission to withhold payment of disputed balances and a narrow list of circumstances in which provider may suspend or terminate services.

3. Objective Standards

When will the application be available?
What processing speeds will be provided?
What response times will be accepted?
In what format will subscriber's data be stored?
In what format will reports and other output be delivered to subscriber?

To protect both sides, it is important that these and other standards be stated clearly and be subject to objective measurement. Without objective standards, subjective judgments ("It's too slow!") could put the project at risk.

4. Testing

We will purchase an auto after a 20 minute test drive and a house after a walk-through and home inspection (and a little haggling). Outsourcing business functions, however, merits more detailed examination. The more critical the processes, the more important it is to thoroughly test the application in the most realistic setting possible.

5. Business Continuity

If the provider's servers fail, will subscriber's business come to halt? Thus the need to verify that provider observes proper security, back up and recovery procedures. For truly critical processes, consider requiring a source code escrow (which must be kept current) or maintenance of a mirror site that could easily be taken over by subscriber.

We will explore these and other features of a successful ASP contract in greater detail in future postings.


This article is derived from "Application Service Provider and Software As A Service Agreements Line by Line," Kelly L. Frey, Sr. and Thomas J. Hall. Published by Aspatore Press, 2007.

Note - my friend and colleague Kelly Frey had no part in drafting this post. Any errors in it are mine alone.

"B" is for "Breach"

The term “material breach” is a familiar one. It appears routinely in contracts, generally in the termination provisions:Ether party may terminate this agreement if the other commits a material breach of any term hereof, and fails to cure such breach within thirty days of receiving written notice of the existence thereof.” At first reading, this provision appears to be clear, fair and easily enforced. It is mutual – it protects either party. It provides notice and an opportunity to cure, in the event the breach was inadvertent. It permits termination only for serious - “material” - breaches. But what is a “material breach”?

In the legal world, a breach is failure to fulfill an obligation set forth in a contract. A “material breach” is a failure so severe that it threatens the value of the entire contract. For example, if a customer orders one ton of steel, she will probably not want to terminate the contract if the vendor delivers only 1, 998 pounds, rather than the 2,000 expected. Vendor might issue a credit or refund or promise to deliver the missing material immediately. Or customer might overlook the missing two pounds as inconsequential. In contrast, if the vendor delivers one ton of brass rather than steel, customer may wish to cancel the order or terminate the supply contract. If we assume the customer needs the steel for an office tower, the brass simply will not suffice; it is simply not strong enough. Clearly a material breach.

Or is it?

Assume the contract says “metal,” rather than “steel.” Brass is a metal.

Assume customer wants to terminate the contract because she needs the steel immediately, and lacks the time to wait for vendor to deliver the correct product. Is timely and accurate delivery a condition of the contract? Is it a MATERIAL condition of the contract? Put another way, did vendor know that the contract required him to deliver the right product, at the right time?

What if the contract simply calls for “steel”? Does it matter whether vendor delivers the latest space-age alloy or a truckload of rusting auto parts?

Let's change industries. Customer orders a “computer.”

• Does it matter that the new device processes 16 million instructions per section, when the industry standard is 25 MIPS?

• Does it matter if customer paid a discount price?

• Does it matter if customer paid a premium price?

• Does it matter if the product is delivered “a little” late?

• That is “slightly” over budget? What is “slightly”?

• That it “doesn't quite” work? What is “doesn't quite”?

• That it runs fine as a stand alone, but won't interface with customer's systems?

• That it won't run customer's software?

• Does it matter whether that software is incidental or critical to customer's operations?

Lawyers have a method for finding answers to questions such as these. They call it “discovery.” It is one of the more expensive and time consuming parts of a lawsuit. If there is enough money at stake, vendor's lawyers will leave no file untouched, and no employee not-interviewed, in an effort to show that the alleged breach is not material – that the failure (assuming there was one) did not cause real and substantive harm to customer. Alternatively, vendor's lawyers will argue that the product or service complained about meets the standards set forth in the contract, or that customer never disclosed that requirement X would be central to the deal. Vendor's lawyers will suggest that, at best, customer is mistaken or confused; at worst they will suggest that customer is making a dishonest attempt to escape the contract, for whatever reason.

Which delivers us to a quandary: What is a drafter to do if the officially sanctioned term “material breach” is simply an invitation to dispute and litigation?

Change the definition.

The problem is not the term itself, but the meaning given that term by the law. But, in commercial contracts, laws, regulations, and legal definitions are generally DEFAULT provisions – they apply only if the parties do not set their own rules or definitions. (Within limits. A contract to commit a crime is still a crime, and unenforceable.)

Which of these provisions would you prefer to administer and enforce?

“Either party may terminate this agreement if the other commits a material breach of any term hereof, and fails to cure such breach within thirty days of receiving written notice of the existence thereof.”

OR

“Either party may terminate this agreement if the other commits a material breach of any term hereof, and fails to cure such breach within thirty days of receiving written notice of the existence thereof.

“For the purposes of this provision, 'material breach' shall mean....”

Admittedly, the latter is more difficult to complete. Each party must ask itself “What would cause me to want to call off this deal?” Then they must persuade the other party to include those provisions in the agreement. Both steps run counter to the common understanding of the deal process - “Get it done” and “Be positive.” A more realistic rule is probably “Be thorough.” The more time spent up-front spelling out the details of a deal – and identifying the key parts of the deal – the less time will be spent arguing about perceived failings.

Or, as our parents always taught us: “Get it right the first time.”

Copyright 2006, Thomas J. Hall. All rights reserved.

ACCEPTANCE TESTING

The project is complete. The hardware, bright, shiny and new is in place, with glowing lights and drives humming with new software. The vendor rep performs the initial log in, demonstrates a few features, pockets the last check and leaves. Over the next few days, problems begin to manifest:

• The new system is painfully slow to boot;
• The automatic backup feature will not run reliably;
• The system will not interface with two of your legacy systems;
• The system incorrectly calculates withholding taxes when printing paychecks.
  

The system commits yet another error and remits an incorrect amount of withholding taxes to the IRS;It completely corrupts the accounts receivable file.

Vendor sends in a technician, who announces that all is well with the system and attributes the difficulties to user error. He leaves behind a large bill for his time.

Could this situation - which is deliberately exaggerated - have been avoided?

• Certain questions come immediately to mind:
• What did vendor commit to deliver"
• What did customer expect to receive?
• What does the contract say customer was to receive?
• What performance standard does the contract specify?

In this instance, the contract refers only to “published specifications” and contains no testing procedures. Of all the safeguards that may be built into a contract, acceptance testing is perhaps the most important. They are the best way to ensure the deliverables:

• Performance promised; and
• Meet customer's needs.

To be effective, the performance standards and testing procedures must be:

• Mutually agreed; and,
• Objectively measurable.

Such acceptance procedures protect customer and vendor. Vendor is protected against a customer who, for whatever reason, wants to escape the contract. Customer is protected against a product that does not perform as customer needs and wants it to.

Vendors occasionally balk at acceptance testing. Not because they object to demonstrating the quality of their work, but because, typically, customers will withhold final payment until acceptance is successfully completed. Vendors, like everyone else, prefer to be paid in full, and as quickly as possible. Clear, objective standards can do much to overcome this concern. If the customer cannot withhold payment arbitrarily, then timely payment depends only on the quality of vendor’s work.

Acceptance testing will not ensure that a project will be on time or within budget, but it will do much to ensure that the final product will perform as promised, and as needed.