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.)

Case Study – Wisconsin’s $100 Million Loss

Note: The promised piece on ASP and SaaS availability standards has been postponed for one week.


It has been said that IT projects are always late and over budget. The most commonly given reasons are:

• Vendor errors;
• Vendor misconduct;
• Changed circumstances;
• Unforeseen obstacles.

Regarding “vendor misconduct,” it is easy to find IT executives willing to believe that vendors deliberately under estimate cost and time requirements to win contracts, only to have the true cost become apparent as the project unfolds. Such “low balling” undoubtedly occurs, but more often vendor and customer must share responsibility for a troubled project. If “blame” is to be assigned, perhaps it should fall upon customers who ignore the ancient maxim: “caveat emptor.”

Remarkable examples of “how projects go wrong” are provided by the State of Wisconsin, which in late 2006 and early 2007 confronted a number of troubled projects, with an exposure of some $100 million. The figure is all the more significant when one considers that the State’s annual IT budget is roughly $400 million. A quick survey of the troubled projects will help set the stage:

• In 2006 the University of Wisconsin discontinued a program to update its salary and benefits system, after spending five years and $26 million.
• As of Spring, 2007, a new system to track unemployment taxes was 3.5 years late and $12.2 million over budget.
• A new voter registration system was more than two years late (i.e. ready two years after the deadline set by Federal law).
  
• New sales and use tax software required a $5.7 million fix.
• Work on a new system to track unemployment claims was suspended in February, 2007, after an expenditure of $23.6 million.
• A new system to handle automobile registrations was abandoned. It was at least a year late, $9.4 million over budget and had significantly increased wait times at the DMV offices.

This string of difficulties prompted members of the State legislature to request a formal audit by the Legislative Audit Bureau (Wisconsin’s equivalent to the Federal General Accounting Office). According to the Bureau, these projects had much in common:

• Failure to appreciate the complexity of the projects;
• Failure to define the final function of the various systems;
• Failure to observe contracting best practices, such as standard procedures and incentive/penalty clauses.
• Lack of leadership and oversight.

Significantly, ALL of these variables were within the control of the State.

As a case study, Wisconsin’s difficulties are rich in lessons, for it appears the State made virtually every mistake in the proverbial book. It made many of them repeatedly:

• Failure to realistically allocate resources;
• Failure to plan in detail;
• Failure to plan with an end in mind.

Of these, perhaps the most damaging was the failure to plan with an end in mind. Without a clear goal in mind, it is not possible to set meaningful specifications. In turn, an absence of meaningful specifications opens the door to “mission creep” as each user tacks on items from his or her wish list. Cost and time requirements can and probably will increase dramatically. Even without mission creep, ambiguous specs are a recipe for failure. Vendor may believe that customer wants and expects “X,” while customer is expecting something quite different. Unfortunately, the misunderstanding might not be discovered until late in the project, after much time and cash has been invested. Also, without clear specs, it is not possible to develop reliable cost estimates or time tables. In a very real sense, the various Wisconsin projects were not over due or over budget, for they had never been properly planned or budgeted. Quite simply, the State did not know what it was getting into, and paid the price.

Taken as a whole, the Wisconsin projects suggest an IT unit in disarray:

• Lack of necessary expertise;
• Lack of leadership willing to set reasonable expectations;
• Lack of uniform contract forms and contracting procedures to guide personnel who might not be versed contractual matters;
• Lack of oversight.

The lack of oversight bears special consideration. The various projects discussed here fell primarily within the responsibility of the Department of Administration (aptly known as “DOA”).  That department failed in its responsibilities because it was pre-occupied with two troubled tech projects of its own. A second level of supervision is, in theory, provided by committees of the State legislature. Those committees, however, have been inactive since at least 2005.

Wisconsin’s misadventures offer a sobering example of the many ways IT projects may go wrong:

