IT Communication: Planned Outages

It’s important to communicate with your customers about planned outages.  Even if you have a designated maintenance window, unless you use it every time, let people know what systems will be down and when you anticipate them being back up.

72 hours (3 work days) ahead of time is a good window.  This gives people enough time to plan, but not enough time to forget that it’s happening.

For really major outages, or outages that are going to happen outside of regular maintenance windows or for very long periods of time, giving earlier warning and then a reminder at 72 and 24 hours ahead is useful.

If you predictably and reliably warn your users about planned outages, their patience for unexpected and unplanned outages will be much higher.  They will trust that if there was any other option, you would have warned them.  Predictability goes a long way towards building good will.

IT Communication: Unplanned Outages

If you are experiencing an unplanned outage, it’s vital that you get the word out as quickly as possible.  Communication should be in two stages:

  • An initial email that says what is down and that the department is aware of the issue and actively working on it
  • A follow-up email with more details, such as:
    • Possible ETA for fixing the issue
    • Whether or not you believe that any data loss has occurred

These messages should be clear and succinct, with very detailed subject lines.  For example:

Email 1

Subject:  System A is DOWN as of 9:10 a.m.

Body:  System A is currently down.  The IT department is actively investigating the problem and will follow up with more information once we have an assessment of the issue.

Email 2

Subject:  System A is down; Estimated to be restored at 10:45

Body:  IT System Administrators are working with the vendor for System A, and estimate that the system will be restored by 10:45 a.m.

We believe that there is a conflict with the version of antivirus software that was upgraded last night, which did not appear during testing.  We are working with the vendor to roll back that change and restore the system.  No data was lost as the database, which is on a separate server, was not affected by this outage.


IT Communication: A Communication Plan If You Don’t Already Have One

What to communicate about:

  • Unplanned service outages
  • Planned service outages
  • Upcoming major changes, such as upgrading the email system

When to communicate it:

  • Unplanned outages:  Immediately.  Try to get a message out announcing the outage immediately, and follow up shortly thereafter with more details.
  • Planned:  72 hours before is a good window.  Enough time for people to plan, but not enough for them to forget.
  • Upcoming major changes:  Depending on the change, you may want to begin communicating about this months in advance.

Who to communicate with:

  • For unplanned and planned outages, communicate directly with everyone affected.
  • For upcoming major changes, you may want to communicate with a liaison group or another group that can get people excited about the change.  Rather than “the disembodied voice of IT,” someone they know and work with regularly can be a better conduit for this sort of information.

In my next series of posts, I’ll go over more details on each of these.

IT Communication: Communicate Expectations for Better Customer Service

We have something of a debate in our organization around customer service.  For some, good customer service is doing whatever someone asks, as soon as they ask it.  For others, it’s more of an “IT knows best, just listen to what we tell you that you want,” attitude.

Realistically, an IT shop can’t go with either of those options.  Option one leads to chaos, a lot of “haves and have-nots,” (based on who can yell the loudest or pull the most weight), and an unsupportable environment.  Option two is predicated on the belief that IT actually does know what is best for everyone, which in practice is ridiculous.

But there’s a middle path, and that relies a lot upon communicating expectations.  Don’t jump right when someone says, “jump!”, but let them know when you can work on it.  Don’t agree to every project they demand, but let them know what makes a project score high on your yearly plan.  Don’t tell them what they want, but tell them what IT requires to make something work in your environment, and how they can work with you within that scope to get something that works for them.


IT Communication: The Prime Directive

Years ago a friend made the point that Orson Scott Card’s book Speaker for the Dead was a lengthy critique of Star Trek’s Prime Directive.  Essentially, a meditation on who we are really protecting when we keep information from “lower civilizations” – them, or ourselves?  Are we making sure that people can’t hurt themselves with knowledge, or making sure that they can’t hurt us?

IT can fall prey to Star Trek thinking (not just about the series).  It’s easy to take everything out of our users’ hands in order to “protect them from themselves.”  But who are we really protecting?  Are we really preventing them from causing problems for themselves, or are we giving ourselves job protection?

