CRITICAL ISSUE REPORT:
FACING THE YEAR 2000 PROBLEM

ISRC - WP - 960401



Leon A. Kappelman
Associate Professor
Business Computer Information Systems Department
Associate Director, Center for Quality and Productivity
College of Business Administration
University of North Texas
P.O. Box 305249
Denton, Texas 76203
Phone: (940) 565-3110
Facsimile: (940) 565-4935
E-mail: kapp@unt.edu

James J. Cappel
Assistant Professor
Department of Business Information Systems
Haworth College of Business
Western Michigan University
Kalamazoo, Michigan 49008-3821


April 6, 1996 (Updated October 10, 1996)




An earlier abridged version of this manuscript was featured in
the July/August 1996 issue of the Journal of Systems Management.

(c) 1996 Leon A. Kappelman. All Rights Reserved.

Copyright Notice: The not-for-profit distribution and use of this manuscript is authorized when done to raise awareness of, or to help solve, the year 2000 computer date problem, so long as credit for authorship is duly noted and the following ownership and contact information included: "(c) 1996 Leon A. Kappelman. All rights reserved. Box 305249, Denton, Texas 76203; Phone: 940-565-3110; Email: kapp@unt.edu" All other rights reserved.

CRITICAL ISSUE REPORT:
FACING THE YEAR 2000 PROBLEM




ABOUT THE AUTHORS

Leon A. Kappelman, Ph.D. is an associate professor of Business Computer Information Systems in the College of Business Administration at the University of North Texas, and Associate Director of the Center for Quality and Productivity. His professional interests include the management of information assets; information systems development and implementation; and benchmarking, measurement, evaluation, and assessment. He has published over two dozen journal articles. His work has appeared in the Communications of the ACM, the Journal of Management Information Systems, the DATA BASE for Advances in Information Systems, the Journal of Systems Management, the Journal of Computer Information Systems, InformationWeek, National Productivity Review, Project Management Journal, the Journal of Information Technology Management, Industrial Management, as well as other journals and conference proceedings. He authored Information Systems for Managers, McGraw-Hill (1993). He is Co-Chair of the Society for Information Management (SIM) Year 2000 Working Group.

James J. Cappel, Ph.D. is an assistant professor of Business Information Systems in the Haworth College of Business at Western Michigan University. He earned a Ph.D. in Business Computer Information Systems at the University of North Texas. His professional interests include group support technologies, ethics, the Internet/WWW, and the organizational impacts of information technology. His publications include articles in the Journal of Systems Management, the Journal of Business Ethics, and the Competitive Intelligence Review.

ACKNOWLEDGMENTS

This work was partially funded by a grant from Harvard, Porter & Associates, Dallas, Texas. The authors also wish to thank the Information Systems Research Center at the University of North Texas, particularly Center Director Dr. Jack Becker for his proofreading assistance and Mark Myerscough for his software support.

CRITICAL ISSUE REPORT:

FACING THE YEAR 2000 PROBLEM

"A problem of rational origin that requires a rational solution"

EXECUTIVE SUMMARY

While there is increasing awareness of the year 2000 date problem, many organizations have yet to take sufficient action to ensure that their systems are "millennium-proof." The year 2000 problem arose from IS professionals applying good economic judgment when business realities were very different. Now, to tackle this issue, organizations need to overcome responses such as denial and anger, and move onto productive problem solving. Given the scope of the effort required and a non-negotiable deadline, the time to act is now. Recommendations are provided for confronting the year 2000 problem head on.

Introduction

In the wake of increased press coverage, most information systems (IS) professionals and their organizations have become aware of the year 2000 date problem facing the business community. However, most organizations have taken little action on this issue to date. Not surprisingly, the Gartner Group estimates that one-half of all companies will not be ready when January 1, 2000 arrives (Bartholomew 1996). Peter de Jager (1995), a keynote speaker and industry consultant, observed in November 1995 that based on his conversations with hundreds of companies, consultants, and vendors, less than 20% of organizations worldwide are addressing the year 2000 date issue. Even among these, most efforts are at an early stage -- focusing on raising problem awareness, assessing the systems affected, and initial planning. Few organizations have embarked on more advanced stages of solving the problem such as revising program code and converting data.

At first glance, particularly to observers outside of the IS community, it appears that the year 2000 date problem was the result of IS departments "dropping the ball." According to this view, IS professionals must have been myopic in utilizing an approach (two-digit year fields) that would eventually lead to systems failure. This paper, however, offers an alternative view of "how we got here," and what is required for an effective solution.

