Some readers were asking for an update on our lean transformation. I’m happy to present part three.
Overall: moving in the right direction
Overall, we’re happy with the progress we’ve made. Some parts of lean have become truly accepted.
The team have adopted the idea of having strong processes, and it has become ingrained in the FINN culture that rework and errors are wasteful. In the most frequent processes (what lean calls “high frequency value demands”), we are able to deliver consistently.
But some challenges remain
Some things did remain difficult though, mostly in more infrequent processes, or big projects with lots of subprocesses.
Here’s what typically happens in such a case:
- A consultant has to deliver something for a client but isn’t sure how to proceed. Human nature is to chew on the problem a while. But then some anxiety sets in — this is taking too long. To get rid of that feeling of anxiety, people will often switch to a task for another customer where it’s clearer what they should do. Meanwhile, customer 1 is waiting for an outcome — which is delayed and snowed under by now. In the end, the customer fires off a frustrated e-mail or phone call: where are you on my project?
Gruadually, we started asking ourselves whether we had misunderstood a lean concept. When reading about lean, some emphasis is put on the fact that you can’t “fixate” processes.
We understood this to mean that you’re not supposed to write them down.
In time, though, we wondered: it might mean that you have to make sure that processes don’t become too rigid. As Jeff Bezos recently put it: the entire team should know that “the process is not the thing”.
Here’s what Bezos writes about this:
Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right. Gulp. It’s not that rare to hear a junior leader defend a bad outcome with something like, “Well, we followed the process.” A more experienced leader will use it as an opportunity to investigate and improve the process. The process is not the thing. It’s always worth asking, do we own the process or does the process own us? In a Day 2 company, you might find it’s the second.
So it should be clear to the entire team that a process is a hypothesis about how to do things with optimal efficiency. But we should always want to change the process if we think it can be improved upon.
But we became more and more convinced that to talk precisely about a process, it became clear to us that you need to document it. It’s not good enough to talk in general terms about a process. You have to be able to point to a step in the process and know which step it is — is it the first or the third step? Why?
We also realized that changing a process is entirely different from improvising or ignoring a process. Changing a process should be a deliberate choice: “we think we can do this faster and cheaper if we skip step 2 and put step 4 before step 3”.
The improvements that are made to processes in this way should be communicated precisely to the team, and should be stored in a place where everyone can access them.
In fact, over time we began to see that a documented process is easier to change than an implicit process, and that it would offer some benefits.
It would allow us to train new colleagues faster
- A documented process, especially if you can visualize it, is easier to understand than verbal instructions.
It would be easier to get more consistency across the entire team
- A documented process decreases cognitive load on the team. You don’t have to remember every step of a process — you can just check the visual process flow to make sure you’re not missing any steps
- PR processes typically involve lots of small tasks — gathering lots of materials (facts & figures, research, documentation, photo & video assets). It’s easy to lose track of the optimal time to gather some of these things. A good process alerts team members to think about things proactively, instead of rushing to get everything together at the end of the project (“oh, we forgot about this: can you please send some pictures asap?”)
It would be easier to innovate — this is true for incremental innovation and for more fundamental innovation
- New ideas and services are hard to sell in organizations. There is an instinctive resistance to trying new methods and new services if you’ve never done them. A visual process can help to show where a new service or idea can add value for the customer. For instance, a visualized process can show us where and how we can improve reputational and marketing outcomes for our customers by using digital advertising on Facebook, LinkedIn or Twitter.
- If we have a shared understanding of what we’re doing and how we’re doing it, it becomes easier to discuss where things typically go wrong or get stuck. It becomes easier to improve processes by adding or eliminating steps in the process.
BPMN and workflow engines
As we looked for ways to document and share processes, naturally we ended up in the world of BPMN and workflow engines.
1. Modeling the processes
BPMN is a universal language to model processes, and we’re now using it to document our most frequent processes. We’re also training the team in understanding BPMN.
We already had a Trello board with “processes”. These processes were mostly a number of checklists.
The processes will now be illustrated with a visual model of the process, like this:
This will help consultants to do a quick sanity check before starting a project.
The checklists on the Trello cards allow them to make sure they don’t forget anything. There’s also a link to the file (on the server) where they can access the file with the process and change it if it needs to be changed.
2. Starting an “operations” team
Most literature on BPMN recommends the creation of a Center of Excellence (CoE) for business processes. It’s also an idea that you see in case studies on lean in service.
In a HBR case study of 2011, for instance, an IT company created a “productivity office”: (*)
It’s important that someone in the organization have an overall view of the initiative; otherwise valuable learning could easily be lost. Wipro’s productivity office filled this role, reviewing every lean project, leading education efforts, and helping standardize practices.
At FINN, we created an “operations team” that is responsible for helping the team document and improve processes.
The goals of the team are:
- to gather information on existing processes
- to help create new processes for new or improved products and services
- to make sure sub processes are as repeatable as possible — this is easier for team members and will create higher quality for the customer
- to be a Center of Excellence (CoE) where colleagues can ask for help to document & improve processes
- to train colleagues
- to spread best practices from one practice area to another
The KPI for this operations team is quite simply customer satisfaction (we will use NPS for this).
This brings us to tools. We used to work with draw.io to draw processes, but this is not a very scalable solution. In draw.io, you have to manually draw every element of a process. This is cumbersome and takes forever.
We wanted to find a solution that would allow us to just point and click to say “new step in the process” — a bit like how MindMeister works.
Research about business process modeling showed that there are two aspects to documenting processes:
- modeling processes — creating process flows (visual “maps” of the process)
- running the processes. There is software that build workflows on top of visual representations of the process: this is called a “workflow engine”.
A workflow engine is a system that automates parts of a process.
- For instance, if an employee has to send something to a manager for approval, a workflow engine will allow the employee to upload a doc and send it to the manager through the system. It will tell the manager that it requires approval, and when the manager checks the “approved” box, the workflow engine pushes it back to the employee or to another department.
Most BPM and workflow engine software is aimed at the enterprise market. It’s complicated and expensive.
For the SME market, there’s not a lot out there. We also wanted to use a tool that worked with BPMN, the internationally accepted standard for documenting and visualizing processes. This requirement ruled out a huge bunch of tools like Pipefy and Sweetprocess, which are more casual workflow engines and which don’t use BPMN.
In the end, we narrowed it down to two tools:
They both offer free process modeling.
In Bizagi, if you want to collaborate on processes and build a workflow engine on top of them, you need to take a license (something like 800 EUR per person, to be paid upfront).
However, you don’t need to pay for the cloud collaboration feature in Bizagi. You can download the software for free, create processes and save them on your server, like a Word file. Your colleagues can open and alter the files (also like Word).
In the end, we chose Bizagi, because it’s more intuitivie to use. It’s quite easy to use once you know the basics of BPMN, and allows you to draw up a small process in a matter of minutes.
Challenges & next steps
We haven’t solved all our challenges yet.
A major challenge is the way we organize our teams. We don’t have fixed teams. Rather, we assign consultants to clients based on the needs of the client and how well the consultant’s skills fit with these needs. This means that every team member is collaborating with different colleagues on different clients, like this:
This makes it very hard to find a way to keep track of all the tasks and projects that are underway.
We tried to address this using scrum solutions, notably a fifteen minute “standup” meeting every morning. However, these meetings were not very useful to the team. 90 percent of the information that was shared at any time was not relevant to the team members standing there, and it felt like a waste of time.
We also tried to use LeanKit to have an overview of all the tasks flowing through the team at any time. Unfortunately, this quickly amounted to a huge kanban with a 15 person team. (We’re talking close to a thousand cards on the Kanban at any time — way too many to keep track.)
Rather than giving us an overview, it overwhelmed the team.
We reverted back to using Trello. Every consultant now has a personal Trello board. And every client has a Trello board. We have not been able to solve the issue of how to match the client Trello boards with the individual boards without doing duplicate work.
As always, we look forward to your comments!
(*Special thanks to Lauren Heeffer for pointing me to the HBR case study)