"D" is for Damages

The project is late.  Your team leader had emergency surgery, an earthquake put the server manufacturer two months behind in deliveries and Customer did not tell  you about a  half dozen legacy programs written in Fortran that require customized interfaces to operate with the new system.  You have just received a polite message from Customer that each day of delay is costing $10,000 in lost opportunities, and would you please pay up.  Are you liable?

In this scenario, the answer is "Probably not."  The delay in receiving servers, and the illness of your team leader would be events beyond your control, and would be covered by standard force majeure language,  which reads roughly:

"Neither party shall be liable to the other for loss, delay or disruption caused by events or circumstances beyond the control of said party, such as war, natural disaster, labor unrest or government intervention."

As for the $10,000 per day, the contract should contain language that excludes liability for lost business, lost opportunities and lost profits. More than that, you can object that the claim is speculative, that Customer cannot prove that he would have realized the 10 grand per day but for the delay in completing the new system.  Courts do not like to make awards if the damages cannot be quantified with relative certainty.  

Another scenario:  You deliver the system on time and on budget.  Two days before the warranty expires, you receive a report that smoke is rising from the new server array.  By the time you arrive, the heat from the servers has set off the sprinkler system and everyone at Customer's data center is irate and dripping wet.  Worse, when the data center went down, it took Customer's national network with it, the switch over to a back up center having failed.  When the data center is back in order, Customer discovers it has lost ten years of vital statistical data.  An investigation makes it clear that the initial problem - the over heating, and then the fire in the servers, was caused by your team.  Someone did not follow the manufacturer's instructions.  What do you owe Customer?

Part of the answer is easy - new servers, or repair of the originals.  The force majeure exception would not apply, because this failure was one your team could and should have anticipated and guarded against.  The law calls such damages, which are the reasonably foreseeable consequence of an error or omission "direct damages."  Direct damages are typically recoverable to the extent needed to make the injuried party "whole."  


The meaning of "whole" can lead to much litigation.  In our example, must you:

• Provide Customer with brand new servers of the same model and configuration?
• Repairs to the original servers?
• Servers of the same model and configuration, but refurbished by a third party?
• New servers using a new generation of processors, which just came out and cost one third more than those you originally installed?

The last option - new servers with new processors can probably be excluded, as that would be a windfall for Customer.  He/she would be better off than before the failure.  But what if Customer wants the first option - new servers, and asks that you pay for them to be installed by your competitor?  Would the extra cost - paying your competitor - be a windfall to Customer or merely make Customer whole?  That is a question only the litigation attorneys would enjoy.  Thus a carefully drafted contract will provide that the remedy will be repair or replacement at vendor's option.  A very carefully drafted contract will also protect Customer - adding provisions to ensure that the work is done promptly and correctly.


What of the other damages - the network disruption, the cost of cleaning up from the sprinkler, the lost data?  The network disruption might turn on another question - why did the back up fail?  That is a question Customer needs to take up with its back up provider.  The lost data and the sprinkler clean up, however, are arguably "consequential damages" - they are indirect and unforeseeable results of the failure.  Consider: Shouldn't Customer have  had off site back up for the data, if it was critical to continued operations?  Was it reasonable design a sprinkler system that would inundate the entire center in response to a fire in one area?  Standard contracts routinely exclude liability for such remote, indirect and unforeseeable damages.


Assume the court (the jury and the judge) determine that it was foreseeable that a fire would trigger the sprinklers, which would damage equipment.  Are you liable for the entire cost of replacement equipment and clean up?  Here the limitation of liability provision of the contract would come into play.  Standard language will cap the potential liability of both parties, either at a dollar limit (e.g.  "shall not exceed $X") or using a formula, such as "X times the fees paid...."  Another approach is to tie the limit to the insurance coverage carried by the parties.  This method has the advantage of making sure there is a "deep pocket" - the insurer - on  hand in the event of a claim.  Of course the parties must take care to require that both carry adequate insurance, from reputable, financially sound companies.  

Questions we will address in the future:

• Appropriate insurance language
• Appropriate responses to a force majuere event
• Who should pay for the interfaces mentioned in the first paragraph, and why.

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.

The Wordsmith Is In, Part One