• Failed leadership, leading to unreasonable commitments. These commitments led, in turn, to unreasonable expectations and burdens on personnel.
• Lack of a core of personnel trained in the art and science of managing large projects (not to mention negotiating large contracts). As a result, individual units were left to fend for themselves, with unfortunate and expensive results.
• Absence of standard forms and procedures to guide users when they were indeed forced to fend for themselves.

A word should also be said about the broader consequences of these difficulties. The responsible CIO has returned to the private sector and the State has represented that all is not lost – that portions of these troubled projects can still be put to productive use. In a private company, the results might have been more dramatic. Such losses, combined with the evidence of failed oversight and leadership, might well cause a wholesale dismissal of management, not to mention the possibility of shareholder derivative suits.
Whatever the political or economic consequences, Wisconsin illustrates the importance of professional, systematic management of IT contracts (indeed, of all contracts) and the importance careful, detailed planning by trained and experienced personnel.

Towards a Successful ASP Agreement, Pt. 2

Where Has All My Data Gone?

Microsoft and T Mobile are currently receiving lots of bad press relating to the loss of data from users of T Mobile's Sidekick device. Because Microsoft was essentially acting as an ASP for those users – storing data for them – this event raises some interesting questions.

What happens if my ASP loses my data?

That depends on whether the data is critical to the operation of your business. If you were using thousands of Sidekicks to run a world-wide enterprise, you would probably be out of business. In a more likely scenario, if you had out-sourced complex calculations or processing of a large volume of information, you might still face a serious business interruption. Orders may not be filled correctly, or on time, trading (or reporting) deadlines might slip past or payroll checks might not issue on time.

Of course “What happens if my data is lost?” is the obvious question. A better one is “What is the appropriate response to such a loss?” While the answer is obvious – restore the data – it begs a number of questions:

Who is responsible for the restoration?
Who will pay the cost?
Where will the information for the restoration come from?

According to media reports, in the Sidekick case both the main and backup databases were lost due to a server malfunction. From that it would appear Microsoft observed one of the main commandments of computing: Back up your data. Whether the back ups were made in an appropriate manner is not clear from published reports. For example, were the main and back up files stored on the same server, meaning that one failure would interrupt access to both?

User difficulties were apparently compounded by the fact they did not have copies of their data on their PCs or their Sidekick devices. They could not simply update Sidekick from PC (or vice versa) and continue with their lives while Microsoft and T Mobile sorted things out. They had put “all their eggs in one basket,” and lost the basket.

The lessons are not new:

Back up your data
Observe appropriate back up protocols (e.g. off-site storage of back up data)
Keep your own copies, just in case

What safeguards should I observe?

The first safeguard has just been mentioned – keep your own copies. The second is to require the provider to keep its own back ups, and to observe appropriate processes and protocols. At a minimum the contract should require back ups, and specify the protocols to be observed. Failure of provider to meet these obligations should be defined as a material breach of the agreement, constituting grounds for subscriber to terminate the contract. But mere words on the page may be insufficient, particularly if the data is critical, sensitive or protected by law. After all, the ink on the page will not rise up and compel provider to perform. Even a court order enforcing the written words might come only after significant, if not irreparable, harm, has been done to your business. The more important the information is to your business, therefore, the more important it is to verify provider's data protection practices before the contract is signed, and to inspect provider's facility periodically to ensure compliance during the contract term. To avoid any doubt or dispute on the question, the right to inspect should be written into the agreement.

Yet the ASP model contains an exposure not presented by the Sidekick occurrence – loss of functionality. Users could still access the various functions of their devices, but could not retrieve their stored data. But what if the software that enabled each device to communicate with the servers had failed? What if software used by your payroll processor abruptly doubles everyone's salary?

Mitigating this exposure in the ASP context requires a bit of care. Should subscribers require their providers to have off-site back up facilities, able to begin processing in the event a disaster strikes the primary site? Absolutely, if the provider is providing services critical to subscriber's business. Again, the need for careful drafting by counsel and due diligence by business personnel rises in direct proportion to the importance of the services. If provider cannot, or will not, provide such a mirror back up site, consider creating one of your own, complete with copies of the necessary software, licensed for use in the event of catastrophic failure by provider. (Care would also be needed to define what constitutes a “catastrophic failure”.) But if subscriber is compelled to create its own emergency back up site, is the ASP investment cost effective?

