Below is the recommended, phase-by-phase process for campus departments to review and correct their customized applications.

Phase One: Identify a project lead
First and foremost, Y2K work on departmental systems must have project status, with someone given the accountability and the resources to do it. Both technical and functional experts should be involved in the project, as well as those who have institutional knowledge of the department's business operations. Every system won't be documented, so the department will have to rely on knowledgeable staff to explain both what the systems do and what their significance is to the department's mission.

Phase Two: Inventory the applications in the department
In a standard format, such as on a spreadsheet, capture the vital statistics of every departmental customized application used for administrative, academic, business, research, and instructional purposes in the department.

The information collected should include the computer(s) where the application is located, the operating system under which the application runs, the development language(s), any database used by the application, the number of users, the typical hours of operation, any vendor support provided, any data interfaces to other systems, etc.

Click here to view a template your department might want to use, or to revise and use, to profile each system in the department's inventory (The template is from the Departmental Technology Solutions unit of the Administrative Systems Department of IST).

If you are having trouble viewing the PDF file, you may need to download Microsoft Excel's viewer. If you still have trouble, try opening the above file in a new window.

Phase Three: Assess the extent of the problem
The goal of this phase is to answer two questions:

(1) When will the customized application start having Y2K problems? For example, a room scheduling system that looks ahead six months should be fixed before July 1999.

(2) Approximately how much work is needed?

A recommended step-by-step assessment process is provided here.

The result of this assessment should be an initial estimate of time and resources that will be needed by the department to fix the system - that is, a budget figure.

It is critical that plans for infrastructure changes (hardware, operating systems, common departmental software, etc.) be taken into account. There must be a two-way conversation between the project lead for the Y2K business applications assessment and the project lead for infrastructure changes (if you wear both hats, don't overlook the impact of one of your roles on the other). A platform or operating system change could mean you must modify or replace an otherwise Y2K compliant application anyway.

Phase Four: Prioritize and get the work underway
Once you know how much work is involved in addressing your business applications that must be modified or replaced because of Y2K, you will have to marshal your resources for the little time that remains. In-house staff may have to postpone other projects, or you may have to look elsewhere for programming expertise. If you have to look elsewhere, here are some possible sources.

If there are not adequate resources to work on all customized applications at once, then prioritization (what gets worked first) is needed. Here are some suggestions for how to prioritize.

Once priorities have been decided, you should document the scope of work for each application, so that the person(s) doing the work and the project leader have a firm, reciprocal understanding of what will be done, and when.

Phase Five: Fix each application
Although exactly what will be done with each application depends on its complexity and development environment, it is recommended that a systematic process be followed, particularly because it is important to document what was done. Such a systematic process would include

• Identifying each and every instance where date manipulation is done, and checking to ensure that it will work with years after 1999;
  
• Changing all input screens, output reports, and stored data to use four digits for the year rather than two digits, and
  
• Making sure that all incoming and outgoing data files are modified as necessary (with the agreement of whoever sends to or receives them from the department).

A recommended systematic approach is offered here. In doing these modifications, you may find some general tools or some specific product-related tools to be helpful.

Phase Six: Test and validate each application
Year 2000 testing and validation should be done using Y2K-compliant hardware and operating systems - hopefully the ones that will be used in production. However, because proper testing requires setting the system clock ahead (referred to as "time machine" testing), significant problems can arise (for example, damaged database logs) unless either a special (Y2K testing only) computer is used, or unless everything on the computer is reset (for example, by restoring the entire hard drive to what it was before testing began). In short, part of proper testing probably requires additional hardware.

Another issue with testing and validation is any data exchange used by the application - these should be Y2K-compliant as well. So proper testing and validation may require working with other campus units, or outside organizations, to get or send sample data exchanges in new formats or with dates in the year 2000.

Year 2000 modifications are like any other program changes in at least one way - they may introduce bugs, not behave exactly as anticipated, or otherwise be problematical. The way to minimize such problems is a systematic approach to testing, so that problems that occur when applications are in production (live) are minimized.

A recommended systematic approach is offered here.

Phase Seven: Implement each application
Implementing well-tested code still doesn't guarantee that there won't be problems, but they should be minor ones at worst. Proper implementation of an application may involve pilot units or another phased approach. And until weekly, monthly, and quarterly processes have been run, there are plenty of opportunities for problems to appear - another good reason to implement applications well before the end of September 1999.

In bringing applications with Y2K fixes into production, departments should generally follow ther normal implementation procedures. For example, it's best to bring a new application into production in a controlled way - say, on a Saturday, with an experienced user to enter real data to see if everything goes as expected.

If your department doesn't have well-defined procedures for implementing applications, you might want to look at the University standards for implementation, in section 2.13 of the UC Business and Finance Bulletin IS-10, October 1997. This file needs Adobe Acrobat Reader, which you can download for free.

Return to Customized Departmental Applications - General Information