A Problem of Staggering Proportions

Understanding the year 2000 date problem at its most basic level is not difficult. The problem has resulted from the storage of year data in two digits instead of four. This approach has worked for many years since systems could rightfully assume that year data were always preceded by "19." It breaks down, however, at the year 2000 where applications will interpret the year to be 1900 instead of 2000. This potentially causes problems for any systems that include date references, which is most of them. It is estimated that a typical large organization will pay approximately $40 million to address this problem (Bartholomew 1996). Moreover, according to the Gartner Group, fixing the year 2000 date problem will cost about $1 for each line of code in the organization (excluding documentation, training, and final implementation testing), and the total cost worldwide is estimated to be $300 to $600 billion (de Jager 1996).

The year 2000 date problem is more complex and far reaching than a causal observation would suggest. It involves not only modifying source code, but also making changes to other components such as data files, screens, utility programs, packaged applications, reports, interfaces, operating systems, and so on. Its potential impact even extends to building security systems, special embedded devices that activate elevators, copy machines, and other systems that utilize computer chips (McCarthy 1996). Thus, the effect of the year 2000 problem extends far beyond legacy, mainframe-based applications.

Searching for date fields and references in program code is often not easy, since some date fields may be hidden while other fields that look like date fields might not be. Automated tools provide some assistance in identifying potential problems, but there is still a significant amount of manual work involved considering that many organizations have more than 50 million lines of code to search in order to find date problems (de Jager 1995). Programs with no source code or those with hard-coded year changes, for example, are especially troublesome (Gow 1995). Union Pacific estimated that more than 82% of its 7,000 COBOL programs would be impacted by date-related field names; the company selected a vendor to help them update these systems after estimating that it would require 200,000 hours or 100 staff years to convert the programs (Baum 1996b). Two years ago, Nationwide estimated that the year 2000 problem would affect about 20,000 of the company's 35,000 mainframe program modules and cost easily more than $10 million to fix (Jones 1995).

There are many potential problems that can result from what Geoffrey Ward, a partner at McGladery & Pullen, calls the "first century change ever faced by an automated society (Jones 1995). The problem affects a variety of date-critical applications such as loans, payables, receivables, payroll, forecasts, and personnel records (Betts 1995). It can produce program failures or logic errors that can turn debits into credits or assets into liabilities (Jones 1995). For instance, a bank program that uses two-digit year fields for a 30-year mortgage begun in 1992 and ending in the year 2022 could calculate the instrument's time period to be -70 years (i.e., 22-92), resulting in potentially large losses (Celko 1996). Similarly, an inventory retention program that is not "millennium-proof" could throw away good stock made after 01/01/2000, thinking it has been in inventory for 100 years (Celko 1996). There has already been a report of a 104 year old woman in Winona, Minnesota being invited to join a kindergarten class when a database search of people born in "88" turned up her name (Hayes 1995). de Jager (1996) predicts that shortly after January 1, 2000, a major company will fail when its mission-critical systems do not function properly due to the year 2000 date problem, since they have not yet taken action to even determine the size of the problem, and for them, it may already be too late.

A Problem of Rational Origin

Understanding the year 2000 at a deeper level -- the "how in the world did we get here?" level -- requires more of an historical perspective. What will surprise some observers, especially those outside of the IS community, is that this problem resulted from rational decision making. More importantly, these decisions were economically sound when they were made and have saved a great deal of money: Enough, in many cases, to more than pay for "millennium-proofing." The year 2000 problem arose from IS professionals applying sound business judgment at a time when business realities were markedly different. When applications were developed decades ago, an important goal was to conserve hardware (e.g., disk space, memory, registers, etc.) at a time when these resources were very expensive. Kenneth Flamm, a senior research fellow at the Brookings Institution, found that there was a 25% annually compounded price/performance improvement in computing in real dollar terms from 1957 to 1978 (Runyan 1991). Moreover, according to Flamm, the rate of improvement has probably been even greater since then (Runyan 1991).