What are my remedies?

“What are my remedies?” is simply a polite way of asking “What does my provider owe me?” Assuming the contract has been properly researched, drafted and enforced, the answer should be “Nothing.” A failure at provider's facilities should pass virtually unnoticed by subscriber, certainly without loss of critical information or functionality. That would be an excellent example of a contract that works. After all, even if a court eventually orders provider to hand over a sack of money equal to the value of the interrupted services, it may be too little and too late to pay for your attorneys, lost business and loss of goodwill.

COMING SOON: Part 3 - When is a warranty of 99.7% availability a bad deal?

"B" Is For Boilerplate

Lawyers are fond of boilerplate language. It is quick to add, it covers a wide variety of exposures that might otherwise be overlooked and, since many of the phrases have been around for ages, the meaning is not likely to be debated. It is quick, it is easy, but it can also miss the mark.

Non-lawyers are now asking "What is boilerplate?" It is a lawyer-speak for language that is considered more or less standard in all contracts, such as a disclaimer of consequential damages: "Vendor hereby expressly disclaims any and all liability for consequential damages, whether or not foreseeable and whether or not Vendor was advised of the possibility of such damages." Boilerplate is generally found under the heading of "Miscellaneous."

Difficulties arise, however, when boilerplate is cut and pasted without regard for the transaction in question. For instance, this language comes from an agreement for custom programming service:

Each party to this Agreement shall keep in force during the term of this Agreement a policy or policies of insurance providing the following coverages in commercially reasonable amounts from reputable underwriters:...comprehensive automobile liability, covering all owned, hired, and nonowned vehicles of a party or its affiliates.

Setting aside the questions of what are "commercially reasonable amounts" and how to identify a "reputable underwriter," I am still wondering why auto insurance is relevant to this deal. If memory serves, customer and vendor met twice - when customer drove to vendor's offices. That would not create an exposure for vendor. After the work was awarded, all communications were via telephone, Web conference and email. I struck the language (and vendor agreed) because I saw no raise questions as to whether customer was carrying insurance that would contribute nothing to the deal.

Two of my favorite bits of boilerplate:

1. Mask Works

"Vendor claims all right, title and interest in and to, works of authorship, inventions, mask works, discoveries and other intellectual property created in the performance of this Agreement." But what is a mask work?

According to Wikipedia, a mask work is:

A mask work is a two or three-dimensional layout or topography of an integrated circuit (IC or "chip"), i.e. the arrangement on a chip of semiconductor devices such as transistors and passive electronic components such as resistors and interconnections. By extension, it also refers to the copyright-like intellectual property right conferring time-limited exclusivity to reproduction of a particular layout. The layout is called a mask work because, in photolithographic processes, the multiple etched layers within actual ICs are each created using a mask, called the photomask, to permit or block the light at specific locations, sometimes for hundreds of chips on a wafer simultaneously.

Clearly a mask work can be quite valuable, and such works are specifically protected by US law (17 USC Section 904). At the same time, mentioning mask works in a contract for custom database design merely invites question and confusion, without adding to the protections given to either party.

2. All Rights Anywhere In The Known Universe

"Licensor hereby retains all right, title and interest in and to the intellectual property anywhere in the known universe."

Yes, I have seen this language in genuine contracts. I generally reply that, to my knowledge, the Martians have not agreed to recognize American patents and copyrights. According to one of my very senior colleagues, this language started in a New York firm when satellite communications started to become common. The reasoning was that a radio wave continues forever and ever, and that the copyright owners need appropriate protection. Of course, broadcasts do NOT continue forever, but will eventually dissipate into nothing. More importantly, if the Martians ARE watching reruns of "Lucy" and "My Mother The Car," copyright claims would have to be pursued in Martian courts.

