Making Big Problems Into Little Problems

Over the last couple of months, I have talked about how the Process Improvement Project is different than just a regular Project.  This is because, when you start a process improvement project, you do not know what is really happening.  You typically have a high-level problem, identified with some high-level data, that has a high-level impact.  It is like flying over the countryside in a plane and seeing a fire burning on the ground below.  You know a fire exists, you can see approximately how big it is, and you can somewhat tell its impact.  You have very little detail outside of that.

Project management would say, “Put out the fire.”

Process improvement says, “Figure out what is causing the fire and ensure that you put the fire out in such a way that it does not come back.”

That’s Root Cause Analysis.

From the moment you define a problem, you start the effort of root cause analysis.  In DMAIC (Define, Measure, Analyze, Improve, and Control), the first three phases of Define, Measure, and Analyze are all part of root cause analysis.  Improve and Control are the Project Management parts of the process improvement project.

The biggest (and most overlooked) part of root cause analysis is breaking the big problem down into smaller problems.  Honestly, this is because most problems tend to have a whole host of root causes.  If we do not break the problem down, we will try to solve everything at once.  Then, we end up with a whole list of solutions to implement, but you never know which solution truly solves the problem.  What is worse is that when we do not break down the problem, it takes a long time to solve the problem, if it gets solved at all.

So, starting in Define, we begin breaking down the problem in order to get to something very specific — one root cause.  Perhaps (hopefully) the biggest root cause.  Everything we are doing up to this point is pinpointing that particular root cause.  Once you have the root cause, we ask, “Why?”  When your root cause is that specific, the Why is usually a no-brainer.

Here are some of the tools we are using to break down a problem:

Tree Diagramming

In Step Two of Gemba Academy’s Practical Problem Solving course, you learn to use Tree Diagramming to break the defined problem statement down. There are many ways to break your big problem down into smaller problems, however, the most often used principle for arranging your tree diagram is by asking questions such as, “What is the problem?”, “Where is the problem happening?”, “When does the problem occur?”, and “Who is being impacted by the problem?”

By doing this, we are able to break the problem down into more manageable pieces.  This allows us to focus on one specific problem area that is contributing to the overall problem.

Process Mapping

Process maps and value steam maps serve a lot of different purposes.  They provide a document that helps everyone in the process understand what everyone else is doing in the process.  Maps show hand-offs, decisions, rework, and a whole host of information.  You can use a map to identify what parts of a process add value and what parts do not add value to the end product.  They also provide a resource for training new people on the process and how it works — this of course gets more detailed as you move to Standard Work and Work Instructions.

From a root cause analysis perspective, a mapped process allows you to pinpoint specific areas where problems might be occurring.  This allows you to draw a red box around that part of the map and say, “Let’s focus our efforts here.”

Charts and Graphs

In Gemba Academy’s Graphs Overview video, they share many of the most popular charts and graphs that are used in process improvement today.  While presenting your data in a visual format is essential for reporting, these tools provide a wealth of assistance in pinpointing specific areas to focus on in process improvement.  A Pareto Chart or Pie Chart helps you see what is occurring or where something is occurring the most. Plotting graphs (e.g., Dot Plot, Individual Values Plot, and Box Plot) allow you to compare things like workers, shifts, geographic locations, etc.  In process improvement, all these charts and graphs are designed to further distill precisely where something is happening.

Statistical Analysis and Inferential Statistics

When we look at charts and graphs, we make “visual inferences” of the data.  The data (sometimes referred to as “The Voice of the Process”) speaks to us visually.  However, sometimes what we see is not always statistically true.  T-Tests, Analysis of Variances (ANOVA), and other such tests provide a mathematical view of the data that our eyes do not typically see.  The computer software makes the inferences for us and spits out a P-value that represents its level of confidence in his decisions.  These tools are mainly designed to further pinpoint specific areas to look for the most important root causes.

Fishbone Diagram and Five Whys

Once you have gone from this massive problem to a very specific area where the problem is occurring, now is the time to ask, “Why?”  At this point, is when we typically begin the brainstorming activities designed to determine why this problem is happening where it is happening — the answer becomes your root cause.  The two most popular tools to structure your brainstorming activities are the Fishbone Diagram (also called the Cause and Effect Diagram or Ishikawa Diagram) and Five Whys.  Both of these tools are explained in Gemba Academy’s Practical Problem Solving course.  Two months ago, I shared a simplified brainstorming approach in a Gemba Academy blog.

Everything, from the moment your process improvement project charter is built, should be focused on breaking down the big problem into something manageable so you can get to one root cause and one solution.  Using these tools through the Define, Measure, and Analyze phases help you in making big problems into little problems.

---