Having a Team Communication Plan is Great- Making It Work Is Something Else
The German general Carl von Clausewitz famously said, "no plan survives the first contact with the enemy". Not that your remote team is the enemy (seriously, no matter how badly your day is going) but the idea is the same: having a process in place doesn't mean people will use it, the results will be what you think they'll be, or that you won't have to constantly adjust and adapt.
I was speaking to a group of Project Managers the other night about managing their remote teams and the idea of team communication plans came up. "You have to have a process!" they proclaimed loudly. Project Managers are big on processes, as they should be. I asked how many people had a true, formal, written plan for team communication. Most of their hands went up (I'll be charitable and assume that none of them were sheepishly refusing to admit they didn't have one).
Then I asked how many felt their team adhered to the plan. Hands dropped. Then I asked how many of their team communication plans looked the same now as they did the day they were created. One or two lone hands remained. Communication plans, like Prussian defense strategies, are subject to the harsh reality of the work.
Out of that discussion, we came up with some guidelines for putting a team communication plan in place that will survive in the real world:
- Have the team build the plan and commit to it. Top-down plans are doomed to failure. Getting the team to talk about what's important to them, then gaining their commitment is critical to building trust and making sure what's really important gets covered. A great example is response time. It's one thing to say "all messages returned within 12 hours", it's quite another to say "when you leave a message, state the priority so people can prioritize their responses". The important things get handled first- that's a good thing in any plan.
- Post it where they can see it and refer to it constantly. The communication plan needs to be properly built and launched, but it also needs to be the way you work as a team. If people use it well, trumpet that success with the team. If it failed in an instance, ask the team why and find out if it was a one-time problem or there's a bigger problem.
- If people aren't using it, find out why. Now. There are plenty of reasons why a plan fails in a specific instance. Maybe the person got distracted and forgot to answer that question. Maybe they were out of town and forgot to post their status. Maybe that fancy SharePoint system is such a pain they can't be bothered. Track your team's performance against the plan from the beginning. If it's a "people" issue, coach them right away. If it's a system or equipment problem, fix it and show your commitment to the team's success. Enforcing rules that are counterproductive or defy the laws of physics can damage team morale. Maybe it's the plan that needs fixing, not the people.
- When choosing technology, start with the end in mind. Technology is critical to remote teams, but only if it helps get the work done. When deciding on the tools you'll build into your plan start with what work needs to be done. "We need to have quick access to the latest version of that document, so use the shared files" is a good idea. "We have this new shared file system, so learn to use it for version control" is the same idea but sounds like so much IT nonsense to people out in the field. If a tool isn't getting the job done, find out why it's not working. Does it not do the job? Are people not using it because there's a technical problem? Do they need more training or do you just have to enforce the rules?
- Revisit the policy. Periodically (and how often depends on whether it seems to be working or not, but at least once a year) the whole team should honestly discuss what's working and what needs to be tweaked/changed/scrapped. Technology changes, team members change and the demands of the job (especially in project work) change. The plan needs to evolve to meet the job at hand, not the other way around.
Read more: