Project Communications – Where to Start

From my experience as a Project Manager, and similar to most professions, every project manager tends to develop their own unique style of managing projects and communicating with stakeholders which will be in accordance with the engagement framework they’re operating under. Similarly, each stakeholder involved in a project will have their own way of engaging with the project manager and the project team which varies between individuals.

Regardless of this, it is imperative for all members of the project team to effectively communicate in order for the project delivery to be successful. This is hardly a revelation and more of a requirement against any project, with great communication skills being one of the fundamental traits that all project managers need to have and nurture within the project team.

Throughout my career, and especially during the COVID-19 pandemic, I’ve tried and tested various different ways to improve communications within my projects and delivery teams with varying success. There are now more communication tools than ever for PMs and projects to utilise and leverage within their projects but there is also an increased risk of genuine communications getting lost in the various channels and noise that these virtual collaboration spaces now create.

There are many ways to skin a cat when it comes to project communications and unfortunately there isn’t a silver bullet or a one-size fits all tool on how to overcome and manage communications barriers within projects to ensure everyone is communicating effectively throughout the project lifecycle. That said, I have detailed some of my main considerations below that I always employ within my projects to help me get a successful communications framework in place for my projects.

  • Who, Why and How

The first 3 questions I typically tend to think about when looking at any project communications plan is ‘Who do I need to communicate to’ which is often followed in quick succession by ‘Why do I need to communicate with them’ and then ‘How will I communicate with them’.

Once I’ve sufficiently answered those questions, I will then ask myself those same questions inversed, ‘Who needs to communicate with me’, ‘why do they need to communicate with me’ and finally ‘How will they communicate with me’.

From the above questions, it is the responsibility of the project manager to ensure the right form and frequency of project communications are defined for each and every project stakeholder that comes to mind. It is also key for stakeholders to understand the intention behind the communications issued to them and also what they need to do in response to these communications.

As an example, you wouldn’t send an executive summary for a project to the projects executive sponsors via a group teams IM. It’s far too informal and the importance of that report isn’t reflected in the communications channel it has been issued in. It is more likely to get diluted and missed with all the noise generated by other chats/ IMs which will increase the likelihood of inaction a reduced response rate. By issuing it via email to a targeted group and marking as a priority, the executive sponsors will perceive the importance of the communications before understanding the content, it provokes action and will ensure that items are understood and addressed in a timely manner.

  • Roles and Responsibilities

Once I have defined the ‘Who, Why and How’ for the project which I typically tend to playback and confirm in the Project Definition Workshop at the beginning of my project, I’ll then ensure that Roles and Responsibilities are understood for all project stakeholders once the project communications plan has been agreed.

Certain communications can vary between projects and also between different phases of the same project so it’s critical for stakeholders to understand how they’re expected to communicate and how that changes throughout the project. As an example, a technical consultant within the plan and design phase of an project will be expected to communicate through a series of workshops to gather the clients business and technical requirements in order to produce technical designs for review and approval. This same consultant in the migration phase of the project, will instead be expected to be available for any CAB/ T-Minus review calls against the migration phases and will be responsible for updating and completing the Migration runbook and testing plan for each migration phase with the associated application/ service owners.

There are some constants through the project too when it comes to project communications. Certain communications will intentionally not change their format or frequency to serve as a regular baseline for delivery, these include the highlight reports, project plans and RAID reviews. For example, a technical consultant is expected to flag any RAID items against their workstreams throughout project delivery, it is then for the Project Manager to identity the correct response/ action to that item and track and manage it through delivery.

  • Keeping people engaged

Consistency is key when it comes to project communications. As highlighted above, it is important for all stakeholders to know their role and responsibilities in project communications but it is equally important for them to know how long they’re expected to communicate for.

Everybody has their part to play when it comes to communications but this is only for a set period of time. A failure to acknowledge this may result in a lack of engagement from the project stakeholders or communications shortfalls which can cause significant pain in project delivery. Setting expectations from the start help will help with this as covered in Points 1 and 2 but it is also important to understand the project stakeholders capacity to handle the communications expected from them. All too often I have seen a reluctance initially to get a Communications/ Marketing lead involved in the project to handle certain communications only for that requirement to be revisited later down the line due to the amount of work involved. Making communication requirements known and visible at the beginning of a project will help the team come to a decision quicker on whether additional support is necessary or not. Providing a start and finish date for any communications activities will also help teams to manage their workloads to accommodate these responsibilities during project delivery.

So you’d be right in thinking that all three points are fairly straight forward and easily recognisable, however you’d be surprised at how often they’re missed or overlooked. If you get the basics right then the rest will follow and any good communications plan will address all of the above points. Typically communication problems all boil down to a misalignment on one of these fundamental principles and it’s always the place I start from if there’s a communications shortfall in one of my projects which I need to address.

About the author