Thirty years ago, when many of today's legacy systems were designed, the cost of mainframe, disk-based data storage was nearly 2000 times greater per unit of storage than today (i.e., prices have fallen 99.9995% since 1965). If inflation is taken into consideration, the 1965 price is nearly 10 thousand times greater than the 1996 price or about 1 million percent more! Organizational data has a typical date density of 3-6% depending on the industry (i.e., 3-6% of total data storage is date data). Since a MMDDYY date format with a two-digit year uses 25% less storage than a MMDDYYYY date format, the two-digit year format saves about 1% of total storage costs, when the lower 3% figure for date density is used, or about 10 megabytes for each gigabyte of total storage. It is estimated that conserving precious disk space with the two-digit year format saved the typical organization over $1,000,000 per gigabyte of total storage in the 30 year period from 1963-1992 (in 1992 dollars). Factor in the benefits (and presumably profits) generated by these unspent dollars, using a conservative 10% internal rate of return, and the opportunity cost per gigabyte of total storage rises to more than $15 million. These savings estimates can be doubled for date-intensive areas like banking, insurance, securities, credit, and others.

Considered from this perspective, even though addressing the year 2000 date problem requires a significant expenditure of resources, it is actually a "small price to pay" compared to the savings the typical organization has realized from using the two-digit approach (Kappelman and Scott 1996). This is not a trivial point. It should be underscored by CIO's when they make their case to senior management to obtain resources for addressing the year 2000 issue.

Early Response Avoidance Mechanisms

The year 2000 date issue may be looked at as an "impending crisis." That is, it is an inevitable, potentially disastrous occurrence, with an immovable deadline, that affected parties must ultimately "come to grips with" in order to prevent. Consequently, it is not surprising that reactions to the year 2000 problem in many ways parallel the responses that people commonly use to cope with other types of crises such as divorce or terminal illness. These reactions, which may be termed "early response avoidance mechanisms," are shown in Figure 1. They are responses that tend to occur as organizational personnel prepare to accept and deal with an unpleasant reality. Their relevance to the year 2000 date problem is that no problem solving occurs until the full magnitude of the problem is accepted. What is important is that an organization minimize the time and effort spent reaching acceptance and especially not get stuck or linger in any of the early avoidance stages.

Notice in Figure 1 that time is depicted by the length of the line in any direction. The shortest route to millennium-proof systems is a straight, horizontal line. When early response avoidance mechanisms occur, they result in vertical, off-target lines. While these reactions are understandable, they amount largely to wasted effort which does not address the problem. They are only precursors to productive problem solving. Yet, too many organizations are still lingering at various points in these avoidance stages. By understanding these avoidance reactions, organization can potentially minimize their impact.

(1) Awareness. As indicated in Figure 1, the first stage of approaching the year 2000 issue involves problem recognition. As noted earlier, based on the recent attention this issue has received in the IS literature (e.g., de Jager 1993; Furman et al. 1995; Edwards 1995/1996) and to a far lesser extent in the popular business press (e.g., Sullivan 1995; Kim 1996), most IS managers have at least become aware of the year 2000 date problem. Yet, few organizations have mapped out a strategy for addressing this issue.

(2) Denial. Perhaps the biggest obstacle to addressing the year 2000 date problem is denial, i.e., ignoring or downplaying the importance of the issue or its potential impact. Several reasons account for this. To some IS managers, confronting the year 2000 date problem is akin to admitting failure. As de Jager (1994, p. 33) comments, "no one wants to tell management they have a multi-million dollar requirement just to keep the business running." Other IS managers assume the attitude, "I won't be here in the year 2000, so it is not my problem" (de Jager 1994, p. 32). Still other managers may underestimate the scope of the change required and reason that "there is plenty of time left" to address this problem. According to David Eddy of Global Software Inc., while many IS staff members are aware of the impending crisis, many CIO's tend to underestimate the importance of it (Edwards 1995/1996). Managers outside of the IS department may be especially prone to not recognizing the importance of year 2000 date problem. Since little attention has been given to this issue in the popular business press, when senior managers are confronted with this problem by their IS managers, they may have the reaction, "If this is a real problem, why haven't I read anything about it in the press?" (de Jager 1996, p. 76).

(3) Anger. Even after moving past denial and acknowledging the problem, a common response is to look for parties to blame for the "mishap." This may especially be a common response of top management when they first hear about this issue. To many observers, the year 2000 date problem appears to be more of a "tax" or "data virus" than an opportunity. That is, the cost associated with addressing this problem is something that no one wants to pay, it is not value adding, and it is a maintenance expense that is required just to stay in business. Yet, it is not productive to look for scapegoats for the year 2000 date problem since it is really not anyone's "fault." If this were the case, the problem would likely affect only a few organizations instead of being so widespread. To mitigate the potential response of anger from top management, IS managers need to emphasize the rational origin of the problem discussed in the previous section. This approach will enhance the credibility of the IS function in the eyes of top management. It will increase the likelihood that IS management can work with top management as a business partner in forging an effective response to this issue.

