by Gregory P. Cirillo and Ira T. Kasdan
The Year 2000 software meltdown has gone prime time: widespread coverage in the media, hearings before Congress--and warnings by tort lawyers that they are preparing to pounce.
If you haven't heard by now, many software programs that perform calculations by reference to the calendar year will utter their last meaningful gasp on Dec. 31, 1999; thereafter, these programs will belch out nonsensical results. For example, employees hired in 1996 may be logged in as being employed for negative 96 years as of Jan. 1, 1996 (as the program subtracts 96 from 00).
Even today, you may run into difficulty renting a car if your license expiration date is after 1999. One congressional subcommittee has estimated that the repair cost to the federal government alone is $30 billion. For states and the private sector, the bill could be a multiple of that.
It seems incomprehensible that we allowed a problem of this magnitude to sneak up on us. Doomsday is 3.3 years away, but analysts have concluded that it is already too late to fully address the problem. Many will suffer, but some will be impacted more than others. Financial institutions (especially banks), insurance companies, and other industries with intensive date-sensitive computer systems will be the hardest hit, according to many well-respected Year 2000 experts.
Many organizations, both well-established and lesser known, are offering or developing fixes to the problem, and those packages vary significantly in terms of price complexity, efficacy, and guaranteed results. Most of the "Big Six" accounting firms, and all of the major management consulting firms, are preparing to hit the streets with comprehensive solutions. Before you spend, however, consider the following points:
Principle 1: The most important device -- and your first line of defense -- for protecting yourself from the Year 2000 meltdown is the license agreement in your files. (You did keep it, didn't you?)
The ultimate fix to your Year 2000 problem may be technical, but the remediation process will begin in your file cabinet. Every piece of software is governed by a license that may have specific provisions critical to addressing the Year 2000 crisis, including warranties, representations as to functionality, and access to the "source code" that's necessary to make fundamental changes to software. Chances are, unless your contract was vigorously negotiated, it probably is subject to broad waivers of warranties and limitations of liability.
Nevertheless, depending on the language of the license, applicable state law, and the skill of legal counsel in deciphering the intent of the parties, the license may have a few precious nuggets that can be used to your advantage. Do not simply jump into a technical solution. Rather, first determine your contractual rights to shift the burden, in whole or in part, to a responsible party. That may affect which technical solution should be selected and how, by whom, and by what means it should be implemented.
Principle 2: The company best able to fix your software (and perhaps the only one capable of doing so lawfully) is the one who developed it, but the window of opportunity for a conciliatory resolution is closing fast.
Practically, software is modifiable by its source code only; in all likelihood, only the developer of the software has the source code and the right to modify it. Thus, once you know your license rights, your next call should be to the software developer. You may get lucky and find that: (1) the developer already has a patch for the Year 2000 problem; or (2) it is willing to release its source code to permit modification; or (3) if you found useful provisions in your license, the developer itself may feel compelled to undertake the repair.
In all circumstances, the resolution achieved must be carefully documented to ensure that the fix works technically and legally. Keep in mind that conciliatory fixes will become less common as software developers get swamped with calls from, and claims by, frustrated licensees. Settle up amicably, reasonably, and early, and you may achieve a resolution that others may not be afforded. If, however, that avenue is foreclosed, follow the guidelines under the next principle.
Principle 3: Technology solutions have a religious quality in that (1) there are many variations on the same theme, and (2) you will be told that all of them are absolutely wrong, except for the one being pitched to you.
Nontechnical professionals and managers do not want to learn the inner workings of computer software or hardware. They simply want someone to take control and make the problem go away. But often these nonprofessionals cannot make an informed decision because the fundamental facts and lingo are foreign to them.
On the other hand, technology professionals have a single-minded fervor that often precludes balanced decision making. Ask a Macintosh user what is good about a PC. The answer will be clear, definitive, convincing, and, for the most part, empirically useless.
The bottom line? Year 2000 corrective measures may or may not work, depending on how well you manage each step of the process and how well you have protected the investment you have made in a solution. Remember . . . there will not be time for you to do it all over again. So, (1) be certain that you are advised of all options, risks, likelihoods, and possible scenarios by technical professionals who have no stake in the outcome; (2) do not rely on the advice and opinions of the solution-seller alone; (3) always seek multiple views, including those of a competent Year 2000 consultant if your technical issues require such expertise; (4) obtain from all service providers the best possible (written) proposals and contractual assurances of a timely and effective fix; and (5) follow Principles 4 and 5, below.
Principle 4: Do not seek only outside help to implement the solutions; seek qualified help to manage the solutions.
A single adviser/manager should orchestrate the process of assessing and pursuing license rights, selecting and contracting with outside solution providers, and closely managing the implementation of the solution. There will be a multitude of decisions to be made (especially if you need a separate solution provider for each software program you have). Do you replace your system entirely? Contract for a fix? Gear up to sue your vendor? Or do nothing and gear up to defend against the consequences? What will these various options cost? If you do not have diverse in-house capabilities to answer these questions, you should consider hiring an adviser/manager from the outside--no ties to the solution provider(s)--who can act as the company's representative.
Principle 5: Notwithstanding Principles 1 through 4, prepare for the worst (or at least for the next to worst).
The "worst" means that you will not have taken the necessary steps to fix the problem by Jan. 1, 2000. Since that is unthinkable--and you will have little recourse by then (there is no escaping the turn of the century)--at least prepare for "the next to worst." That means, get ready for the lawsuits against (and perhaps by) you, for they are virtually sure to come--even if you meet that immutable deadline.
Assess the legal issues that must be addressed. For starters, determine what (if any) shareholder disclosures are necessary regarding the problem and the anticipated solutions. This is an especially important issue for publicly traded corporations that are required to identify events or uncertainties that are reasonably likely to result in the corporation's liquidity increasing or decreasing in any material way.
Next, review your existing contracts with customers. What obligations do you have that might be affected by the Year 2000 problem? Do contracts have to be renegotiated or amended? As for future contracts, make sure that the problem is properly addressed. Will a limitation of liability clause do the trick, or are other contractual terms appropriate? These are just a few of the considerations that should be covered.
Finally, directors and officers must be protected. While it may seem unfair to hold directors and top executives responsible for computer glitches, think of it this way: If a bank's computers suddenly cannot handle or accurately make date-sensitive calculations or if a corporation's computers can't input orders beyond 1999 and revenues are lost, someone will be sued--and you can bet that it won't be the company computer programmer.
The fiduciary duty of due care requires the exercise of reasonable diligence and care, including the obligation to make informed decisions. The standard of care inevitably will be determined by reference to similarly situated boards of directors and officers. If your competitors are getting the necessary advice on Year 2000 issues and are assessing and addressing the problem, you may be in trouble if you do not do likewise.
Following these principles alone may not save you or your company from the millennium meltdown. But at least it should give you a leg up--if nothing more than to stave off the lawsuits against officers and directors, a feat in itself.
* Text reprinted with permission of Legal Times, 1730 M St., N.W., Washington, D.C. 20036, Copyright, 1996.
Return to Publications