Executive Overview

The Year 2000 Software Problem

A Rational Approach


The Year 2000 Software Problem is a fact of life.

Every organisation must take action to ensure that its viability will not be adversely affected.

Considering that time is now running out, there may not be sufficient time left to do a comprehensive inventory, followed by detailed assessments of all hardware and software that an organisation uses, as has been suggested by most early Y2000 methodologies.

This paper presents an outline of how the problem may be addressed. You are free to make copies of this document available to others, providing that the usual rules of copyright are observed.

Elmar Roberg
Business Transformation Services
PO Box 7367, Westgate, 1734 South Africa
Phone   +27 (82) 651-5138
Fax             +27 (11) 954-3411
e-mail  roberg@iafrica.com
Copyright (c) 1997 by Elmar Roberg,
Business Transformation Services
All Rights Reserved
The Year 2000 Software Problem is likely to turn out to be the greatest challenge ever faced by the IT (Information Technology) industry.

Because of the pervasive nature of the use of IT in all sectors of the national economy, this challenge will quite likely be transferred to the whole economy.

Some analysts have expressed concern that many businesses and other enterprises may fail as a consequence of the software problem.

Since the economy does not exist in separate and independent parts, but is a cohesive whole, problems in one company may easily affect the effective operations of another - for example, the supply chain.

Description of the Problem

Early Year 2000 methodologies have emphasised the need to do a comprehensive survey of all hardware and software (IT components) in the organisation, and then to set about ensuring that every component is compliant, by either fixing or replacing it.

Regrettably, this approach has become a luxury that many organisations can no longer afford:

* There is the strong possibility that organisations will find out, too late, that there is not enough time to complete the renovation programme. The Year 2000 Problem has a fixed end date. If all required changes are effected by that time, no postponement of the date will be allowed.

* Smaller organisations, especially, just do not have the resources (money and people) to execute such a comprehensive programme.

* It may not actually be necessary for every IT component to be compliant.

Basic Definition of Compliance

There is currently no universally accepted definition describing "Year 2000 Software Compliance".

For the purposes of this article, compliance is taken to mean Information systems are Y2000 compliant if they are "able to accurately process date data - including but not limited to, calculating, comparing, and sequencing - from, into, and between the twentieth and twenty-first centuries, including leap year calculations." (Washington State Government)

Business Value vs. Cost

There is a tendency in enterprises to make decisions on the basis of historical actions and decisions, rather than on the impact on the future.

For example, if an enterprise has just spent a large sum of money on the installation or development of a new computer system, and it then becomes evident that the system is not addressing the enterprise's needs, it is a tough decision to decide that the system should be discontinued.

For the purposes of addressing the Year 2000 problem, we shall take value to mean "what an IT component means, or adds, to the business".

For example, Lotus 123 or MS Excel has no inherent value unless it is used to create spreadsheets for some purpose.

If this spreadsheet becomes critical to the running of the enterprise, and it can only be used with a given version of the spreadsheet software, then the spreadsheet software assumes connected value, i.e. it has value because of its connection with the sp readsheet that the enterprise relies upon.

However, the moment use of the spreadsheet is discontinued, the value of the software to the enterprise disappears.

Regrettably, the cost of the spreadsheet software tends to cloud judgement when the tough decision has to be made whether to discard the software.

A Rational Approach

A more rational approach is to focus on the value to the business of an IT component and to make decisions on the basis of this value. This is the approach that we would like to propose in this paper.

Any enterprise is supported by functions which are performed in the execution of its day-to-day work. These functions are in turn supported by systems (whether manual or automated). People and other resources are then used to execute these systems.

Prioritise Functions.

The first step should then be to identify the functions in the enterprise. These functions can then be categorised according to their importance to the healthy operations of the enterprise.

Prio A: Extended downtime, incorrect operation or incorrect data output can threaten the viability of the enterprise (e.g. the sales order processing function).

Prio B: As above, but viability is not threatened. Loss of function can seriously impact the ability of the enterprise to operate at full potential (e.g. the payroll function).

Prio C: Functions that make life easier, however, the enterprise could operate without them, or manual workarounds can be developed (e.g. sales reporting).

