About Me

header banner

Good communication within Projects is vital - consider how to improve and risks

Communication is important in many ways during the execution of a Project. There are risks of miscommunication to be mitigated and several areas of communication to focus on which I will cover in this post with a few Proverbs thrown in to help reinforce points.

Requirements Gathering

Most projects involve agreeing some business requirements. The ability to agree a set of requirements that the business and delivering teams both understand (and is non ambiguous) is a real skill and has many risks as can be illustrated by this cartoon  
Projects - Communication doesn't always result in correct understanding

Also as a good analyst you need to probe the subject matter as a user may naturally not volunteer information.
Project Communication - A user will tell you anything you ask but nothing more
Also, I'm sure that most of you are aware of the tree swing analogy re communication breakdown. 

So the requirements need to be echoed back in some written form and validated by the users but sometimes this has a risk of misinterpretation. Analysis techniques such as UML with Use Case Diagrams are designed to reduce the risk of such communication breakdowns - as the saying goes  ""A picture is worth a thousand words"

[For IT Project Managers, it can be difficult for users to articulate detailed requirements in some circumstances and this is where Agile methodologies are useful]

Written communication

Firstly remember the Proverb "What isn't written hasn't been said". So while face to face verbal communication is important the formality of some written audit trail is essential to ensure underpinning detail is agreed [note that an Agile methodology will reduce this]
Projects - What isn't written hasn't been said
So your project is likely to have a whole raft of documentation which needs to be able to properly communicate with an audience of reviewers and approvers as well as other people in the team. Having templates (or PRINCE2 product descriptions) can aid structuring the document correctly for understanding (and ensuring all subject matter is covered). However, the individual producing the document still has a role to set out the content in a sensible fashion to aid communication.

Of course, topics such as configuration management and ease of finding documents in the Project file also come into play. Tools such as SharePoint can help here although you still need to structure your Project file correctly to aid communication.

Stakeholder communications

You should understand who your stakeholders are and how best to communicate to them, see my post on Stakeholder analysis.

For Project updates, a Status Report (Highlight Report in PRINCE2) is a good way of regularly communicating project progress and issues to several groups. Additionally for the project governance group (Project Board in PRINCE2) you should organise formal meetings at least monthly. 

Your Sponsor deserves special consideration. A weekly status report is something which can be read at leisure to keep up to date and with the Project Board meetings for formal monthly updates, this is fine if things are broadly going to plan. But if things have gone awry and you need to convey some bad news, I strongly recommend picking up the phone to explain things rather than other communication approaches and especially before the status report is published!!
Projects - The best way to communicate bad news to your Sponsor

Other Communication considerations

  • Balance of listening versus speaking!
  • Consider the use of Email within the Project
  • Consider whether access to the Status report is sufficient communication with your Project team? A forum for two way conversations about progress is beneficial. Options here are to use your meetings with team leads to convey information which is then cascaded down to all team members with feedback coming back up through the next meeting. Also you can tap into existing "whole team" meetings or establish your own Project or Programme Town hall meetings to allow a two way dialogue directly with all team members periodically. Maybe consider a weekly Blog for a more informal style of team communication than the Status Report?
  • Consider the personality of the recipient, for some you should wallow in detail, for others it needs to be really punchy "what is the so what?"  
  • Consider the use of jargon in communication as per this cartoon showing poor Project Manager - Sponsor communication!

Conclusion

I know I have only scratched the surface of a discussion on Communications within Projects but hopefully it is sufficient to inspire you to consider this topic carefully both when Initiating a new Project and continuously during the execution.

Post a Comment

0 Comments