HTML clipboardLong before email, the quickest form of interoffice communication was the dial switch message tube. Plastic cylinders were sucked from one end of the building to a central switch board. From there they were placed in another tube and pushed to their destination. Instead of having a megabyte size limit for attachments there was a weight limit.
Given the length of time that people have been communicating, the topic of communication is obviously huge. Methods have evolved from papyrus to paper and are headed to paperless�which just seems to create more paper. Communication is concerned with the entire package: what to communicate, when to say it and how to deliver it.
What to Communicate
Simply put, as a project manager you need to communicate answers, accolades, applause, bad news, budgets, briefs, causes, critiques, costs, delays, dangers, decisions, earned value�and I'm only up to the Es!!! An estimated 80% of a manager's job is communication.
So how do you know what to communicate? That depends on who needs to know.
Delivery Team. To the team you need to articulate the vision and direction of the project. Begin with the defining documents (Charter, Scoping Document, SOW, etc.) to lay out the vision of the project. Use the Work Breakdown Structure (WBS) to drive discussion of what needs to be accomplished and how to get there. Set delivery expectations by laying out a schedule with assigned resources, specified effort, and agreed upon dates.
Since communication is a bi-directional exchange, require feedback. Collect status, effort, re-estimates, criticism and suggestions. Don't accept excuses, complaints and whining without moving them beyond to solutions.
Sponsor / Management. Contrary to popular belief, management does not always want a rosy picture painted for them. They need the truth told succinctly so they can make informed decisions. They also need bad news delivered as soon as possible so they can take action.
On the other hand, management, if left to their own devices, will make assumptions that may not be true. Understand their expectations and work to align them with reality. Based on the scope definition of one project I was on, we successfully upgraded a software package. The directive for Phase 1 was "out of the box" and we and held the modifications to a minimum. At the end, the sponsor was disappointed she didn't get the new reports she wanted. I had failed to keep her expectations focused on the scope.
Governance / Auditors. The job of the Governance (Program or Project Management Office) and Auditor groups is to ensure that the safeguards are in place to make the project a success. They want to know that you understand the processes are following them. If your project doesn't fit the mold, meet with them up front and carve out a new mold that everyone can live with. Communicate lessons learned and process improvements to make projects work more effectively.
End Users. Usually End Users are ignored until the product is virtually complete and then they are brought in to ooh and ah over what we created for them. Your job is to understand their expectations from the inception of the product, align those expectations with the development, confirm them in the User Acceptance Testing and deliver successfully. Communication is the key through each of these steps.
Others. There are always others. Some of them can kill even the most successful project. While speaking with my PMO counterpart on a mass transit project, I asked who was handling the communications to the ultimate end users: the people taking the trains and buses. The project was to implement smartcard technology into the public transportation system. If they were unprepared to use the system, it would be a failure. Who will be impacted by your project and how should you be communicating the changes to them?
The ultimate purpose of communication is to eliminate surprises. Do that and you will be communicating the "what."
