Ever since the heydays of six sigma it is considered a self-evident truth that rigorous, objective analysis of a problem is only possible if we have data to analyze. Remember the famous dollar bill of Jack Welch – “in God we trust, everybody else must bring data”? This is the spirit I am talking about.
In the grittier world of real-life problem solving and coaching we often see situations where data is just not available. This can happen in situations as wildly different as NGOs far more interested in field-work then possibly difficult data collection or a bank where there is a wealth of data but just not of the type that would be needed. Interestingly enough, I met both situations within a week and this got me to think and write about our methodology to handle these situations.
The standard six sigma reaction to a case like this would be to use the Measure Phase to start a data collection, collect the relevant data and move forward from there. It is also the standard answer of the stakeholders in many cases, to simply reject the idea of a DMAIC project on the basis that the data collection would be too expensive, time – consuming and with no guarantee that the project will be worth the effort. This is generally framed in terms like “Six Sigma works in a mass manufacturing environment, but not here”.
Of course, we also have a Lean answer for such cases: analyze the value stream, identify wastes and hope that if enough waste were eliminated from the process the performance would improve. This approach will work very well, if we want to address lead times (the main focus of lean process improvements). However, organizations have many different problems and needs – and a classical value stream mapping and analysis will not address most of those. Just think about some of these examples and how you would solve them using a six sigma or a lean approach: – high turnover at a local office, low hit rate of a marketing campaign, low availability of field workers , low volume of products sold to a key customer etc. Of course, in each of these and of similar cases we could force a solution method based on six sigma or lean, it is just that they do not seem to be a natural fit and will probably take more effort and more time then it would be necessary.
A methodology that would work well in such situations was developed by us at ifss. It is a mixture of the Toyota Kata methodology and tools from the Logical Thinking Process popularized (if this is the right word) by William Dettmer. This would go like this:
- Define a target condition
This means, we define the way we want our process to work in the future. This will definitely NOT be a numerical goal, though it might contain sub-goals that have numerical values. We describe our goal state as well as possible. This very often includes references to Mura and Muri in leanspeak, like: our goal is to have smoothly flowing operations free of stress for the people involved. This definition is often a step that is far from easy : we absolutely have to match our process improvement goal to the more general goals of the organization we work in. If we can not do this, there is a high chance that our support will falter along the way – after all our management is focused on achieving THEIR goal, not our. On the other hand, if we can map our goal to the organizations goals the case is clear – by improving here we contribute to the general objective of the organization.
While Toyota Kata does not offer any tool to embed our target condition into the organizations targets we use the Goal Tree (aka IOM – Intermediate Objectives Map from the Logical Thinking Process ) to achieve this.
- Set up a PDCA framework
The trick here is to recognize from the start the we do not know how to achieve the target condition. If we did, we would not have a project now, would we? So, as a framework, we can define the target condition, describe the present situation as well as we can and START a list of factors that keep us from achieving the target condition. The relevant Kata question would be : “so, why can’t we start next week with the process as described in the target condition?”. I mean, we start this list only, because as the project progresses, we will definitely enlarge the list and/or eliminate some elements of it. Remember, we do not KNOW what is really going on.
- Pick one factor from the list and work on it
There are many possibilities for such factors – it could be something as simple as our ignorance of how the process really works, or what the true values of important KPIs really are. If this is the case and only if this is the case, we could go back to something like a DMAIC or traditional Lean project – measure (or estimate ) KPIs or do a process map of the process steps where we need more infos. The crucial difference would be that we know where and how much to do of these time consuming steps. Keeping the target condition in mind, we can pick where to apply our effort much more efficiently than if we just applied the methods at the start in a sort of fact-finding mission.
It can also happen that the element we pick is something else entirely and the underlying problem cannot be solved by data collection or process mapping (actually this will be the more frequent occurrence). In such a case we shall need to devise an improvement step to implement in our PDCA cycle. Here, again, we have two cases: either the improvement is obvious in which case we shall jut trial it or it is something more complex. If it is then our recommendation is to use the Apollo Chart (aka Current Reality Tree of the Logical Thinking). This enables us to drill deeper and to find actionable root causes . Once those found we can develop the Future Reality Tree of the Logical Thinking Process to derive an action. The Current Reality Tree is a methodology that, implemented correctly, makes maximum usage of all available information and it also enforces active steps to gather more information in case we only have some hypothesis concerning our causes. In this the method is far superior to other Root Cause Analysis methods, like the venerable Ishikawa or the 5 – Why. So, by enforcing the route – Problem -> Current Reality Tree -> Future Reality Tree -> Analysis of Risks and Side Effects -> Define Action we make sure that in our process of working through the list of hindering factors we stay objective and fact – base (though not necessarily data -based).
- Update the PDCA and repeat the cycle by picking a new element from the list
At each turn of the cycle we make sure that we know more about the problem than we knew before – even if this is just the acknowledgement that something does not work. It will also naturally engender continuous activity and progress, so chances are that the project will be faster.
I am very much convinced of the utility of this scheme and used it from implementing SMED to solving complex issues in sales. It allows us to apply rigor in situations where others would either impose a costly process mapping or data collection plan or give up altogether. It provides for continuous progress towards a solution and makes coaching almost standardized and easy for both parties. What do you think?