Process Excellence Coaching & Consulting

I have recently read The Book of Why (Pearl, Judea, 2018) and found it really insightful in terms of connection to improvement methodologies (like Lean or Six Sigma).

Basic message from the author is: any type of passive data analysis (passive meaning without actively changing some conditions, for example during experiments) is questionable without building causal model first (on the basis of science or subject matter expert’s knowledge about the topic under study). He is even positioning this approach (with some deeper math behind) as better than experimentation in some selected specific cases.

From the reading point of view, it was interesting to read ‘good-old’ stories about R.A. Fisher and the impact smoking has on lung cancer – from another point of view. Author is teasing ‘classic statisticians’ a lot 😊

What does this approach mean in practice, in reality of running improvement projects?

#1 Good understanding the process to be improved should be done before analysis of the process data.

To some extend such sequence is part of “classic” DMAIC approach (where typically within Analyse phase the process should be mapped before input-output data would be analysed); however, in practice, data are usually perceived as the most valuable information about the process. As a result, many practitioners are jumping to data analysis far too early within the improvement project, before even knowing what questions should be answered by data. This leads to making wrong conclusions (correlation vs causation!) and missing real improvement opportunities.

My recommendation: Make sure that proper understanding of the process is well and early embedded in the improvement projects you are involved in.

#2 Root Causing is not enough!

Both Lean and DMAIC are rightfully recommending looking for causes behind problems, because if we treat just symptoms – problems will come back very soon. However the most common tools in this area (Five Why, Ishikawa, FMEA) are not strong enough to identify real cause and effect mechanisms in the process. Five Why is too narrow (just one “path” to follow), Ishikawa and FMEA are more about listing different factors under one umbrella, without clear and complete cause-effect path

There are some tools that are going in the right direction here (let me point out House of Quality from Quality Function Deployment methodology or Fault Tree Analysis); however, they are not very common and sometimes are too difficult to implement in the specific case.

On the other hand I believe we don’t need fancy tools to sketch causal diagrams as those below.

My recommendation: Use pen and paper to identify cause and effect relations in any process you are improving, as early in the improvement journey as possible.