A Year 2000 Readiness Checklist

Watts S. Humphrey

Abstract

The checklist in this article is designed to help organizations determine their readiness for the Year 2000 (Y2K) date change. It will help managers quickly assess their status and determine where they are exposed. The dates given in the checklist are the latest advisable for small organizations. Larger organizations should complete these items much sooner. Lastly, any organizations that do not have an active Y2K program underway now had best get started immediately. The date when the work will be completed is principally determined by when the work starts. If you are still studying, stop and get to work. Make a plan at the same time, but get to work!

The checklist is brief but it includes the items a number of experienced professionals have concluded are necessary for adequate Y2K preparation. It also includes explanations of the various items as well as some overall comments. The checklist is brief so managers can quickly determine their status. While organizations may identify additional important areas, they should not substantially expand the checklist as that would make it harder to use and less effective.

Introduction

Recently, I was invited to a meeting in Washington D.C. to review a proposed quality standard for the year 2000 (Y2K). While the meeting was focused on testing, the discussion reinforced the multi-faceted nature of this work. Since few people have ever seen a problem like this before, we need to characterize it in a way that clearly identifies the actions that must be taken. It occurred to me that a checklist could be just what is needed. It would briefly describe the required actions and enable managers to quickly see the work they need to get underway.

After drafting the Y2K readiness checklist, I had several knowledgeable people review it. While no brief checklist can be complete, this one does cover the points I and my reviewers felt were most important. You may think of additional items to add, but remember that the longer checklists get, the less useful they become.

Readers and reviews have since suggested that this material would be very helpful to many organizations and that I should make it as widely available as possible. I have thus modified the initial article to concentrate on the checklist. This checklist is designed to help you judge the readiness of your organization for the Year 2000 (Y2K) transition. In using this checklist, you should consider several points:

1. The Y2K transition problem will be much like those you have experienced in installing and converting to a new system or application program version, only this time, you will be installing and converting to an updated version of every application and system simultaneously. To minimize late discovery of fix defects and to reduce cutover workload, put repaired applications back into production as soon as possible.
2. If you experience Y2K problems with any commercially supplied software package, others will likely have similar problems at the same time. Thus the vendors' help desks and support services will likely be swamped and unavailable for extended periods.
3. Unless you have contracted for dedicated support services, you must be prepared to be self-sufficient. If you have a support contract, you had best ensure that the suppliers of such services really have resources dedicated to your needs.
4. The Y2K cutover is very likely to result in multiple application and system crashes and other disasters. It is thus essential that you maintain complete back ups of all application and system data and programs. Note, however, that with Y2K, traditional backup practices will not work. Usually, when backing up, one returns the system to a prior configuration that worked. With Y2K, at least until after the cutover period, there will be no prior configuration that is known to work.
5. Be careful about vendor selection because there will almost certainly be unscrupulous providers of Y2K services. When organizations do not have a competent technical staff, dishonest operators could pretend to do the required work and then disappear before 1/1/2000. Any organization that wants substantial payments up front should be avoided like the plague. While scams are nothing new, Y2K is a very attractive opportunity and any organization that is victimized could well be out of business before they can recover damages.
6. View all Y2K tools, services, guidelines, and checklists (including this one) with a high degree of skepticism. Remember, none of them have actually been tested in practice and shown to work. You thus must examine all such offerings and satisfy yourself that they are credible and reliable.
7. Consider each specific item in this checklist and satisfy yourself that it is necessary for your organization. With the exception of the crisis response, zero-hour testing, and emergency backup, all other items except one may or may not be essential, depending on your situation. While you may not need crisis-response, zero-hour testing, and emergency back-up capabilities, if you do (and most organizations will) you cannot build them on short notice.
8. The one capability exception which every organization should put in place ASAP is a configuration management system. If you do not have this capability, you will almost certainly have problems that could be severe and unrecoverable. This must not be viewed as something to do later when you have a chance. If you don't already have one, put a configuration management system in place now.

The Y2K Readiness Checklists

The following checklists are designed to help you quickly assess the readiness of your organization for the Year 2000 (Y2K) transition. Complete the organization checklist first and then fill out the application checklist for every active application.

