Project Management for PR and Communication

In this briefing, PR Academy co-founder Ann Pilkington outlines some of the fundamental principles of project management for PR that can benefit communicators.

Use these links to jump to the relevant section of this guide.

Introduction

Introducing project management: what is a project?

Approaches to project management: waterfall and agile

Time, cost and quality

Starting a project: the business case and requirements

Project roles – who does what

Project success or failure

What is it going to cost?

How long will the project take?

Project risks and issues

Learning lessons

How to understand a project: tips for communicators

Introduction

I’m a big fan of project management. Pretty much everything around us has come about because of a project. It is a process that results in something new being developed or something that is established being updated.

We all manage projects, often without really knowing. That special meal, a wedding, decorating a room – they all involve some principles of project management.

As PR and communication practitioners an understanding of project management helps in two ways:

• We can apply the principles to make our own work more effective.
• We are often asked to deliver change communication or launch products and services so understanding the project that underpins them will help us to develop the best communication strategy and plan.

After working on major change programmes in government I studied project management, eventually qualifying with the Association for Project Management (APM) Level 7 Project Management Qualification.

I draw on my project management experience and qualification when teaching change communication as I firmly believe to deliver good change comms you need to understand both projects and change management.

For communicators who would like to learn more, check out our Diploma in Change Management and Communication awarded by the Public Relations and Communication Association (PRCA).

Discover the course

 

For a practical guide to delivering change communication, see our briefing: The Role of Communication in Supporting Successful Change Management.

Read the briefing

Introducing project management: what is a project?

The Association for Project Management – the chartered body for the project profession – offers this definition:

Let’s explore that definition a bit more:

• Unique: every project is unique. Even if something has been done before, the second time will be different. The people involved may be different, the budget might be different, the external environment will be different.

Tip for communicators: From a communication perspective, it’s good to find out what worked the first time, but also important to recognise that repeating exactly what was done before might not be the best approach.

• Transient: a project has an end date.
• Desired outcome: projects are about delivering something, a final outcome.

It is worth also noting a couple of other useful definitions: “programmes” and “portfolios”.

A programme is a collection of projects; it is more strategic in nature, and the projects within it may come and go.

Portfolio management is about selecting and prioritising the organisation’s projects and programmes to both ensure return on investment and balance change with business as usual.

The difference between a project and business as usual

Projects:

• Produce change
• Timebound
• Develop a product or service

Business as usual:

• Ongoing stable production
• Repetitive without a defined end date

In his book “Agile Beyond IT: How to develop agility in project management in any sector”, Adrian Pyne says: “Project people are generally change people. We like change; projects are mostly about change. [Whereas] business as usual is about keeping the show on the road.”

Read our review of Adrian’s book

Approaches to project management: waterfall and agile

Projects that adopt a waterfall approach are divided into clear stages, as one finishes, the next one starts. The term waterfall is used because when the project lifecycle is drawn it looks a bit like a waterfall (or a staircase!).  Requirements are gathered at the outset and documented.

Where some projects will establish a detailed plan and detailed requirements at the start then attempt to follow the plan, agile starts work with a rough idea of what is required and by delivering something in a short period of time, clarifies the requirements as the project progresses.

As a result the project team need to work very closely with stakeholders as the product or service is developed in a more collaborative way.

An agile project should be quicker to deliver, although the product may not be quite perfect.

The Agile Manifesto has a principle which states: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” This is echoed by Adrian in his book:

Time, cost and quality

Projects have a number of characteristics that can be expressed through the iron triangle of project management: time, cost and quality/scope.

The concept of a triangle is a quick and clear reminder of what can go wrong on projects; if one of the three factors changes, there is an impact on the other two. If the scope of a project is increased, for example by adding extra activities to an event, then this will raise the cost and/or take longer to complete. Or if the budget is reduced, the scope of what can be delivered is also reduced.

Tip for communicators: Scope simply means what will be delivered, and what won’t. This is also a useful concept for inclusion in a communication strategy to help ensure everyone is clear about what is being done.

In project management terms quality is about fitness for purpose. For example a well-built, high specification sports car may be thought of as a quality product, but if the requirement is to take a family of five, their luggage, bikes and a dog on holiday then it isn’t fit for purpose.