(4) Bargaining. Once denial and the search for the guilty are overcome, another response that some organizations take to the year 2000 date problem amounts to a marginal, "band aid" approach. They think that if they just change a few lines of code and data, the problem will go away. For example, some organizations have only patched specific systems as millennium-related problems have arisen, rather than being proactive in considering what problems are likely to occur with other systems. Confining the focus of the issue in such narrow terms may be a sufficient response in some settings. However, in most cases, this approach is short-sighted and oversimplified. It entails a higher risk of failure, and it does not take advantage of potential opportunities that may be presented in a year 2000 conversion such as the chance to retire outmoded or unused systems, add functional enhancements, or migrate data or applications to other platforms. In other words, the year 2000 date problem can be used as a catalyst for change as part of an organization's long-term IS strategy (Edwards 1995/1996).

(5) Acceptance. As shown in Figure 1, reaching this step marks the end of the early response avoidance mechanisms and the beginning of productive problem solving. It is reached when an organization reaches the full realization that this is a business problem that will not go away, it is important, and it must be addressed now. Acceptance means assuming the attitude, "now that we're here, let's move forward." Unfortunately, the year 2000 date problem in most cases cannot be solved in a few days or even a few months. However, the key is to start the productive problem-solving phases as soon as possible. As the saying goes, "even the longest journey begins with a single step."

Productive Problem Solving

The ultimate goal is to achieve millennium-proof applications while maintaining and improving operating effectiveness. "Millennium-proof applications" are "year 2000-compliant" systems that will function correctly as intended when utilizing year data that falls in the next century. As shown in Figure 1, four basic steps are important for achieving this:

1. Impact analysis. The first step of productive problem solving is to do a thorough inventory of applications and data files. This will serve to identify how many applications exist in the organization, their size and complexity, and which components are likely to be affected. An audit of existing systems will also help to identify which programs are frequently and infrequently used, so that unused or duplicate applications can be discontinued. Inventorying systems helps to clarify "where you are now," and it is an important first step in estimating the scope of the effort required for the conversion.

Once an organization's date-sensitive applications have been identified, a detailed impact analysis should be performed. This entails developing an estimate of the magnitude of the change effort required, i.e., how many applications and line of code are affected, and what additional components are affected, e.g., data, load modules, JCL, PROCS, control cards, as well as smaller applications that use downloaded data, hardware, and inter-organizational systems. In many cases, organizations may benefit from the assistance of consultants or millennium service providers to perform a detailed impact analysis. Automated identification tools (e.g., software that identifies which programs obtain dates from the operating system) and software estimation tools are also useful in this effort. According to Xenakis (1995), some leading automated tools that are available for performing an impact analysis and estimating the time and labor resources required for the conversion are Viasoft's Enterprise 2000 and ADPAC's SystemVision Year 2000.

Performing an impact analysis also involves categorizing each system according to its year 2000 exposure level: (1) no exposure; (2) cosmetic and run-time exposures (e.g., systems whose execution results in dates appearing on reports); and (3) date-sensitive logic exposures. The latter systems have routines that perform logic on date fields such as doing arithmetic comparisons and calculations, sorting records, or date validation. These systems require the most effort since their logic must be checked carefully.

2. Planning and scheduling. After an initial assessment of the situation, organizations should develop plans and strategies to get each application "year 2000-ready." This includes defining project stages and prioritizing them. Each application, based in part on its exposure level, needs to be evaluated in terms of alternative, but not mutually exclusive, strategies such as restructuring, redevelopment, redeployment, replacement, and retirement. Restructuring involves modifying program code and its associated objects such as data files, JCL, and documentation. Redevelopment involves adding functional enhancements to existing systems in order to improve their effectiveness. This approach recognizes that since some systems need to be updated for the year 2000 conversion, they might also be improved at the same time; although, care must be taken to not allow enhancements to interfere with time critical, date-related restructuring. Redeployment options include migrating applications or data to other hardware platforms. Replacement entails new or other existing applications taking over. Retirement involves the discontinuance of outmoded or redundant applications. These systems should be identified from an audit of existing systems.

