Mike Staman
University of Georgia System
Michael_Staman@oit.peachnet.edu

This is the beginning, and the smallest part of the project. Every institution should know this answer by now. Note that a full inventory will include software systems, hardware, networking devices, and operating systems.

Some buildings have systems or facilities within that cause them to be high risk, and sometimes the question is more simply related to building security or other infrastructure. A simple punch list of base infrastructure tests should suffice for most buildings. Remember that the question applies to embedded chips as well.

Triage is a critical second step. Few institutions, if any will fix every problem. The issue is management: make lists, establish priorities, follow-up, pay intense attention to details. Technical solutions are important, but in comparison to management processes, technical solutions may prove to be the less difficult part of the problem.

The question here is whether ALL management agrees on the critical list, not just technical personnel. Perhaps you should ask for examples to get a sense of current thinking.

But not because someone says so, because the systems were tested, and work. Given the time remaining, and the critical nature of this activity, a system of checks and balances might not be out of the question. A second, high level manager to simply review and confirm results might be appropriate.

Do we have a plan which will work and which is achievable? Can we be comfortable that testing will be complete well in advance of December 31? Many organizations have targeted March 31, 1999. We should also be aware of other important dates which ultimately relate to January 1, 2000 - the July 1 start of the fiscal year or early student registration could be examples. A problem for you may well evolve at this stage - the question of whether the project is adequately funded, and, of course, the source of funding if the answer is no.

Unfortunately, solving only your problems is not sufficient. You need to know the answer in order to prepare for question #8.

Assume that after all of your preparation something that was supposed to be a "sure thing" breaks. Perhaps a system breaks because internal code and testing turns out to be insufficient after all; perhaps a vendor did not tell the truth. What written plans do you have if, for some reason, you can't meet a payroll, food for students does not arrive, the student registration system fails, or heating and power systems fail? At the least, you need to understand the risk and be prepared in case some of the negative Y2K predictions are actually correct.

Perhaps a one-page summary should be presented to you and your immediate reports twice a month through March, then weekly through sometime this summer, than twice a week from that point on. A simple list of projects, contingency plans under development, along with targeted dates, status and comments might prove to be very useful as you work to involve your institution in the compliance process.

At a minimum you should understand the extent to which you, your institution, and your board are liable in the event that you are the target of a lawsuit. What if, for example, a current or former student claims career or significant financial damage because you are unable to get a transcript out in support of a high profile opportunity of some kind? Suppose a vendor provides you with goods, you are not able to process payment, and the vendor claims bankruptcy because of cash flow as a result? Lawyers can probably write pages of questions such as these, and probably are -- even as we work to solve the problems.

E. Michael Staman is Vice Chancellor/CIO
Board of Regents of the University System of Georgia

He can be reached at Michael_Staman@oit.peachnet.edu

Top of page