I

N

S

I

G

H

T

Y2K Demystified
by G. M. Samaras, PhD, DSc, PE, CPE

Introduction

By now, ‘most everyone has heard of the Y2K (year 2000) problem. No, the solution is not the process of changing all the dates from "y" to "k" (Januark, Februark,….). It is a business problem of unprecedented proportions, but susceptible to standard management solutions. As with every problem, you first have to understand the problem (and all its dimensions), before you begin attempting to solve it. It is a business challenge that you cannot avoid and you must make a commitment to solving it for your particular enterprise.

In this brief article, you will learn that:

The Y2K problem has very little to do with the year 2000 AD; we will identify the source of the problem, the locus of the problem, and the conceptual difference between software and hardware.
It is a classical business engineering problem; you can implement an innovation approach, a kaizen approach, or a combination of the two.
You can manage this problem to your advantage, just as you have successfully managed numerous other business challenges; we will identify a structured, systematic approach for continuation planning – consisting of contingency planning, event management, and target date strategies.

Defining the Y2K problem

It is a common misconception that horrible things will happen on or about December 31, 1999. This is NOT true. Problems related to Y2K have been occurring for the better part of 30 years … and will continue to occur long after January 1, 2000 – which is why this is an important management problem that warrants your attention. It is, however, true, that the frequency of problem occurrences is predicted to increase during the 1999 – 2001 time frame. What is the source of the Y2K problem?

PROBLEM SOURCES

Data Operations (with 2 digits)

Leap year calculations (2/29/2000 exists)

Special Meanings (e.g., 9/9/99 or 0/0/00)

Combinatorial Software effects

Human Errors (ergonomic issues)

There appear to be five (5) fundamental problem sources associated with the Y2K problem.

Many are now aware that the year 2000 AD will be a leap year – but this is actually due to a little known 3^rd rule (leap year rules: every 4^th year, not on years divisible by 100, but on years divisible by 400).

Some are aware that programmers routinely gave date codes in the far future (theirs, not yours!) special meanings; these special codes would signify an end of file (EOF), or an end of process (EOP), or some other event totally unrelated to the actual date code.

Few of us tend to remember that multiple small errors in computer programs will result either in cancellation (you will notice NO effect) or in amplification (a bunch of small errors will turn into a BIG problem).

Finally, we all tend to forget what history repeatedly teaches us – each time there is a crisis or a disaster, the human factor often dramatically compounds the problem (see "Set Phasers on Stun" by Steven Casey, 1998, ISBN 0-9636178-8-5).

Everyone, by now, is aware of potential problems with data operations (storage, transfer, output, and calculations) using 2 digits. These include no only obvious operations, such as erroneous date-related operations, but also more subtle problems such as overflows in database fields or other unexpected violations of the original programmer’s explicit or implicit assumptions.

That is all quite interesting, you may say, but "Do I have this problem, and if so, where is it?"

PROBLEM LOCUS

In Everyone’s system

In YOUR mainframes, desktops, & embedded chips

In YOUR suppliers & distributors & regulators systems

In non-date sensitive devices

Much to our chagrin, it appears that the problem is in everybody’s system. It is in your mainframes, desktop computers, and the embedded chips in your office equipment, your manufacturing equipment, your quality control equipment, and your calibration equipment. Furthermore, your dependable suppliers, distributors, and regulators have exactly the same problem – and if they do not fully appreciate the problem they are not going to properly correct it; this will adversely impact your business! Finally, and only poorly understood by most, the Y2K problem even exists in devices that do not externally appear to be date sensitive or date dependent. Virtually all silicon chips are made primarily from an assemblage of pre-designed library modules – if the chip has a non-compliant library module, it may have a failure problem.

Most of us can relate to "hardware" problems. They are tangible, understandable, and part of our everyday experience. Very few of us (including many good programmers) can properly relate to "software" problems. Understanding the difference between hardware and software is crucial – not just from a safety and reliability perspective, but also from a testing perspective; if you use hardware style tests for software, you will get back irrelevant results.

Understanding the difference between hardware and software is crucial

Let us briefly review some of the big differences between hardware and software, so as to gain an appreciation of the conceptual differences:

Unlike hardware, where making identical copies is a challenge, the hardest thing for software is getting the original to work properly.
Unlike hardware, even short (tiny) programs can be very complex and quite difficult to understand.
Unlike hardware, neither static nor dynamic testing alone can verify that software is complete and correct.
Unlike hardware, software is intangible and does not wear out; in fact, software often improves with age, as latent defects are identified and corrected.
Unlike hardware, software is easy to modify (thus the term ‘soft’), giving the FALSE impression that software problems can be easily corrected.
Unlike hardware, software cannot have preventative maintenance (PM) programs; repairs to software create a NEW DESIGN!
Unlike some hardware testing, correctly testing software requires following rigorous, statistically appropriate techniques and procedures.

