Once you have completed your inventory and assessment of internal Y2K problems, then the internal systems likely to fail should be much more obvious. However, for most organizations, this is not where they need to apply their immediate contingency planning resources. You first need to address those systems over which you have little or no control -- internal systems MUST be addressed, but you at least have some degree of control over these systems.
First, I would concentrate on infrastructure. Hopefully, your existing disaster management plan will at least address how to deal with the failure of a single infrastructure resource. What you would need to do for Y2K is layer these plans to handle multiple simultaneous infrastructure failures. Examples of what I would consider priority infrastructure failures to address would include: Electric Power Telephone Service (wire and wireless) Pagers Other communications (for example, are your radios using a repeater not under your control?) Water and Sewer Waste/Trash disposal Fuel shortages Even if Y2K does not cause these infrastructure items to fail, they are very likely to someday fail. The Galaxy IV satellite failure is a perfect example of where an infrastructure failure occurred and organizations did not have adequate (read... any!) contingency plans to address its failure.
How Y2K complicates the issue is the planning for multiple failures. For example, if you have both a telephone systems failure and a pager system failure, how will you contact on-call employees? If there are long duration power outages, does this mean that schools will be closed and you will have employees unable to work because they must 'baby-sit' their children? These are just some of the types of compound failures you need to consider.
The other high priority area that requires contingency planning is the failure of customers and suppliers. What if the blood bank fails? What if the liquid oxygen supplier fails? What if an HMO, to which your organization is a provider, fails? What are your alternatives? You must examine in detail each of your suppliers and customers and they must do likewise to theirs.
After you are underway with addressing the above issues, now is the time to examine your internal problems. Safety critical systems must come first. Then mission critical systems. These require detailed planning. For most organizations, the failure of support and ancillary systems will not be an issue in a Y2K crisis environment, so these could possibly survive with very minimal planning.
What is reality? I think the biggest Y2K problem is not going to be the failure of any given system or service, rather, it will be the multiple simultaneous failures that occur, and the results of these failures (i.e., cascade failures, where one failure causes another failure), that will be the real source of problems. I can assure you that at least some to most of the above listed infrastructures will fail. The real question is: "How long will the failures last?" Unfortunately, we will probably not be able to answer that question until after the failure has occurred -- which is too late to do contingency planning. You MUST assume a reasonable "worst cast" and hope for the best.
Personally, I recommend worrying about "everything". If you worry about "everything", then it becomes much easier to determine "what failures will have the greatest impact", which then gives you your contingency planning priorities.
(BTW, we cover all this and much more in our full day technical Y2K seminar.)
Hope this is somewhat helpful. I'm sorry that I cannot give you exact answers, but no one will know what are the right questions to ask until sometime way past January 1, 2000.
Sincerely,
Jon R. Kibler
Systems Architect Year 2000 Services Manager
Jon.Kibler@aset.com
(from CPSR list)
Ian Wells - ian@rsn.hp.com
Belvidere Neighborhood Association Y2k Committee, Lowell MA
http://www.lowellonline.org/bna/y2k
Std. disclaimer
subscribe to Lowell Y2k list: mail majordomo@oceana.uml.edu, in body: subscribe y2k
-- Jon R. Kibler (Jon.Kibler@aset.com), July 18, 1998