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

I Paid For It, Don't I Own It?

My expert on Internet telecom is unavailable until later this week.  As a result, the promised article on VOIP systems will be delayed by a couple of days.  In the mean time, let's discuss ownership of intellectual property.


In the last fifteen years or so, "intellectual property" has become one of the favorite buzz words in industry.  Everyone wants to have it, protect it and, most of all, exploit it.  Which begs the question, what IS intellectual property?

As the name suggests, intellectual property ("IP") is ideas, in particular ideas that are both new and useful.  A car engine that would remove greenhouse gases from the atmosphere would be an example of particularly valuable IP asset.

IP is covered by different sets of laws:

Utility patents protect tangible inventions or discoveries, things you can hold in your hand or which perform a useful function.  The light bulb is the classic example.

Design patents protect the look or styling of a product.  Think of the distinctive shape of a Coca Cola bottle, or the racy lines of your favorite motorcycle.  A design patent can help prevent a competitor from copying these "looks" too closely.

Copyrights protect "works of authorship," such as books, music and computer software.  (Just to add to the confusion, software can also be patented.)

Trade secrets protect information that is valuable, but not publicly known.  Col. Sander's fabled "eleven herbs and spices," is a famous example.  Reportedly only a handful of senior executives know the recipe.

Trademarks and service marks protect company logos, such as the Nike "swoop," the yellow Kodak film box, and even the name "Kodak."  If I tried to exploit Kodak's good name by bringing out a film product named "Coldack," the good people in Rochester would probably be able to shut me down, claiming that my name is too similar to the name they have used for years. 

For today, however, I'd like to focus on patents and copyrights, as they seem to generate the bulk of confusion regarding ownership and use rights.

The default rule in American law is that the person who creates or discovers an IP asset owns it.  Or, to put it another way, the law automatically sees the discoverer or creator as the owner, unless he or she has made an agreement that gives ownership to someone else.  The legal term for such an agreement is an "assignment" and the new owner is generally referred to as the "assignee."

There is an exception to the default rule, called the "works for hire" rule.  It provides that, in certain conditions, assets created by employees in the course of their employment belong to the employer, not the employee.  The rule is not as clear as it might be, and employers are encouraged to include assignment language in their personnel handbooks.  In addition, if an employee is being hired to do research and development, she or he should be asked to sign an individual agreement, assigning rights to any assets created in the course of employment.  "Better safe than sorry."

The default rule can be particularly troublesome when work is outsourced to a contractor.  It would seem logical to assume that "I paid for it; I own it."  Logical, but contrary to the default rule.  You may recall that ten or fifteen years ago, when the Web began to boom, companies discovered that they did not own their Web sites, because they had not secured proper assignment of the page design from the Web developer.  The same, or worse, can happen if the "developer" is a third party programmer who  happens to create the key part of the new application that will help you dominate your industry.  Without proper assignments, you may not have this vital new asset under lock and key.  Rather, the third party might be in a position to charge you outrageous support fees, prevent you from modifying "her" product or even market it to  your competitors.  Any of those would be difficult to explain to the boss.

For all that, one does not always need, or perhaps want, to own all rights to every bit of software one pays to develop.  One may front the cost of vendor's development of THEIR new killer application, in return for a great deal on maintenance and upgrades.  Or one may pay for the development, and allow re-sale of the new product, provided, it is not sold to your direct competitors and provided you get a cut of the profits.  I once effectively owned a major software vendor for several days because no one told me my client was funding vendor's new flagship product.  I therefore provided that my client would own all rights to the new product.  Their attorneys did not see the problem until after the contract had been signed and delivered. 

The lesson is that American law protects the person who creates the IP asset, not necessarily the person who pays for the creation.  Care, and often good legal counsel, are needed to ensure that  your company secures the rights it wants and needs product it is paying for.  But do not stop your analysis with "We paid for it, we want to own it."  Ask, rather "What rights do we need to secure the competitive advantage this product offers?" and then "After we've secured our competitive advantage, can we make additional money off the new product?"

If you can transform Project X from an expensive sunk cost into a competitive advantage AND a revenue stream, that would be something to tell the boss.

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?

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.

A Bit Of International Law

A reader has asked about laws governing international transactions, and particularly what law controls if vendor is in one nation and customer is another. While international transactions are not one of my strengths, I've done a few and can offer some insights.