Another consideration is what combination of in-house versus outsourced resources is appropriate for each application. Deciding what strategies will be pursued for different applications impacts budgets and estimates of what other resources will be required to address the overall problem. Harvard, Porter & Associates (1995) estimate that the first two steps of productive problem solving, impact analysis and planning and scheduling, account for about 40% of a company's year 2000 project effort.

Some of the other actions taken to date by progressive companies in organizing for the year 2000 issue include: appointing project managers to be responsible for the overall coordination of the project; contacting vendors and electronic trading partners to determine what action they are taking on the problem; setting a goal to have an action plan in place within a few months; establishing a relatively early goal for project completion (typically in late 1998); and allocating a certain additional amount of non-discretionary money over each of the next few years to address this issue as part of the organization's ongoing maintenance program.

3. Conversion. Once the strategies have been decided on for different applications, they need to be implemented according to the project timetable. The term "conversion" is typically used to refer to the restructuring option, which involves replacing appropriate source code, updating databases and files, and expanding year fields (Meador 1996). Nevertheless, most of the same concerns apply regardless of the options employed: The need for good project management and good change management is essential. Restructuring is particularly a viable option for mission-critical systems, where an organization has good in-house expertise and the cost (in time and/or other resources) to rewrite systems is prohibitive (Scheier 1996). According to Harvard, Porter & Associates (1995), conversion constitutes about 20% of a year 2000 project. Automated tools such as ADPAC's SystemVision Year 2000, which has edit macros, can be used to facilitate source code conversion (Meador 1996).

A conversion approach that uses other automated tools called date-server software (such as TransCentury Data System's Calendar Routines or Computer Software's DateServer 2000) involves changing only source code while leaving the two-digit year fields in place. This option entails inserting Call statements at appropriate places in programs to access external date routines in the date-server packages. While this approach eliminates the time-consuming need to convert files and databases, it does not really "fix" the old programs in that they rely on another set of applications to keep them functioning properly (Baum 1996a). According to the Gartner Group, an organization will probably wind up using a combination of date conversion and date servers. The choice of which approach is used for specific systems will depend upon considerations such as how fast the conversion is needed, how critical is the application, and how many resources are available for the conversion (Baum 1996a).

4. Testing and implementation. Restructuring, redevelopment, replacement, and redeployment all have substantial testing requirements associated with them to ensure that new or modified systems function correctly. For example, with restructuring, changed programs must be recompiled and tested before these systems and their converted files are moved back into the production environment. Every modified system and its interfaces must be tested with year data before and after the year 2000. Automated tools such as date simulation software, that allows systems testing using future and past dates, can be used to ensure that applications maintain their functionality. Examples of automated test tools that are available include HourGlass 2000, TicToc, and ValidDate, which is part of Viasoft's comprehensive toolkit (Xenakis 1995). In many cases, testing and implementation is the biggest and most time consuming stage of a year 2000 project. According to Harvard, Porter & Associates (1995), testing and implementation account for about 40% of an organization's total project effort.

Signs of Progress

The organizations that are farthest along on this issue are banks, insurance, and transportation companies, and governmental organizations. In many cases, these organizations responded to the year 2000 date problem after they encountered some type of "triggering event" such as problems with long-range applications. For example, banks encountered year 2000 problems with long-term financial instruments and mortgages beginning in the 1970s (Lindholm 1996). GTE Corp. became concerned with the risks of the year 2000 date problem at the end of 1993, when date-related problems became apparent. In response, the organization appointed two high-level IS managers to be in charge of their Millennium Date Conversion Project. In August 1995, GTE enacted a policy that said all organization locations had to have a defined and managed data conversion plan in place by April 1, 1996, and all software and operational changes needed to be complete by December 31, 1998 (de Jager 1995).

Massachusetts Mutual Life Insurance Co. reports that it has been aware of the year 2000 date problem for more than 10 years. For awhile, the company responded to this problem in a piecemeal fashion before they realized that a more concerted effort was needed. Looking upon this issue as a matter of company survival, the firm appointed a year 2000 project leader and have hired three service providers to implement the project, which involves reviewing and making needed changes to the company's 45 million lines of code. The effort is scheduled for completion at the end of 1998 (Dieterich 1996).

Among governmental bodies, the state of Nebraska has allocated $11.4 million over four years to restructure its systems, even though the cost has reportedly hit the $31 million mark (Kim 1996). The Federal Reserve Bank began a major upgrade of its mainframe systems in the early 1990s that is still a few years away from completion (Bartholomew 1996). The Social Security Administration began taking action on the problem as part of their regular maintenance activities in 1989, when they had a date-related failure in a debt recovery application (de Jager 1995).

