When Technology Doesn't Work

People who negotiate tech deals and draft contracts must always remember one constant in today's ever-changing world: The technology we depend on every day often does not work.

This is true whether one is dealing with e-commerce, e-discovery or simply day-to-day procurement.

As a result, the traditional wisdom, “failing to plan is planning to fail,” has been transformed into a rule of thumb for the tech sector: “plan for failure.” Firms that do not explicitly anticipate systems failure run the risk of being unprepared for a catastrophe, just as Floridians must plan for hurricanes in August ' and New Orleans must now be prepared for potential dike breaches.

Not Always A Sure Thing

Consider, for example, the high-profile, widely reported problems recently suffered by industry leaders Microsoft, Apple and Yahoo! at annual trade shows. Last year, Bill Gates endured multiple crashes of his own products, and even suffered his own “blue screen of death” during his keynote address at the Consumer Electronics Show. (You can use technology to check it out on the Internet at www.vnunet.com/vnunet/news/2126451/blue-screen-death-crashes-gates-ces.)

At the 2005 MacWorld event, Steve Jobs also had to ad lib through unexpected freezes during his keynote. (See, http://comment.silicon.com/weeklyroundup/0,39024756,39127082,00.htm.)

And it wasn't just a 2005 curse, either. Yahoo! boss Terry Semel was similarly stumped by crashes during his “glitch riddled keynote” at this year's Consumer Electronics Show. (Again, through the '  let's hope glitchless ' wonder of technology, see, http://news.com.com/Yahoos+CES+demo+Mission+impossible/2100-1026_3-6021983.html.)

Now, if anyone ought to be able to make technology work flawlessly, it should be the leaders of the industry ' especially when demonstrating new products to eager customers, at a show covered by all the trade press. Presumably, their presentations were tested in advance, and not thrown together the morning of the show ' yet still, they all failed at the crucial moment.

But despite these executives' embarrassment, the average IT manager may face much graver risks from tech failures. For example, The Wall Street Journal recently reported a study that found an increased death rate following a hospital's installation of a new computer system. (See, http://homepages.utoledo.edu/pfritz/_news/news-2429.htm.)

“These are very complex systems that completely disrupt, and hopefully improve, the work flow in a hospital,” the article quoted health-information technology expert Paul Tang as saying of the system installed in 2002 at the Children's Hospital of Pittsburgh. “If you don't do it right, it can fail miserably and cause harm to patients.” Tang is also chief medical information officer at the Palo Alto Medical Foundation.

The article included information from Pediatrics journal from technologists saying that such systems as computerized physician-order-entry systems, which allow doctors to use computers to prescribe medications and have them administered, require training for health-care practitioners to use properly, and to help the practitioners change some of their practices and mindset to adapt to using technology properly.

Citing classified studies, another journal reported in 2004 that U.S. troops in the Iraq invasion were “plagued by tech glitches” that left ground forces without “access to vital intelligence and surveillance data” (see, www.abc.net.au/news/newsitems/200410/s1218341.htm). The report “uncovered a digital divide that allowed division commanders to get a good view of the battlefield, but left front-line commanders basically in the dark. The problems preventing effective relaying of crucial data included lengthy download times, software failures and lack of access to high-bandwidth communications.”

The Legal World Is Also Vulnerable

In the practice of law, malfunctioning recording technology has exposed clients to judges' wrath ' and sanctions that can make a courtroom victory near impossible. “Incomplete and missing transcripts and pages peppered with the word 'inaudible,'” plain old “gibberish,” and the simple “failure to switch on a tape recorder” have generated adverse rulings ' and appeals, according to a recent article in e-Commerce Law & Strategy sibling New Jersey Law Journal. (See, www.law.com/jsp/ltn/pubArticleLTN.jsp?id=1118666114493.)

One high-profile case, involving Morgan Stanley and financier Ronald Perelman, even resolved the key liability issue before trial, leading to a $1.58 billion jury award, when problems with electronic-discovery software prevented the defense from delivering accurate versions of key discovery documents. But knowing that technology will inevitably fail isn't the same as doing something (or nothing) about it. People who rely on technology can take several steps to try to reduce the costs of the problem, or prevent the problem altogether.

When discussing tech failures, don't forget the human factor ' it's surprising how often this factor is forgotten. In many of the failure incidents described above, human error contributed to the problem: failures to turn on a transcription machine, or slow adjustment to new medical systems. “Human error can always be a factor,” said a researcher at the National Center for State Courts, who has tracked data on courtroom snafus. And better training for those who must use new technology may be the most prudent way to reap its benefits.

Similarly, expectations about new technology must be realistic. Just because new e-discovery software has been installed, or an e-commerce site has been opened for business, doesn't mean that a failing firm's fortunes or win rate will turn around overnight. Also, the complexity of today's products ' hardware and software ' has made integration a task in itself. Incompatibil-ities with a firm's existing software and infrastructure ' much less that of the vendors and customers with whom the firm does business ' may create unexpected delays and problems that must be solved.

Instead, key employees in the firm must become familiar with the technology, and the most beneficial ' and cost-efficient ' ways to use it. In fact, with time, a firm's own staff may develop innovative ways to use the technology to its fullest for that firm's particular needs, beyond what the vendor could have anticipated. But those results will not appear on the first P & L statement after the go-live date.

Just as backing up has long been the first rule of data, especially in the age of technology, having readily available alternatives to the technology may also have to be considered. An 800 number for an e-commerce site, for example, can keep a firm in business when its computers crash. When introducing new systems, extensive testing under actual conditions and using real data, but before the system goes live, can help to identify flaws.

Redundancy counts as well. Preserving old systems after replacement may provide a refuge in a catastrophe ' as long as the old system's availability doesn't become the crutch that delays acceptance and use of a new system by reluctant employees.

Vendor-provided insurance coverage may be available after the fact to fund costs of fixing a problem. Practical warranty protection ' where the vendor steps in, immediately to make the system work under the terms of a service and maintenance contract ' rather than the typical limited warranty is also helpful.

Of course, all of these protections must be negotiated, in advance, in the original license agreement. But, unless the vendor has a “blank check” help-desk policy, this type of support can be quite expensive.

Moreover, vendors may be reluctant to extend standard support, particularly for new or cutting-edge products. No vendor wants to offer a perpetual, full-time help desk, unless its cost has been included in the pricing. Third-party support services are available, but may not be helpful to employees or customers working with customized products beyond basic Office programs, or complex installations.

And ultimately, firms don't introduce new technology to duplicate systems, or costs. They expect it to work, immediately, to justify the expense incurred to acquire it, and the usually much greater cost of installing the new system and training people to use it.

Give Due Diligence Its Due '
Plan, Plan, Plan

Indeed, with today's e-commerce volume, traditional backup and redundancy strategies may be obsolete. After all, if the old system could have handled the task, it would not have been replaced. Manual analysis of thousands or millions of e-mail messages, or internal discovery documents, may make settlement of the underlying litigation – even on unfavorable terms ' a more cost-efficient alternative than continuing to fight and spend on e-discovery. In the e-commerce context, manual processing, or even redundant electronic fulfillment, may eliminate all cost advantages of the online economy.

So, perhaps the best strategy becomes focusing on making the tech product work, from the beginning, whether it involves e-commerce software, a Web front or just a new in-house back office. As the foregoing “parade of horribles” indicates, however, that process may not be easy, quick or inexpensive.

From a business perspective, then, the best recommendation is to always budget for the unknown time and expense of new technology. The first budget or timeline, at the beginning of every project, must anticipate failures.

No matter how optimistic you may be at the start that everything will work well, assume that it will not. Remember to include all of the costs associated with a failure, and avoiding its potentially harmful consequences ' backup and redundant systems, insurance, extended warranties, even overtime and emergency billing costs for consultants to put your firm back in business. In that way, you can hope, the inevitable failure won't stick a firm with impossible deadlines, or cost overruns that could kill the project. Without this “failure factor,” the project may never proceed when the realistic costs prove too high.

Similarly, don't arbitrarily wait until the final week of a discovery period to begin collecting and tagging internal e-mail for production. If business reasons dictate that a site or feature must be available on a certain day, begin to roll it out well before the deadline to allow time for the inevitable fixes.

As for service contracts, if one is available, evaluate its cost as part of acquisition expenses, rather than as an option (regardless of how it is booked under accounting rules). Be sure, though, that it covers ongoing live technical support for a firm's specific problems, and not just releases of upgrades and comprehensive fixes. Your firm will one day almost certainly need someone to tell you how to fix your system, rather than instructions on how to implement or secure a theoretical fix. Don't trust the vendor with blind faith that it will fix your problem, or make you whole, when all you have is a generic limited warranty, or less, in your license agreement.

Also, remember that most “standard” warranties or service contracts will not cover many problems you are likely to face with technology projects, or provide any real remedy. A warranty of compliance with documentation, for example, may be worthless if the documentation promises little, or is heavily qualified.

In fact, before negotiating, analyze the license agreement from the perspective of what could go wrong in your firm, and what problems might shut you down. Then write into the contract remedies for those specific problems, in addition to the typical damages and injunctive relief. Although most contracts proceed from forms, here you should try to be flexible and creative to conjure up your own “insurance” against the harmful effects of a tech glitch.

But be wary of unrealistic caps or limits on damages. While many contract writers include these limits as part of the boilerplate, the right to be compensated for harm caused by a failure to perform goes to the heart of the deal. A party's refusal to stand behind its promises may tell more about the likelihood of success than any due diligence.

Also, you should investigate whether you ' and the other party ' have sufficient insurance coverage for losses that may arise as a consequence of a failed project. Be certain to consider whether tech-related losses are insured at all, and not excluded or limited, by the policy terms. If insurance is not available, evaluate whether your firm can absorb the costs created by problems, and of fixing them.

Working Wisely With The Inevitable

Some tech projects are “all or nothing,” and can't be rolled out in phases to monitor for problems and control losses. Then the preliminary work of writing a flexible contract becomes even more important. For example, the right to cancel prematurely, as discussed in the June 2005 edition of e-Commerce Law & Strategy, preserves the right not to continue losing money on a failing project. (See, “Use Escape Clauses For Tech Contracts: Breaking Up Is Always Hard To Do, But Don't Let It Kill Your Business.”)

Of course, contracts work two ways. While you may get that right, you also risk seeing a valued deal go awry when the other person exercises his or her right to walk away. Unfortunately, sometimes when a project has failed, cutting losses and switching to an alternative may be the most cost-effective solution. Certainly, it doesn't make financial or business sense to pour more time and money into something that may not work.

Everyone who works with technology knows that it will fail ' just not when. Plan to avoid the false “new deal” optimism of those who haven't lived through the last tech fiasco.

Instead, draft a contract to minimize the inevitable costs of such failures. While no one goes into a deal expecting failure, protecting the right to control the cost of a failure ' and recognizing that failure in tech contracts is more than a possibility ' can be the most significant part of a tech-contract negotiation.

People who negotiate tech deals and draft contracts must always remember one constant in today's ever-changing world: The technology we depend on every day often does not work.

This is true whether one is dealing with e-commerce, e-discovery or simply day-to-day procurement.

As a result, the traditional wisdom, “failing to plan is planning to fail,” has been transformed into a rule of thumb for the tech sector: “plan for failure.” Firms that do not explicitly anticipate systems failure run the risk of being unprepared for a catastrophe, just as Floridians must plan for hurricanes in August ' and New Orleans must now be prepared for potential dike breaches.

Not Always A Sure Thing

Consider, for example, the high-profile, widely reported problems recently suffered by industry leaders Microsoft, Apple and Yahoo! at annual trade shows. Last year, Bill Gates endured multiple crashes of his own products, and even suffered his own “blue screen of death” during his keynote address at the Consumer Electronics Show. (You can use technology to check it out on the Internet at www.vnunet.com/vnunet/news/2126451/blue-screen-death-crashes-gates-ces.)

At the 2005 MacWorld event, Steve Jobs also had to ad lib through unexpected freezes during his keynote. (See, http://comment.silicon.com/weeklyroundup/0,39024756,39127082,00.htm.)

And it wasn't just a 2005 curse, either. Yahoo! boss Terry Semel was similarly stumped by crashes during his “glitch riddled keynote” at this year's Consumer Electronics Show. (Again, through the '  let's hope glitchless ' wonder of technology, see, http://news.com.com/Yahoos+CES+demo+Mission+impossible/2100-1026_3-6021983.html.)

Now, if anyone ought to be able to make technology work flawlessly, it should be the leaders of the industry ' especially when demonstrating new products to eager customers, at a show covered by all the trade press. Presumably, their presentations were tested in advance, and not thrown together the morning of the show ' yet still, they all failed at the crucial moment.

But despite these executives' embarrassment, the average IT manager may face much graver risks from tech failures. For example, The Wall Street Journal recently reported a study that found an increased death rate following a hospital's installation of a new computer system. (See, http://homepages.utoledo.edu/pfritz/_news/news-2429.htm.)

“These are very complex systems that completely disrupt, and hopefully improve, the work flow in a hospital,” the article quoted health-information technology expert Paul Tang as saying of the system installed in 2002 at the Children's Hospital of Pittsburgh. “If you don't do it right, it can fail miserably and cause harm to patients.” Tang is also chief medical information officer at the Palo Alto Medical Foundation.

The article included information from Pediatrics journal from technologists saying that such systems as computerized physician-order-entry systems, which allow doctors to use computers to prescribe medications and have them administered, require training for health-care practitioners to use properly, and to help the practitioners change some of their practices and mindset to adapt to using technology properly.

Citing classified studies, another journal reported in 2004 that U.S. troops in the Iraq invasion were “plagued by tech glitches” that left ground forces without “access to vital intelligence and surveillance data” (see, www.abc.net.au/news/newsitems/200410/s1218341.htm). The report “uncovered a digital divide that allowed division commanders to get a good view of the battlefield, but left front-line commanders basically in the dark. The problems preventing effective relaying of crucial data included lengthy download times, software failures and lack of access to high-bandwidth communications.”

The Legal World Is Also Vulnerable

In the practice of law, malfunctioning recording technology has exposed clients to judges' wrath ' and sanctions that can make a courtroom victory near impossible. “Incomplete and missing transcripts and pages peppered with the word 'inaudible,'” plain old “gibberish,” and the simple “failure to switch on a tape recorder” have generated adverse rulings ' and appeals, according to a recent article in e-Commerce Law & Strategy sibling New Jersey Law Journal. (See, www.law.com/jsp/ltn/pubArticleLTN.jsp?id=1118666114493.)

One high-profile case, involving Morgan Stanley and financier Ronald Perelman, even resolved the key liability issue before trial, leading to a $1.58 billion jury award, when problems with electronic-discovery software prevented the defense from delivering accurate versions of key discovery documents. But knowing that technology will inevitably fail isn't the same as doing something (or nothing) about it. People who rely on technology can take several steps to try to reduce the costs of the problem, or prevent the problem altogether.

When discussing tech failures, don't forget the human factor ' it's surprising how often this factor is forgotten. In many of the failure incidents described above, human error contributed to the problem: failures to turn on a transcription machine, or slow adjustment to new medical systems. “Human error can always be a factor,” said a researcher at the National Center for State Courts, who has tracked data on courtroom snafus. And better training for those who must use new technology may be the most prudent way to reap its benefits.

Similarly, expectations about new technology must be realistic. Just because new e-discovery software has been installed, or an e-commerce site has been opened for business, doesn't mean that a failing firm's fortunes or win rate will turn around overnight. Also, the complexity of today's products ' hardware and software ' has made integration a task in itself. Incompatibil-ities with a firm's existing software and infrastructure ' much less that of the vendors and customers with whom the firm does business ' may create unexpected delays and problems that must be solved.

Instead, key employees in the firm must become familiar with the technology, and the most beneficial ' and cost-efficient ' ways to use it. In fact, with time, a firm's own staff may develop innovative ways to use the technology to its fullest for that firm's particular needs, beyond what the vendor could have anticipated. But those results will not appear on the first P & L statement after the go-live date.

Just as backing up has long been the first rule of data, especially in the age of technology, having readily available alternatives to the technology may also have to be considered. An 800 number for an e-commerce site, for example, can keep a firm in business when its computers crash. When introducing new systems, extensive testing under actual conditions and using real data, but before the system goes live, can help to identify flaws.

Redundancy counts as well. Preserving old systems after replacement may provide a refuge in a catastrophe ' as long as the old system's availability doesn't become the crutch that delays acceptance and use of a new system by reluctant employees.

Vendor-provided insurance coverage may be available after the fact to fund costs of fixing a problem. Practical warranty protection ' where the vendor steps in, immediately to make the system work under the terms of a service and maintenance contract ' rather than the typical limited warranty is also helpful.

Of course, all of these protections must be negotiated, in advance, in the original license agreement. But, unless the vendor has a “blank check” help-desk policy, this type of support can be quite expensive.

Moreover, vendors may be reluctant to extend standard support, particularly for new or cutting-edge products. No vendor wants to offer a perpetual, full-time help desk, unless its cost has been included in the pricing. Third-party support services are available, but may not be helpful to employees or customers working with customized products beyond basic Office programs, or complex installations.

And ultimately, firms don't introduce new technology to duplicate systems, or costs. They expect it to work, immediately, to justify the expense incurred to acquire it, and the usually much greater cost of installing the new system and training people to use it.

Give Due Diligence Its Due '
Plan, Plan, Plan

Indeed, with today's e-commerce volume, traditional backup and redundancy strategies may be obsolete. After all, if the old system could have handled the task, it would not have been replaced. Manual analysis of thousands or millions of e-mail messages, or internal discovery documents, may make settlement of the underlying litigation – even on unfavorable terms ' a more cost-efficient alternative than continuing to fight and spend on e-discovery. In the e-commerce context, manual processing, or even redundant electronic fulfillment, may eliminate all cost advantages of the online economy.

So, perhaps the best strategy becomes focusing on making the tech product work, from the beginning, whether it involves e-commerce software, a Web front or just a new in-house back office. As the foregoing “parade of horribles” indicates, however, that process may not be easy, quick or inexpensive.

From a business perspective, then, the best recommendation is to always budget for the unknown time and expense of new technology. The first budget or timeline, at the beginning of every project, must anticipate failures.

No matter how optimistic you may be at the start that everything will work well, assume that it will not. Remember to include all of the costs associated with a failure, and avoiding its potentially harmful consequences ' backup and redundant systems, insurance, extended warranties, even overtime and emergency billing costs for consultants to put your firm back in business. In that way, you can hope, the inevitable failure won't stick a firm with impossible deadlines, or cost overruns that could kill the project. Without this “failure factor,” the project may never proceed when the realistic costs prove too high.

Similarly, don't arbitrarily wait until the final week of a discovery period to begin collecting and tagging internal e-mail for production. If business reasons dictate that a site or feature must be available on a certain day, begin to roll it out well before the deadline to allow time for the inevitable fixes.

As for service contracts, if one is available, evaluate its cost as part of acquisition expenses, rather than as an option (regardless of how it is booked under accounting rules). Be sure, though, that it covers ongoing live technical support for a firm's specific problems, and not just releases of upgrades and comprehensive fixes. Your firm will one day almost certainly need someone to tell you how to fix your system, rather than instructions on how to implement or secure a theoretical fix. Don't trust the vendor with blind faith that it will fix your problem, or make you whole, when all you have is a generic limited warranty, or less, in your license agreement.

Also, remember that most “standard” warranties or service contracts will not cover many problems you are likely to face with technology projects, or provide any real remedy. A warranty of compliance with documentation, for example, may be worthless if the documentation promises little, or is heavily qualified.

In fact, before negotiating, analyze the license agreement from the perspective of what could go wrong in your firm, and what problems might shut you down. Then write into the contract remedies for those specific problems, in addition to the typical damages and injunctive relief. Although most contracts proceed from forms, here you should try to be flexible and creative to conjure up your own “insurance” against the harmful effects of a tech glitch.

But be wary of unrealistic caps or limits on damages. While many contract writers include these limits as part of the boilerplate, the right to be compensated for harm caused by a failure to perform goes to the heart of the deal. A party's refusal to stand behind its promises may tell more about the likelihood of success than any due diligence.

Also, you should investigate whether you ' and the other party ' have sufficient insurance coverage for losses that may arise as a consequence of a failed project. Be certain to consider whether tech-related losses are insured at all, and not excluded or limited, by the policy terms. If insurance is not available, evaluate whether your firm can absorb the costs created by problems, and of fixing them.

Working Wisely With The Inevitable

Some tech projects are “all or nothing,” and can't be rolled out in phases to monitor for problems and control losses. Then the preliminary work of writing a flexible contract becomes even more important. For example, the right to cancel prematurely, as discussed in the June 2005 edition of e-Commerce Law & Strategy, preserves the right not to continue losing money on a failing project. (See, “Use Escape Clauses For Tech Contracts: Breaking Up Is Always Hard To Do, But Don't Let It Kill Your Business.”)

Of course, contracts work two ways. While you may get that right, you also risk seeing a valued deal go awry when the other person exercises his or her right to walk away. Unfortunately, sometimes when a project has failed, cutting losses and switching to an alternative may be the most cost-effective solution. Certainly, it doesn't make financial or business sense to pour more time and money into something that may not work.

Everyone who works with technology knows that it will fail ' just not when. Plan to avoid the false “new deal” optimism of those who haven't lived through the last tech fiasco.

Instead, draft a contract to minimize the inevitable costs of such failures. While no one goes into a deal expecting failure, protecting the right to control the cost of a failure ' and recognizing that failure in tech contracts is more than a possibility ' can be the most significant part of a tech-contract negotiation.