In my former life as a communicator, we planned communications campaigns using the ROSIE principle:

• Research: Why is this needed, and what do we already know?
• Objective: What (SMART) outcomes are we trying to achieve?
• Strategy: How, broadly, are we going to achieve our objective?
• Implementation:  Specifically, what are we going to do and when?
• Evaluation: How will we measure what we’ve done and prove we’re successful?

 

As the old adage goes, fail to plan and you plan to fail. But problems arise because projects, be they in communications or software engineering, can fail to deliver results when they focus on the plan and not on the objective.

ROSIE, much like PRINCE2 and other project management methodologies, works on the waterfall principle of sequential design.

Waterfall is the model which is used for the step-by-step production of physical products, in which after-the-fact changes are difficult or impossible. The problem with this approach is that by sticking to the plan you bet large, and if you fail, you fail bad.

So from the late 80s onwards, software engineers slowly came to the realisation that their products are fundamentally different, and so a different approach is needed.  The result was Agile software development, a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organising, cross-functional teams.

There are, broadly, three main reasons why agile methodology has taken off in software engineering:

• First, there’s an increased awareness of complexity. There isn’t always one answer, and there’s rarely one means of getting people to where we want them to go. Realities are usually more nuanced. This means focussing on incremental progress toward goals rather than a ‘big bang’ win.
• Secondly, there’s an understanding that work doesn’t exist in isolation, and its success (or otherwise) is often a result of factors outside of our direct control.
• Finally, a realisation that we’re working with systems and people, not tangible things, so we need to stop thinking like engineers.

And here’s where I see many parallels with communications strategy. Campaigns, too, are not tangible objects, so we shouldn’t apply the same project management methods to them as we might for a car or a widget.

In creating and delivering a communications campaign, you’re dealing with people (notoriously fickle as they are), complex organisations and myriad factors beyond your control – whether that’s a cultural trend, a rival campaign or even some freak weather.

All this leads me to think that agile project management could drive success in strategic communications campaigns. By being aware of complexity and externality, communicators can free their resources up to focus on the objective rather than simply the plan.

So what does that really mean in a communications context?

When planning communications strategies, we treat the strategy as unmovable. But really, it’s the objective which should be the constant. Our strategy and our implementation plan should shift in the face of changing context in order to deliver the outcome.

Agile privileges individuals over processes and tools, outputs over documentation, collaboration over documentation, and responding to change over following a plan.

Twelve principles underlie the Agile Manifesto. And while these don’t easily map to communications work, there’s some broad principles here which could bring agility to communications campaigns (this borrows heavily from Catherine Howe’s session on Agile Policymaking at UKGovCamp).

Keep in mind your goal rather than your plan. Catherine notes the old army adage “no plan survives contact with the enemy”; keep the objective in mind but change the plan and circumstances change.

So in practice this could mean that while you have a series of printed communications planned for successive months, an agile approach would mean reviewing honestly after the first one and changing your approach in the face of success or failure. This means senior stakeholders need to sign off on the objective but trust their teams to deliver it as they see fit.

This means having a different attitude to risk. Agile breaks things down into smaller chunks to make it manageable. This means you can fail fast, but fail cheaply.

There are myriad examples of comms campaigns that just haven’t clicked at the off. But there’s often also an unwillingness to admit when things just haven’t worked, leading us to pretend all campaigns are somehow successful (this is especially true for agencies, in my experience). We need to be mature enough to admit failure and change our plans accordingly in order to achieve our objectives. That way we can support innovation and reduce the cost of failure (with campaigns failing early and cheaply rather than late and expensively).

And that means looking at small, incremental changes rather than a ‘big bang’ approach. For communications this makes a lot of sense – our focus is people and we usually want them to change their  attitudes or behaviours. That’s a slow process, and rarely should we expect anything other than incremental change.

Expecting a ‘big bang’ change in people’s mindsets or long-held habits is setting ourselves up for failure – real people just don’t work like that. We need to work in manageable stages and learn from success or failure as we go along. This way we can show incremental improvements while reducing communication failure.

And in order to do that, we need to test our work as we go along. Then you can adapt your approach based on evidence of what works or doesn’t.

Granted, there’s a world of difference between testing code and testing communications campaigns, but using things like metrics and pulse surveys we can begin to build a robust evidence base on which to plan our next steps. This, in turn, can reduce risk and reduce costs.

But testing shouldn’t be for testing’s sake; we need to work flexibly and adjust our plans in the face of new evidence. As Catherine Howe comments “Good ideas can be the wrong solution and serendipity can happen”.

In agile projects teams are usually cross-functional and self-organising with a flat management structure. Team members normally take responsibility for tasks that deliver the desired outcome. They decide individually how to meet requirements, increasing accountability.

It’s a team-based approach in everyone’s skills are valued and everyone has a responsibility for making it happen.

Central, too, is the end user or audience. In web development we use User Stories, which take the format of:

As a…

I want…

So that…

Using a similar user-centred approach to communications would help shift the focus from pleasing senior stakeholders to simply achieving the stated objective (for instance, changing the thoughts, feelings or behaviours of the target audience). In agile we constantly refer back to the user stories, placing the user – not the person with the purse strings – at the heart of what we do.

In employee engagement, we talk a lot about co-production as the engagement holy grail. Agile seems to me an important shift in the right direction, with campaigns and messaging driven by user (audience) requirements rather than the whims of stakeholders, and increasing their sense of ownership.

Finally, being agile relies on frequent, open communication, with people being kept in the loop every day. This is helped by working in small teams and open offices, with the aid of a quick, daily meeting called a stand-up. Communication should be open and honest, focussing on what’s going wrong as well as that which is going right.

But…

Like any project management methodology, there are dangers of sticking to it rigidly like some kind of cult. Practitioners can and should borrow those elements which work for them and adapt them to suit the circumstances.

The language of agile – with its scrums, stand-ups, smells, pigs and chickens – can be offputting. But the principles of making work more flexible and responsive to change have potential to drive forward projects in communications and many other fields besides.

In many, probably most, organisations, taking an agile approach to projects and campaigns outside of IT is going to mean a big cultural shift. The waterfall mindset is deeply ingrained in almost every project; changing that mindset so that stakeholders accept plans will constantly change isn’t going to be easy. It requires trust on the part of stakeholders and bean-counters, and getting that is going to require a hard selling job emphasising the rewards that come from reducing large-scale failure, and in some cases a big leap of faith.