You can never over-communicate. I hear this all the time in IT, and while I like the sentiment, I disagree. We are all badgered daily with non-stop communications that we ignore, filter and block just to maintain some semblance of sanity.
That said, given the sheer number of times we need to communicate; the complexity of the messages; and our users’ ability (or inability) to consume the information, we need to rethink our approach to IT communications. Here is what I mean:
- Traditionally, project teams default to previous communications plans, tactics and timelines. For instance, a preview email, a launch email, some supporting content, and a poster. It’s what we did last time. However, is there a better way to reach our users?
- Project teams also tend to be silo’d, so they may not realize there are other communications planned elsewhere in the organization. Rather than barraging our users with multiple messages, we should look for a more logical timeline, or even better, package similar project comms into one more impactful and easy-to-consume message.
- Email is not the only option. While not everyone uses the internal social media tools, perhaps your message will be better received from a different online or in-person channel. It really depends on how the users want to get their news, not what’s easiest for us.
- Deadlines are important in IT. However, sending a communications to hit a deadline does not mean it will be effective at driving usage or adoption. For instance, just because your project is ready on a Friday afternoon, doesn’t mean you send the email. People are already mentally starting their weekends, so the communications will be a dud.
- And finally, for fear of missing someone, IT teams love sending to widest audience even if the impact is minor. While we want to minimize user stress and avoid help desk calls, targeting a smaller, more appropriate group will likely be more effective.
Of course, I haven’t even mentioned how the message itself can make users to tune out. That is a blog (or two) for another day. In the meantime, consider the points above. What I’m suggesting is not unique, but it does require us to evolve how we approach communications in IT. What do you think?