9 Things We Should Learn from the Y2K Crisis

There is always a gap between lessons we should learn and the lessons we actually learn. After expending so much money, so much effort and so much intellectual capital, everyone should get more out of their Y2K experience than a compliant system. There are plenty of issues, good and bad, that came up while organizations tackled the Millennium Bug. Some of these issues will plague business and government for years to come. Some may believe it is premature, but I think it is time to look back and take stock of the past few 'unusual' years in the Information Technology (IT) industry.

Based on my experience, research and discussions with peers the following is a list of nine lessons that should have been learned. It is by no means exhaustive and I hope they provoke some thoughts and ideas from your own experience so you can add the tenth lesson.

Lesson 1: Our dependency on computers should not be underestimated
It may seem obvious to people in the IT field, but the majority of the population remembers (maybe even long for) life before computers entered their daily routine. The Year 2000 crisis demonstrated with absolute clarity that our society, economy and our very well being is completely dependent on the smooth operation of millions of computers. If nothing were done to fix the problem, entire industries and governments would cease to operate.

One of the challenges in the early days for IT Managers was trying to communicate to senior management the seriousness of the Y2K threat not just to the systems, but to the business as a whole. There is ample anecdotal evidence of members of the executive ranks who dismissed the whole thing as "consultant spawned hype" and/or the belief in the "$19.95 solution". They were wrong on both counts. When the enormity of the Y2K problem was appreciated, there was anxiety from some of the executive ranks concerning their organization's dependency on the IT infrastructure and the subsequent cost of repairing the problem. This is puzzling. Streamlining, downsizing and all its other variations to save money and increase productivity was often only possible by increasing an organization's reliance on IT, thereby increasing its vulnerability to the Millennium Bug. The same executives suffering from anxiety often made the earlier decisions to streamline. It could indicate a disconnect between how executives believe an organization operates versus how it actually does, or a lack of long term planning, or both. It will be a challenge for IT Managers to obtain the executives' understanding of the role of IT in business operations.

Lesson 2 - Complex problems require complex solutions
Another flash of the obvious but how many people were waiting for the "$19.95 solution" for the Year 2000 problem? While the Millennium Bug was a relatively simple, technical problem, the impacts on business operations were quite complex. As such, successful resolution of the Millennium Bug could not be isolated to the Information Systems departments. If there were pre-existing frictions between the information systems and non-technical areas of an organization they almost certainly became evident during a Y2K project. As well, an organization's capacity to coordinate efforts that crossed internal, administrative boundaries was also tested by Y2K. Both the IT Managers and business managers should look back at relations during the project. Areas of strengths and weaknesses in coordination should be identified and improvements acted upon. A Y2K project can be used as a case study for an organization to develop mechanisms for coping more effectively with complex issues.

Lesson 3 - Not everything you do is important
This lesson applies mainly to large organizations but it is worth noting. Due to delays in addressing the Millennium Bug, some organizations faced conducting a triage of their software because they had insufficient time and resources to repair everything. The software triage inevitably meant a business triage, a source of considerable debate and differing views. An inability to prioritize business activities is a sign of leadership problems and a possible long- term issue.

The ability to prioritize business activities may have raised other issues. Many people associate criticality with job security. Therefore, would you like to be working in an area classified as "non-critical"? The association is not entirely valid. For example, payroll is critical for a business (most of us will not work for free). Yet, the payroll function can be easily outsourced. A corporate culture change is required to break this association.

For some organizations, applying different levels of criticality to business activities is a new concept. IT Managers should seize the opportunity to exploit this new awareness, particularly when planning is being conducted. The link between the priority of work and availability of resources needs to be strengthened by IT Managers for these organizations. Although there will be endless debate on what is a priority, at least its a starting point to managing the workload effectively since everything is not equally important.

Lesson 4 - Some things your suppliers and clients do are very important
Welcome to the global economy. For many, the Millennium Bug was the first in depth analysis of relations with suppliers and clients. Tracing the interconnectedness of relations between organizations revealed previously unknown risks. The interdependency of businesses, even the failure of competitors could have an impact. Sometimes a company is more dependent on a supplier or a client than on some internal departments. Risk management should become a part of coordinating business relationships in the future.

