After visualizing the value chain, it is time for the service team of BIT to introduce Work in Progress Limits in the Kanbanize dashboard.
KANBANIZE AREAS and SWIMLANES.
The steps identified in the value chain analysis constitute the columns of Fig 1.
Kanbanize, to facilitate the future analysis, asks to associate each column with one of these 3 areas:
The two horizontal lines constitute the swimlanes “Public” and “Private”.
Swimlanes are extremely useful to segment workflows when the types of work have a very different length but the steps are the same.
In this workflow, the difference in the length is due to the different project management approaches. For the public broker activity all the functions of the projects are outsourced to a partner (except the administrative part); for the private broker activity, the project coordination (and often the design of the service) is managed internally.
Usually, different swimlanes are associated with different WIP limits.
Once the design phase is complete, it is time to limit the work in progress (the second practice of the six Kanban practices).
The quality coordinator of BIT already prepared the management of BIT for this important (and not intuitive) practice and, following the ADKAR approach, he spent a lot of time with all the service team members to prepare them for this change.
It is now time to finalize all this preparatory work in setting up WIP limits for this specific flow.
How to start? The Kanban approach is quite clear: start from the current reality of the team. A very good data source it is represented by the tracking list of the service team.
The work in progress of Fig 1 for the Progress and Done columns (for the two swimlanes) are just the average (for one year) of the monthly numbers of items registered in the tracking list.
Data are important but they must then be challenged by an honest discussion among the team members and their manager.
Once the WIP limits for the requested area columns are set up, it is the moment to speak with the upstream colleagues of the sales. That’s the moment to explain clearly what a “Pull behavior” means in a Kanban Approach for the stakeholders that are not directly involved in the workflow.
The message sounds more or less like this:
“Dear colleagues, the service team has adopted a Kanban approach to manage our workflows. As to this approach, we believe (and commit toward you) to process (no more) than 25 sales opportunities that you present to us (for Public). We really believe that this is the maximus amount of work items we can process without jeopardizing customer satisfaction. Of course, we will review with you periodically (let’s say every quarter, as a start) this commitment.
Considering this current throughput, let’s determine together what should be the max. number of opportunities that, from one hand, they assure that the service team is not waiting for job and on the other hand doesn’t create frustration (and waste) to you as we will not have anyway the possibility to execute. The two teams agree on 40 (for Public).
Coherently, a similar talk must happen with the downstream colleague.
The limitations of work in progress must be set up for each workflow and, at the same time, must consider all the workflows of the service team. The Kanbanize dashboard allows to represent all the workflows (and their limits) of the service team of BIT and this hugely facilitate the implementation of this important tasks
Once the Work in progress limits are set up for each workflow, it is advisable to map these limits to each member of the service team.
It is advisable to perform this last operation in coordination with HR, in order to maximize the prevention effect of the Company practices to prevent burn out.
To Know more:
Using Cumulative Flow Diagrams to Analyze Process Stability in Kanban.