Enterprise Kanban: Where to Start?
For a corporation setting out on a large scale Kanban implementation, there is the inevitable question of, where to start? Typically, clients want to run a pilot on a single service delivery workflow but which one to choose? Firstly, we must find a service delivery workflow that is appropriate for a kanban system. [See the first post in this series on appropriateness of kanban systems]. To do this, we might view the organization through The Kanban Lens in order to identify suitable services. Secondly, we must assess whether this service is a good choice for a place to start Kanban.
Goals for a pilot kanban system
Assuming we hope to implement the Enterprise Services Planning widely across our entrprise and across many creative or knowledge worker services in our business, then we want our initial kanban system pilot to be successful, to be permission giving for others, to inspire and motivate further change and to catalyze a viral spread of Kanban throughout our business. In order to achieve these goals we must be careful where we choose to start.
This flip chart shows our guidance on where to start with Kanban initiative. Let’s look at each of these in turn…
Must be highly visible
If we wish a pilot project to be inspirational, to cause a viral spread, to be permission giving for others, then they have to be able to see it. Typically, we advise that initial pilots should be in services provided in the headquarters or main corporate campus. We do not advise that the pilot is run at a satellite office as this is unlikely to meet our goals of being permission giving for others. There are some exceptions to this. If we pick a service within a product range that is core to the identity of a business, for example a platform development unit such as core layer in telecom infrastructure where the firm makes telephone switching equipment and being in that business is core to its identity, then regardless of the geographic location then the outcome is likely to be permission giving to other product units within the enterprise.
Connectedness
An aspect of visibility and ability to be permission giving or catalyze viral spread is whether the service is connected to others or not. Ideally, we don’t want to start with an isolated pilot. We want to choose a service that actually has dependencies on others or services others which are dependent on it, or both. The reason for this is that we want other services to feel the effects of implementing this first kanban system. We want the pilot system to perturb the wider system of systems, our ecosystem of interdependent services within our enterprise.
Must not be mission critical
Executive tolerance is greater when changes are being made to services that are not considered mission critical, therefore we will get more time and latitude to make change if we pick an area that isn’t mission critical. The J-curve effect can be larger when we pick a non-mission critical service as a starting point. Our goal will be to be successful and as a result gain more executive tolerance before we try to apply similar changes to a mission critical part of the business.
The Intersection
At first, the sets “highly visible” and “not mission critical” sound like they are mutually exclusive. However, it appears that maintenance work on mission critical systems is often viewed as not mission critical. However, because it is a mission critical system, any upgrades and enhancements deployed have a high level of visibility. Hence, the maintenance group for a mission critical system is actually a highly visible part of the business. It is perhaps no accident that all the early Kanban implementations were on IT systems maintenance in large firms such as Microsoft and Robert Bosch.
Management motivation
Early Kanban implementations fell into the first category – in so much pain, no one cared what was tried. Simply put when current service delivery is so poor there is a desire for change, any kind of change so long as someone is willing to show leadership and make it happen. However, we may choose to start in a part of our business where the local management is enthusiastic about Kanban, the Modern Management Framework or things which inspired them such as Lean, Theory of Constraints, or Agile methods. There is one other circumstance where we may choose to start: an area of the business where senior management wishes to actively shift cost, risk or investment. This third category requires a truly deep implementation of the Kanban Method and hence the J-curve will be larger. We would only pursuse this if other circumstances were suitable such as strong executive tolerance and a high level of organizational maturity. We need these things in order to buy enough time and understanding to allow our deeper changes to take hold.
Scaling Out
As our pilot kanban system shows success we want to start scaling out Kanban across the enterprise. Typically, we would look to “kanbanize” dependent services and those connected to our initial pilot until we’ve completed the roll-out across an entire business unit. We’d then repeat the process in other business units until the entire enterprise is running on Kanban.
Soft Targets
Obvious places to start with Kanban are existing shared services within an organization. These can be simple places to get started. Some shared services, such as enterprise architecture, database administration, code security and so forth, can be so simple that the resultant kanban systems are degenerate forms such as personal kanban or team kanban. They typically have no real workflow and result is visualizations that show To Do | Doing | Done three column boards. While these are not bad they are typically not permission giving examples for wider service delivery workflows with multiple activities and handoffs between different groups of specialist workers.
