Our step by step journey to becoming a lean PR agency (1)

About 2 years ago, we started a change toward “lean” at our communication agency FINN.

Initially, we were mostly influenced by ‘The Lean Startup’ and John Seddon’s work on “rethinking lean services”, which means we were mostly looking at ways to reduce failure demands, or what David J. Anderson calls “failure load” in his excellent book Kanban. (*)

I wrote about these early steps toward lean on the Mustr blog.

Early steps towards lean: the war on failure demands

So we duly declared war on failure demands, and we agreed with the team that we would try to root out failure demands completely.

Identifying failure demands in PR context wasn’t too hard — after a minimal brainstorm we came up with these main categories of failure demands:

1. Progress chasing

Progress chasing (“where are you on X? You didn’t forget about Y, did you? You never got back to me on Z”)

2. Errors

Errors in deliverables caused by substandard briefings: we have since implemented a process that puts the onus of a good briefing on us, the agency. This process is designed to reduce rework because of incompatible expectations. The process requires:

• a (phone) meeting to discuss high level messages and proof pointsa MindMeister mindmap with messages, proof points and storyline
• a written brief with context, key messages, headline, likely and desired outcomes, resources needed and next steps
• approval on the briefing by client

only at this point will we start work on deliverables.

3. Rework

Rework based on (sometimes minor) errors.

If a draft press release has two typos, chances are the client will demand rework on the messaging — this is not logical, but it’s human: it’s a sign of frustration.

The thing here is that there is a trade off between error free drafts and waste. If we write a draft and substantial parts have to be rewritten, it is clearly wasteful to send such an early draft to a proofreader, or to spend too much time spell checking and grammar checking the copy. To be honest, we have not yet decided on how to deal with this problem. Currently, we try to do a thorough check ourselves to send error free drafts, without having them specifically “proofread”. We do include a disclaimer to explain why we don’t proofread drafts, and with the specific reassurance that we will proofread the copy before it is sent out.

4. Illegitimate forks of work

Illegitimate “forks” of deliverables: when two versions of a deliverable start to cross each other, errors are inevitable, which will cause confusion, unclear communication to clients and inevitably, screw ups in materials that get sent out to journalists.

Forks happen most frequently when people are rushing and send a text to a translator, thinking “we will implement whatever remarks of the client later in both language versions” (this never works and always — always — causes trouble at some point).

Thinking about value demand versus failure demand was incredibly helpful, and I urge everyone who has a professional service firm to read Seddon’s paper - and to a lesser extent his book ‘Freedom from Command and Control: Rethinking Management for Lean Service’, because that seems mostly geared towards management of customer service centers.

To get more visibility on our value stream, we started using Trello.

But it still felt like something was missing. We were nowhere near the visibility of value streams that some manufacturers were achieving in books like ‘The Machine that Changed the World’ or ‘Workplace Management’ by Taichi Ohno.

What we missed was a good framework to translate the concepts of lean manufacturing to a service environment.

We knew that scrum and agile were somewhat related to lean, but it was only after reading ‘The Phoenix Project’, ‘The Goal’ and ‘Kanban’ however, that a few things seemed to click.

It seems that all the hard work of translating lean from manufacturing to services has already been done by developers (thanks, guys!).

While PR is obviously different from software development, there are also quite some similarities:

• there is the need for a good briefing in PR (which translates to solid requirements and user stories in development)
• the need for quality control in both disciplines
• there are rush orders (fatal bugs in IT, unexpected crises and issues in PR)
• recurring demands (monthly reportings in PR, maintenance in IT)
• deployments (pressing the “send” button on a PR campaign)
• etcetera

From the literature on lean in development and IT, it became clear that what was still missing in our approach was a limit on Work in Progress (WIP).

Without limited WIP, says Anderson, teams see only marginal improvements in lead times and productivity. To unlock the benefits of kanban/lean, a limitation on the Work in Progress is necessary.

Looking at our Trello boards at this very moment, we see that every person is working on between 5 and 10 items of WIP, with another 10 items marked as “ready”. I would estimate the WIP at the agency at between 150 and 200 — probably too high for a 10 person agency.

Next steps

1. Limit Work In Progress

So this is where we are now. We are convinced (or convinced enough to make a serious effort to experiment) about following things:

• We know that the key to using kanban and becoming lean is to limit Work In Progress
• Limiting WIP and batch sizes and working with a clear priority system should reduce lead times and at the same time increase quality of deliverables
• We know that we need to do a value stream mapping in order to find the flows and see where the constraints are
• We know that limited WIP is the key to higher quality
• We know that we should try to visualise workflows, which will visualise bottlenecks/constraints and enable us to protect these bottleneck resources

2. Optimise Kanban

At this point, the agency is using Trello as a kanban tool.

Previously, we created one Trello “board” per account. The agency has a few dozens of accounts, ranging from small to big. On average, three consultants work on accounts, sometimes complemented with other consultants. An account manager is responsible for pulling requests into the “to do” and assigning it to the consultants.

However, we don’t work with persistent teams across the accounts, which means that account managers have no visibility on the WIP of their account team (meaning: they might assign a work item to a team member who is already dealing with a lot of WIP from other accounts).

So account managers don’t have visibility on WIP of their teams and management has no visibility on the WIP of the agency as a whole. Clearly this is our biggest issue right now.

Our next step, therefore, is to get visibility on the WIP of the agency as a whole. This will allow us to get an idea of where the bottlenecks are, and what our lead times are. Currently, we are implementing a kanban board per team member, which will allow us to see how many items every team member is working on, what he has marked as “ready” and how many items are in his/her backlog.

3. Limit WIP

The next step is to impose personal WIP limits (we are currently thinking to limit WIP to 3 “in progress” and 6 “ready”). Our kanban will start with the following columns:

• backlog
• ready
• waiting for third party
• doing
• done

4. Define classes of service

Then, we will define “classes” of service, and to define the policies that govern them. We will start with the following classes, derived from “Kanban” by David J. Anderson:

Expedite

• will always take precedence
• limited to 1 or 2 WIP at a time

Due date

• will be pulled in to the system at the [internal due date] — [lead time + 1 day of reserve]
• internal due date will be set 48h before external due date
• will take precedence over standard class items

Standard class

• will follow the “normal” flow

Intangible

• will be worked on by resources with slack when there are no items of a higher class available on the kanban

5. Later steps: create custom swim lanes and workflows

After we have a better view on the type of demands that the system is getting, our next step will be to define “swim lanes” for specific pieces of work. (Still a bit muddy how these swim lanes should work).

If necessary, we can go further by create specific workflows for specific pieces of work (eg press releases will progress differently through the system than recommendations or monthly reportings).

Big question at this time: how to account for customer involvement in the flow?

What we are wrestling with is the amount of customer involvement in the PR process. Much of what we do needs to be cocreated and validated by the customer at different steps, and this will have a huge impact on our WIP.

I would love to hear feedback how other kanban teams deal with this issue. Please feel free to ask me any questions on Twitter: I’m rafweverbergh.

(Edit 22/02/2015: David Anderson told me on Twitter he is no longer using the term ‘failure load’ but now uses ‘failure demand’).