Management Solution Approach

Now that you appreciate certain aspects of the Y2K problem and understand that it can impact your business, affecting your revenues, your product quality, your customer’s loyalty, and your regulatory position, what can you do about it? As usual, the answer is good management. And, since every business problem can be turned to a business opportunity, you need to think about how the time, effort, and other resources you use can improved your current enterprise.

In general, the evaluation of your organization’s susceptibility to Y2K problems either internally or externally (from your suppliers, distributors, and regulators) is a business process engineering endeavor. There are two diametrically opposite approaches: the Hammer & Champy innovation style re-engineering approach versus the Imai kaizen style continuous process improvement approach (see Hammer & Champy, "Reengineering the Corporation", 1993, ISBN 0-88730-640-3 and Imai, "Gemba Kaizen", 1997, ISBN 0-07-031446-2). You would be best served by employing a combination of the two called the Ergonomic Quality approach, which institutes an ergonomic focus on all aspects of the enterprise (see Gross, "The Right Fit", 1996, ISBN 1-56327-111-7). With this approach, you re-examine and re-assess all your business processes not only for Y2K concerns, but also to improve the efficiency and effectiveness of the entire enterprise from a user perspective.

Implementing the "fixes" is only a small part of the management solution

Risk assessment and risk management start with a hazard analysis; its not just for medical devices or pharmaceutical products, it works for the whole organization. An incomplete hazard analysis (or a wrong criticality assessment or a wrong test strategy), inadequate resources (insufficient time for testing, lack of management commitment or administrative support, or insufficient personnel and test equipment), or improper post-test revalidation (test-related failures) are all issues that need careful management attention. But doing the assessment, developing the remediation plan, and implementing the "fixes" is only a small part of the management solution.

The truly important and difficult part of the management solution is the continuation-planning component. It consists of the triad of contingency planning, event management, and target date processes. This is the core of the risk management process, since - not matter how hard you try - you and your staff cannot fix all the problems or prevent all the adverse events. It is here that you systematically think through how your organization will respond to a particular crisis (internal or external), who will be responsible for managing a particular crisis, and what parameters cannot be exceeded without damaging other aspects of the enterprise. It is this process of thinking through the events that may confront you that will give you the tools and confidence to handle the crisis.

CONTINUATION PLANNING

Contingency Planning – expected or predictable problems

Event Management – unexpected or unpredictable problems

Target Date Processes – known or suspected transitions

For further information, click on the hyperlinks below. Our staff can assist you in all aspects of your managerial efforts – from strategic planning to project management to test protocol development and analysis of results. We can help your staff analyze your enterprise and implement a structured, systematic program of risk management and process improvement – so that your efforts in the Y2K arena will not only protect you, but improve your ability to compete in the market place.

Further On-line Information

Y2Ktoday is one of a number of centralized, on-line information sources on the Y2K issue with information by economic sector and with a good list of web-based resources (see link on lower left of their home page)
The U. S. Senate has a Special Committee on the Y2K Technology Problem that has its won home page and has recently published a detailed report on their findings
The Food and Drug Administration maintains an on-line information resource, "Year 2000 on Biomedical Equipment".
Some folks aren’t sure that the problem will be fixed in a timely manner. Two examples are:
Matt Hettler’s article which provides every manager with a quite checklist to ascertain the veracity of staff claims and assurances.
Hayes’ & Ulrich’s article discusses "Getting Your Clients Beyond the Obvious Problems" and addresses a number of real incidents that should encourage you and your management team to be more critical in your evaluations.
Advice on Microsoft’s web site to technology providers, consultants, and resellers includes "Avoid Y2K traps with Good Project Management" (this gives some embarrassing statistics on delivering projects on time and on budget), a primer on "Y2K Remediation Techniques" (ways of actually fixing the software), a simple risk assessment process for "Understanding Year 2000 Risk", and brief summary of the various competing "forces" supporting and opposing Y2K projects.

If you have any comments on these INSIGHTS we hope that you let us hear them. If you have any of your own INSIGHTS that you feel would be of value to other companies, we would be pleased to hear from you and to discuss them with you and if you allow, we would even put them up on this site for others to learn from.
e-mail INSIGHT