Conclusions and Recommendations

The challenges raised by the year 2000 date problem are significant but not insurmountable. As Lindholm (1996, p. 7) points out, "the toughest part about dealing with the Year 2000 problem may not be figuring out what needs to be done and then doing it, but changing people's attitudes." Clearly, most organizations are not far enough along in terms of productive problem solving for the year 2000 date problem. They must act soon or they risk their very survival in the new millennium. As one writer points out, "to know and not to act is gross negligence" (de Jager 1995, p. 100). While the concept of "gross negligence" is not specifically defined in codes of ethics issued by the Association of Systems Management (ASM) or the Association for Computing Machinery (ACM), the external auditing profession defines it as "an extreme, flagrant, or reckless departure from the standards of due care and competence in performing professional duties" (Taylor and Glezen 1988, p. 115). For example, the failure to audit significant accounts that could materially impact the fairness of financial statements would likely constitute gross negligence for an external auditor (Taylor and Glezen 1988).

Similarly, the year 2000 date problem raises the prospects for a "sin of omission" to be committed by IS professionals. Several provisions of the ASM and ACM ethical codes suggest that IS professionals need to take action on the year 2000 date problem. According to the ASM Code of Ethics, it is the responsibility of IS professionals "to maintain and improve sound business practices and foster high standards of professional conduct" as well as "to maintain high personal standards of moral responsibility, character and business integrity." Moreover, the ACM Code of Ethics (its relevant sections italicized below) holds that IS professionals are responsible for: minimizing "the negative consequences of computing systems" (1.1); reporting "any signs of systems dangers that might result in serious personal or social damage" (1.2); striving for quality in the products of their professional work and being "cognizant of the serious negative consequences that may result from poor quality in a system" (2.1); and providing to their employer a";comprehensive and thorough evaluations of computer systems and their impacts, including analysis of possible risks" (2.5) (Anderson et al. 1993). The "bottom line" is that IS professionals are responsible for the effective development and operation of information systems. When significant events are known to occur that pose significant risks or that will compromise the effective operation of these systems, such as the year 2000 date problem, IS professionals have a professional responsibility to alert management and take corrective action in a timely manner.

To facilitate an effective response to the year 2000 date problem, several key points should be stressed:

1. Organizations must accept the problem and begin solving it as soon as possible. The year 2000 date problem will not magically strike at 01/01/2000 -- its effects are already being felt. For example, a mid-1995 ADPAC survey found that 44% of respondents reported that they were already encountering year 2000 date-related problems in their mainframe applications (Celko 1996). Organizations cannot afford to waste scarce time and resources in the early avoidance response mechanisms described above.

2. The year 2000 conversion problem is often larger than originally envisioned. Cost estimates typically escalate as IS managers take a more detailed look at this problem. Thus, organizations need to inventory their systems as soon as possible to understand and budget for the scope of the effort that lies ahead. The quicker acceptance is reached, the more lead time organizations have to evaluate their current applications, consider alternative solutions, take advantage of opportunities, and avoid the risk of failure.

3. IS managers should confront this issue as business partners with top management. It is important for CIO's to stress to top management that the year 2000 date problem is not an information systems problem -- it is an organization problem. Malfunctioning systems that are not year 2000 compliant can threaten the survival of the business. The year 2000 problem arose from IS managers applying sound business judgment when times were different. Now, they need to continue to work with top management as good business partners in addressing this problem. This means that IS managers need to make a good case to top management about the potential severity of this problem so they commit adequate resources for addressing it. In making their case, IS managers should point out that the cost of upgrading systems dwarfs in comparison to the savings that have been realized in the past.

4. Take advantage of available resources including consultants, training sessions, conferences, automated tools, and Internet resources. Table 1 lists a number of year 2000 service providers and vendors and their contact information. It also shows a sampling of the automated tools that are available to address this problem. While a detailed review of these tools is beyond the scope of this article, some useful information on automated tool options is presented in articles by Furman et al. (1995), Xenakis (1995), Meador (1996), Baum (1996a), and Appleton (1996), as well as in vendor World Wide Web (WWW) home pages, and through the recently-launched year-2000 certification programs of ITAA and MITRE (see Table 2).

Table 1: Year 2000 Service Providers and Vendors

