It's a tricky business, communicating IT updates to users, particularly during a system downtime. Send out too many messages, and users ignore them or find them annoying. Send too few, and users demand to know what's going on. All the while, you want to convey the kind of information that shows the tech team is in control. Well, a few years ago I was that person walking the thin line.
I was working in the IT department at a hospital, a setting that poses unique challenges in and of itself since it never closes and people's lives and health are on the line. Technical maintenance was difficult because we often had to shut down the systems. By doing it at night, the shutdowns impacted the fewest people, but departments had to use their "downtime procedures," which could affect patient care. Communication was critical.
[ Get a $50 American Express gift cheque if we publish your IT story. Send it to email@example.com. | For your daily dose of workplace shenanigans, follow Off the Record on Twitter. | For a quick, smart take on the news you'll be talking about, check out InfoWorld TechBrief -- subscribe today. ]
While we were being trained for the task, my supervisor stressed how important it was during downtimes to contact all the tech departments involved before sending any information; that way, the updates would be accurate. We had to work efficiently to show users that we recognized the inconvenience and took systems down only when necessary.
Learning the ropes
Luckily, the first few downtimes that I was responsible for went off without any problems. But it was a busy job. Days in advance, I'd send out pre-downtime emails alerting the users to the scheduled maintenance. Then, on the night of the downtime, I'd send email and text updates of when the maintenance was starting, open up a conference line for anyone to get a status, answer questions from users, keep in contact with the techs, send announcements if an unexpected problem occurred, and finally notify users when the system was back up and ready to be accessed.
But it wasn't too long before I learned that even though my job was to be a conduit of information between the techs and the users, making the decisions about what information to pass along was ultimately my responsibility. I had to trust myself.