As a project manager, I tend to think of communication planning as the means through which I fulfill my responsibility of keeping the stakeholders informed. While this is a necessary component of project communications, it falls short on collaboration.
Technology projects of significance have complex dimensions that go beyond hardware and software to encompass business processes, organizational structure, job roles, and the interactions between an organization and its customers and partners. Those projects that succeed in creating the most value are those that are highly collaborative. Stakeholders take responsibility for working together through complex problems. And the collaboration goes beyond core team members — business analysts, programmers, testers, trainers — to involve a diversity of non-core stakeholders from the employees who know the daily details of operations to the C-level executives who understand how the project fits into corporate strategy. The conversations cross department lines. There is mutual learning and a willingness to challenge the status quo.
Now it is not easy to get this creative, collaborative process going. Key players may not make the necessary commitment for a variety of reasons. They may be busy with higher priorities, not clear of their role on the project, feeling left out, trying to avoid confrontation with other adversarial stakeholders, or thinking that the responsibility for the project lies exclusively with the core team. Some stakeholders may believe that the input of their requirements at the start of the project represents the end of their responsibility. And while I’m not going to suggest that a communication plan is a silver bullet guaranteed to overcome these obstacles, it is a useful tool that can help get a project off to a good start or at least highlight problems earlier.
A communication plan needs to not only clarify what communications are expected from the project manager, it should also spell out the responsibilities of stakeholders to participate, especially those beyond the core team. While it is neither feasible nor desirable to adhere to a rigid schedule of stakeholder feedback such as a one hour meeting per week or a one-page memo per month, it is important to specify an expected time commitment on a weekly or at least monthly basis. An iterative, agile process requires flexibility. But it is easier to cancel, shorten, or reschedule a regularly scheduled meeting than to get on the calendar of a busy stakeholder who never expected to invest time in the project. While it may have been obvious to you that that the stakeholders regular participation was essential, that is just an unspoken assumption until written into a plan.
If stakeholders whose participation the project manager believes to be essential to success refuses to commit to the communication plan, then it is important to raise a red flag. This should be added to the risk register and raised to the attention of the sponsor. It may even call for reevaluating the project go-no-go decision.
Because most communication plan templates available consist of a table documenting the who, what, when, and how of communications that emanate from the project manager to the stakeholders. I’d recommend adding at least at additional column documenting the expectations for that stakeholder to return communications and provide continued input into the project as it iterates forward.
Resources:
Basic descriptions of the steps to putting together a communications plan:
http://isb.wa.gov/pmframework/pmfplanning/communications.aspx
http://www.method123.com/articles/2007/01/29/Communications-Plan/
http://www.projectperfect.com.au/info_comms_plan.php
http://www.usask.ca/its/services/itproject_services/guidelines/communication.php
Templates:
http://www.projectmanagementdocs.com/templates/Communications%20Management%20Plan.doc
http://office.microsoft.com/en-us/templates/TC011455851033.aspx?ofcresset=1
Jim Downey 
Leave a Reply