The year 2000 computer date problem is the biggest maintenance problem that the IS community has ever faced. Maybe the largest, highest-risk, most-expensive project humanity has ever faced. Given the tight time constraints and the magnitude of the effort required, it is prudent in many cases for IS departments to enlist the specialized skills and tools of year 2000 consultants, vendors, and service providers. The service options available range from assistance in certain project stages (such as inventory, impact analysis, and/or conversion) to supporting all stages of the project effort. With the growth of interest in the year 2000 issue, consultants, vendors, and service providers are increasingly holding training sessions and conferences. Importantly, those organizations who decide to use consultants, vendors, and service providers are advised to work out their arrangements no later than the first or second quarter of 1997 to avoid getting caught in the rush. Care must be exercised in selecting year 2000 vendors and services providers because there is neither time nor resources to be wasted on the incompetent or unscrupulous.

Table 2 provides a list of additional year 2000 resources that will help IS managers to get the latest word on year 2000 developments and allow them to network with other professionals. These resources include WWW home pages, electronic discussion groups and reports, newsletters, trade associations, and issue/user groups. Collaboration and cooperation among year 2000 project managers is an important element in mitigating the risks of the year 2000 computer date problem.

5. For most organizations there is still time to act, but delaying represents a costly and risky proposition. Organization that have not started a conversion effort by 1996 likely face the greatest risk. Ideally, the conversion should be complete by December 1998, so that there is time to test and run programs through a full business cycle (Appleton 1996). The year 2000 date problem is not something that can be "put on the back burner." Organizations that wait until the eleventh hour, or even the ninth or tenth, to address this problem face the prospects of only partially solving it (which could mean organizational failure) or solving it at substantially higher costs. Similar to a student trying to cram a couple of hours before a major exam, they are flirting with disaster. If organizations wait a year or two to take a serious look at this issue, they may not find sufficient skilled personnel or resources. As John Burns, the Year 2000 Project Manager at Canadian Imperial Bank of Commerce, observes, "In 1997 or 1998, most of IS will wake up and realize they need to increase staff by 30% or some such number, over two years to complete the year 2000 project. If we all require even a 10% to 15% increase in skilled staff, supply will not meet the demand." (de Jager 1995, p. 100). Estimates are that contract COBOL programmers will be fetching $100 per hour within a year.

In the final analysis, the time to act is now.

Table 2: Other Year 2000 Resources

Bibliography

• Anderson, Ronald E., Deborah G. Johnson, Donald Gotterbarn, and Judith Perrolle. "Using the New ACM Code of Ethics in Decision Making." Communications of the ACM 36.2 (February 1993): 98-107.
  
• Appleton, Elaine L. "Call in the Cavalry." Datamation(January 1, 1996): 42-44.
  
• Bartholomew, Doug. "Time's Running Out." InformationWeek(February 5, 1996): 30-40.
  
• Baum, David. "Tool Up For 2000." Datamation (January 1, 1996a): 49-53.
  
• Baum, David. "Union Pacific Stays on Track for 2000." Datamation(January 1, 1996b): 39.
  
• Betts, Mitch. "IBM Pledges Year 2000 Update in >96." Computerworld(November 13, 1995): 79,87.
  
• Celko, Joe. "Start Fixing the Year 2000 Problems Now!" Datamation(January 1, 1996): 36-38.
  
• de Jager, Peter. "Countdown to System Disaster." Journal of Systems Management (February 1994): 32-34.
  
• de Jager, Peter. "Doomsday." Computerworld (September 6, 1993): 105-109.
  
• de Jager, Peter. "If You Start Now...You Just Might Make It." Computerworld (November 20, 1995): 97-100.
  
• de Jager, Peter. "Take a Reporter to Lunch." Datamation(January 1, 1996): 76.
  
• Dieterich, Robert. "Happy Millennium!" Computerworld(March 25, 1996): 86.
  
• Edwards, John. "New Year's Evil." CIO (Dec. 15, 1995/Jan. 1, 1996): 82-87.
  
• Farber, Arnold and Rosemary LaChance. "Time Slips Away." Enterprise Systems Journal (February 1996): 42-48.
  
• Furman, Jeff, Albert Marotta, and Cliff Candiotti. "Party When It's 1999." Software Magazine (April 1995): 6-8.
  
• Gow, Kathy. "Simple Problem, Ugly Solution." Computerworld(November 20, 1995): 98.
  
• Harvard, Porter & Associates, Inc. "The Year 2000: A Critical Cost Containment Challenge." Working Paper (July 5, 1995).
  
