Tomorrow and tomorrow and tomorrow,
Creeps in this petty pace from day to day
To the last syllable of recorded time...
SHAKESPEARE may not have been concerned about how computers will handle the Year 2000, but as certainty as tomorrow follows today, January 1st, 2000 will come around in its turn. The issue for computer users, therefore, is to assess just what it will mean for them. Companies should be looking for realistic, cost effective solutions to ensure that they can function smoothly through the turn of the millennium. To this end, a few Do's and Don'ts can help focus efforts to deal with the issues.
. Don't expect the problem to evaporate. The date will come around and if your systems have vulnerabilities they will show themselves. The question is what you do between now and then. Do take it seriously. Make sure that others with responsibility take it seriously too.
. Don't think it's the end of the world - we've no evidence for that, so far. Year 2000 presents a business, technical and cultural problem, but solving problems is what most of us are here for. It can be tackled.
. Do tackle it like another problem. Start with a list of potential vulnerabilities. List all the systems you can think of where your business uses date conscious equipment. This includes computers (hardware software, firmware, operating systems and networks), security systems, environmental controls like heating and air conditioning, lifts, video recorders, time lock vaults, telephone switches, dispatch and delivery systems and many more.
. Do go back over your work. When you've finished, start again and ask for fresh input. You will find a few more items.
. Don't think of each of these systems in isolation. Include with each one all its interdependencies, information exchanges and links to other systems.
. Do break down this tangled web into bite sized pieces. Each piece can then be given a priority, and the possible vulnerability assessed and dealt with.
. Do set a timeline of tasks and completion dates. Aim to have the overall project completed by Christmas 1998, so that all systems go through a year end and quarterly, monthly and weekly routines for a year before 2000.
. Don't buy yourself any fresh problems between now and 1999. Draw up a standard for Year 2000 compliance that satisfies your organisation's needs and use it in all purchases from now on.
. Do look beyond your own organisation. Ensure that crucial customers and suppliers are also taking the problem seriously and moving to deal with it. Be wary of those who are not.
. Don't ignore obvious sources of help. User groups, for example, can help pressurise a supplier to deal with the issue and keep members informed of progress and problems along the way. In case you don't already use it, the Internet provides an ideal way to make and maintain contact with other users of that innovative in 1981 accounting program that nobody else in your city has ever heard of.
. Do move now to deal with it. As time goes on the pressure and price of tackling the problem is likely to escalate. People with skills in obscure systems and programming languages are going to get busier - and more expensive - in the next three years.
. Don't be shy about going to look for resources to deal with the problem. It may be difficult to ask to spend money on dealing with something that is a whole three years away and doesn't immediately add to the productivity of your organisation. But self restraint now will not be an excuse if people are looking to you after crashes in January 2000.
. Don't bank on changing jobs in autumn 1999. You may move to a bigger mess than the one you've left behind.
. Don't "test" live systems by putting the system clock to 23.55 on December 31st, 1999, switching off for 10 minutes and turning back on to see what happens.
Lots of software - one example is Telecom Eireann's CD Rom telephone directory does not take kindly to the shift forwards and backwards. (In the case of the phone directory it will stop working and won't reinstall until you delete a couple of hard to find files it leaves behind.) Do feel free to experiment on new equipment before it carries crucial information or joins your network. Load it up with copies of live applications and data for more validity.
. Don't take it for granted that all your technology suppliers are doing everything right. Test new systems against the Year 2000 assurances offered by manufacturers and look hard at the fixes offered by suppliers of older equipment.
. Do look at the collateral benefits of working on this problem. The tools used to deal with Year 2000 can have wider application. This is a good opportunity to revamp your procedures for planning, implementing, testing and reviewing all software changes.
. Don't, on the other hand, get distracted by these side benefits to the point where the main task - Year 2000 protection - is no longer the central focus. Especially, don't let deadlines slip while you look for the perfect solution to a noncore problem.
. Don't assume that all the problems, or all the solutions, lie within the IT department. Involve users, expert power users and even the former employee who remembers the first system in the place. Remember the Byzantine complexity and variety of things running on PCs scattered throughout the organisation.
. Do pay particular attention to communications links which can involve multiple providers, geographically scattered and with whom you have no day to day relationship when everything is working.