Completing the Checklist

Have the most knowledgeable engineers and managers complete the checklists. Brief descriptions of the checklist terms follow the checklists. In completing the checklist, the columns to the right refer to the status of the application or the overall organization. If all the required work has been done, check the "Done" column. Similarly, if the work is not yet done but the project is staffed and under way, check the "Under Way" column. Later, when the application checklists are completed, you can enter percentage values for the percent of the applications that have been completed for each checklist category.

The Y2K Organization Readiness Checklist

*	Organization Units (laboratory, plant, etc.):	Done	Under Way	Plan	No Plan
	Should be done by 1/1/1998
1	Adequate 1998 budget and staff in place
2	Configuration management system in place
3	Fix tracking system in place
4	Applications inventoried
5	Applications assessed (with checklist)
6	Application source code under control
7	Application priorities determined
8	Y2K tools available
9	Date change standards defined and tested
10	Database correction needs inventoried
11	Service and support facilities surveyed for Y2K
12	Critical applications staffed and in development
	Should be done by 1/1/1999
13	Adequate 1999 budget and staff in place
14	Applications updated and in test: critical
15	All applications staffed and in development
16	Database corrections staffed and in development
17	Service and support corrections underway
18	Hot-line group funded and staffing identified
	Should be done by 7/1/1999
19	Backup procedures defined
20	Applications updated and in test: key
21	Emergency procedures defined and tested
22	Customer and supplier testing underway
23	Zero-hour procedures defined
24	Hot-line groups staffed and supporting testing
25	Database corrections in test
	Should be done by 9/1/1999
26	Emergency procedures training in place
27	Applications updated and in test: all
28	Zero-hour procedures tested
29	Backup procedures tested
30	Service and support tests completed
	Should be done by 12/1/1999
31	All application and database testing complete
32	Adequate 2000 budget and staff in place
33	Customer and supplier testing completed
34	Emergency procedures training complete
35	Backup procedures in full operation
36	Zero-hour testing staffed for 1/1/2000
37	Hot lines fully staffed and rehearsing procedures
	Should be done by 1/1/2000
38	Emergency procedures rehearsals completed
39	Zero-hour testing underway for 1/1/2000
40	Zero-hour testing staffed for 2/29/2000

The Y2K Application Checklist

Complete the application checklist for every active application in the organization.

 

	Application Name:
	Application Priority:
	Application Support Needs:				Yes	No
	Emergency procedures required:
	Hot-line capability required:
	Zero-hour testing required:
*			Done	Under Way	Plan	No Plan
	Should be done by 1/1/1998
50	Application priority determined
51	Source code available
52	Source code checked against object code in use
53	Critical applications: staffed and in development
54	Applications under configuration management
55	Date-sensitive interfaces identified
56	Database correction needs inventoried
	Should be done by 1/1/1999
57	Applications updated and in test: critical
58	All active applications: staffed, in development
59	Database corrections staffed and underway
60	Hot-line groups funded and staffing identified
	Should be done by 7/1/1999
61	Emergency procedures defined and tested
62	Applications updated and in test: key
63	Critical applications tested with updated database
64	Hot line partially staffed and supporting testing
	Should be done by 9/1/1999
65	Emergency procedures training in place
66	Applications updated and in test: all
	Should be done by 12/1/1999
67	All application testing complete
68	Emergency procedures training complete
69	Hot-line fully staffed and rehearsing procedures
	Should be done by 1/1/2000
70	Emergency procedures rehearsals completed
71	Zero-hour testing underway

Checklist Definitions - checklist columns

The four columns to the right of the checklist are for status information. In most cases, this work is either done or not done. Generally it is desirable to either check the item or enter a date when it will be done. After an initial assessment, and after the work is underway, it is helpful to enter a percentage figure, as with "Applications assessed (with checklist)." Here you would enter the percentage of the applications assessed. Note, however, that the columns should add to 100% when using percentage values for a checklist row.

