Our step by step journey to becoming a lean PR agency (part 2)
At FINN, we have been looking for ways to consistently deliver quality to our clients, using lean kanban. We promised to keep our colleagues and friends up to date about figuring out lean kanban in a PR agency, so here’s part 2 as promised.
For readers unfamiliar with lean, it might be technical at times, for which I apologise. For PR freelancers, it might not be useful at all — it’s mostly aimed at people who run an agency with more than 5 people.
The goal of the kanban program is to make sure that our entire team delivers a consistent quality to clients, without errors and without wasting time or resources.
It might be a good idea to read these two blogs first to get an idea of why we are writing this, and where we’re trying to go with “lean”:
We have been working on this for about two years now, first working on evangelising the idea that it is possible in an agency to deliver “zero error work”. Then, we started experimenting with workflows and tools to implement a version of “lean” at the agency.
Things moved to a new level of understanding when, beginning of 2015, we settled on lean kanban as described by David J. Anderson as the system that would make most sense in our agency.
Rather than rushing to implement this agency wide in a top down way, we introduced a first, careful version of lean kanban.
Team Trello + personal Trello
Since everyone was already working with Trello at the agency, we introduced a system with “personal kanbans” (for every consultant) and “client kanbans” (per client).
We did this to avoid introducing a big change before the entire team was convinced of the quality improvements that kanban could offer.
Personal kanbans (to do list) and account kanbans (planning tool)
The system works like this: every team member at FINN has a personal Trello board with columns backlog/ready/doing/done.
This Trello board is the personal to do list of every consultant.
Every account has a Trello board which keeps track of the work in progress (WIP) for every client with the same columns backlog/ready/doing/done. This board functions as a planning tool — it allows us to see where certain projects are.
In addition to these columns, we also added a “waiting for 3rd party” column very early on. Anderson doesn’t discuss this issue of having to coordinate with external people, but PR work requires so much input from clients, that this was necessary to add. It is now by far the biggest list on our boards: we routinely have 15 to 20 assignments that are waiting for client approval.
We have used this system for almost a year now, and the feedback from the team is positive. The team feels that the quality of our work is higher than before, and customer satisfaction has improved (which was the point, if you remember).
Of course, errors still happen. In rush hours, some team members still feel tempted to skip one or two steps in the process, which (almost always) creates errors, rework, delays and client frustration.
The good thing is that that we no longer have to debate the merits of lean, like in the early days of using the system.
Most of the time when versions of deliverables are flying here and there, with plenty of notes and remarks, telephones and miscommunications, the team member acknowledges that it was unwise to try to rush work, and that the rework caused bigger delays than the potential time gains that could be expected. (I have never known these shortcuts to actually produce a time gain, by the way, which might explain why people give up trying after a while).
Moving towards lean kanban v1
Since the team seems to accept the system, we decided to move onto a true team wide kanban, which shows, for all the accounts and projects, the status of work and the consultants attached to them.
Because a bigger issue with the way that we approached (pre-)lean at FINN is that it is still not showing all the work that we are currently handling for clients. It is showing the work that every consultant is doing, and it is showing the work that we are doing for every client, with a manual intervention needed to synchronise the two.
Unfortunately, synchronization is time consuming, and we notice a tendency to focus on personal kanban boards.
A related issue is the fact that this approach does not value the role of the account manager enough.
In the current system, it’s possible for every consultant to be booekd 100 % while some clients are underserviced (and some overserviced). We wanted to move to a system where the account manager can fully take on 2 crucial roles:
1. defend the “backlog” line
The key to lean, as Anderson indicates, is that you have to limit the WIP to make sure that work can flow through the system. More WIP increases lead times and reduces quality.
The most important role of the account manager then, is to defend the backlog/ready line.
He or she must avoid allowing work to go into the system that is not “ready” to be performed. Because that is the work that will be blocked or will never be finished — which uses resources but ultimately does not result in any work being delivered to the client.
2. make sure that every client receives value
The other advantage of an organization wide view is that it allows the account manager to better assess whether we are performing work for every client.
Currently, with everybody absorbed by their personal kanban board (most consultants have it opened on their desktop the entire workday), the 30 to 40 client boards are consulted a few times a week, which means that some clients who are less proactive or demanding than others might be relatively underserviced.
Another nuisance is that account managers are forced to duplicate Trello cards on their personal boards and on the account boards — and to synchronise the cards all the time.
By integrating the personal level with the team level, we will automatically add a new level of insight: we will get an idea of the cumulative flow (how many pieces of work are we delivering in total for a given period of time) and the average lead time across the entire team.
Also, by having a shared kanban, we will accelerate junior team members’ understanding of the system and encourage the correct use of work classes (priority/standard/due date/intangible). This will help junior members in their path to become account managers.
Also, a team kanban will allow us to identify bottlenecks and constraints, which we can then tackle.
The question is: how do we do this?
Offline & online kanban + daily standup meeting
Anderson advises to use a physical kanban — on a wall or a whiteboard — and to synchronise this with a digital one (like Kanbanize or Leankit or something).
I have to admit that originally, this seemed like a huge waste to me, but I’m beginning to see the point — updating the “physical” kanban every day offers an opportunity to discuss the amount of WIP in the system (as well as per account and per consultant) and to identify overburdened consultants as well as blocked cards (pieces of work that are stuck in the system).
In a pilot phase, we will choose a number of high volume clients and start a physical kanban for them, which we will synchronise with a digital kanban. We will choose a system which tracks cumulative flow, like Kanbanize or Leankit.
We will also need a system which allows us to load predefined checklists. This is a quibble that we have with Trello. Trello does not offer the possibility to define standard checklists and load them onto a specific card. Trello wants you to create a card with a process and then copy this card. This is cumbersome, because we have a tendency to create a card on our personal board and only later realise that there is a predefined “process card” available for this briefing. This causes missed opportunities to use a predefined and strong process.
Trello rival MeisterTask does offer the possibility to load checklists onto an existing card, which is clearly the better way.
(Full disclosure: MeisterLabs, the company which created MeisterTask and MindMeister, is a client of FINN).
For us, the hardest question is how we will define “swim lanes”. Do we define them based on our internal organization (per account manager or even per consultant)? Or do we define them based on the demands by the client (per account, or per type of work)? Or do we define them based on the class of work: priority and rush work (crises and issues), standard class, due date and intangible?
For now, we will assign swim lanes per client, and limit the WIP per client to 1 or 2. This will allow us to see how much value we are creating for clients, and to see which clients are not getting enough attention (empty swim lane, empty backlog).
We will also move towards a more PR-specific kanban. Until now, we have used the generic backlog/ready/doing/done system, with the extra “waiting for 3rd party” column as discussed.
We noticed that most PR work, however small or big — from strategies to brand PR to public affairs campaigns — follows mostly the same steps. We think that we will use a 5 to 7 column kanban, with most of them divided between “agency” and “client approval”.
///this is the line that the account manager needs to “defend”///
- agency prepares
- client approves
2. Draft 1 of deliverable
(can be anything: strategy, media campaign, investor deck,…)
- agency prepares
- client approves
3. Final draft
(our goal is to go from draft 1 to final draft — in case of a good briefing, this should be possible)
- agency prepares
- client approves
4. Check for deploy
> This is where a lot of checklists kick in on the agency side, to check whether all the materials have gone through:
- approvals in place
- final timing…
> After all these checks have cleared, the project goes to the client to be greenlit.
5. Deploy & follow up
Once green light is received, the agency deploys and, if necessary, follows up with external stakeholders.
According to the project, this can be a huge part of the project.
And finally, we report about our activities to the client.
This system will be a big jump in functionality of our kanban — it will be the first time that our kanban reflects the rhythm of our specific job, which will make it easier for our people to understand and to get an overview of where projects are for clients.
(Many thanks to Dirk Schaele for suggesting that we look at a workflow that mirrors our value stream to make it more intuitive for the team. His suggestion that we would likely end up with “5 to 7 steps” turned out to be impressively accurate.)
The big jump
We feel that this next leap is crucial in becoming truly lean, but we also know that there are a lot of unanswered questions.
Specifically, using 30 or 40 swim lanes might become cumbersome — it’s not clear that it will allow us the visibility that we are after.
As usual, we welcome any suggestions from people in service environments who have implemented lean, and of course we’re happy to answer any questions from people who are interested in agile or lean processes in marketing and PR.