Starting a project: the business case and requirements

Firstly, note that on projects being run along “agile” lines, requirements are more likely to develop as the project progresses.

The business case sets out the problem or opportunity, analyses the options, and recommends a way forward. A business case should explain the benefits of the project – who will benefit, how and when these benefits will be realised.

The costs are included and risks highlighted. It provides a justification for undertaking a project or programme.

Tip for communicators: When supporting a change project with communication, the business case is one of the first documents to read because it should set out clearly what the project is doing. Communication should be designed to support delivery of the business case and help to achieve the benefits that have been set out.

Of course practitioners should also develop business cases for their own projects. Presenting a compelling, well argued case for a particular course of action is an important skill that helps to win the support of stakeholders for internal and change  communication work. You can think of a communication strategy as being like a business case.

Check out our guide to writing reports and business cases

What about requirements?

These are the things that the customer really needs. It can be really hard to capture these effectively but getting it wrong can be a cause of project failure – and probably lots of arguments!

There is a really good blog on the Association for Project Management that discusses this.

Project roles – who does what

• Project sponsor. The sponsor owns the business case (although they don’t usually write it) and is responsible for making sure that benefits are realised. The sponsor is an important role because he or she can help with stakeholder relationships and support the project manager. They will probably sign off the communication strategy for the project.
• Project manager. The project manager is responsible for the day to day running of the project and must be competent in managing (not necessarily doing) the key parts of a project: scope, schedule, finance, quality, resources, the project plan and management of the team, suppliers and stakeholders.
• Project management office (PMO). The PMO supports the project with administration, for example reporting.

Project success or failure

A project should have a set of success criteria – measures by which the success of the project management is judged. These might be to do with the product or service being developed coming in on time and to budget.

Project benefits are a bit different. Benefits are the measurable improvements that result from the project and perceived as positive by stakeholders. For example, a new website might attract more customers and purchases. An employee event may result in people having a better understanding of the company values.

A project may set out KPIs (key performance indicators) which are measures used during a project to check that it is on track.

Tip for communicators: Sometimes when SMART communication objectives are set, they end up being about process rather than outcomes. For example, visits to a website, attendees at an event, media coverage. These types of objectives could be considered as KPIs. It can help to use the same language as rest of the project team.

Learn more about setting SMART communication objectives in our guide to developing a communication strategy.

Get the guide

What is it going to cost?

There are three main ways to work out what something will cost:

• Bottom-up. This is done by costing all the pieces of work that have been identified and adding them up to a grand total.
• Comparative. This involves looking at what something cost before and basing the estimate on that.
• Parametric. This is based on knowing how much a unit of something costs. It is often used in building, for example a house will cost a certain amount per square metre to build.

How long will the project take?

The first point to make is that the best project planning starts with what needs to be done, not the end date.

Having said that, if the end date isn’t acceptable this is where the iron triangle comes into play. If the amount of time needs to be reduced, then there needs to be an adjustment in one or both of the other angles. It might mean allocating more money or reducing the scope of what is to be delivered.

The critical path

The critical path emerges from an exercise to schedule the project based on precedence – i.e. what needs to be done before another activity and what tasks can be done in parallel. It identifies what tasks have no “float”, i.e. no spare time and if they slip, they will throw the whole project behind. These tasks must be monitored closely and given high priority when allocating resources.

Project plans and critical paths are usually developed using software, but for a short project, a simple critical path can be worked out manually quite quickly.

Keeping a check on scope

Larger projects and programmes may have a change control board which considers any requests for a change in scope, or it may be the responsibility of the project manager who will organise for the impact of any change to be assessed.

Tip for communicators: It is useful for the communicator to be involved in the change control process by being part of the assessment process. This is a way to get early sight of things that might change and have an impact on stakeholders. And of course the communicator may be involved in communicating the change once approved.

Project risks and issues

In project terms, the definitions are as follows:

• Risk is something that might happen and, if it did, threatens the project success criteria.
• A problem or issue is a risk that has materialised.

Risks are assessed by how likely they are to happen and how serious the impact would be if they did.

Once risks are captured, they are assigned a value and, importantly, an owner. Some organisations have their own methodology for this, but the principle will be the same.

