The Year 2000 Computer Crisis -- What To Do NOW?

The various independent surveys from SIM and Anderson Consulting Worldwide and Peter deJager keep telling us the same thing - that only 20-30% of all US companies have begun to inventory their systems and perform any risk assessment steps to address their Year 2000 problem. Worse, less than 10% have actually started fixing their code. While the rest of the world, and your company is catching up, there are things that you can - and must - do right NOW to help your company address the problem and withstand the inevitable onslaught of litigation that is allegedly making some attorneys salivate.

The Economist in its cover story in its October 4th-10th, 1997 issue entitled "The Millennium-Bug, Muddle" quotes the estimated cost to the world's companies and governments of fixing the problem (including fixing the errors, lost productivity from those systems that fail, and the cost of liability lawsuits) at - take your choice: Gartner Group $600 billion; Technology Research Reports, a California market-research firm, $2 trillion; and Boston's Software Productivity Research at $3.6 trillion. It's getting pretty ridiculous and over the top.

When I'm pressured by the press for a number, I respond as many others have: "With the trillions staked out already by others, and me not feeling comfortable with a 'quadrillion,' let's just agree that we are talking about a lot of money here."

There are things that you must do right away if you haven't done so already to protect yourself and your company in case of future litigation and to help resolve your Year 2000 problem. These things include:

1. Develop a contingency plan - For those companies that have not yet made significant process already, the reality is that they will not be able to fix all of their problems. The contingency plan may call for:

