Every Jack has his Jill (2/2)

While moving on with the implementation program, where we had factories who have been on the implementation journey for a long time already and factories which were just starting and still remaining ones in the pipeline, we recognized an increasing amount of confusion and drifting away when it comes to the classification of topics. We have already been working with the PDCA methodology for “smaller issues” and on slightly bigger topics which we call “improvement projects” but there was no further definition. It’s always interesting to see how perceptive and self-driven people are when you patiently wait for the right time and the urgency to propose something (anything in life has a maturity time, nothing happens too early or too late). With little steering we had our first agreed guideline with the respective, and as I would say very legitimate criteria for it. As parameters we took the differentiation if something is just a simple task, a low complexity problem, a middle complexity problem or something bigger. Also some other parameters, which should reflect also our newly established company mindset, were taken into account and also reflected in the work. A simple task which was subject for a routine certainly does not require any other handling and can be directly executed (“fix this screw”, “order this spare part”, “call the customer and inform/ask…”). Low complexity problems already needed a little bit more attention and should be handled with a simple PDCA form by one single person. For selecting those we asked questions like, “Can the person solve the problem / realize the idea by her/himself?”, “Is the person allowed to take decision within the given framework?” which should reflect an empowerment principle of taking certain decisions at the source, one of our company principles. For middle complexity problems we had the criteria to assess if a topic is cross functional, which makes a minimum coordination of the improvement process necessary. Also the decision taking power was elevated one level up and we needed one single employee to “lead” the project. Another company principle which is one of the TPS values as well: work together in cross functional teams and avoid silos.

Also some time frame as an orientation and some general principles had to be set up. Regarding the time frame the simple tasks were agreed to last a maximum of 2 weeks, a low complexity problem within ca. a month and a middle complexity problem 1 to max. 3 months. Yes, in our case a “project” shouldn’t last for longer than 3 months.

In addition following general principles were established: before starting the work and after having established the needed transparency the prioritization process has to be performed to ensure choosing the right topic to work on. Identify the actual problem and ensure the actual need of solving this problem now is given. Another principle is: come to an end:  70% improvement in a shorter time is better than 100% next year. Actually we focus more on “closing” topics than opening them. The huge transparency we created triggered working on topics anyway automatically, our job was rather to stop people taking too many topics at the same time to work on. A full board of issues makes everybody nervous and makes managers also ask about the progress. Then it is time for the “blender-process”: refine, refine, refine, which means anything bigger than a PDCA must underlie enough efforts to be refined until the last particle before being handled. Utilize the self-control and self-dynamics of a group for choosing the right topic, refining the topics and selecting them. This process gets better and better and is in itself a PDCA with multiple cycles.

Do you recognize that preparing the work is also work, which is many times totally underestimated and therefor enhances firefighting? Do you recognize how we reflect “agility” into our improvement activities? With limiting the size of the topics, respectively the duration of the improvement process, we always have possibility to work on the right topics which are currently relevant. We avoid binding resources for a long time into certain improvement initiatives when the actual need has changed already long time ago. Also it makes resource planning far more easier for the management. On the other hand none of the resources are bound full time into an improvement activity.

I hear you asking: Not everything is “divisible”, what are you doing with the other topics? Well with the KATA approach we try to train ourselves and learn how to stubbornly split topics into smaller pieces and if this is not possible, we have our middle complexity category to handle a topic. We know that there are many other topics which require a more sophisticated approach but we don’t focus on them right now with the Lean methodology. Lean methods help us to specify topics which we thought they are big so that even they are refined to smaller pieces.

Our goal is not to improve processes or reduce waste (which is a big mistake many companies make when implementing Lean), our goal is to establish a continuous improvement mindset, enable people to do so and create respective habits in a strong way to reach excellence.

In the end, when companies (will) look back, it is always the small but continuous steps which made the difference and not the big improvement initiatives (which certainly have a legitimate reason for existence).