It is also important to only count completed work. For example, if you had 10 items and 3 of them were done, that would be 30% complete. When 6 of 10 items are each half done, however, you would have 0% done. Do not take credit for partially completed work as partial status is generally hard to estimate and can be misleading.

These status levels are defined as follows:

Done - This column is checked when the listed work has been completed.

Under Way - This column is for that work that is staffed and work is actually under way. In those cases where the work is only 50% staffed, for example, it would be more informative to enter a 50% in this column. Note that this column does not give any indication of whether the work is likely to be completed on schedule.

Plan - This column is for those cases where the work is planned but it is not yet staffed or the staff may have been identified but the work has not yet started.

No Plan - This column is for those areas where the work has not yet been planned or it has been planned but no staff has yet been identified to do the work.

* - Where any tasks are late or need special attention, mark them with an * in the * column.

Application Priorities

The definition of critical applications is a matter of judgement and must usually be settled by senior management. It is therefore suggested that a comprehensive listing of all applications be reviewed with management, together with a list of those applications that are deemed critical and why. This is the action called for under "Application priorities determined." These priorities should specify which programs are critical, key, active, and inactive and also which will need emergency backup procedures, hot-line support, and zero-hour testing.

The application priorities are as follows:

• Critical - These are the applications upon which the organization's business depends. They can be found by identifying the work that would have to be done manually if all computers were shut down for weeks or months. Without the critical applications, the business could not function.
• Key - The key applications are ones that the business needs but are not a matter of organizational survival. While they are needed, their unavailability for periods of weeks and even a few months would not be fatal. That is, either the application work can be deferred or manual back-up procedures will be devised to handle the needs in the interim.
• Active - The active applications are all those that are actively in use other than the critical or key applications. These applications may only be run once a year or occasionally on demand. While they are needed, their repair can be deferred until shortly before the application is needed. Note, however, that some applications may only be used once a year for tax purposes. If that one-time use is in January, however, this could become a critical application.
• Inactive - These are all the applications that are no longer in active use. Generally, these would not warrant a Y2K repair effort.

Readiness Dates

The dates given in the checklist are selected based on overall judgement of the amount of work to be done in a small to medium-sized organization that has a competent software staff on hand. These are the latest advisable dates and organizations should strive to get this work done earlier if possible. Also, if the organization is very large or if it does not have a reasonably large and competent staff, these dates should be much earlier.

For large organizations, earlier dates are needed because the volume of work is so large. Smaller organizations without a substantial information systems staff will need to hire one or more suppliers of Y2K services. It takes time to identify and obtain these services so these organizations should strive to meet the earliest possible dates.

Note that for organizations on the U.S. Government fiscal year, there must also be a zero-hour test program starting shortly before 1/10/1999.

Alphabetical Glossary

Following is an alphabetical listing of definitions of and comments on many of the items on the readiness checklists. The topic headings are the same as in the checklists, and the numbers refer to the small numbers in the * column.

• (1, 13, 32) Adequate (year) budget and staff in place - This should be management's top priority. Unless the work is staffed in time, there is no way to finish in time. The adequacy of the funding and staffing should be based on an assessment of a plan to do the work and an estimate of the resources required.
• (5) Applications assessed (with checklist) - This refers to applications being assessed with the application checklist.
• (4) Applications inventoried - Every application in use must be identified. This requires naming the application and where and when it runs. The inventory should also list available source code, build environments, manuals, procedures, and guidelines about the application, who uses it, and when. This information is needed to set priorities.
• (7, 50) Application priority determined - Management must decide which applications to fix, which to replace, and which to handle with a hot-line capability. This sets the priorities for every application and guides the allocation of development work. If these decisions are not made early in the Y2K program, important programs will likely be overlooked while less critical applications are being fixed. Management must set priorities at the earliest possible point: which applications are critical, key, active, and inactive.
• (6) Application source code under control - see Configuration Management and Source Code Available.
• (54) Applications under configuration management - see configuration management.
• (14, 20, 27, 57, 62, 66) Applications updated and in test - once corrected, the applications must be tested with the corrected databases. It is important that this testing cover the applications' functions as well as all the code and database changes.

  Note that adequate testing requires that you have defined test procedures, a way to verify test results, and means for aging the database, environment, and input data to simulate future dates.

