Pointing to cause

I see it all the time. People generally have no clue how to do a real root cause analysis. This results in many different issues. For example, your root cause is that if you had the solution you had in mind in place, the problem would never have occurred. Therefore the only possible solution is to implement that solution. Sounds ridiculous doesn’t it, but how often do you see this? I see it all the time.

Luckily for all you lovely people there are ways to avoid this. Firstly when doing a root cause analysis do not just ask “why?”. What? I hear you cry! That is what the whole tool is about. But is it? 5 whys is about identifying and mapping cause and effect relationships for a given situation. Therefore the question I like to ask is, “what could cause….?” This helps because it retains us in the cause mindset and helps avoid the solution mindset. Solutions will have their time once we understand the problem’s causes to the real root level.

Secondly try asking therefore going back up the chain from the root cause to the problem statement. Remember you are telling a story of consequences leading up to the problem. If something doesn’t make sense when you do this, review it and alter things. Most likely you will have taken a big jump and need to add some more steps in. This is very common.

My final tip for today is do not ignore the physics of the situation. I will give you a real example. A problem I was helping a colleague with. He had a metal pin, in a hole in a plastic part. The pin was getting small and the hole was getting larger. What is the cause? Well, it wasn’t what my colleague thought it was for sure. He theorized that the plastic was swelling causing excessive friction between the plastic and the pin. Not too much application there really. He ignored that there must be physical movement between the two parts to cause the wear.

I did have another tip for you which I had written but it seems the WordPress app on my ipad thought it was a bad tip and lost it. If I remember what it is I will write it in.



SIPOC is not a friend of the Dalek

Makes sense doesn’t it, why would it be a friend to the evil alien creatures? I love SIPOC, I think it is the best starting point when trying to define a process that is not functioning correctly. I see a lot of people who are afraid of it though, as if it is…. you got it 😉 I thought I would therefore write you some tips on how to do a SIPOC well and to help you feel at ease with using the tool.

  1. There are no good SIPOC templates out there. I have never seen one. Don’t even waste time looking. My advice, is to draw it on a whiteboard. Supplier, Input, Input Requirement, Process, Output, Output Requirement, Customer. Remember to add a name and purpose for your SIPOC at the very top
  2. Ensure to start with the beginning and the end of the process. It is important to establish these limits before filling in anything else. If you miss this you could have a lot of re-work to do later
  3. Don’t mistake a SIPOC for a detailed process mapping. The steps in between the beginning and end should be big steps which will require (if necessary) more detailed mapping later. This is a good thing! Do not mix your SIPOC with your process map.
  4. Do map the suppliers, inputs and outputs for each of the big process steps you have identified. It will help you later!
  5. Do not forget your customers and to split them between your primary and secondary customers. Your primary customer is the receiver of the value of the process. Your secondary customers are other stakeholders in the performance of the process
  6. Include where known the input and output requirements. What are these? They are “features” that are looked for in the input or output. For example and output of a purchasing process step could be an order confirmation the requirement on that could be “sent to customer within 24 hours of receiving the order”
  7. Do not fall into the trap of mapping should be or desired state, to start with focus only on AS IS. You can convert this later to reflect future state but unless you map as is you cannot identify the big gaps that exist and there will most likely be some!
  8. Later ensure that your outputs and output requirements are aligned with your CTQ’s (critical to quality attributes) that are aligned to your VOC (voice of the customer). So what your process kicks out is aligned with the value the customer wants not what you as a business want to deliver. Note this is only done later when try to define the new way of working

You get 8 tips as that is all I can think of right now, any more ideas?

Oh one more, try to avoid skipping the layout of each supplier and inputs for each process step. If we do it is just work later and it ruins the advantage of visualising the gaps in the current way of working from a high level.



10 Roots to the Truth

I still have not been convinced that root causes don’t exist. When I get my phone call returned maybe I will.

I teach problem solving a lot. Unfortunately I do not teach A3. I teach a custom system for the organization I work in. It is a great system that has been specifically catered to fit the organisation’s business model and the most common types of problems it faces. Through teaching this system I have gained a lot of insights into how people view structured problem solving with root cause analysis for the first time and what some of the key challenges they face are. I thought I would share some of these with you.

Most People are scared that not following things strictly will mean they mess up and that messing up is a bad thing. When people come into my training course I can see the anxiety on their face. They probably did the pre-reading I sent them but it most likely did more to confuse them than help them. They take our system and they treat it as a process that must be followed to the letter, with every step executed 100% or they will fail. My message to them now, you will probably fail. That’s ok. You are trying to improve and that takes time and understanding. The system is not a process. You can go back, revise, update and change anything you want any time as long as it is based on facts. (Note to self, make the pre-reading easier to digest)

