Communicate as Much as Possible

Tell Your Users What You Are Going to Do

Make sure you give your users sufficient warning before you do anything. The actual amount of warning will vary according to the type of change (upgrading an operating system demands more lead time than changing the default color of the system login screen), as well as the nature of your user community (more technically adept users may be able to handle changes more readily than users with minimal technical skills).

At a minimum, you should describe:

• The nature of the change

• When it will take place

• Why it is happening

• Approximately how long it should take

• The impact (if any) that the users can expect due to the change

• Contact information should they have any questions or concerns

Here is a hypothetical situation. The Finance department has been experiencing problems with their database server being very slow at times. You are going to bring the server down, upgrade the CPU module to a faster model, and reboot. Once this is done, you will move the database itself to faster, RAID-based storage. Here is one possible announcement for this situation:

System Downtime Scheduled for Friday Night

Starting this Friday at 6pm (midnight for our associates in Berlin), all financial applications will be unavailable for a period of approximately four hours.

During this time, changes to both the hardware and software on the Finance database server will be performed. These changes should greatly reduce the time required to run the Accounts Payable and Accounts Receivable applications, and the weekly Balance Sheet report.

Other than the change in runtime, most people will notice no other change. However, those of you that have written your own SQL queries should be aware that the layout of some indices will change. This is documented on the company intranet website, on the Finance page.

Should you have any questions, comments, or concerns, please contact System Administration at extension 4321.

A few points are worth noting here:

• Effectively communicate the start and duration of any downtime that might be involved in the change.

• Make sure you give the time of the change in such a way that it is useful to all users, no matter where they may be located.

• Use terms that your users will understand. The people impacted by this work do not care that the new CPU module has twice as much cache, or that the database will live on a RAID 5 logical volume.

Tell Your Users What You Are Doing

This step is primarily a last-minute warning of the impending change; as such, it should be a brief repeat of the first message, though with the impending nature of the change made more apparent ("The system upgrade will take place TOMORROW."). This is also a good place to publicly answer any questions you may have received as a result of the first message.

Continuing our hypothetical example, here is one possible last-minute warning:

System Downtime Scheduled for Tonight

Reminder: The system downtime announced this past Monday will take place as scheduled tonight at 6pm (midnight for the Berlin office). You can find the original announcement on the company intranet website, on the System Administration page.

Several people have asked whether they should stop working early tonight to make sure their work is backed up prior to the downtime. This will not be necessary, as the work being done tonight will not impact any work done on your personal workstations.

Your users have been alerted; now you are ready to actually do the work.

Tell Your Users What You Have Done

After you have finished making the changes, you must tell them what you have done. Again, this should be a summary of the previous messages (invariably someone will not have read them).

However, there is one important addition that you must make. It is vital that you give your users the current status. Did the upgrade not go as smoothly as planned? Was the new storage server only able to serve the systems in Engineering, and not in Finance? These types of issues must be addressed here.

Of course, if the current status differs from what you communicated previously, you should make this point clear, and describe what will be done (if anything) to arrive at the final solution.

In our hypothetical situation, the downtime had some problems. The new CPU module did not work; a call to the system's manufacturer revealed that a special version of the module is required for in-the-field upgrades. On the plus side, the migration of the database to the RAID volume went well (even though it took a bit longer than planned due to the problems with the CPU module.

Here is one possible announcement:

System Downtime Complete

The system downtime scheduled for Friday night (please see the System Administration page on the company intranet website) has been completed. Unfortunately, hardware issues prevented one of the tasks from being completed. Due to this, the remaining tasks took longer than the originally-schedule four hours. Instead, all systems were back in production by midnight (6am Saturday for the Berlin office).

Because of the remaining hardware issues, performance of the AP, AR, and the Balance Sheet report will be slightly improved, but not to the extent originally planned. A second downtime will be announced and scheduled as soon as the nature of the hardware issues is clear.

Please note that the downtime did change some database indices; people that have written their own SQL queries should consult the Finance page on the company intranet website. Please contact System Administration at extension 4321 with any questions.

With this kind of information, your users will have sufficient background to continue their work, and to understand how the changes will impact them.