I’m certainly not arguing that you should give everyone admin rights – NO, no, no.  We all know that would be bad.  But do you really have to keep them from installing their own Adobe Reader updates?  Or make it a dark and mysterious path to find out how to order a new mouse or keyboard?

Think about things in your environment that are low-risk to open up to users, but would lower the number of tickets you get.  If you can tackle even a few of those things, you’ll both improve your users’ happiness with working with you, and cut your own workload.  Win, win!

IT Communication: Talk to Yourselves!

It’s really irritating, when you work in IT, to be out in the wilds of user-land and have someone stop you and say, “Hey, is X system down?” and then another person pops up – “yeah!  Mine is down, too!  What’s going on?”  And you have NO IDEA.  Because no one in your department bothered to let you know what’s happening.

Why doesn’t the communication happen?  Because the people who know what’s going on are working the problem.  But that still leaves others in the department hanging out to dry, with no idea of what is going on.

We need to communicate with our users.  But we also need to communicate with ourselves.  When there is an outage, make sure that it’s communicated to your department as well as to the users.  So, here’s a priority list:

  1. Quick message to your department (server name, system name, whatever – IS DOWN.)
  2. Quick message to power users/liaisons – those people who are close enough to IT to handle getting very little info, but knowing that more will be coming soon.  This is a good use for Twitter, actually.
  3. Slightly more detailed message to your users.  Name of the system as they refer to it, and any information you might have about ETA for getting it back online.   If you don’t know, just say that you will send an update when you do.

If you follow these guidelines, the people who need to know what’s going on will.

IT Communication: Say it once, say it again

Some messages bear repeating.  Occasional reminders about recurring issues, such as phishing attacks, can serve your users well.  Here are some things that it is worth sending periodic reminders about:

  • How to spot phishing attacks.
  • The most frequently asked questions at your Help Desk, and the answers to them.
  • Reminders about maintenance windows, if you don’t actually do anything in those windows most of the time.

The goal here is to balance your communication frequency.  You don’t want to spam your users, but you also don’t want them to forget about you.  If you haven’t sent out a message in a couple of weeks, it’s nice to have a canned reminder ready to send out just to keep the communication lines open.

IT Communication: The Ghost

I used to be a ghost.  I was the person who did everything in my power to not interact with my users – wander by their office and keep walking by when I saw them at their desk, schedule time to work on issues when they would be in a meeting and I’d have their computer all to myself, communicating entirely via email.

Being a ghost isn’t the best way to serve your users, though.  It’s so tempting – it seems like you can get so much more done when you just do it, no interruptions.  But if your users don’t know that you are helping them, you aren’t doing them any good.

This was really brought home to me when I was supervising another ghost.  At review time, one of their customers told me how frustrated they were – “He does good work – but it sucks to not know that we can use something, and then later find out that it was fixed days or weeks ago.  Not knowing impacts our productivity, so he might as well not fix it at all.”

If you are a ghost and really hate the thought of in-person interaction with your users, here are some ways to inform them but stay on the edge of your comfort zone:

Leave a little note

Sure, you can do a drive-by and make sure to work on their issue when they aren’t around, but make sure you leave a note telling them what you did and what they need to test.  It’s best to have something printed up that you can just fill out – that makes it nice and professional.

Schedule an appointment

Scheduling an appointment lets the user know when you’ll be working, so they can plan around it but still know when the work is being done.  If you schedule a few minutes at the end for them to test, you’ll be less likely to have to revisit the issue.

Do things remotely

Honestly, I’m not a fan of doing remote work, because I do think that interacting with people produces the best results.  But if you are really reticent, you can fix most thing with a good remote control tool.  That doesn’t clear you from communicating, though.  You still need to schedule it, and you still need to tell people what’s been done.

create a template

If communication is really hard for you, create a template that you can reuse.  Talk to a coworker to see what they send to people.