Lesson 5 - Contingency planning is not a one-time event
Have you ever had to change a flat tire, only to discover the spare tire in the trunk is equally flat? Or have you been in a power outage and all the radios and flashlights have dead batteries? Most of us live our personal lives with little thought or preparation for a disaster. The same is true for most businesses. The reason is because disasters are, thankfully, rare. A strong argument can be made that the cost of developing in depth contingency plans and measures exceed the level of risk (the chance they would be required). But if your organization already made contingency plans for the Year 2000, the cost of keeping them up to date is relatively low. Labor unrest, natural disasters, market ups and downs, and old-fashioned accidents will continue to happen and an organization should be prepared. The easiest way is to maintain your contingency plans in the future.

Lesson 6 - Obsolescence does not equal extinction
We are always amazed by the rapid development of new technologies. Yet, many organizations have been relying on the same systems for decades to fulfil their business functions. Although IT is known for quick obsolescence, it does not mean the technology ceases to be used. Many Y2K inventories discovered old code and hardware components still in operation; some made by companies that no longer exist. (One person quipped to me the system documentation should be written on papyrus) The demand for experts in older technologies jumped as a result of the Millennium Bug. Using older technology may be cost effective in the short term, but the long -term costs include:
1. Lack of vendor support - The vendors cease to exist or no longer support the product.
2. Difficulty finding people with the skills to maintain the system - Schools simply do not teach older technologies. Professionals with the required skills will eventually retire.
3. Difficulty maintaining the system - Decades of enhancements and repairs will make a system very complex.
4. Huge costs when an upgrade or change in technology can no longer be avoided.

Decisions regarding the types of technology to use and when to upgrade or replace them need to be part of a long-range strategic plan. Studies of Y2K costs may provide some hard financial data to include in decisions regarding when to upgrade technologies.

Lesson 7 - Is money the root of all evil?
The Millennium Bug's primary origin was money. Two digit years were used to save space on what was then, expensive disc drives for mainframes. The practice was promulgated to other software and hardware components. Keeping older technologies operating (Lesson 6) exasperated the Y2K crisis. All businesses are under pressure to save money, but a short-term gain may not be worth the long-term price. The savings realized were not savings at all but deferred costs. And the costs for some organizations have been very high. The solution is long term IT planning and investment. Just as civil engineers should factor in maintenance and replacement costs for roads, so should similar costs be part of an overall IT strategy. It is no surprise that these savings would have to be paid for eventually.

Lesson 8 - Should we kill all the lawyers?
I know it is easy to pick on lawyers but the Year 2000 problem has shown what a litigious society we have become. Companies were unable to share good news about their Year 2000 repair efforts for fear if something did go wrong, they could be sued. Legal complications either delayed or blocked organizations from working together, sharing ideas and even communicating with their clients and suppliers. To paraphrase John Locke, law is required to regulate the transactions of private property. But when fear of potential (as opposed to actual) legal problems cripple society's ability to conduct transactions and deal with a problem that impacts us all, then we have another, larger, problem. It is not that law and business do not need a strong relationship, quite the contrary. Yet, businesses must operate both as a legal entity and as a member of society. Both roles for businesses appear to be out of balance. The fear of litigation and the increasing importance of lawyers in business decisions will continue to be an issue for the future.

Lesson 9 - There is a tremendous capacity for change
How many hundreds of millions of lines of code, hardware devices and business processes have been analyzed, modified and tested in the last three years alone? Many organizations went from Year 2000 ignorant to compliant in a very short period of time. Most organizations in the United States and Canada have demonstrated a tremendous capacity for change. Those that have not would be doomed by some other factor if not the Year 2000. Our society may be fragile but it is not brittle. When facing crisis, complex problems or just the day to day of the global economy in the future, we must remember it not only can be done, but it has been done. The Y2K Crisis should be a source of optimism. As outlined in the previous lessons, many problems could have been avoided but hindsight should not diminish the accomplishments of the past few years.

I guess in the dying days of this century my optimism runneth over. I do not believe the Millennium Bug will trigger TEOTWAWKI. Will there be Y2K related problems? Absolutely, but no longer being able to program a VCR is not a threat to civilization. I hope these lessons have stimulated some ideas. I would be very interested in hearing of any tenth lessons (or more) from you.

This Article was published at the Year 2000 Information Center on November 25, 1999.

This Article was referenced by bankinfo.com.