Assumptions – A Bridge Across Why – Part 2
April 27, 2011
Problem – the perceived difference between a current state and a desired state.
In my last post I discussed assumptions as a good starting point when looking for initial causes in a root cause analysis. Today, I will look at one more practical way of finding these hidden assumptions. I will make an assumption myself here and that is that you are already familiar with basic root cause analysis and know what an Ishikawa (or fishbone) diagram is. If my assumption is wrong you can find some good basics at Wikipedia before continuing.
I find that using brainstorming techniques such as working with Ishikawa diagrams in order to find starting points for causes, have a hard time bringing out unspoken assumptions and prerequisites. Usually the brainstorming is done first and then the results are mapped to the categories in the fishbone diagram or the brainstorming is done with respect to each category, but if we instead start by asking questions that combine the different categories in our Ishikawa diagram, we can find several of the failed assumptions. This can be done as a complement to what is normally done and should not be seen as an either or.
Let’s say we’re working with the 4, 6 or 8 M’s (Machine, Method, Material, Man Power, Measurement, Management etc). Try to combine the categories in questions that are relevant to your situation, e.g.:
- What training will our Man Power need in order to understand our Method?
- What limitations do we have on our Material considering the Machines we’re using?
- What support will Management need in order to make good Measurements?
- When will we need our Material if we’re going to follow the new Method?
- What is required from Management for our Man Power to get the Machines or tools they need?
Doing this we might come up with a list of prerequisites or assumptions that were never made explicit at the outset:
- If we assumed that everyone on the project was familiar with some basic technology, compare this assumption to reality.
- If we assumed that our target audience belonged to a certain demographic group, compare this to our true audience.
- If we assumed that people in adjoining departments would communicate with each other, check if this actually happened.
- If we assumed that our instructions would be read by everyone, check if everyone actually read the instructions.
- If we assumed that everyone knew where to find the background documents, see if everyone actually knows how to find them.
- If we assumed that a new hire would be brought up to speed by the team within two months, check if that was the case.
If any of our key assumptions or prerequisites turn out to be false, investigate their impact on the process and problem statement and continue the root cause analysis from there.
As I mentioned in my previous post; validating assumptions is something that should be done all the time and preferably at the beginning of a new project or endeavor of some kind. Using the technique described above does not have to be limited to root cause analysis when the problem is already a fact. Perform this exercise or whatever works for you at the outset of any new project, change program or other activity where you’ll be working according to a new process.