use a form

Our department gave us giant sticky notes that said, “Hi, (fill in your name) worked on your pc at (time) on (date).  Work performed was (several blank lines).”  These were handy and standard, so our users knew immediately what they were when they saw one on their monitor or desk.

It’s fine to be reticent to interact with people all day long.  Lots of us are that way.  But you can still provide good customer service by just leaving a little something behind to let people know that you were there.

IT Communication: 5 Tips to Get Your Messages Read

If you’ve worked really hard on a project, or have vital information about upcoming changes that you absolutely must get across to your users, how do you write your message so that they’ll read it?  In many organizations, IT is like a utility – it’s in the background, and people don’t think about it much unless something’s not working.  Unless you have groupies, probably no one is waiting with baited breath to read you latest missive.  How do you get the information you need to across to people?

Tip 1:  Put key information into the subject line.

At least tell them what and when (“Email servers down for maintenance Saturday at 8:00 a.m.”).  Tell them why they should care, and enough info that if they never open the message, they’ll have at least some clue about what’s happening.

Tip 2:  Front-load the message with key data.

Start your first sentence with the what and the when (“On Saturday, IT will be upgrading your Office suite to the new version”).  Then add the next most-important information (“Please go to (this website) for training information, or come to one of our open sessions at 10:00 a.m. every day next week”).

Tip 3:  Use bullets liberally.

Quit trying to write a dissertation.  Take the key points, slap ’em in a bulletized list, and keep the bullets short.  Hey, bonus, with lists, you don’t even have to write complete sentences!

Tip 4:  Use a standard format whenever possible.

If you can create a standard format for certain types of activities, such as system maintenance, outages, or upgrades, your users will know what to expect when they see your messages and easily find the information they need.

Tip 5:  Don’t bother with the details – but let them know how to ask.

Most of your users won’t care to read the entire history of the project, or even know why you are doing it.  If the tale is truly enchanting, or if you frequently get questions, feel free to tack that information onto the end of your message.  But keep it at the end.  And provide people with a way to contact someone if they are interested in knowing more.  It sometimes happens.

Keep your messages short and to the point, and people will be more likely to read them.

IT Communication: If you don’t know what you are doing, how will anyone else?

It’s amazing how many times I ask someone in IT, “what’s going on with XYZ issue?” and they look at me like I’m speaking another language.  Don’t they know what’s going on in their own department?  Why is it that to get an update on something I have to know exactly the right person to ask and no one else even knows who that person is so they can refer me to them?

Why IT Does This

This arises when IT departments don’t have a set way for everyone to communicate about projects and what they are working on.  Maybe there is no Change Control process in place.  Maybe people are physically separated from one another so they don’t have a casual way to find out what’s going on.  It doesn’t take much of a physical barrier to deter communication – in my office, our offices are in sort of a donut-shape around a central copier room, but you would think that we were in different states.  You might not see someone from the “other side” all week, even though you are both there full-time.  So, without a regular way for people to be updated about important goings-on, staff can be very out-of-touch.

It’s amazing how difficult it can be.  We recently had a huge project that affected most of our organization, but communication about it within the department was nil.  I wouldn’t have even known it was going on except that I am friends with the project manager.

What IT Should Do Instead

  •  Require managers to post a weekly summary of the major things their division is working on that week.
    • Focus on the highlights – “John is completing user testing in anticipation of go-live in two weeks,” “Jen is replacing network equipment at site X and site y.”  Don’t give a complete list of every little thing people are working on, but list a few of the big items.
    • If one group is just doing the same thing they always do, don’t mention it (“the device team continues to fulfill Help Desk requests” – not really necessary to explain that).
  • Have a regular (weekly at least) stand-up meeting where people can say what they are working on that week.  Make people be disciplined and concise.
  • Maintain an accurate project calendar with major tasks and milestones recorded for the entire department to view.

It doesn’t take much to keep everyone in the loop.  An informed staff will make your whole department look more professional to the organization.