• (19, 29, 35) Backup procedures - The Y2K cutover is very likely to result in multiple application and system crashes and other disasters. It is essential that complete back ups be maintained of all application and system data and programs and that these backups be updated frequently. All old backups must also be retained since files can be unknowingly corrupted and not discovered until much later. Good practice dictates that backups be taken as early as possible, even before Y2K work starts. Note, however, that with Y2K, traditional backup practices will not work. Usually, when backing up, one returns the system to a prior configuration that worked. With Y2K, at least until after the cutover period, there will be no prior configuration that is known to work.
• (2, 54) Configuration management - The configuration management system maintains physical and electronic control of the organization's programs, data, test suites, and environments. Applications that have been in use for many years often have not been changed for much of that time. Unless the organization has an established configuration management system, the source code could have been lost. The configuration management system is also needed to ensure that the changed programs are properly updated in test and that only tested programs are put into use. Without an effective configuration management system, organizations are likely to lose programs, misapply fixes, or use the wrong tests and test data. All this wastes time which is the one thing you cannot recover.
• (22, 33) Customer and supplier testing - Many businesses have critical dependencies on their customers or suppliers. Where these relationships involve data processing interactions, there will likely be Y2K problems. The fixes to these problems must be tested in advance.

  Note that adequate testing requires that you and the organizations with whom you work have defined test procedures, a way to verify test results, and means for aging the database, environment, and input data to simulate future dates.

• (10, 16, 25, 56, 59) Database corrections - Depending on the Y2K change strategy, many database changes may have to be made. You will also need test versions of the databases for aging purposes. Here, aging refers to the process of transforming a database so all dates are, say, 2, 5, or 10 years in the future. Also, during the transition, there are many ways that databases can be corrupted. Until programs have been corrected, for example, many date calculations will put incorrect dates in the database. After the programs are corrected, subsequent dates will be correctly calculated. The application, however, will not go back and search for the incorrect entries in the old data. This must be done by hand or with special tools, if any can be obtained. This issue is further complicated by the phased cutover of multiple applications. The corrected databases must then be tested with the corrected applications.
• (9) Date change standards defined and tested - The Y2K date conversion formulas are not complex but they are not trivial. It is essential that the engineering change teams know precisely how to handle date calculations.

• (55) Date-sensitive interfaces identified - Many applications will have interfaces with other applications within the organization. Where such interfaces involve date-sensitive data, they should be identified and tested.

• (21, 26, 34, 38, 61, 65, 68, 70) Emergency procedures defined - With large systems and large volumes of changes, there will be many defects. Thus even the most critical applications will likely be unavailable for periods. The organization must be prepared for this eventuality and have a capability in place to handle any problems. The emergency procedures define how an application is handled under these conditions. Manual procedures should be in place and tested for all critical and selected key applications. Because large numbers of people will need to know how to quickly respond in an emergency, training programs and procedure rehearsals will generally be needed.
• (3) Fix-tracking system in place - As fixes are made for the Y2K problem, these fixes must be tracked to ensure that they are properly saved and tested. It is also important to maintain a complete fix inventory. With large numbers of fixes it is often difficult to know which programs have been fixed and which fixes in those programs have been made and tested.

• (18, 24, 37, 60, 64, 69) Hot lines - The hot-line support group handles the crisis calls when applications fail during and after the Y2K cutover. Since application failures can occur early for applications with advanced dates (like credit card expirations, or organizations on earlier fiscal years like the U. S. Government), the hot-line groups may have to be staffed much earlier, depending on application needs. It is also important to staff these groups early to give them experience with the applications they will handle. The best way to do this is to have them in place handling Y2K testing problems and fixes.

  A hot-line support capability will be needed even for those applications that have been completely repaired and tested. The reason is that between 1% to 20% or more of all the Y2K fixes will likely have problems, even after testing. With a fix quality program in place, the 1% number is achievable. If not, 20% or more is likely, depending on staff experience, program complexity, and the degree of testing.

  Generally, you will need application-knowledgeable people staffing the hot lines. They provide telephone assistance to system and application users, internal or external. Their job is to help the application users when they run into problems.