A lot of people do not understand that they are fire fighting. So when they get into your training course, they are expecting you to show them how to fight fires better. Or, worse, expecting you to come with some “unreal guff” that is not practical to implement as it takes more time. Telling them they are fire fighting will not help. They know that but they can’t help it, and most likely it’s what their boss/peers expect them to do. To approach this situation I like to start big. Take a big problem they have encourage them to apply it to that. They will usually see the most value in doing that and can justify it.

More data will help me understand the problem better. No. Just no. This has to be one of the most common issues I encounter in problem solving. In all my years experience I do not think I have seen a case where there was insufficient data available. Usually the opposite. So much data that you cannot see the problem for the amazon rain forest worth of sheets of paper on the conference room table. A lack of understanding the problem, yes. Definitely, almost every time. This is not solved by more data. It is solved by GEMBA. What do I mean by Gemba? Well I am not going to define the word for you, if you don’t know, google it. What I will tell you is it is not about going and looking. That is just the start, go and observe. Observe until you understand what the problem really is. Ensure to capture your observations in a way that is easy to share with colleagues. This is the most valuable data you will collect and it is the only way to really understand a problem deeply.

Treating Understanding the Problem and Root Cause Analysis as separate. In our system they are separate. But really root cause analysis is just a deeper level of understanding the problem. Really when we “define” the problem we are just scoping. This is why in A3 there is only current and future state. No section for cause. That is part of the current state. This being said, we should not confuse gathering facts with looking for evidence of cause. If we do the later before the former when we find evidence of a possible cause, it is likely to shut our minds off to all the other possibilities. Not a good thing. So focus firstly on describing the problem and then on finding the causes but don’t treat them differently. The Gemba method applies for both.

Our job is finished when we contain a problem. This is the fire fighting culture again and again. Put the fire out, then move to the next one. Then comeback 6 months later and put the same fire out again. Personally I would rather push through to greater understanding and therefore better quality actions but if you must contain first to get breathing space, make sure you communicate that that is what you are doing. If you don’t others may assume that you have solved the problem and that sets the expectation that the problem will not recur.

Root Cause Analysis is not a workshop exercise. Similar to my first point in a way. Personally I hate the idea of a root cause analysis workshop. I am doing one next week against my advice. We’ve already done it and without much new information they are expecting a different outcome…. I’m skeptical as you can tell. The idea of a root cause analysis is to trace carefully back through the events that led to the observed problem so we can find the origin(s). The origins being the root causes. Again, this is best done at the Gemba. It is worst done in the conference room. In the conference room you have limited access to facts (note I didn’t say data). You also usually do not have the people who were closest to the problem, you more likely have their manager or a colleague who doesn’t travel so much. You can get valuable ideas being generated in these sessions and good discussions. The only issue being that you probably cannot verify them immediately. You need to go do testing or gather information to confirm which ones are real and which ones were just ideas.

Transitioning to a Fishbone Diagram to a 5 Why’s is difficult for people who are new to problem solving. I might have been more into rant mode on the last couple of points. This one, however, is very concrete. I noticed this very early when I started teaching problem solving. We start by using a Fishbone diagram with 4M to generate possible ideas. We then evaluate (I won’t go into how) the probable cause and then use a 5 why’s to drill down to root causes. This is a great method that personally I have had a lot of success with over the years. However, I found an issue with beginners transitioning between the two. As we used to teach Fishbone, it is very much a put what you think on the diagram and then evaluate. Once evaluation is done start 5 whys. Simple right? Well no. When the problem solvers get into 5 whys they invariably get lost and confused. I think I know one of the causes for this. They do not know where they are on the cause and effect path when they start as they do not fully understand the structure of cause and effect. This results in them often going the wrong way or looping. It also usually results in them repeating stuff that was on their Fishbone as the relationships are not understood. To avoid this, I get my students to start mapping the cause and effect relationships already in the Fishbone diagram, after ideas creations and before evaluation. Tis has an additional effect of reducing the quantity of ideas that need evaluating.

People like to try and get away with being lazy. It’s not because they are bad people. People are just lazy. I see this in my classes in the following form. Using general expressions to describe a problem or a cause. Come on people, honestly, is that going to help? An example, someone gave me a possible cause “material bad quality”. Well…. I can’t say no to that but come on, how wide a statement do you want to use? What material? And what part of its specification is it not meeting that tells me it’s bad? So define material and define bad quality. If we do not start talking in this way about problems we are not going to solve any. Incidentally I had another experienced problem solver in a class who disagreed with me on this point. His argument was that you can check later what it means. Yes absolutely you can, but why not think harder about the problem in the first instance before spending time checking? We would save a lot of time. Also, do not forget that these general statements are also often used to throw the problem over the fence. If I say “supplier bad quality” and happen to exclude all possible causes related to my organisation it must be a supply chain problem, surely? Being precise removes ambiguity and saves time in problem solving. Period.