Lawyers have a reputation for being poor writers. We are regarded as wordy, repetitive, wordy, given to overly complex sentences and wordy.

Some complexity in legal drafting cannot be avoided. After all, many contracts record complicated transactions.

But that does not mean lawyers should stop trying to draft contracts that are as clear and brief as possible

To that end we offer some suggestions from George Orwell. His essay, "Politics and the English Language," was first published in May, 1945.

A scrupulous writer, in every sentence that he writes, will ask himself at least four questions, thus:

1. What am I trying to say?

2. What words will express it?

3. What image or idiom will make it clearer?

4. Is this image fresh enough to have an effect?

And he will probably ask himself two more:

1. Could I put it more shortly?

2. Have I said anything that is avoidably ugly?

AND.....

I think the following rules will cover most cases:

1. Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.

2. Never us a long word where a short one will do.

3. If it is possible to cut a word out, always cut it out.

4. Never use the passive where you can use the active.

5. Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.

6. Break any of these rules sooner than say anything outright barbarous.

These rules sound elementary, and so they are, but they demand a deep change of attitude in anyone who has grown used to writing in the style now fashionable.

"R" is for "Remedy"

A “remedy” is a tool used when a contract goes bad. Statutory law provides a set of “default” remedies, but they are far from perfect. They are designed to “make a party whole,” to deliver “the benefit of the bargain.” In most cases that “benefit” is measured in cash, and the definition of “benefit” might seem unduly narrow. In addition, statutory remedies are retroactive, and do little to promote performance of the agreement.

Example:

A contracts with B for 100 widgets, at $1.00 each. B fails to deliver and, after a ten day search, A finds C, who provides the widgets for $1.20 each. Also, because of the delay, A incurs a $20 penalty to D. How much does B owe A?

The first claim would be for the extra $20 for the widgets. A expected to pay only $1.00 each, and bid the work based on that price. A incurred the extra cost only because of B (something B would dispute). A may also want to claim the cost of personnel time and lost productivity incurred in the search for a replacement supplier. In addition, A may feel B is liable for the performance penalty.

A’s claims for personnel time and the performance penalty are problematic. Courts tend to focus on the contract price, and are reluctant to add extra costs not contemplated in the agreement. The claim for personnel time could be dismissed as a cost of doing business, and as something A could have controlled, either by making sure B was ready and able to deliver on time, or by having a backup plan. The same logic could apply to the performance penalty, unless the contract between provided that B would pay for it, or the contract contained a “time is of the essence” clause, which would allow A to argue that B should bear the costs. If A recovers only $20, after spending much time and money on litigation, A is unlikely to feel it was “made whole.”

Statutory remedies are not the only ones available to commercial parties. They are free, within reason, to fashion their own remedies. The statutory remedies exist as a default to serve those parties who do not stop to fashion their own.

In the case of A and B, A might have built in a timetable, with penalties if B failed to deliver on time. In return, B might have insisted that A have a viable backup plan, or B could have bought insurance to cover its own exposure.

The more complex or sophisticated the transaction, the greater the likelihood that statutory remedies will be inadequate. All the more reason for parties to design their own. These should:

• Encourage vendor to perform on time and within budget;
• Provide that timely performance will result in full and prompt payment.

A carefully crafted set of remedies will help keep the project on track. Certain approaches have repeatedly demonstrated their value:

• Tie payment to performance, not merely to the passage of time. Pay when X is completed, not on the 30th day after the contract is signed.
• Define “success” clearly and in terms that can be objectively measured.
• If the project is large or complex, break it into separate phases, permitting customer to call off further work after each phase.

Other Tools:

• Mutually agreed acceptance testing standards and procedures, combined with an opportunity for vendor to correct defects. Customer also may want the right to bring in a third party, at vendor’s expense, if vendor is unable to promptly solve the problem.
• Warranty coverage, beginning on with first productive use, rather than delivery or installation.

Specifications, specifications, specifications.

• What will the product do?
• How will performance be measured?
• When will it be ready?
• What will it cost?
• Who will do the work?

Careful planning can eliminate unreasonable expectations and reduce the chance of unpleasant surprises. As Poor Richard taught us: “An ounce of prevention is worth a pound of cure.”