The need for communication planning in technology projects is significant, and requires careful management. In this video, Bob McGannon discusses the communication techniques required to help you deal with various stakeholders including how to build a Communication Strategy. In addition, Bob discusses the common groups you'll need to communicate with such as the project team, senior management and external vendors.
- Cool Hand Luke is one of my favorite old movies. A famous line from that movie is, "What we've got here is failure to communicate." Sadly, that quote often comes to mind when I perform technical project reviews. Communication planning for technology projects is essential and requires careful management. Let's discuss the communication techniques required to help you deal with the variety of stakeholders that are part of most technology projects.
The first thing you need to do is build a communications strategy. The strategy needs to include who needs to be communicated with, how often you'll communicate with them, and the purpose of each communication. I recommend working with someone from your corporate communications team, as they can assist with the media options available, and can help you create communication campaigns throughout your project. The common groups you'll need to communicate with include project team members, senior management, external vendors, regulatory bodies, and finally, anybody else who cares.
Frequent written and verbal communications is essential for your project team members. All team members need to be aware of what is happening and why, especially part-time team members, as they may not be as close to the project on a daily basis. Communication with senior management does not need to be as frequent, but the information provided must be crisp and succinct. They don't care about the details. They just want to be confident that progress is being made as planned, and the end result will meet their expectations.
I usually create one-page diagrams to explain the message I'm trying to communicate. These documents should be engaging and answer the questions senior executives frequently ask. Such as, are we still on target to hit our deadline? Will we deliver the business value we're projecting? Are any risks actually happening, or are there new risks we need to worry about? It may take a while to create a diagram, but it's worth the effort. There's a great book that can help with this entitled Back of the Napkin, by Dan Roam.
In his book, Dan provides a number of ideas for capturing common business activities in a simple picture. The next group to consider in your communication plan is external vendors. You should be receiving written progress updates from vendors, but you also need to communicate information to them. If the business or project direction changes, they need to understand the impacts this could have on their work. Try to keep vendor communication frequent and to the point.
Regulatory bodies are another group that sometimes need to be included in our communications plan. With this group, provide the information they need, and nothing more. At project kickoff, engage with regulatory agents to understand their expectations around communication, and ensure you adhere to the agreed approach. Keeping regulatory agents fully informed, will make your life much easier. Keep them updated on status, and if something unplanned happens they need to be informed about, communicate the facts and how you plan to address the situation.
Then, follow up when the issue is resolved. The last group of stakeholders is anybody else who cares. Communication with this group should focus around what's in it for them, and what the project means to the company. This can be an important group as the project image could be based on what this group believes. Leverage your corporate communications team to help them build an intranet site for the project, a dedicated website, or write articles for the company's newsletter.
As a technology project manager, a huge percentage of your day should be spent on communications. This is time well spent if the messages you communicate help people understand what the project is all about, why it's important, and when it will be done. Do this well, and you could be cool like Luke, but without any project failures.
- Identify three characteristics of the ideal To Be process map.
- Summarize the steps to manage organizational change.
- Recognize three details to consider when evaluating a cloud solution.
- Recall the consequence of failing to address functionality gaps in a technical solution.
- Determine which facts to collect before discussing resource availability with sponsors.
- Identify the questions to ask when asking team members for feedback on milestone development.