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

Raf Weverbergh
Feb 22, 2015 · 6 min read

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

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)

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

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

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:


  • will always take precedence

Due date

  • will be pulled in to the system at the [internal due date] — [lead time + 1 day of reserve]

Standard class

  • will follow the “normal” flow


  • 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’).

Raf Weverbergh

Written by

I am fascinated by the way information, stories, influence and power flow through networks. Managing partner at http://finnpr.com and http://getmustr.com

Raf Weverbergh

Written by

I am fascinated by the way information, stories, influence and power flow through networks. Managing partner at http://finnpr.com and http://getmustr.com

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store