Don’t get me wrong, the technology is important – but if people don’t understand how they are going to be impacted, what they need to do, and when they need to do it; the project has failed before it even starts. A comprehensive communication plan is vital to any IT Support project success.
The right time to craft your communication plan is after you have completed the technical project plan. This will give you the opportunity to view the project from a 10,000-foot level and see the areas where your end-users may be impacted. Examples might include new application installations that need to be completed, updates to their mobile devices, or times when a key application is going to be taken offline.
Once you’ve identified those spots in your project plan, create a master communication plan from your project plan showing when each mode of communication will be delivered. This is an ‘at a glance’ look at when major communications are going out.
Then, you can insert your communication plan into the project plan. Each communication task should be input into the project plan and given just as much focus as any of the technical tasks.
The communication plan should be written from a non-technical perspective. It can be written by a technical person but should be reviewed by a non-technical person to make sure it makes sense. If you have a ‘pilot’ phase in your project, you should enlist the feedback from your pilot group to help refine your communication plan.
A good communication plan will have several key components from a kick-off email to a project closure email:
This communication usually comes from a senior level executive or project sponsor. We’ve found that an email works well, as does a communication during all-hands meeting or webinar. At a high level, this communication updates the team on what’s going to happen, when it’s going to happen, how they may be impacted, and why it’s good for the company.
The executive kick-off communication isn’t technical – it’s purely a heads-up communication. This is important for two reasons: 1) It shows the company that senior leadership is behind this project and 2) it’s a primer for your team and gets their attention. There is an old marketing adage that people need to hear something seven times before they remember it. Count this as time as number one.
Depending on your company size or structure, you may consider creating departmental level communications that are condensed versions of the Executive Kick Off. We’ve found that using something we call ‘Champion Decks’ works well.
Champion Decks are a few slides that your departmental ‘Champions’ can cover in a departmental all-hands meeting. It should remind people of what’s going to happen, when it’s going to happen, how they may be impacted, and why it’s good for the company.
As you work through your project, craft your communication plan accordingly. In an Office 365 migration, we typically have four touch points for communication after the kick-off communication(s):
Touch point #1 is a two-week out heads up, without much detail, reminding users that they should expect to be impacted in about two weeks. This serves two purposes: It prepares the user for the impact, and it gives them the opportunity to speak up if they know that time may not work for them (due to vacation, project deadlines, etc.).
Touch point #2 is a one-week out heads up. Again, not very technical or detailed – but with a short explanation of what’s going to happen, what they should expect, and who to contact if they have questions.
Touch point #3 is a “D-Day” email that explains exactly what the user should expect, what they need to do, and who to contact if they have issues. (In our Office 365 example, we remind them to print the email – since email may be impacted and they may not be able to access this communication should they have problems.) This D-Day communication should be reinforced by a department head or champion via phone calls, webinars, or other modes of communication other than email.
Touch Point #4 is the check in communication. Most people skip this step (or just forget to do), yet it is the most critical. End users are funny – they don’t care about the tech, they just want to get their work done. They can adapt to most error messages or inconveniences. Interestingly, they will just click through an error message and assume they are the only ones having a specific problem.
In touch point #4, we communicate to the end user that the task is completed and ask for their feedback. Don’t assume that no feedback is a good thing – again, end users will adapt, and you can make the incorrect assumption that all is well. If your project is multi-phased, the feedback from this critical touchpoint can help you refine and recraft your message.
Remember, your end users are exceptionally resilient. People understand that IT Support can sometimes go awry and are remarkably understanding when that happens – but the key is to communicate with them on what to expect!