The key first step is to identify the project stakeholders and perform a stakeholder analysis. Now, the term stakeholder is a bit of a loaded one for many people. For some it is the executive stakeholders who are the customers for whom a system is being built or change is being implemented. Sure, they're stakeholders. But that's a fairly narrow view.
Back it up and think of everyone who has a stake in the successful outcome of a project. Think of anyone who could positively or negatively impact the project. Then think of anyone who could be positively or negatively impacted by the project. Sure, your executive stakeholders or customers are on the list, which probably your project sponsor and/or champion who will probably need more communication than some of the other executives. And, yes, the sponsor/champion needs to be an executive, as they need to have money and political clout to help get past any roadblocks.
Other stakeholders, such as future users of the system may fit higher or lower on the power and interest, depending on what kind of project you're doing. Something that has a status quo that people want to maintain will result in high interest users trying to shut you down. If they're the users, they have relatively high power, as they can sabotage, refuse to help get the system going, or just not use the system after it goes live, even if they are not actually on the project team.
Still others will include people like the dude you always see in the breakroom and is trying to get into a position in your department and really wants to know what is going on, even though at this point the poor soul has nothing to actually offer you. Then you have managers in other departments that could shut you down if they wanted, but they care little if anything about what is going on in your project, so you try to keep away from those people as much as possible. If one of those high power / low interest executives finds out how much your project is costing and wants some of that funding for something in their department, watch out. So a big piece of what you want to watch for is considering what information is relevant to which people, so you can be sure everyone has everything they need and nothing they don't. Even the lowly users who don't have much say in what is going on may be upset if they knew how much the project is costing, but unless they're writing the check, that's not something you talk to them about.
Once you've thoroughly gone through who the various stakeholders are, what kinds of things they can offer you, how much they care about what is going on, the methods of communication that would be most effective for each, and the specific details each cares about, it's time to actually create the communication plan.
The plan itself will be based on the stakeholder analysis and three major phases - introducing the project, carrying out the project, and closure.
Project introduction will include things like gaining buy-in from everyone. Sometimes it's little more than a courtesy notification that the project is happening, particularly for low power players. You'd be surprised how often people are surprised by projects that have been started and people who thought they were a key stakeholder are completely left out of the loop. Let people know what is going on, how the project will affect them, and what help you will need from them. If they have high power over your project, something deeper like explaining the ROI or strategic purpose behind the project will be necessary.
As the project begins, you need to check in with people every so often. A person who won't see the system for 2 years until it's completely done and ready to launch and isn't working on the project will get annoyed if they are receiving weekly status reports. Don't CC the entire company on things. Don't throw information out to people that they don't need to know. Be thoughtful and consider both their time and the political fallout of making people angry at you.
Do make your plan specific. Lay out what information team leads and other team members need to report back to the project manager and how often. Then lay out what the project manager will collect and analyze and who that aggregated information will be sent out to. What format will it be in? What are they expected to do with it? Just read it if they choose or provide feedback and approvals? What items don't recur regularly but happen on either just a certain date or upon some event occurring. When there are change requests, there should be a plan for getting those communicated to people, even though you don't know when they are going to happen. You just know when they are approved, they need to be communicated quickly so the project team is working on the latest information.
And as the project comes to an end, there is information that needs to be communicated and gathered to close out the project. Often final versions of the recurring communications will be put together. Other information, such as lessons learned and team member performance may not be known until the project actually does end. Whether the project is successful or unsuccessful, there should be closure. In fact, one piece of closure is to communicate about the success (or not) of the project. There can be many lessons learned from a failed project, so don't forget to sit down and talk about how to make sure the same thing doesn't happen again in the future. If you don't document that you were going to compile the approvals of all the project deliverables at the completion of each project phase, you may not be able to go back and collect those all later, due to people either leaving the company, losing interest in the project, forgetting what they agreed to, changing their mind, or otherwise. So know what you'll be communicating at the end so you can be gathering that information throughout.
As you lay out the items you will be communicating to gain buy-in and start the project off on the right foot, the items you will be communicating on a recurring or scheduled basis throughout the project itself, and the items you will gather to provide closure to your stakeholders when the project wraps up, be sure that you refer back regularly to the stakeholder analysis. Don't spend a lot of time on people who have nothing to help you with or who don't care about what you're doing. Be sure you have a sponsor who isn't going to lose interest in you half way through.
Make certain you include everything from the stakeholder analysis in your communication plan; if you know someone cares about the project costs and the communication plan never has you sending them a report on how much is being spent, you're missing something. Possibly even more important, when you're sending information to people, refer to the communication plan and from there back to the stakeholder analysis, and don't send stuff to people they don't care about and don't need, as it will begin to burn any goodwill you have with people and make it politically difficult to work with those people in the future. Yes, this means that you need to check who's on the CC line of an email before you hit reply-all and coordinate most of the communication centrally.