Risks must be described in some detail, as specifically as possible. For example, in event organisation, it is not sufficient to say that the weather is a risk. Is the risk that it will rain? Snow? Be a heat wave? Each of these scenarios would require a different solution.

There are key steps to a risk management process:

• Initiation – this simply means starting off the risk management process and putting everything needed in place.
• Identification – this is where risks are spotted. This can be done in a number of ways, for example during a risk workshop, interviews with stakeholders and subject matter experts, reviewing lessons learned logs from previous projects.
• Assess – at this stage the potential impact and seriousness of the risk is assessed. Risks can be plotted on to a ‘probability impact grid’. Many organisations will have their own template for doing this. Some can be quite sophisticated, but essentially the task is to work out how likely something is to happen and how serious it would be if it did.
• Plan responses – this involves deciding what can be done to reduce the probability of something happening and then putting a plan in place. This can be captured on a risk log.
• Generally speaking, there are only four courses of action when dealing with a risk:

Accept: don’t take any action, but monitor

Avoid: change the project scope for example so that the risk is excluded

Transfer: pass the risk elsewhere. This is what we do when we insure our car against an accident

Reduce: do things that lesson the change of it happening.

Think: risk and opportunity

Project managers are taught to think in terms of risk and opportunity. For example, a risk is identified and the way to manage it actually turns into an opportunity.

Tip for communicators: The project risk and issues register can be a valuable way of getting the voice of communication heard. Once something is captured on the risk log then it is hard to ignore it. For example, there can sometimes be a reluctance for project colleagues to share progress – particularly when things aren’t going too well – or to give the communication function a low priority. If this is happening, consider raising it as a risk. After all, stakeholders will lose confidence if they aren’t kept up to date and problems aren’t acknowledged so this is a valid communication risk. But raise risks wisely, the risk log is no substitute for building trusted relationships with colleagues.

Learning lessons

Post project reviews or lessons learned reviews look at how successful the project was against its success criteria and how effective processes were. Communication will be a part of this. It is a good opportunity to have any problems or barriers documented so they can be addressed in the future.

However saving lessons learned to the end of the project misses the opportunity to improve processes during the project’s life time so it can be good to have lessons learned reviews built into regular project boards.

How to understand a project: tips for communicators

You’ve been asked to deliver change communication on a project. Where do you start? How can you get to grips quickly with what the project is doing?

All projects will have documentation that can help the communicator and it pays to spend time reviewing them. Depending on the size of the project and the project methodology being used, these may vary in name and nature, but here are some key ones to look out for. Key documents to review include:

• The business case: this should set out the rationale for the project and the benefits to be gained.
• The vision and blueprint: used in change projects, this will tell you what the project wants to achieve and what the organisation will be like when the project completes.
• Project initiation document (PID): this should set out things like the objectives for the project, the scope, assumptions, deliverables, resources and risks.
• The risks and issues register: communication should be contributing to this either in terms of raising risks or providing mitigation of risks. Reviewing the register is a quick way to understand any problems that the project may face.
• Project plans and roadmaps: they set out what will be achieved by when and the communication plan should of course be aligned with them.
• Lessons learned: has a similar project been done before? If so, review the lessons learned document.

As the new communicator on a project, set up some short interviews with key project people. Start with the project manager and maybe ask their advice about whom else to talk to. Get their support for this so that others can see that it is a priority.

Go into any such interview well prepared. Refer back to the project documentation and identify any gaps and points where more detail is needed to inform communication. People may try to save time and avoid answering questions by simply referring back to their documentation, so it is important to make it clear that this has been read, but that there is more explanation needed.

Further reading and useful links

Links

Association for Project Management (APM)

Books

Agile Beyond IT: How to develop agility in project management in any sector by Adrian Pyne

The following books are also available on our Study Hub for those studying with us:

• The Effective Change Manager’s Handbook: Essential Guidance to the Change Management Body of Knowledge. Editors: Richard Smith, David King, Ranjit Sidhu.
• Managing and Leading People Through Organizational Change : The Theory and Practice of Sustaining Change Through People by Julie Hodges.
• Communicating Projects : From Waterfall to Agile by Ann Pilkington

Courses

PR Academy Guide to CIPR Internal Communication qualifications 

PRCA Diploma in Change Management and Communication