• Hayes, Brian. "Waiting for 01-01-00." American Scientist(Jan.-Feb. 1995): 12-15.
  
• Jones, David C. "Solving the Year 2000 Problem: A Long and Costly Project." National Underwriter 99.25 (June 19, 1995): 5.
  
• Kappelman, Leon and Phil Scott. "Year 2000 Problem: A Small Price to Pay" (in press, Computerworld, 1996.)
  
• Kim, James. "Year 2000 Problem Poses Computer Software Headache." USA Today (March 8, 1996): 1B.
  
• Lindholm, Elizabeth. "1460 Days and Counting." Datamation(January 1, 1996): 7.
  
• Meador, C. Lawrence. "Solving the Year 2000 Problem." InformationWeek(February 5, 1996): 44-51.
  
• McCarthy, Vance. "Keep the Millennium Virus Off Your Net." Datamation (January 1, 1996): 55-56.
  
• Runyan, Linda. "40 Years on the Frontier." Datamation(March 15, 1991): 34-38.
  
• Scheier, Robert L. "Face up to It." Computerworld(March 25, 1996): 83-84.
  
• Sullivan, R. Lee. "Ghosts in the Machines." Forbes (June 19, 1995): 92.
  
• Taylor, Donald H. and G. William Glezen. Auditing: Integrated Concepts and Procedures New York: John Wiley & Sons, 1988.
  
• Xenakis, John J. "The Year 2000 Surprise." CFO: The Magazine for Chief Financial Officers 11.8 (August 1995): 22.
  

Other Readings of Interest

• Brown, D., "So You Think the Year 2000 is Just a Mainframe Problem," Gartner Group, Research Note, Strategic Planning, RDS-0596, (30 May 1996).
  
• Castelluccio, Michael, "One Year Closer to Doomsday," Management Accounting, (January 1996).
  
• de Jager, Peter, "Lock up Your Year 2000 Staff," Datamation, (15 May 1996): 102,
  
• de Jager, Peter, "Systemic Triage," American Programmer, (February 1996): 12.
  
• Hoffman, Thomas, "Overseas: One Solution to Year 2000," Computerworld,(29 April 1996).
  
• Hoffman, Thomas, "Biting the Bullet," Computerworld, (18 March 1996).
  
• Jones, Capers, The Global Impact of the Year 2000 Software Problem , (SPR, Inc. Version 3, 20 August 1996): www.spr.com.
  
• Jones, Capers, The Economic Impact of the Year 2000 Software Problem in the United States, (SPR, Inc. Version 2, 24 February 1996): www.spr.com.
  
• Kappelman, Leon and Jim Cappel, "Confronting the Year 2000 Issue", Journal of Systems Management, (July/August 1996): 4-13.
  
• Kearney, Dick, "Beating the Clock," InformationWeek, (15 April, 1996): 66-71,
  
• Keuffel, Warren, "Coping with the Year 2000 Rollover," Software Development Magazine 4.8, (August 1996),
  
• Kilmar, Thomas and Roxane Wasserman, "Pros/Cons Procedure vs. Data," American Programmer, (February 1996).
  
• Lowenstein, Roger, "The Year 2000 and the CEOs' Big Secret,"The Wall Street Journal, July 25, 1996, sec. C1.
  
• Miller, Harris, "Are Your Computers Ready for the Year 2000?" Executive Update (June/July 1996):44.
  
• Nathans, Leah, "Panic in the Year Zero Zero," Business Week, (12 August 1996): 72-73.
  
• Petzinger, Thomas Jr., "The Front Lines - "be Lichtig Answers Alarm at Con Ed for Year 2000 Crisis," The Wall Street Journal,(5 July 1996): B1.
  
• Reid, Warren S., "2001: A Legal Odyssey," www.year2000.com/legal.html.
  
• Society for Information Management Year 2000 Working Group. Solving the Year 2000 Computer Date Problem: A Guide and Resource Directory, edited by Leon A. Kappelman. Available Fall 1996: SIM, Chicago: www.simnet.org.
  
• Weinberger, Caspar W., "All for "Naughts"," Forbes, (29 July 1996): 25.
  
• Williamson, Miryam. "Will Your Computer Systems Survive the Year 2000?" CIO, September (15 September 1996): 53-64.
  
• Zvegintzov, Nicholas, "The Year 2000 as Racket and Ruse," American Programmer, (February 1996): 16.