Many information technology phenomena, such as the Internet and the Year 2000 problem, have become extremely well known. Other information technology activities are so well integrated into our daily activities that we even forget they are there. These include not only computer systems, but also telephone, satellite and data networks, control systems in industry, bank teller machines, controls for elevators and air conditioning, and many others. These become highly visible when they do not work .

And also at budget time.

The so-called Year 2000 problem or "Y2K bug", however, presents a major challenge to organizations worldwide.

What is it?

Simply that many systems and controls around the world using computing technology will not be able to tell the difference between the year 1900 and the year 2000. In benign cases, the outcome will be a wrong answer (a 105-year-old lady receives a letter asking her to report to a primary school—to the computer, she is five years old). In serious cases, the computer system, not knowing how to handle the dilemma, will just give up and fail to work.

Why does the problem exist?

In the early days of commercial computing, memory was a highly specialized and expensive resource. Programmers had to be creative to get around memory limitations and one of these shortcuts consisted of leaving out the first two digits from the year. After all, nobody expected the life of their programmes to reach 30 years and, besides, the next generations of programmers would fix the problem. Unfortunately, for most organizations, both assumptions proved to be wrong.

The Gartner Group—respected information technology industry analysts—estimates that the total cost to resolve Year 2000 problems around the world will reach $600 billion. The impact of this on budgets and resources for information technology is without precedent.

Will the world come to a stop on 1 January 2000?

The doomsayers say yes. This is debatable. There are many computer systems that can be described as "sinkers" if they fail. These include all the transaction oriented systems used by banks, airlines, air traffic control and railways, the logistics and distribution industries, automated manufacturing and telephone exchanges and their control systems. Because of this, all of these systems are the subject of considerable attention and effort.

The general approach to this project contains the following steps:

Problem awareness: Is this really relevant to our organization? Denial to acknowledge that a problem exists and needs to be fixed will cause delay in taking appropriate action and lead to malfunctions.

Inventory and impact analysis: This includes a review of the following:

What are the information technology systems in the organization? Out of all these—which may include payroll and other systems, the control of elevators, building security systems, telephone exchanges, Internet Web sites, etc.—some, if not operational, could paralyze the organization, whereas other could cause anything from serious inconvenience to acute public embarrassment.

• Date dependencies: This is an analysis for each of the systems and facilities deemed to be critical to determine how many processes, programmes and subprogrammes involve date calculations, this in turn allows the amount of work to be done to be estimated.

• The date problem: A large part of the project consists of selecting the approach to be taken. The three main options are: replacing the system; replacing all date fields in programmes and data bases and date formats in calculations with a four-digit format; and making the programme believe that it is dealing with a four-digit year formats without modifying the original software or databases (the "windowing" approach).

Whilst some tools exist that can automate part or most of the fixing process, these have limitations and there is no "magic" solution that can be applied.

Much work still needs to be done manually and this, in turn, requires complete, up-to-date and quality documentation about the original programme. Regrettably, the older the programme, the less likely it is that this documentation can be relied upon.

If, of course, it still exists.

• The domino effect: In our increasingly networked world, computerized systems exchange data. These systems are often owned and managed by different organizations and, in these circumstances, the failure of one of them to achieve Y2K compliance will impact the operations of others. For example, employees' pay involves their employer sending data to their banks to credit accounts with the appropriate amounts. If the payroll system is compliant, but either the bank or the network provider is not, the transaction will not be completed.

• Testing: All the software modified to meet the Y2K problem needs to be tested, first as individual modules and then as part of the total system software. This is a major undertaking as tests must be comprehensive. As tests cannot be carried out with the (non-Y2K compliant) production system, copies must be made for the system and at least some of its data for testing purposes. In many cases, this requires additional computing and storage capacity or contracts with companies that can provide such a test environment.

• Production systems: Even if all the applications software and databases have been made Y2K compliant, it is essential that all the processing equipment—hardware, operating system and utilities software, communications sub-systems, etc.—is also Year 2000 compliant. This is another complex task as it relies on compliance warranties from vendors who may not yet have a complete range of compliant products or may be unwilling to issue such warranties.

• Management: Projects of this size, complexity and criticality can only succeed if they have the commitment and support of top management, are properly funded and resourced, and, most important of all, if they have the detailed planning and project management throughout their implementation.

• Contingency planning: All systems of importance should be supported by a contingency plan in case the above processes cannot be completed on time or are unsuccessful. These system should be taken out of service and replaced by the contingency arrangements, which should be tested in advance. These arrangements need to be supported by effective communications to the media and/or the public to avoid a public relations disaster.

The information technology industry acknowledges that the strategy of replacing systems also carries the highest cost and project risk. This limits an organization's capability to replace all its systems at once and, therefore, the approach has to be one of mixing the replacement and fixing non-compliant systems. Fortunately, the Year 2000 compliance was recognized some time ago as an important factor in the information systems strategy in the United Nations.

About the Author:

Eduardo Gelbstein joined the United Nations system in 1993 as Director of the ICC. Prior to this, he worked with British Rail. His work included project management of several major information technology projects, the chairmanship of the Business Information Technology Steering Group for the whole of the railway, and setting up and managing the information technology group of the largest business unit created prior to the privatization of the industry. What's Happening @ un.org?.