Prio D: Nice to have functions that the enterprise could just as easily do without. These tend to be functions created by persons for their own use. When the person leaves, they tend to become Prio E type.

Prio E: Functions that add no value to the enterprise. These are typically functions that are a legacy of the way the business used to operate in the past - they should have been discontinued but haven't. There are many such instances in most organisatio ns - they act like the silting of a dam. They consume energy with no benefit whatsoever.

Determine Risk

Having identified the priorities, we then need to determine the level of exposure for each function. We can categorise them as follows:

Risk Level A: Will fail if not fixed.

Risk Level B: Uncertain of impact. Requires more investigation. (Includes all packages and COTS Commercial-Off-The-Shelf software.)

Risk Level D: Requires fixing, but workaround is possible. (Can choose whether to develop workaround or fix.)

Risk Level D: Appears to be Year 2000 Compliant. (No fixing required, but may have to be included in certification testing).

Risk Level E: No date processing involved.

Determine Urgency

Next, each functional component should be identified according to the urgency with which it must be addressed.

The basis would be the earliest date by when failure could occur (for example, a stock control system may record the expiry dates for products; if the life of the product is 18 months, the date when the software could start showing symptoms of failure would then be 1 July 1998).

If the problem is not fixed before 1 July 1998, the enterprise would be negatively affected. A useful method would be to identify urgency as follows:

Urgency 1: Must be fixed by 31Dec97
Urgency 2: Must be fixed by 31Mar98
Urgency 3: Must be fixed by 3Jun98
Urgency 4: Must be fixed by 30Sep98
Urgency 5: Must be fixed by 31Dec98
Urgency 6: Must be fixed by 31Mar99
Urgency 7: Must be fixed by 30Jun99
Urgency 8: Must be fixed by 30Sep99
Urgency 9: All the rest.

We could then prioritise each function and functional component according to the general classification:

Prio-Urgency (e.g. A-1). As a rule, the highest priority components should be fixed before any lower priority items are even considered.

Reaction Strategies

There are many different types of IT components.

They could be categorised into mainframe systems, client/server technologies, packages, system software, utilities, end user software and PC software.

Each of these categories will typically be addressed in a different way.

The generic strategies for addressing the Year 2000 Problem are:

Retirement: remove the components from use.

Replacement: upgrade to the latest version, or replace with a compliant version through new development or purchase.

Fixing: may be a physical fix where programs and databases are changed to include the century in dates; logical fix, where a fixed or sliding date window is introduced with the use of bridges; combination of the above; data compression and day counter.

Develop Workaround: manual procedures are developed to provide a temporary solution (this would be especially attractive if there are plans to retire, repair or replace components in the future.

Elimination and Consolidation: if two components perform similar functions, they could be consolidated with some of the components being eliminated. (Don't re-engineer, obliterate.)

Transfer: it may be possible to outsource the maintenance and operation to another enterprise that already has appropriate functions in place.


It is not the purpose of this paper to offer a comprehensive discussion of the Year 2000 Problem and its resolution. We have attempted to place the problem into perspective and offer an overview of how it may be addressed.

If you require more information about the problem and its resolution, we would like to refer the reader to the following materials obtainable from the sources indicated.

Elmar Roberg is chairman of the CSSA/PMI Y2000 SIG. He entered into the data processing industry in 1972, starting in operations, moved to programming of accounting machines and the first mini computers and progressed to project management, data processin g management and consulting on mainframe and other technologies. Elmar has held positions which have included programmer, systems and business analyst, project manager, development manager, data processing manager and run a small to medium sized consultin g company. Since 1989 Elmar has been practising as an independent consultant, networking with other companies in the IT industry. Elmar has been managing projects in a variety of industries for almost 20 years. He has mentored trainee project managers, developed and presented project management courses and developed techniques and methods for planning and controlling projects.

If you would like more information on dealing with the Y2000 Software Problem, you are welcome to contact Elmar on 082 651-5138, or email him at roberg@iafrica.com

The Y2000 SIG holds regular seminars to brief companies about the status of the problem and how to deal with it.

Sponsored in part by

Try Me?