Personal tools


CPSR Y2K Working Group
CPSR Y2K LOGO Computer Professionals for Social Responsibility
CPSR Y2K Working Group

About CPSR
Y2K Home
Y2K Policy
Rumor Central
Speakers Bureau
Survival Guide
W.G. Members
Y2K Forum
Privacy Policy
Further Reading

The CPSR Year 2000 Action Plan

The most critical part of the Year 2000 problem is not any specific technical issue or the code and data changes necessary in a particular language. Rather, it is in the project plan of specifying and managing all the details associated with such a wide-reaching project. The purpose of this white paper is to specify an organized method of determining the scope of the problem and a systematic way of working on it.

In order to specify the theme for this action plan, consider the acronym "I ACT 2000". This acronym has the advantage of both being representative of the various phases of the Year 2000 project as well as being indicative of the critical success factors involved. The letters in the acronym stand for Inventory, Assessment, Correction, and Testing. These four phases are detailed below. The "I" indicates that this project will only be successful if people take individual ownership and accountability for the project. There is too much to be done to simply expect others to do all of it. The "ACT" indicates that the project will only be successful if it is geared to action. Spending a lot of time just studying it or waiting for a better solution to come along wastes precious time, and this project is not one where we can afford to be late * the year 2000 cannot be delayed. Finally, the "2000" indicates that we must be prepared for the year 2000 when it arrives. Despite the best plans and the best people, there are still likely to be things which were not anticipated. We must also have proper backup and recovery procedures for when any difficulties arise.

Phase 1 - Inventory

The Year 2000 problem is not limited to old COBOL programs written on IBM mainframes. Because the shorthand method of referring to years by using only the last two digits has been pervasive, instances of it can be found in any area where automation or electronic circuitry is involved. Some of these may be obvious, others less so. In order to categorize the issues, there is a list of possible areas at the end of this paper. This list has been constructed through observation of many comments on the subject in various Internet discussion groups and news groups and has been verified by cross checking it against lists prepared by others such as the AIAG (Automotive Industry Action Group), a coordinated effort of the major automobile manufactures in the United States. Not all of the areas listed will be pertinent to every situation, and not every possible variation in each category is listed. However, this is a good starting point for deciding what areas to examine in any specific situation.

Phase 2 - Assessment

There are a number of tasks in the assessment phase. If there is computer software involved, then examination of the code for the number of dates (density) and dependence on them should be done. If there is computer hardware or other purchased products involved, then letters to vendors establishing their Year 2000 compliance is appropriate. For all items in the inventory an assessment of how important that item is to the continued operations of the enterprise is appropriate. Items which are critical or have a high degree of "risk" associated with them deserve more attention than those which are less critical. The following categories are indicative of the "risk" involved: High Risk -- Safety / Health / Environment / Regulatory reporting; Medium Risk -- Plant shut-down / Production constraint / Asset control / Customer relationships; Low Risk -- Inconvenience / Efficiency loss / Billing / Internal reporting. However, risk is cumulative, so a particular system may have high risk because it impacts multiple low-medium risk areas. (For a more complete robust definition and calculation of risk, the Corporate Audit Department has developed a model, contact them for details.) For critical systems, one should consider testing it anyway to determine or verify compliance, even if a vendor indicates that there are no problems. Finally, if results indicate that there may not be enough time to correct every last detail, then one might consider "triage", setting priorities as to which systems will get attention first so that limited resources may be used where most needed.

Phase 3 - Correction

Like the assessment phase, the correction phase is multi-faceted. One simple solution is sometimes a simple version upgrade. Where actual computer programs or code exist, a possible solution is rehabilitate it, i.e. expand the dates or change the logic to properly handle dates in multiple centuries. Another solution is replacement of the system with a purchased or other (compliant) package, however, if a replacement strategy encounters delays, adequate time and resources must be available to revert to a rehabilitation strategy. Finally, one could consider retiring a non-compliant system or piece of hardware.

Phase 4 - Testing

While some limited testing may have been done in the assessment phase, all critical systems as well as those which have been modified during the correction phase must be properly tested. A well-conceived test plan must address not only verification that the changes made during the correction phase have not introduced other problems (regression testing), but that there will not be any problems when the actual century change occurs (time-dimensional testing). To this end, we have introduced a Year 2000 test plan for application packages. A similar type of checklist would be needed for infrastructure changes, process control changes, etc. The purpose of this testing is to ensure that the problem has been addressed properly and that we have not overlooked anything. While testing cannot ensure that no problems exist, a well-conceived test plan can help us ensure that we have taken proper diligence in determining whether the system will work correctly. The testing phase can take anywhere from 30-70% of the total time and resources in a Year 2000 project, so careful planning of this phase is necessary.

In all of the above phases, one must ensure that proper documentation is made of all activities and that appropriate record retention policies and practices are used. There are quite likely to be lawsuits and various types of post-mortem analyses performed as a results of Year 2000 activities. Having the proper evidence of efforts made will be valuable. Because of the large number of Year 2000 activities and the necessity of being done on time, having appropriate measures to track progress is also important.

Categorization of Areas to Check for
Year 2000 Compliance

Note - Not all of the areas listed will be pertinent to every situation, and not every possible variation in each category is listed

1) IT Infrastructure

Hardware, PC's, etc.
Local area networks (LAN), servers, security systems, routers
PC*s (286*s, 386*s, 486*s, etc.)
Operating systems, utilities, security software, databases, etc.
Operating system, scheduling software, development tools, tape backup
Other "standard" components, such as word processors, etc.
Microsoft office, Windows, Microsoft Access, Paradox, FoxPro

2) Application systems

MIS developed, user developed, purchased, or used (i.e. outside
Computer-aided design (CAD), computer-aided engineering (CAE), modeling
Material requirements planning, inventory, forecasting
Production scheduling
Ordering and billing
Accounting, general ledger
Personnel, payroll, human resources (HR)
Electronic Data Interchange (EDI)

3) Non-IT Infrastructure

Telephones, voice mail, wireless communication, video conferencing,
faxes, etc.
Building services
Energy management systems, heating, air conditioning, electrical
Security systems, building access, fire alarms

4) Process Control Systems and Equipment

Operating plants
Bar coding, card readers, conveyers, optical scanners, equipment
testing devices,
Programmable Logic Controllers (PLC*s), Computer Numerical Control
Radios, pagers
Research & Development
Diagnostic systems
Data management systems
Simulation tools
Embedded systems
Electronics, processors

5) Other Areas

Utilities, financial services
Maintenance scheduling, Vehicle maintenance systems
Production suppliers
Non-production suppliers (tools, office supplies, chemicals, etc.)
Outsourcing vendors, Service providers (transportation, etc.)
Disaster recovery plans
Back-up and restore systems and procedures


Send Questions or Comments to Webmaster
©1997, 1998 Computer Professionals for Social Responsibility
Revised 1999-01-06

Archived CPSR Information
Created before October 2004

Sign up for CPSR announcements emails


International Chapters -

> Canada
> Japan
> Peru
> Spain

USA Chapters -

> Chicago, IL
> Pittsburgh, PA
> San Francisco Bay Area
> Seattle, WA
Why did you join CPSR?

Technology must be questioned! And the public and politicians are easily misled.