• (11, 17, 30) Service and support - Many facilities such as elevators, security systems, power distribution, telephone systems, and air conditioning could have date dependencies. While these items may not have problems, they could. Every one should be tested or checked with the manufacturer for Y2K compliance, warranty coverage, and emergency support availability.
• (51) Source code available - If the source code for any active program is not available and the program has date dependencies, the application must be replaced and tested. Replacement may be expensive and take time, but, without the original author, programs can rarely be fixed without the source code.
• (52) Source code checked against object code in use - In older systems, applications were occasionally patched to avoid the time required to recompile and rebuild. When this has been done, the source code will not represent the program that is actually being used. When the developers update the source code for the Y2K fixes, compiling and installing it will erase all these prior object corrections. The result will be the simultaneous reemergence of all the problems the original object patches were designed to fix. These problems won't wait until the year 2000, they will happen starting now. To resolve such problems, these patches must be identified and added to the Y2K workload. These patches can be found by compiling a new object program from the source and making a bit for bit comparison with a copy of the object program in use.

  It is also essential to check the availability of the support environment needed to compile and build the operating applications from the source code. Since these environments may not still be fully compatible with the old programs, new object programs should be generated and bit-for-bit compared with the object currently in use. If they differ, you have four choices: find and fix all the differences, immediately move the application to the newly generated object (and use that base for Y2K fixes), replace the program, or wait and see what happens. If there is any likelihood of Y2K problems with this application and if it is still in use, this last alternative is dangerous. Without a valid source program you have no way to recover or even fix problems.

• (8) Y2K tools available - This box should only be checked after the tools have been evaluated, obtained, and tested in practice. Until they are, it is likely that many of the tools will be found less effective or harder to use than promised.
• (23, 28, 36, 39, 71) Zero-hour - The zero hour for most organizations is midnight Friday 12/31/1999. Over the 1/1/2000 long weekend, the large and complex Y2K system change must be tested live for the first time. The zero-hour procedures define how the time following Thursday 12/30/1999 is to be used. During this period, many groups should make test application runs both in house, with suppliers, and with customers. This weekend is also when the hot-line support groups must crank up to full capacity. The zero-hour procedures are used to do final testing of the full operational environment, fully test emergency and back-up procedures, and start the recovery work for operational problems as they are found. While this cutover should be started as early as possible, special recovery resources and procedures must be available and tested during zero-hour testing. Plan to maintain the zero-hour testing capability until all the critical applications are cut over and work properly. This will likely take at least a month and could take much longer. Some organizations plan to maintain this special testing and support capability for at least three months.

The duration of zero-hour testing should be determined by experience. Since many organizations will be experiencing problems during this cut-over period, and also because of normal business delays around year end, many applications may not be fully exercised for several weeks. The testing and recovery procedures and staffing should thus be maintained for at least a month. The plan should be to continue this operation until the problem call rate declines to a level that the standard help-desk facilities can handle it.

Depending on the degree to which the Y2K repair and testing work was completed, zero-hour support might need to be maintained at full staff for many months until all applications have encountered the bulk of their operational problems and been repaired. While this repair strategy might make sense for little-used or low-priority applications, it is generally much more expensive to fix programs this way than to use an orderly development process. It also exposes the organization to much more operational disruption.

(40) Zero-hour testing underway for 2/29/2000 - Normally, there is a leap year every 4 years. The exception is every 100 years when there is not a leap year. This too has an exception every 400 years when there is a leap year. Thus, 2000 is a leap year and there will be a 2/29/2000. It is important that the date change algorithms be clearly defined and disseminated so everybody working on this problem understands them. Since these date algorithms will first be tested on 2/29/2000, a zero-hour testing plan is needed.

For More Information

For more information about the Software Engineering Institute, please contact

Customer Relations
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Phone, Voicemail, and On-Demand FAX: 412-268-5800
E-mail: customer-relations@sei.cmu.edu

© 2009 Carnegie Mellon University

Terms of Use | Privacy Statement