To begin, the transaction must be legal in each nation. While that would seem obvious in theory, in practice it an yield many surprises. Years ago I ordered some rare earth magnets from a well known and well respected vendor of woodworking supplies located in Canada. Rare earth magnets are very powerful for their size, and woodworkers use them in all sorts of ways. I glue them to the wall of my workshop and hang tools from them. A few days later I received a call from a very nice, but rather embarrassed fellow at vendor, who advised that it was (then, at least) illegal to ship such magnets across the US/Canadian border. He apologized for the inconvenience, the rest of my order arrived in due course, and to this day I wonder why magnets, of all things, should receive such treatment from government. The moral however, is that government restrictions can pop up in the most unexpected locations. IT, of course, often receives special scrutiny from regulators. I sometimes think one could make a career simply dealing with US government controls on the export of technology.

Assuming the transaction is permitted in both nations, the next question is how to enforce the agreement. If I, as an American, hire a German company to build a factory in Mongolia, where do I file suit if something goes wrong? Despite all the progress of globalization, there is no “international commercial court” to hear such disputes. My choices would appear to be the US, Germany or Mongolia.

Although Mongolia has long fascinated me, I have no knowledge of their system of commercial law. Perhaps their courts would not even hear a case between two foreigners over a project that just happened to be located in Mongolia. Indeed, if the money is merely flowing between the US and Germany, the Mongolian courts may not have effective jurisdiction. Even if I were to win in the Mongolian courts, I would still have to locate the bank accounts (or other assets) of my German vendor and persuade a court there to enforce the Mongolian judgment.

If we presume the contract was signed in the US, I would have a good case for filing suit in that nation. Again, even if I were to win, I would have to find assets to satisfy the judgment. That could be difficult if my vendor only has a small sales force. In that case my US judgment would be useful only if I can enforce it in Germany.

There are, of course, treaties between most nations promising to respect the judgments of one another's courts. But that does not guarantee success. The German judge might discover some defect in the American proceedings and refuse to confirm the judgment. That would leave me with one option – filing suit in Germany.

In this case I have made at least three mistakes:

• I did not insist that the contract specify what law would apply;
• I did not insist that the contract specify where any litigation would be filed;
• I did not make certain that vendor had assets where I could reach them easily (assuming I won my case).

As a result, I condemned myself to play hide and seek across the world with my vendor.

A better course would have been to:

• Hire a US attorney skilled in this type of transaction and the applicable government regulations;
• Hire an attorney in Mongolia to ensure compliance with all local laws;
• Reach an agreement with the foreign vendor regarding where any disputes will be heard, and what law should apply;
• Require the vendor to set up assets or other security within my reach (Vendor, of course, will want similar protection in the event they have to bring suit against me.).

Better to plan and agree how disputes will be handled than to leave the question open and creating something additional to argue about.

Working With Your Attorney, Part One

Once upon a time I was in-house counsel and had a close working relationship with Jim, Contracts Manager in the IT unit. One day Jim sent me a request for a contract. “Vendor is ABC, price is $2.5 million, split 40/60. Product is a custom program called Killer App.” I drew up the appropriate contract. We would pay $2.5 million, with 40% up front (not always a wise thing to do) and 60% upon final delivery (and passing acceptance tests). All of the work product would belong to us, including all intellectual property rights. My CIO signed; ABC’s lawyers reviewed it and their CEO signed. I filed the executed agreement and went to the next project.

A few days later Jim called and said “We need to change the ABC agreement.”

“Why?” I asked. “I thought they had signed off.”

Jim explained that there had been a mix-up. Our company wanted to front the money to develop ABC’s new flagship product. In return, we would receive a no-charge license and free support ad infinitum. “They want a new agreement that says they own the work product,” Jim said.

I was in a bit of a quandary. ABC’s lawyers had blessed the contract. More, I had been a business lawyer too long to simply give away an asset. I replied “What’s it worth to them?”

Jim laughed and said he’d follow up with management. Later that day our CIO called. He complimented my mercenary instincts, but directed me to make the necessary changes. I did, but I also “extorted” a coffee mug from ABC’s sales rep. I wanted something to commemorate the occasion.

I like this story because it illustrates several things, including the need to involve lawyers in the transaction process. Had I known more about the deal, I could have got the contract right the first time. I would not have an amusing story, but the companies would have saved time and money.

Jim and I took a cue from this transaction and revised our procedures. We created a standard contract request template requiring internal clients to fully describe the transaction. When in doubt, we asked for more information. The CIO also endorsed a requirement that Jim sit in on all negotiations over a certain dollar amount. I also sat in on these from time to time, with the informed consent of the vendor.

An attorney can only draft from what he/she knows. If that knowledge is flawed or incomplete, the contract will be flawed, resulting in unnecessary delay. In addition, regarding the lawyer as merely a scribe, to be involved only at the last minute, can deprive the parties of the lawyer’s experience and insight. No one will be pleased if the lawyer is asked to provide a contract “tomorrow,” and he/she replies “But you have overlooked this, and this, and this and this.”

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

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.