People Expect Root Cause Analysis to be some sort of solve everything instantly magic thingermejigger. As you and I know, it isn’t. Root cause analysis doesn’t even give you a solution! How rubbish is that? haha. It takes time and concentration and most important, diligence (more of a corporate dirty word than buzz word unfortunately) to really identify root causes. If you do take the time to do it well then you will be rewarded with the best quality information you could hope for when deciding what corrective actions you are going to take to prevent the problem from recurring. If you do it poorly or skip bits you will end up most likely doing too large a redesign or implementing a half assed checklist or similar.

They are surprised to discover there is a quality scale for corrective actions. AND it is not rocket science. It just requires, yes that phrase again, brain power. How likely is this solution to prevent the problem from recurring. What does its success depend on? People? (UhOh) machine? etc. I also immediately get the retort that it will always be more expensive to take the “best” solution. My response, on what timeline? If your timeline is long enough it will probably be the cheapest and I have yet to meet an organisation that admits it takes a short-term view to life (although we all know most do, all of the time)

So there are 10 reflections/thoughts/(insights?) on problem solving. Hope you find them useful. As always I am keen to hear what others think. Please comment or email me: leanconfidential@gmail.com



God Bless you Mark Graban

I’m young and occasionally I get a little carried away with my own ego and “I can change the world” attitude. So it is nice for me to be taken down a peg or two. Mark Graban did that to me today, and I thanked him for it. He reminded me of something I already knew, had read again earlier that day in one of Womack’s books and really should act out more. What did he remind me of? This:

@Leantruth No place for “name and shame” in #lean

There is no need to go into the background. I suggested he name and shame and the above was his response. Respect to you sir, you taught me a valuable lesson today.

If we want to improve and become more lean as managers, leaders, associates or whatever we call ourselves, we must respect people. That includes being positive about feedback In negative situations and not creating negative thought structures in the way we work. We must encourage, support, mentor and coach. Not berate, discipline or harass people.

Thank you Mark!

Free Root Cause Analysis coaching

There is a guy on twitter who is well known in the lean thinkers community who says that he root causes do not exist. There is only something called root conditions. I didn’t understand this fully so I contacted him. We didn’t get to the bottom of the discussion and I am still waiting for him to return my call, but I am sceptical of this notion.


Root causes are important. I would hope if you are reading this then I do not really need to tell you why they are important. If you don’t know feel free to email me and we can discuss it or if you are feeling generous you can pay my very reasonable consulting fee to help you out! 😀

So if root causes are important why do more people not work with finding them properly? Well honestly, root cause analysis takes a lot of time and effort to get the hang of it. If I reflect on my career to date, I think it has only been in the last few years that I have really understood how to do it well. I’m not going to slap a load of my training slides on here and go into real detail (yet) on this, however.

At this point in part 1 I implore you to have a go. It was only by trying, failing, reviewing and changing (PDCA??) did I get to the level where I am confident in my abilities. Along with this I was not afforded the opportunity to get feedback from anyone as there was not anyone to mentor me in that way. However, you are all extremely lucky people. Due to my world famous generosity I am offering, for free, to give you feedback and coaching on root cause analysis. Not sure about it? Want some help here and there? Send me an email or post a comment on the blog and I will do my best to give you advice and support. I do this because I’m a nice person (despite what everyone says…)) So don’t be shy, ask for help!



Why Yoda Was Wrong

A really good article about why it is important to try, do not have the expectations that failure to improve is not an option. This will create a fear and resistance to trying. Start early, start trying.

Lean Renaissance

“No. Try not.  Do….or do not.  There is no try.”

Master Yoda, from George Lucas’ Star Wars, Episode V: The Empire Strikes Back


One of the most powerful words you can use while implementing lean is “try.”   It’s important to set this expectation early.  It’s as important as understanding that there is no rank or authority when you’re embracing kaizen and that there are no stupid ideas.  True kaizen is a process of trying small changes to understand how they affect the process.  Ideally, they will all be improvements, but in reality not all “improvements” actually have a positive impact.  But you must try them to understand why.

Even if some of the team knows something won’t work, it’s often worth letting people try things so they can learn by doing.  Sometimes it doesn’t make sense to do this because the premise can be explained clearly and is easily understood once explained.  Sometimes there are…

View original post 349 more words

Toyota Recalls Again

Stop the presses, bring out the voices of disbelieving people Toyota has issued another recall on a previous recall. Is my sarcastic tone coming through? So what? If you want to read about it, look here. People are obviously questioning whether this is evidence that Toyota is still on the way down after their highs. I would rather say that it is evidence of Toyota’s honesty than anything else. I cannot really see an American or German car company admitting it made a mistake twice, can you? 

This brings up the usual, “what happened to Toyota?” discussion. It is very clear people, it really is. They lost focus. They focussed on becoming big rather than continually improving. This loss of focus was only temporary though. If you want a great view on it I recommend reading this brief article. I think it sums up the whole situation of what happened at Toyota well. I do not think Toyota is the sort of company that will make the same mistake twice. Is yours?