I didn’t know what to expect from Ann Pilkington’s book, Communicating Projects. It isn’t about just about producing a communication plan and while it is broadly aligned to the APM Body of Knowledge (6th Edition) it isn’t a guide to doing things according to any particular method or standard.
It turns out that the book offers practical help and guidance to the person on the team doing the communicating. She assumes that this isn’t always the project manager. On a large project team you may well have a project communicator (as she calls them) but the book could also be of use to people in a non-project role who find themselves being dragged in to prepare communication materials about a project they know nothing about – your corporate PR or Marketing team, for example.
Agree what ‘communications’ is
The first bit of advice Pilkington has is not to communicate. At least, not to communicate too soon. The first thing to do is to agree the role of the communication workstream. Who is going to do what? And what is it that you are going to communicate?
Communications have two objectives:
- To share what has been done (the output)
- To share what has been achieved (the outcome)
Outputs are things like producing newsletters or updating the intranet page for the project. Outcomes are things like ensuring that employees know what the project means for them. Your communication plans will need to include both these types of objectives, in a structured way. And that doesn’t mean simply issuing briefings. Pilkington writes:
Despite the fact that projects exist in a world of sophisticated media and advertising, there is a still a tendency for communication to be thought of as a simply linear process, that is, somebody is told something, they interpret it in the way that was intended by the sender and that is all that is needed. Where this ‘send out stuff’ approach still prevails on projects it is no wonder that stakeholders are cynical or disengaged and projects don’t realise their benefits.
And what it is not for
There are, Pilkington says, limits to what communications can achieve on projects. She says that the communication function is not there to:
- Replace good project governance
- Remove the responsibility for line managers to communicate with their teams directly
- Manage project documentation
- Massage the message and make bad decisions look good
- Stroke the ego of the project sponsor or manager
- Fix things that aren’t problems caused by or to be addressed by communication.
So, having got clarity on what the project communication function is supposed to be doing, how do you do it?
Strategy, content and execution
Chapter 2 covers communication strategies and includes a template. In fact, most chapters end with a template and sometimes a ‘vignette’ which explains an element of theory or gives an example. While the templates are good, I found the vignettes distracting and I can’t see why these haven’t been woven into the main body of the text.
Part of your strategy is defining your stakeholders and the book also includes a stakeholder analysis model which goes into plenty of detail.
Pilkington goes on to discuss the content of your communications plan in Chapter 4. She recommends that you don’t create a project ‘brand’ because it looks transient and “wacky”. I had never thought of this before but I have seen plenty of awful brands for projects and worked on branding my own projects – something I will now stop!
She does, however, recommend having a house style for communication that covers a consistent approach to
Managing your message
The final two sections don’t fit the project management lifecycle particularly well but are good additions to the book. There is a useful section on crisis planning. Not all projects will need to take account of this, but yours might if it meets the criteria that Pilkington sets out. If you do think that crisis management might be needed (for example, if your project is going to make lots of people redundant and you think this might hit the news) then it is definitely worth being prepared before it happens.
The final section of the book is about evaluating your communications, which is something I don’t think project teams do routinely. The point of evaluating what you communicate is to check that it actually did what you wanted it to do. Pilkington recommends doing a communications audit to check the desired effect of your communications. She says:
Project communications should not be judged only by how much activity is undertaken, how nice the posters look or how busy the team seems to be. While there is some value in knowing how much activity has been carried out, this is no indicator or quality or outcomes.
Evaluation is worth doing because it helps you:
- Identify what is working
- Identify what isn’t working so you can stop or change it
- Identify lessons for a lessons learned meeting, based on evidence rather than anecdotes
- Prove that the communication function on the project is worth doing.
This last point seems particularly important to Pilkington as it’s also one of the reasons she wrote the book in the first place. She wants to elevate the communication function on a project to raise its profile, something which I can agree with.
Overall, this is a useful end-to-end guide and it is written with a wide enough audience in mind to make it valuable to anyone on the core team or in the extended business team who finds themselves responsible for communicating to others about a project.