Prioritizing Y2K Work on Customized Applications

There are at least three different ways to evaluate which systems (applications) should be fixed first: importance of the system, severity of the problems, and when applications are going to experience Y2K problems.

Importance of the System
To determine the impact to your department's business operations, consider these questions:

• Is the system critical to the operations of the department (such as legal compliance)?
  
• Is the system critical to the uninterrupted operation of the department (such as submitting payroll transactions)?
  
• Is the system critical to the health and safety of faculty, staff and/or students?
  
• Does the system provide important support, such as management and financial reports?
  
• Is the system desirable but not absolutely required to support the department, at least in the short term? (Is there a manual or partially-automated workaround?)

Severity of the Problem
Not all Y2K errors are of the same severity. An error that prevents a system from running at all is very different from an error that puts an incorrect date on a report. For each application (or possibly programs within each application), you might evaluate the severity of expected Y2K errors (from the assessment phase). For example, you could use categories such as:

• Fatal: If Y2K errors are not fixed, the system simply won't run.

• Critical: Programs will probably run, but it is highly likely that there will be incorrect results. (For applications used for research, this may be totally unacceptable. For administrative applications, it may be possible to make subsequent corrections, at the cost of additional hours of analysis and input). If errors are severe enough, it may be worse to run the programs than to simply do things manually.

• Moderate: The department can be expected to be able to do manual or other workarounds to those parts of the system that don't work.

• Marginal: The errors result in minor inconveniences, annoyances, or irritation - for example, some items on reports are listed in the wrong sequence.

Based on the severity of the problem, evaluate the desirability of reworking particular programs or applications. Consider possibilities such as:

• Abandoning the particular process
  
• Combining the process with other processes
  
• Replacing the process with a new state-of-the art process
  
• Purchasing an off-the-shelf program that has most of the functionality of the old application.

Determine when the application is going to start having Y2K problems

Department environments are unique. The initial date your application(s) will begin experiencing Year 2000 problems is also unique. If the program forecasts classroom space for the next six months, then it may need to be fixed by June. If the only date calculations the program does are backward looking (e.g., calculating how long a student has been enrolled in a program), then (in theory) you have until January 1, 2000, to fix it. If a program is used for (say) month-end processing, then you may not need to fix it until the end of January, 2000 (assuming you do your December end-of-month processing before December ends, and the program really has no forward-looking date calculations).

Return to Seven Phases to Y2K Compliance