Assumptions – A Bridge Across Why – Part 1

Problem – the perceived difference between the current state and a desired state.

At times when we find ourselves in the need of performing a root cause analysis (RCA) we have usually ended up at a current state that differs significantly from our desired state. When we embarked on the endeavor of trying to reach our desired state, we probably had a plan or process that we expected would help us get there. Now, most of us design our processes very carefully but we also often implement them on top of a number of loosely made assumptions that are more error prone than anything else in our process.

Depending on our selection of method for RCA we might or might not have the tools for looking at our new process in order to find flaws in it. My suggestion is that you select a method that will help you analyze your process, but that is not what this post is supposed to be about. What I find most methods for root cause analysis seem to lack, is a way to look at the assumptions that we base our process on.

Every problem solving approach that I’ve come across so far has followed a similar pattern of:

1. Identify problem
2. Find cause
3. Find and implement solution
4. Check result

There are methods for problem solving and RCA that are a lot more refined and give the user good help on how to move between the different steps but the “find cause”-step is often left to more ad hoc techniques such as brainstorming. I think most methods miss out on one good starting point when looking for the causes; our assumptions.

The old saying that assumption is the mother of all f…ups holds true quite often. Validating assumptions should always be done, but if you missed doing this validation earlier, at least do it during the root cause analysis. You will stand a good chance of finding some problem causes in this group.

I want to suggest an approach where our assumptions are made explicit and are compared to history and facts as a first step to identify possible causes. After a problem statement has been properly identified and expressed, try to list any key assumptions or prerequisites that would have been necessary to hold true in order for your process to be valid and for you to reach your desired state. These assumptions might have looked more or less obvious at the outset and thus taken for granted, but that is not the same as them being true. Compare these assumptions to history for fulfillment to see if we actually had everything in place in order for our process to work.

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. Remember that these are probably only immediate causes and not our system causes.

In part 2, we’ll look at one way of bringing these assumptions out into the light.