In my previous blogs, I describe the framework around how to manage a project, the process groups and we have discussed the knowledge areas from Scope to Human Resources. Next on the list is Communication.

Introduction

It has been said that if you are a project manager and are not doing some form of communicating around 90% of your time then you are doing something wrong. So, it is clear that good communication is vital to any project. But how do you get it right? We can address this by considering “how we communicate”, “what we communicate” and “who we communicate to” (I’m assuming we all understand “why we communicate”).

How - Communication Model

Below is a model of what happens when we communicate. The Sender has information that they want to convey to the Receiver. So, they transmit it using the Medium, this could be email, PowerPoint or verbally in a meeting. Inevitably, there is going to be some ‘noise’ within the medium. Now, I’m not just talking about a crackling phone line, there is also noise in the understanding of the message. The Receiver may have different assumptions to the Sender, hear the same words but interpret them differently. To mitigate this we listen to the acknowledge message from the Receiver, which could be as simple as ‘I agree’. In that case the Sender has no hope of confirming that the message was interpreted correctly. Or it could be a more complicated back-and-forth discussion. However, I’m sure most people will remember times when you had entire conversations where both parties appeared to reach agreement, only to discover later that there was a big misunderstanding over exactly what had been agreed.

Communication Model [PMI PMBOK 5th Edition]
Communication Model [PMI PMBOK 5th Edition]

Thankfully, by understanding that noise is always going to be present, we can change the medium to make the noise less pertinent to the concept you wish to convey.

What - Forms of Communication

What we communicate is modulated by the medium that you use. For example, if I write an email to a colleague versus having a conversation with them, then in the email the tone of my voice has been removed from the message. It’s now up to my colleague to interpret the tone based solely on my words and this can lead to people getting offended by emails where no offence was intended whatsoever. Therefore, for each piece of communication we do, we should consider the medium carefully and sometimes use multiple forms to ensure the correct message gets through. If in the process of the communication we think the medium is wrong, then we shouldn’t be scared to switch to something more appropriate (I’ve lost track of the number of email wars I’ve stopped by asking if the parties could get together and talk about their differences).

Listed below are the 4 types of communication and their pros and cons.

Type ExampleUseDon't Use
Formal writtenContractsUsually when money is involved For every single Engineering Change required
Informal writtenEmailWhen you need a paper trail, or the subject matter is complicated If the contents are difficult to raise or controversial
Formal verbalPresentationsStatusWhen the contents require multi-way discussion
Informal verbalMeetingWhen you need a record of what has been agree

Who - Number of channels

Similarly, we should be careful who we communicate to. Information should be passed only to those that need it at that time and avoid the desire to drown everybody in information that is of no relevance to them. I’m thinking of the worst feature in the email client, the “Reply All” button! We also shouldn’t be passing potentially bad news onto the customers until we’ve had a chance to verify the nature of it and at least have a recommendation for the solution. Nobody likes problems!

At this point, it’s worth noting the complexity of communication that can exist on even the smallest project. Consider a project with just 5 stakeholders:

Therefore, it is necessary to impose some form of control over who is authorised to discuss what with whom. After all, I don’t want a junior engineer telling my client’s CEO that he doesn’t think the project is going to work. Usually, I will authorise a few key people who have the technical ability and the commercial insight to discuss items with the customer. If the customer needs more in-depth knowledge on a topic then we can bring in additional team members for a limited time. I have found this works extremely effectively in controlling communication and is built into Sondrel’s Neon methodology. During Phase 1: Development, only the design quality team discuss issues with the customer, this leaves the remainder of the team to be undistracted by customer requests and can complete their work to schedule.

Neon
Neon

Conclusion

This is an insight into the knowledge area of Communication. We have discussed the how, what and who of communication. We are also aware of the effects that adding a single new stakeholder to the network adds to the amount of communication that occurs. In the next blog, I will continue our examination of the knowledge areas with the Risk knowledge area.

Andrew Miles PMP

Andrew Miles is a physical implementation engineer turned project manager. He is PMP certified and has led many projects for a number of tier one companies. He helps to run the Sondrel Project Management Office (PMO). If you'd like to know how Sondrel's project managers can help your project then please contact sales@sondrel.com