Communication Management: Being the bridge of communication between project stakeholders

Managing the communication within a project is never an easy task – the larger the team and the more teams that are involved, the more difficult it can become without proper foundation, follow-through, and consistency. This is an area that hits close to home to my interests and I am happy to share some information that you can hopefully take something away from, enjoy!

So then, how is this done properly? How do we organize all the information that flows throughout the duration of a project, ensure the integrity of the information remains true and is transparent between teams (inter & intra)? It is up to the technical (IT and business-related) stakeholders to understand their roles and responsibilities but being able to communicate all the technical information (which may be broken into silos within a single team and other teams) into business language and is digestible to any person in the project is another story. Prior to being able to manage communication, we must first understand what types of roles are involved in order to properly facilitate. When we talk about “roles” here, we are talking about project stakeholders and they are as followed:

1. Customers: Provide them with demos/prototypes, ensuring the product is what they’re expecting throughout each phase. They will most likely provide feedback whenever you have a discussion with them, and that feedback must be tracked.
2. Project Sponsor/Manager/Coordinator: The facilitator of the project to ensure deliverables are completed and to track the scope/timeline/resources. Coordinators typically contribute to the more time consuming (tedious) responsibilities. These roles also complete the functional and non-functional requirements and deliver them to the project team.
3. Designers: They may or may not also be software engineers. Their responsibility includes designated to help model out the build via high/level design documents and models.
4. Software Engineers: The builders/programmers of the project! They will be heavily involved in the implementation phase of the project, but most likely involved in other phases (e.g. initiation, planning, design, implementation, deployment, maintenance) as well. 
5. QA/Testers: Depending on the makeup of the organization, this may be a separate team during projects, mold as an integrated workgroup, or testing might just be something the main development team does on their own (more common with smaller projects).
6. Service Desk: What information is needed for them to support at Go-Live and Post Go-Live (tip sheets, break-down sessions, point of contact for escalations, etc.)
7. Field Support: The front-face of technical support. Must know the scope of the project in terms of what they signed off on (e.g. can repair hardware but not replace without payment) to properly provide support when deployed to the location.
8. SMEs (Subject Matter Experts): Personnel that are expert end-users and must be involved throughout the project, beginning in the initiation phase. They think both deeper and broader in terms of what needs to be done from an operations perspective. For example, a primary care doctor of 30 years who worked in a legacy system could be a SME for identifying functionality in their new system based on what functionality is currently required to complete all tasks while maintaining patient safety.
9. Managers: The manager from each team should receive weekly updates (more often in sprints and as deadlines approach) from their team. The managers should have meetings on an interval (e.g. once per week) with the PM to communicate updates/progress/questions/concerns/escalations.
10. Executives/Leadership: This is where the major business decisions are made. These decisions are at an incredibly high-level and numbers are typically the only thing they care about (cost, profit, return on investment, statistics, etc.).

With all these stakeholders mentioned, just think about the massive amount of information flowing through each individual and each team! It may be in the form of conversations (Skype/Slack IM, meetings, emails, texts), within spreadsheets, word documents, ideas on sticky notes, you get the point… How do we not only bring these people together to share their knowledge/questions, but also properly interpret in a meaningful and comprehendible manner?

Ok, enough questions, lets talk about some answers…

The obvious answer is the project manager (PM)! They are responsible for facilitating the types of meetings that need to take place (adoption sessions, weekly team meetings, weekly manager meetings, etc.), who should be involved in each, creating and following an agenda, taking thorough notes, and being the string that ties all of the stakeholders together as a cohesive project team. They should also involve themselves and engage in all forms of communication, which is why relationships are also very important. There will be information that does not need to be fully understood by each individual person, but simply being aware of something goes a long way. For example, a manager from a different team should know about a functionality that may impact their team, but they will not necessarily need the details of how that functionality is being built. They will most likely just want to know if there is any impact/downtime and if there is any build/interface on their team that is necessary.

There are many models that are used for communication management, but most follow similar processes. Such processes include timely and appropriate planning, collection, creation, distribution, storage, retrieval, management, control, and monitoring of project information/materials. The organization’s tools will determine how each of those processes are executed (MS Teams, Sharepoint, Dropbox, etc.) and there may be a combination. At my organization, we heavily use Sharepoint to post the project timeline to the homepage, then have folders which are named as different types of deliverables. After meetings, the PM (or assigned notetaker) will email all of the attendees with a link to the notes (on Sharepoint) from the meeting so that they may review and have accountability for the points and action items discussed.

Hopefully some of the information in this post interested you in learning more about communication management and becoming more aware of its importance. If you have ever been in a project with a PM and felt minimal disconnect between co-workers/teams, then they are doing their job! Remember, project management in its best form is when it is practically invisible. Feel free to respond to this post, ask questions, and share your feedback. I have a lot more that I would love to discuss, but then this would never be posted in time.

I would love to hear what you guys have to add. Thanks for reading!