In manufacturing, when stuff goes wrong, there tends to be physical evidence, such as a part with holes in the wrong place.  It is therefore often easy to find the immediate cause of the problem, which might be to say that the wholes were drilled in the wrong place and go yell at the person who does the drilling.  But in Kaizen, the immediate cause of a problem is only the beginning of the analysis, not the end. The team is supposed to start with the problem and ask “Why?” seven times to determine the root cause of the problem.  Why was the hole in the wrong place? Because it was drilled in the wrong place.  Why was it drilled in the wrong place? Because it was marked in the wrong place. Why was it marked in the wrong place? Because the person marking it measured from the wrong location.  Why did they measure from the wrong location? Because the measurement directions were unclear.  And so on.

There are several wonderful things about root cause analysis.  First, it immediately changes the dynamic from finger pointing to learning.  The immediate cause of any error is only the last element in a chain of causes and the goal is to understand that chain.  Second, by working towards the root cause a simple problem may be found to have a root cause that is in fact responsible for many other problems.  This is why it is important not to ignore little problems, which in turn ties back to the first post in this series.  If you set seemingly outlandish quality goals, then every little problem is worthy of analysis.  That analysis – if done right – will help uncover root causes that were either already – or would in the future be – responsible for many more problems.

In software development we tend not to have any physical artifacts to go on.  If something is not working on a site or service, there are a myriad of possible different causes.  So often identifying the immediate cause is already difficult.  That results in an added tendency when a bug is finally found to just fix it – often with a hack – and move on (possibly after some yelling at the directly responsible person).  In the Kaizen approach that represents a lot of lost opportunity for learning and lasting improvement.  Using the “seven whys” takes patience but is great discipline.  In fact so much so, that I recommend it not just for manufacturing or software errors, but anything you encounter that’s not going the way it should.

In manufacturing, when stuff goes wrong, there tends to be physical evidence, such as a part with holes in the wrong place.  It is therefore often easy to find the immediate cause of the problem, which might be to say that the wholes were drilled in the wrong place and go yell at the person who does the drilling.  But in Kaizen, the immediate cause of a problem is only the beginning of the analysis, not the end. The team is supposed to start with the problem and ask “Why?” seven times to determine the root cause of the problem.  Why was the hole in the wrong place? Because it was drilled in the wrong place.  Why was it drilled in the wrong place? Because it was marked in the wrong place. Why was it marked in the wrong place? Because the person marking it measured from the wrong location.  Why did they measure from the wrong location? Because the measurement directions were unclear.  And so on.

There are several wonderful things about root cause analysis.  First, it immediately changes the dynamic from finger pointing to learning.  The immediate cause of any error is only the last element in a chain of causes and the goal is to understand that chain.  Second, by working towards the root cause a simple problem may be found to have a root cause that is in fact responsible for many other problems.  This is why it is important not to ignore little problems, which in turn ties back to the first post in this series.  If you set seemingly outlandish quality goals, then every little problem is worthy of analysis.  That analysis – if done right – will help uncover root causes that were either already – or would in the future be – responsible for many more problems.

In software development we tend not to have any physical artifacts to go on.  If something is not working on a site or service, there are a myriad of possible different causes.  So often identifying the immediate cause is already difficult.  That results in an added tendency when a bug is finally found to just fix it – often with a hack – and move on (possibly after some yelling at the directly responsible person).  In the Kaizen approach that represents a lot of lost opportunity for learning and lasting improvement.  Using the “seven whys” takes patience but is great discipline.  In fact so much so, that I recommend it not just for manufacturing or software errors, but anything you encounter that’s not going the way it should.