(b) selling off parts of the business where the systems cannot be fixed (e.g., to a competitor that doesn't need your systems but wants your assets, customers, backlog, patents, brand name, etc.), or

(c) outsourcing (e.g., letting ADP do your payroll, pension, and profit sharing plans for the 2000 and part of 2001 if you need more time to get your system ready for production)

2. Thoroughly research and investigate all loans, partnerships, investments, and proposed mergers and acquisitions - Companies are still buying, selling, and investing in other organizations at all time highs. The executives of acquiring or investing organizations have a responsibility, sometimes a fiduciary one, to thoroughly investigate and evaluate the Year 2000 risks, liability, and costs. Buyer beware - and don't rely on the representations and warranties that the target company makes!

3. Review your insurance plans and options -- what coverage do you have for Errors and Omissions? Director and Officer Liability? Product Liability? Project Liability? Professional Malpractice? General Liability? Third Party Liability? Fiduciary Policies? And, specifically tailored policies? Note that insurance companies are specifically trying to exclude Year 2000 related problems/coverage when you renew your policies (typically once per year).

Know what you have, what you are loosing, and determine what your risks are and whether and how much to insure. Warning: So far, the only two nationally advertised insurance policies that specially cover Year 2000 problems are notoriously expensive and poor and/or confusing in coverage. Perhaps this results from those insurers being unable to accurately determine the risks, or because they have no historic experience yet regarding this problem, or they believe they are unable to control the behavior of the insureds over the next couple years regarding their Year 2000 fix. Look into insurance and risk management with your appropriate professionals.

4. Have your attorneys review all contracts with your systems vendors, maintenance, outsourcers, and developers. What software do you own vs. license? What are the contractual scope, rights, responsibilities, warranties, limitation in liabilities, remedies, and other key provisions and how will they impact you? You can make fixes to owned software (created internally with rights assigned to the employer). However, must check with your attorneys and your vendor licensors lest you be charged with creating a derivative work or breaching your contracts by letting staff or third parties have access to/modify the vendors' software. Many contracts treat software as a trade secret and you must be careful here.

There is one respected attorney who told me that there may be some relief, but only under the right set of circumstances, from a 1989 Kansas Federal District Court case (Foresight Resources Corp. v. Portmiller). He interprets this decision to mean that the owner of a copy of computer software (which may be determined to include a licensor under certain circumstances) may' have the right to adapt/modify such software if such software cannot be used for its intended purpose without such modifications. This may be true as long as the licensee treats the source code as the licensor's trade secret, has the modifiers sign a confidentiality agreement, and does not otherwise sell the modifications or make a profit on such work. He noted also that this does not at all necessarily allow the user to add new non-Y2K related functionality to that software. This is obviously a tricky issue and you must proceed with care and with your attorney's advice. Getting approval in writing from the vendor to modify his/her software is certainly the way to go if you can get it! Caution please!

Will your vendors promise to make the necessary repairs? In writing? What guarantees or warrantees will they give you? At what cost? In what timeframe? Can you wait and rely upon them? How can you help assure their success and that they are staying on target and on schedule? What are your alternatives if they begin to miss critical dates? Have you left enough time to thoroughly test the "fixed" version before you go live with it?

For all new systems procurement and development, assure that you have appropriate Y2K clauses negotiated in as express warranties and representations so that meeting your Y2K requirements are objectively measurable and enforceable.

5. Review all contracts with your customers and suppliers -- to determine what penalties exist for failing to deliver goods and services and payments on time. What if your systems are not ready -- what impact will that have? What if your systems are not compatible in terms if electronic data interchange (EDI) -- what impact will that have? What if their fixes are late, what alternatives exist? Keep open communication with your trading partners.

6. Reserve your right to sue (Statute of Limitations) - You should tell your vendors that you have a problem or concern in writing to put them on notice as soon as possible, or file a claim. An action for breach of contract (e.g., the system does not work according to spec, or has a material bug(s) that causes the system to fail) must be brought within the statute of limitations of the state whose laws are to be applied, typically four years (unless there is a federal statute of limitations preemption or if you reach a tolling agreement with the vendor to stop the clock from running).

Time generally begins to run when the breach occurs regardless of the aggrieved party's lack of knowledge of the breach (i.e., this could be the time of the sale/license or expected first use of the software and not when you first are hit with the Year 2000 bug). However, a defendant may argue that the Year 2000 bug won't affect your operations until 2000 and your suit may be thrown out. This has yet to be determined in court.

In any event, this statute is intended to protect the defendant by forcing a party to exercise a right of action it might have in a reasonable time frame so that the defendant can best defend itself. Protect your own future rights now and don't let the clock beat you!

7. Form a Technology Leadership Committee - a leadership team will create the commitment, mobilize the resources, and address the hard questions regarding setting priorities, monitoring the fixes, and implementing contingency alternatives that is needed to successfully address Year 2000. The Committee should have representation from all over the company including public/shareholder relations, legal, CIO, CFO, top management, operating division management, risk management, quality assurance, and the Board. Members may change over time as the project progresses into new phases.

8. Assign a Legal Overseer - to help do the right things-today to prepare for inevitable litigation in the future if your systems aren't fixed in time. While he/she will oversee many of the areas covered in this article, he/she also must be particularly sensitive to creating an appropriate paper trail for trial.

There must be a quelling of letters, documents, e-mails and/or open internet communications by frustrated programmers and managers that say the company is on its way to "hell in a hand-basket," is doing nothing about the problem, has not adequately planned, budgeted, scheduled, managed, or monitored the Y2K projects. To the extent these accusations are true, there must be an appropriate forum for hearing and addressing these issues. To the extent they are not true, they can only create additional huge hurdles and confusion in a future lawsuit once they are discovered.

Documents supporting the timely investigation, analysis, planning, execution and management of the Y2K remediation, suitable use of outside experts, apt Board level deliberations and the use of good business judgment, and the application of appropriate monitoring and contingency processes will all help in defending a case - even though the Y2K solution failed. Assure that your Board minutes adequately cover the Board's Y2K discussions, deliberations, and decisions.

9. Disclose, Disclose, Disclose! - The jig is up! Now the Securities and Exchange Commission, the Financial Accounting Standards Board, the Federal Financial Institutions Examination Council, insurance companies, and even ISO 9000 all demand that you properly disclose, on an ongoing basis, the risks from the Year 2000 problem. Estimated costs, schedules, likelihood of success, progress made, costs already incurred, and how risk is being mitigated are all part of the kinds of information you must provide. Failure to do so can have severe civil and even criminal penalties.

10. Start your Y2K remediation - You must start immediately in identifying and addressing the Y2K risks, determining resources, developing triage and fix strategies, and code, test and implement your fixes. Note that simply changing to a client/server system can take two years with another left for testing. This is also true of implementing a large Oracle, SAP or PeopleSoft system solution. Thus, if you have not yet begun, think of your alternatives, address what you can, and go into contingency mode for those things that you cannot fix in time. Remember to include all of your key imbedded systems (e.g., security systems, environmental systems, etc.) and to review the Y2K compliance of your PCs in your plan.

11. Lock in resources - Consider alternate ways, as opposed to doubling and tripling systems staff salaries (someone will always pay more anyway), to attract, motivate and retain year 2000 staff over the next few years as your competitors and late starters begin to raid your organization. Think about offering: sign on, completion, and stay bonuses; relaxed dress codes; monthly lunches with management; special lunchroom passes; promised future sabbatical, and special training and assignment to the company's most exciting projects after year 2000; ability to work at home (telecommute) part of the time with a company installed high-speed ISDN line to the staffer's home; limousine service (hey, it works in New York) and more. Lock in outside consultants as it backup in case of resource problems in the future.

12. Remember, Murphy was right - accordingly, year 2000 is a leap year; "1/1/99" and "9/9/99" were trained, standard, legitimate defaults (such as for products with "no expiration date" or documents with "no date at all") which will cause your programs to go haywire when the real 1/1/99 and 9/9/99 hit; and programs figuring the day of the week for some future date (almost all invariably use only two digits) will misfire (e.g., January 1, 1900 was a Monday and January 1, 2000 will be a Saturday).