Introduction Many may dismiss the predictions that there would be a worldwide chaos on January 1, 2000 as many computers programmed with two-digit year fields would mistake it to be 1900 and breakdown. However, we need not wait for the turn of the century for the trouble. Signs of early troubles are already everywhere to sufficiently warrant both IT and business managers to take the issue seriously, if they have not already done so. What seemed as a reasonable solution to costly storage problem in past, would now cost, by some estimates, 600 Billion dollars to organizations worldwide. No matter what the final cost comes out to be, even at conservative 300 billion dollars, it is no pocket change. All concern parties must have thorough understanding of the problem, its solutions, and possible ramifications. Importance of the Issue IT managers are not the only one who needs to understand the depth of Y2K problem. Business managers probably has more in stake here than any one else. If timely solutions are not achieved, many business stands to lose many billions of dollars in form of lost revenues. This loss does not include possible losses resulting from litigation and out-of-court settlements. Many firms, including some large ones, have continued to drag their feet on fixing Y2K related problems. Companies with Y2K problems now often cannot find people to work on those problems. Shortages of qualified people to work on Y2K projects are very evident globally. January 1st, 2000 is a non-flexible date that is sure to come without any mercy and possibility of extension. If companies are not addressing it by now, they are simply playing catch-up(14). The good news is that the technical know-how exists and many tools are available. For many organizations, problem can be adequately addressed even if they start now – but for a higher cost, of course. Historical Perspective In 1956, Howard Aiken, a computer pioneer from Harvard University remarked: "If it should ever turn out that basic logic of a machine design for numerical solution of differential equations coincide with the logic of a machine intended to make bills for a department store, I would regard this as the most amazing coincidence that I have ever encountered."(1) First, it was truly an amazing coincidence. Second, the first generation of computer programmers were also right by recording years as two digit numbers. It saved costly storage capacity. Third, by another amazing chance, the result of a correct decision will be an expensive (may be the most expensive) industrial accident of our time. Many articles have included stories that show the date problem surfacing as early as 1993:
In 1993, associated Press reported that Mary Bandar of Minnesota was invited to attend kindergarten classes, since she was born in 88. She was born in 1888 and was 104 years old.
C.G. Blodgett’s auto insurance premium tripled when he was reclassified as youthful high-risk driver. He turned 101.
What is the Year 2000 problem? It is not one, but series of problems. It Involves software, computer hardware, data, people, and large amounts of money. Nature of these problems can be explained simply: until 1989, all of the standards followed to create computer programs stated that only last two digits would be used to identify the year. As the millennium nears, most computers would regard 2000 as 1900. In late 1800s, Mr. Hollerith invented the punch card with 80 columns to help the U.S. Census done on time. Same cards has been in use for programming until recent time. Eighty characters of information was barely enough for a full name and address. To save space for more important information, programmers designated two-digit year field assuming all years would have same prefix of 19. Even when computers were later equipped with larger storage capacities in magnetic form, memory was the most expensive part of the machine and programmers continued to use two-digit year field to save memory. How the problem continued Programmers of 1960s and 1970s assumed that these program would long be replaced with new ones before the turn of the century. Though the computer hardware has come a long ways in past 30 years, the mainframe machine is still with us – only faster and able to run old programs cheaply. Many of these programs were written for a specific company to do a specific job and over the years more features have been added but little has changed at the core level, including two-digit dates. Scope of the problem Solving the problem, looking from the top, is as simple as telling the computer to change all existing dates to four digits and only to accept four-digits dates from now on. But few dates are easy to find in ‘date = MM/DD/YY format’. Many programmers used conventions such as "john – mary = sue" to calculate differences between two dates -– making it harder to find the date code if one is not familiar with the convention (3). But that is only the part of the problem. Over the years large amounts of data has been stored on disks and tapes and there are lots of duplicate data. In most part these data are stored in large files in a date sequence of collection. Many programs that handles these physical resources cannot handle four-digit year. Business applications that depends on these systems to figure out person’s age, length of unpaid invoices, interest due on bank deposits and so on are in for plenty of trouble. (14). Furthermore, many businesses have used date stamping –- a method that use embedded dates in the records. Date stamps are automatically placed on the record by the system in many transaction tracing systems. Brian Hayes in January/February 1995 American Scientist used the following examples to describe the date stamping problem:
At the local dairy, the oldest milk on hand is supposed to be shipped first, but in the early weeks of the new millennium milk from year 00 is given precedence. Indeed, any milk remaining from December 1999 will not be scheduled until the end of 2099. Meanwhile, at the bakery across town a computer calculates the bread dated 01-01-00 must be a century old, and sends it to the landfill.
Where Are We Now?
If the companies and governments were to do nothing about the problem, unthinkable crisis would certainly follow. However, for a change, we have the media to thank for. Numerous reports, stories, and articles presented to people is likely to save us from such a disastrous possibility. No one can now say that they were not warned.
Problem hits early
The problems associated with the millennium bug have already started to prop up and many are expected to strike harder well before January 1, 1999. A report published by Cutter Consortium outlines some Significant Milestones Prior to 2000 (2):
Jan 1, 1999: reservation systems that accept booking one year ahead and business planning systems projecting forward one year.
April 1, 1999: NY State and some companies 2000 fiscal year begins, affecting all fiscal systems
July 1, 1999: 44 more states and other companies begin their fiscal years.
Sept. 9, 1999: Programmers use 9999 as an end of file indicator, so date may confuse system.
Oct. 1, 1999: federal government and many other companies begin fiscal year 2000.
Unfortunately, all companies are not reacting accordingly. While many addressed the problem in somewhat timely manner, others are dragging their feet. Many are taking wrong positions. As stated by William McDonough, President of Federal Reserve Bank of New York, they are(3):
Denial. The year 2000 is not an issue for our organization.
No resource problems. "Our organization can handle the year 2000 with its existing resources and within current budgets."
Vendors will address the issue. Our outside vendors and service providers won’t let us down.
Covered by contract. "Our lawyers have determined that we are appropriately protected by our legal agreements".
On the other hand, Some companies decided to be silent. Management of these companies are fearful of shareholder suites claiming negligence. Many fears that acknowledgement of a serious Y2K problem within a business unit or across an enterprise may cause clients to flee and competitors to flock. The legal ramifications remain unclear for consulting services companies that have provided hardware and software solutions that did not include Year 2000 fixes in the recent past. Others are awaiting the leadership of regulatory agencies and/or financial accounting standard bodies within the federal government for this unique event(3).
News for late starters
A new survey conducted by International Data corp., of Farmingham, Mass., found that small companies are more likely than the larger firms to neglect the year 2000 projects(10). Out of the 400 firms surveyed, 23% percent had not started the conversion project. A vast majority of these firms (88%) has annual revenue of $25 million or less. In the same survey CIOs and CFOs were asked to rate their concerns about year 2000 conversion. They rated impact on customers first, followed by their competitive position against other companies. Impact on the business partners was rated third, and financial impact was rated fourth.
If companies are not addressing the problem right now, they may be in for a lot of trouble. Only viable solutions are to retire and replace, or to repair the system. Ignoring the problem is not an alternative.
They need to take an inventory of the software on a system and identify where Y2K will effect it and prioritize the order in which to fix problems. Organizations that did not contract for Year 2000 services by 1997 can expect to pay up to 100% premium to obtain services from leading service providers.
Staffing and outsourcing
Only 21 months to go, staffing the Year 2000 team could be a cause of major anxiety for companies. According to Casper Jones, a noted year 2000 consultant, "1996 was the last year in which a midsize corporation with a software portfolio of a half-million function point could have finished work on time without extraordinary staffing measures. Those include halting all but emergency and required work, assigning up to 85% of staff, running round-the-clock efforts and partnering with consortia or industry groups."(6)
Surveys show the growing staffing shortage and it will only continue to get worse. The real shortage will come when federal government will get serious about year 2000 fixes. Organizations with head start and adequate staff are not all that secure – they could be the target of companies seeking ready-made expertise. The cost to repair codes stands at $1.50 per line currently. Some expects it to at least double over the next few months.
Experts say, there is still hope for late starters. If they act quickly. Late starters still benefit from others’ denial of the problems(6). Outsourcing still remains a option for some. Some large and many small consulting firms are still seeking new businesses. Off-shore providers can also provide some relief. More companies are also getting back to their retirees for help. The retirees may have not only the necessary experience, but they also may know the system better than the outsiders. What’s in the Future?
Companies that have their project 2000 well under control as well those who are starting out -- both needs some future planning. If nothing else, they should review the legal issues involving their business and have a well drawn contingency plan in place.
Buying a liability insurance, just as other business insurance, may not be an option -– companies cannot insure out of this one. While some insurance coverage is available, the cost of coverage and loopholes in policies make it prohibitive. Companies spending money on insurance will never get return on their investment. Policies are likely to provide false security and companies are better of putting their money and effort to solving problems at hand (15).
Legal issues arising from year 2000 problem alone can put many organizations out of business. By the turn of the century, business managers and IT vendors will be seeing lot of year 2000 related lawsuits. Many has wrongfully believed the problem to be a primarily a technical issue. But lot of companies will fail to conduct business even before the deadline hits home.
Produce Place International Inc. of Warren, Michigan recently had its newly installed Unix Point-of-Sales system come to crashing halt when a customer tried to use a credit card with "00" expiration date. All the register froze. Though the business could accept cash or checks, lots of people walked out in frustration due to backed up line at the registers. After many support calls to the vendor, the store has sued the manufacturer of all American Cash Register Inc. for breach of warranty and breach of duty of good faith, etc.(8).
Vendors are not going to face the lawsuits alone –- IT managers who fail to meet the Y2K compliance and would cause contamination in customers’ and partners’ systems may also find themselves defending in court of law. Some experts asks IT managers to take it as a legal issue as well and to document their Y2K repair efforts.
There are other lawsuits pending in the Superior Court of the State of California. It is likely that all these early cases will be settled out of court to avoid public attention. Some companies are taking actions now. The big three auto manufacturers has joined together to write to the suppliers to fix the problem or face litigation in future (8).
The vendors are likely to use the theory that the risk was unforeseeable or there was a disclaimer of warranty explicit or implied in the transaction. Another issue would be of the statute of limitations. Generally warranties does not last as long as acceptance and delivery of the goods. Many are discussing of alternatives to all possible litigation and product liabilities. But, prudent business managers should not count on it to defend themselves(11).
Many experts say that disclosure is the best defense against Y2K litigation – the board of directors and shareholders need to know. SEC advised companies to "disclose internal Y2K issues, relationships with customers and suppliers, a timetable for carrying out the plans, and a total dollar amount the customer estimates will be spent on Y2K issues."(8)
Some government agencies are trying to pass laws that may protect them. However, that is not a choice for companies. In California, a bill has been proposed that, if passed, will limit awards for year 2000 lawsuits to ‘reasonably incurred costs regarding relevant computers and software’ and may weaken businesses’ ability to recover actual damages (9).
A case for contingency planning
When an information system group at the state of Washington performed a routine test of its disaster recovery plan two years ago, it also decided to take a look at its year 2000 problem. But when they set the mainframe’s system date forward to 2000, it caused the entire test to crash. The computer informed that testers’ passwords has expired (4).
The moral of the story is that the companies not only need contingency plans, it also needs to test those plans thoroughly. But it remains an idea that many companies do not adopt. Preparing for the Year 2000, contingency planning is not only a good idea, but one that should not be ignored. Study shows that companies that need contingency plans are least likely to have them.
Washington’s Department Social and health Services is field testing a commercial accounts payable package that can be turned on quickly if needed. One would suppose that it is their solutions to Year 2000 problem. In the contrary, the department is far along in remediation of their 12 year old mission critical system. The Prudential Insurance Company of America has a broad contingency plan that covers application software, internal infrastructure, and external partners. Each of these area has a plan for not meeting January 1 deadline, if it fails after January 1, and if a problem is not discovered until later. Similarly, Geico Corp. of Maryland plans to include manual backups for some mission critical automated processes by keeping paper copies of data that would allow cross-checking of data if disputes arises from online transactions (4).
Not only companies need Year 2000 contingency plans, but also needs to test those plans. Even if remediation programs are going well, companies should have contingency plans. No matter how much care is taken, some systems will break unexpectedly, as Murphy’s law predicts.
Take BankBoston for example. It operates in 24 countries and exchanges information electronically with about 500 institutions. There is always the potential that its own system would be corrupted if these partners have not prepared adequately. Furthermore, BankBoston lends money to other businesses that must also be Year 2000 complaint.
One cannot assume suppliers and partners won’t have Year 2000 problems that will impact the business(5). Build year 2000 contingency plans on top of existing disaster recovery plans. Like all disaster recovery plans, the Year 2000 plans should be tested under as realistic conditions as possible.
Companies looking to establish a contingency plan should(4):
Cover application software, internal infrastructure and external partners. Most companies are focussing on application software. But the other infrastructure problems can be as big a problem – how does get into premises if lock would not open or places phone calls when the system is out?
External partners should not be ignored at this age EDI. The whole system will fall as easily if EDI partners are not Year 2000 compliant when you are.
Formally document the plan, widely distribute and test the plans. Everyone in the organization needs to know what the contingency plan is.
3. Contingency planning should include legal considerations as well. Prepare for damage claims from customers, partners and shareholders. Shareholder lawsuits will be encouraged if management does not adequately disclose Year 2000 problems. And Document Y2K remediation efforts well.
A case for testing
With passing of time and as the January 1, 2000 nears, testing phase of the Y2K fixes are most likely to be the one to be ignored. The payoff of testing is great and once completed, one can rest easy that all are well. It is not the most fun part of the project by any means but a very important one -- a fix is no good if it does not work.
Securities Industry Association is planning for four testing before the final date gets here. Starting March 6, 1999 it will test all members system on four consecutive Saturdays. The first test will mimic Dec 29, 1999, followed in order by Dec. 30, 31, and Jan. 3, 2000(13).
According to a Eric Hammond, a technology Analyst, thoroughly testing a year 2000 fix requires that one runs it through three tests: functionality testing, year 2000 testing, and system testing. Mission critical systems should be tested first(12).
In the functional testing one makes sure that altered codes work with current date. In the year 2000 testing, an aging data of current data should be tested. In system testing phase all system components are brought together to insure their compliance. System testing is the most time consuming of all the three and generally left behind when time is short(12).
Management needs to fully understand the depth of the Y2K problem in their organization. Simple return on investment and cost-benefit analysis may not be adequate without considering other repercussions that may result due to failure to comply. For many organizations, it may be as simple as either fix the problem while it can or else be out of business. Organizations that are on top of everything will still need contingency planning. As Murphy’s law state: If something can go wrong, it will."
It may be appropriate to conclude by listing Don’t Forget the Basics, 10 Y2K reminders from Greenwich Mean Time, a Y2K software company in Arlington, VA(7):
Don’t panic. While 2000 is an unavoidable deadline, the problem is finite.
Be aware of your liability. Business executives who brush off Y2K compliance may be considered negligent and face huge lawsuits when system fail.
Develop an action plan. If you don’t have one, business partners auditors, bankers and insurers will begin to worry.
Remember the domino effect. Even if your company is Y2K compliant, it is at risk if its customers and suppliers have not addressed the issue in their own systems.
Don’t look for a silver bullet. While tools exist to speed up the repair work, none will automatically solve the problem.
Don’t underestimate the scope of the problem. It affects all companies, regardless of size, an impacts all systems, including PCs.
Focus on business survival, not IT survival. Create backup plan, even if it is as simple as making printed copies of every document you use.
Start now. Otherwise bonuses, profits and share price will be jeopardized by the delay.
Don’t rely on anyone else to solve the problem – they have their hands full with their own year 2000 problems.
Don’t bet your business on promises. Make suppliers guarantee compliance of their systems in writing.
"The Millennium-bug Muddle", The Economist, October 4, 1997, p.17.
Radosevich, L. "Millennium bug already taking its toll," Infoworld, January 12, 1998, p. 1 & p. 19.
"Please panic early: it may not be the end of world as we know it, but the year-2000 bug is already a very expensive nuisance.(Cover Story)," The Economist, Oct 4, 1997, p. 25.
Anthes, G. "Contingency planning when disaster strikes," Computerworld, January 19, 1998, p. 80.
"Beware the Millennium," The Economist, March 8, 1997p. 86.
Maglitta, J. "Fair Warning," Computerworld, January 19, 1998, p. 94.
"Don’t forget the basics," PC Week, March 2, 1998, p. 87.
Neil, S. "2000 reasons to sue: CIOs are standing up for their rights on Y2K problems, but they may face liability themselves," PC Week, March 8, 1998, p. 83.
Benson, M. "2000 bug: group seeks damages cap," The Wall Street Journal, December 10, 1997, p. CA1.
Madden, J. "Smaller Companies Run Big Y2K Risks," PC Week, March 8, 1998, p. 88.
Zirin, J. "Bugs bite, and lawyers litigate," Forbes, July 7, 1997, p. 100.
Hammond, E. "Year-2000 testing issues: Cure for the uncommon test," Infoworld, December 29, 1997, p. 58.
DiDio, L. "Wall Street to test y2K readiness," Computerworld, February 9, 1998, p. 1.
Jagger, D. and Bergeon, R., Managing 00: Surviving the Year 2000, Wiley Computer Publishing, 1997.
Neil, S. "Y2K: You Can’t Insure Your Way Out of This One," PC Week, March 8, 1998, p. 84.