Mitigating Year 2000 Projects Risks
Leon A. Kappelman, Ph.D.
Co-chair, Society for Information Management (SIM) Year 2000 Working Group
Associate Professor, Business Computer Information Systems
Associate Director, Center for Quality and Productivity
College of Business Administration, University of North Texas

Technically speaking, taken one program or one file at a time, solving the year 2000 computer date problem is not especially difficult. IS professionals have been replacing, upgrading, and maintaining applications for many decades. The real problem, and the real crisis potential, is in the simple facts that most programs talk to other programs, most files are shared by several programs, much of the world's daily economic transactions take place electronically, and dates are critical to keeping all this digital documentation and communication and infrastructure functioning properly. The usual one-at-a-time strategy simply does not work this time unless implemented as part of a comprehensive, all-inclusive year-2000-compliance project plan that includes all of the information assets of a particular enterprise, as well as all of the links and connections in and out of that enterprise. The result is an enormously large and complicated project. The kind of project that IS professionals tend to cancel, delay, and deliver late.

In fact, according to Capers Jones' (1996) analysis of over 7000 software projects from over 600 organizations, in the worst-managed IS shops a project with 5000 function points (about 525,000 COBOL source code statements) has a .85 probability of being late and a .40 probability of being completely canceled: Not particularly viable options with year 2000 projects. Yet even in the very best-managed shops, the probability of being late is still .22 with total cancellation down to .01. But even a 1% overall failure rate of year 2000 projects could have profoundly negative economic consequences given that even those enterprises that solve their own year-2000-related problems will face injury from the errors or failures of those that do not.

To make matters worse, most year 2000 projects will be many, many times that size. And IS professionals know all too well that increased size increases project risk and the likelihood of problems keeping projects on-time, on-budget, and as-specified. According to the Society for Information Systems (SIM) Year 2000 Working Group's status and benchmarking study (Kappelman, 1996)¹ that was conducted during August and September 1996 and included over 200 organizations representing most sectors of the economy, about 75% of year 2000 projects will be larger than 50,000 function points in size, with nearly 20% exceeding 1.9 million function points. The SIM study also indicates (differences by industry, size, enterprise age, and IS management practices aside) that about two-thirds of all applications are affected, about one-third of data files will be modified, nearly 4% of all source code is missing, and the cost will be about 25% of the annual IS operating budget, with some estimates exceeding annual budgets several times.

Sadly, far too little progress appears to have been made toward solving the problem (Committee, 1996; Kappelman, 1996). The SIM study indicates that only about 20% of enterprises have completed their inventories and impact analyses, with another 25% making reasonable progress; and less than 10% of enterprises have established their plans, schedules, and budgets, with another 15% making reasonable progress. Not particularly reassuring numbers. But what does the SIM study says about the prospects for increased progress?

According to the SIM study, about two-thirds of enterprises have someone in charge of year 2000. Of these, about half have had the assignment over 6 months and only 10% for more than a year. That might be all right if these were full-time year 2000 project managers (Y2KPMs). Sadly, of the 75 Y2KPMs reporting, on average they were dedicating only 41% of their time to the project, only 35% were spending more than 50% of their time, and only 25% were "full time" (i.e., spending more than 80% of their time). Is it any wonder that the SIM working group concluded that "at best" about 1/3 of enterprises are making reasonable progress, 1/3 are running behind but will likely mitigate most of their year 2000 risks, and "one-third are simply headed for disaster" (p. 34).

Regardless of hardware platform or application age, the transaction processing backbones of most organizations are at risk, as well as most of the world's manufacturing plants, communications and navigation systems, security and environmental control systems, water and sewer systems, chemical plants and military weapons systems, and even nuclear energy plants and waste facilities. Until every governmental, business, educational, and other enterprise on the planet completes its own risk assessments, no one knows for sure the magnitude of the problem or the extent of the work required to mitigate it. It seems that the year 2000 computer date problem is certainly the biggest IS maintenance problem ever; probably the largest IS project ever faced by most enterprises; and maybe the largest, highest-risk, most-expensive project ever faced by humanity.

What can one do to reduce the risks their enterprise faces from year-2000-related problems?

1. Make sure your enterprise is dealing with its own year 2000 problems. You must have a full-time year 2000 project manager. You must know what is at risk, when it will fail, and what it will take to fix it. You must have plans, schedules, and resources based on comprehensive inventories, risk assessments, and pilots. You must know your priorities and what can be delayed.

2. Get top management, legal, and audit involved, as well as marketing, manufacturing, logistics, and sales. Make them aware of the risks both internally and from external sources. Get them involved in risk assessment and mitigation.

3. Do everything you can to raise the visibility of year-2000-problem risks within your enterprise, among all trading partners (e.g., customers, suppliers), in the investment community (e.g., brokers, analysts, portfolio managers), and in your community at large (e.g., utilities, county and municipal governments, school boards, state and federal officials).

4. If their failure can impact you, plan for the contingencies. This includes contingency planning for your own project's potential failures. But you must also know what your trading partners, competitors, utilities, and financial institutions are doing. Sadly, it appears that many may not be ready in time. You must protect yourself from those that may fail; but also, you may want to prepare for the fire sales that will likely take place when some enterprises realize that an acquisition may be their only hope for survival.

If you do your job well, in the end some may say that you over-estimated the magnitude of the problem, that it was easy to solve, and that you were overpaid. While this may be regrettable, it is better to be seen as under-challenged than as incompetent.

Note

1. This complete study is reported in the SIM Year 2000 Working Group's 111 page white-paper report "Solving the Year 2000 Computer Date Problem: A Guide and Resource Directory." This manuscript (which also contains a year 2000 project life cycle with extensive things to do checklists, an international date standard with usage guidelines for old and new applications, size and progress benchmarks from a nationwide study of year 2000 projects, and a comprehensive resource directory) is available to SIM members for only $75. Non-SIM members pay $200 per copy. Obtain copies by contacting Laura Gramling at SIM headquarters 312­644­6610 or emailing her at Laura_Gramling@sba.com. Proceeds help support the Working Group's ongoing year 2000 benchmarks/status study and the establishment of the Working Group's website where year 2000 project managers will be able to share their best practices. SIM is a nonprofit organization of IS professionals.

References

• Committee on Government Reform and Oversight (1996). Year 2000 Computer Software Conversion: Summary of Oversight Findings and Recommendations, (September 27), U.S. Government Printing Office, Washington, DC.
  

• Jones, C. (1996). "The Impact of Software Cost Estimating on Projects that Fail or Succeed," Knowledge Base, 5(1), (January), Software Productivity Research: Burlington, MA. Website: www.spr.com.
  

• Kappelman, L. (Editor): Astwood, R., Bettinger, D., Elliott, K., Hale, M., Kappelman, L., Kucera, K., Long J., Miller, J., Rader, J., Rosemond, C., Scott, P., Seliquini, K., Spears, M., Westbrook, D. (1996). Solving the Year 2000 Computer Date Problem: A Guide and Resource Directory. Society for Information Management (SIM) International: Year 2000 Working Group, Chicago.
  

© 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.