This year, we’re all especially concerned about the potential for catastrophe as we approach the dreaded Year 2000. Unfortunately, the hype surrounding the potential of a Y2K meltdown has been so emphasized by the press that many of us are not yet addressing the greater threats facing our information systems. After all, what is Y2K but a known, impending event that will test everyone’s contingency plans simultaneously? No, the real threat is not Y2K but rather the rapid addition of new software and hardware packages into our organizations. These packages are arriving so quickly and being so swiftly implemented and accepted by our users that we in IS can hardly measure their strategic importance to the organization. Take Lotus Domino and email for instance: We implement the applications and turn users loose with them. They seem happily preoccupied building large Notes and email databases, blithely assuming that we will rescue them if they run into a problem. Little do these users realize that, in the crunch of a catastrophe, they might actually know more about these applications than we do.

This scenario reminds me of the four lessons that every IS manager learns about contingency planning. The first lesson is that, as a practical matter, no one in your management will take contingency planning seriously until after the organization has actually experienced a catastrophe. No matter how long or how loud you gripe about the need to prepare for a disruption, management will always delay the resources until it’s too late. Some critical file must be lost, some important database must become corrupted, some crucial piece of hardware must crash, or some vital service must be disrupted before management will actually feel the pain. Of course, once the pain has been experienced and the price paid, you can rest assured that you’ll have everyone’s attention. Suddenly, everyone will want information systems that are secured, backed up, and archived in gold- lined vaults.

The second lesson that every IS manager learns is how to capitalize upon that catastrophe in order to actually institute some real contingency planning. This doesn’t mean just having an adequate daily archive or implementing AS/400 journaling on key databases, but really setting up a chain of command and disaster scenarios and then testing them on a regular basis.

The first two lessons are the easiest to learn because they are predictable: Accidents will happen (lesson 1), and management will spend money and resources to prevent them from happening again (lesson 2). However, it’s the third lesson of contingency planning that is by far the most difficult: The hardest part of implementing any plan is the communication of the plan itself. In my experience, it was never the contingency plan (if, in fact, one existed) that failed in a disaster. It was the inability of IS to communicate that plan that brought the work environment to its knees. Always, some key piece of knowledge was missing because some key individual was absent. It might have been a server password, a configuration parameter, or even the knowledge of where the manual for contingency resided. Still, hardware can be replaced quickly, software can always be reconfigured, and data can be rekeyed. It’s what you don’t know that hurts, and ignorance is a hole that takes time to fill during a catastrophe. Since time is the enemy in a business of deadlines and dollars, ready access to information about what to do in an emergency is crucial to rapid recovery.

Unfortunately, most IS organizations exist in a “need-to-know” sort of haze. Resources these days are so scarce that there is hardly time enough to get the job done the first time, much less time to tell anyone else how it was accomplished. When a disaster strikes, the fastest route to recovery is always to go to the person who originally installed or configured or worked on the system. However, this is the fourth—and cruelest—lesson that contingency planning teaches: The person who knows the most about a system will always become your weakest link. Why? Because, unless you are careful, that person will soon become the only person who can help in a disaster. That’s why, whenever a serious problem occurs, I always stress that the resolution of that problem must be handled within a team structure. The expert can lead the team, even if it is a small team of two, but he cannot solve the problem alone. Even if the other member of this team is from another department, you are better off with two people than with one. This emergency team structure can cross-train the staff and strengthen the organization as a whole. This approach may be less efficient in the short run, but almost always pays dividends the next time a problem occurs.

All of these lessons go against the grain of common sense, but you should start considering them now—today—before the great Y2K event. Ultimately, I think you’ll agree that the best contingency plan is one that recognizes that every day is a catastrophe in the making—that is, preparing you for the ultimate test. In this light, the Year 2000 may be seen merely as the final exam at the end of a series of daily quizzes.