There are, as far as we know, no Martians or Martian courts, but the example is a useful illustration. Copyrights and patents granted in the US provide protection in the US, and not necessarily in other countries. If you plan to market your new Killer Application or Better Mouse Trap in the EU, China, and South America, make sure you have enforceable rights in each region or nation. A boilerplate statement that "Vendor reserves all intellectual property rights anywhere in the world," may simply not do the job if you will be doing business in a nation that requires special registrations or which does not recognize US grants of rights.

Boilerplate can be a drafter's friend, if he/she has a collection generally tailored to his/her field of practice. But both parties are best served if they read the boilerplate with the same care as the main business terms. After all, an error in the boilerplate may not be simply "harmless error" that will not disrupt the deal.

"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.

Are Your Contracts Litigation Waiting to Happen?

The law school definition of a “contract" is simple: offer, acceptance and consideration. I offer you $100 for a “car.” You pocket the money and hand over a set of keys. We have formed and performed a contract and all is right in the world. Unless I expected the keys to a Ferrari and received keys to a rusty, unreliable East German Trabant. You might say "My mistake, let me get the correct keys.” More realistically, you might respond “You want a Ferrari for $100? Here, take your money back; I can't afford such a deal.” If I insist that you took my money and are now required to deliver a Testarossa, you might respond: “So sue me.”

Our lawyers will begin shopping for vacation homes, while you and I start taking money from productive programs and setting aside time for depositions, discovery and hearings. Consider the vast array of issues our learned counsel may dispute:

• Was there a "meeting of the minds"?

• Was buyer simply mistaken or confused?

• Did seller mislead buyer?

• Would it be against public policy to enforce the deal as buyer understands it?

• Was buyer hoping to take advantage of a seller he thought to be unsophisticated (i.e. one who didn't know the true value of that “strange looking” foreign car)?

Of course, the fireworks may be short - circuited by an impolitic question from the judge: ''What does the contract say?''

You may have noticed that I have made no mention of a written contract. Therefore the case is merely my word against yours. Did you really offer a Ferrari for $100? Did I hand over my money without at least specifying what make and model vehicle I expected in return? This uncertainty explains the old legal proverb that “oral contracts are not worth the paper they are written upon.” Without a document setting forth the agreement, and without any witnesses regarding whether you offered me a Ferrari, the judge has limited options. She can tell me to accept the Trabant, or a similarly priced vehicle, or take my money back.

This example, although a bit extreme, illustrates the value of a written agreement. That document provides an independent source of information regarding the nature, extent and terms of the agreement. It provides a reference a third party – typically a judge – may consult when asked to enforce the agreement. As such, it forces the parties to focus on the details of the transaction. Winston Churchill once quipped that “there's nothing quite like being fired upon to focus one's attention." The business equivalent is being asked to sign a contract, to say, in effect, “I believe this document, this deal, represents a good deal for MY company." By signing, one also implies that "I have done my homework on this transaction and we are adequately protected."

Yet, even if our agreement for “a car,” had been put in writing, dispute would not have been precluded. We failed to define the “car,” to specify make, model, year, color, engine, interior, etc. We would have given our attorneys lots to argue over. Despite the risks that can result from a poorly prepared contract, drafting is often an afterthought. “We'll let the attorneys fill in the details later” may get the project started quickly, but it also creates a variety of potential exposures, such as:

• Lost savings opportunities;

• Late or flawed performance;

• Expensive, time consuming disputes over what is, or is not, to be delivered;

• Delivery of unsatisfactory services or final product.

A sound contract will tell a story, without any unanswered questions. It will identify who will do what, when, how, why, and for how much. It will also provide a “safety net” of remedies to protect the parties in the event something goes wrong. A contract that addresses both obvious and reasonably foreseeable contingencies is one with reasonable chances of success. In contrast, a contract filled with undefined terms and unanswered questions is a litigation waiting to happen.