Methodology like "3x5 why's" and "Prevent, Protect, Predict' have been long established, but organizations still struggle today to get to the bottom of systemic root causes that slow down their programs, cost them money and ultimately can break the trust relationship with their consumers and brand image. So, how can we better leverage data that already exist in organizations to shift the focus on fixing their systemic problems once and for all? And most importantly, what can leaders with no quality background learn from these quality techniques and how can they use them to turn their functions in learning and innovative organizations?
- You haven't solved a problem until you don't understand and fix the systemic root cause that generates it
- If you look at data about symptoms or technical root causes only, you cannot detect the major systemic root causes across the organization
- The steps to solve a technical problem and an organizational one are the same, and by learning what quality professionals bring to the table beyond their area of expertise, executives can boost the organization at large
Hello, and welcome. I’m Simona Pappalardo, Senior Director for Global Quality at Whirlpool Corporation. It is my pleasure to be here today with all of you, and having the possibility to share some of the tips I’ve learned during my 15 years tenure in different quality organization across different industries.
The topic of today is predict, protect, prevent, and what we are still missing in the identification of systemic root causes. We’ll start our discussion today by introducing the steps of problem solving. Then, we will talk specifically about the predict, protect, prevent methodology, and why are organizations still failing to use it effectively. To conclude, we can discuss how you can use some of these tools to solve long lasting issues and drive real change in your organization.
Before we jump into the topic though, let’s all agree on some definitions that we will use moving forward. First of all, a symptom is the effect generated by a mistake or an issue is basically the outcome of something that went wrong. The root cause is the true origin of a symptom is basically the answer to the question why something happened. Last, corrective action, it’s an action taken with the purpose of avoiding the mistake to happen again, and the symptom to represent itself.
Here is the first big idea of today: a problem cannot be solved without understanding its cause. Working on eliminating the symptoms will not generate long lasting success. Today, we will introduce all of the different steps of problem solving. Ultimately, we were really focused on the most critical step, which is understanding the root cause. Steps of problem solving, what needs to happen when you are facing an issue in your organization?
First of all, you identify a team, someone that is responsible and accountable to understand what exactly is going on, understand why something is happening, and how ultimately to solve the problem. Description of the problem. The second step is to describe the problem. The secret to an effective problem solving analysis is for the problem to be probably described. Third item is contain the problem, especially if this is something that you have in a production line that is running today and there is a problem, you need to understand how you’re going to protect your customers and how you are avoiding shipping bad parts or bad products out in the field. This step is all about potentially having to shut down things that could be an extreme example of a contained problem step. Of course, it’s rare that you have to jump into such an extreme situation. It has nothing to do with solving the problem, it’s just to avoid further pain while the problem gets solved. Step number 4, the most important as I was mentioning before, is identify the root cause. We will talk extensively about this, so let’s go quick to step number 5 as we will deep dive in step number 4 later on. Correct the root cause. Of course, we want to solve the problem, right? After having understood the root cause, we need to identify proper action so that the problem can be corrected. Step number 6, confirm that the action we have taken is really effective in solving the problem. Step number 7, prevent the problem from reopening and we will talk more extensively about this one because you can really go through the prevention piece only if you have done proper identification of the root cause in different ways that we are going to see in a minute. Ultimately, step number 8, thank the team for their work. Dissolve the team, thank them, and congratulate them for their results.
Let’s focus now on identifying the root cause. Here is where the predict, protect, prevent methodology really comes into place. It is important to notice that there are different types of root causes. During a problem solving activity, we want to make sure that we don’t miss any of those. Which different type of root causes are out there? The first one is the one that everyone think of, what we call the technical root cause, and is associated with the step of predict. This is basically asking yourself and your organization, what caused the problem in the first place and needs to be corrected moving forward. It’s called predict because by doing this analysis, asking your yourself and organization several times why something has happen? Bottom line, you will find out that you could predict that such a problem would happen, so that’s why is associated with the word predict. The type of root cause is called technical root cause.
As I mentioned, there are other types of root causes. The second one is the escape root cause. The escape root cause is about why wasn’t the problem detected in hours, or anyway as soon as possible? If the problem is in the field, why couldn’t we see it in our labs, for example? Or if the problem is in a production line, and the suffering of the beginning of the line, why does it take us so many steps to even detect that the problem was there in the first place? This is why we use the word protect to describe this step, because it’s all about protecting the next person, the customer, the next step in the line about receiving something that is already broken, that is already containing the mistake. So again, this is what the escape cause is all about, and we associate it with the key term “protect”.
Third and last one type of root cause that is probably the most important and where I will focus the most moving forward is the system root cause, and is associated with the fourth of preventing something from reopening. The system root cause is answering the question: What in our processes went wrong and needs to be improved for the future? It’s all about processes, workflow, organizational decision making. It’s about not focusing on the problem that we have today, but expand our horizon and understand why did we get here in the first place and what can we do moving forward to never re-experience the same issue? There are different type of root causes and we like to remember three groups: technical root cause, escape root cause, and system root cause.
Here is the second big idea for the day: When you are in front of a problem, don’t stop at the technical root cause—remember to investigate also the escape, and even more importantly, the system root cause. This is where a lot of organization fail and also a lot of individuals, no matter how skilled and well trained they are. The reality is, that we have a problem at hand. Sometimes, it can be a big problem. Of course, everyone focuses on the emergency, on the here and now. What is impacting our lines today? Why we cannot produce today? What can we do to improve the experience of the customer that have received our products today? Automatically, a lot of people, effortfully so, focus on the technical root cause because that’s where the corrective action identification will start from. I’m not here to say that that’s not an important area for the investigation—it is, absolutely. What I’m talking about is that that’s not enough for the organization to really learn. Where the learning comes in is if you address the old problem, all of the different root causes. We talked about these in theory. I do believe that it can sound very easy when explaining theory, but as I said, I have seen so often in my 15 years tenure, people forgetting about the need to address all of the three different types of root causes.
Let’s put ourself in a real case example, and let’s talk a little bit more about what predict, protect, and prevent means in this context. Let’s say that there is a washing machine, and the symptoms that the customers in the field or experiences is the machines do not drain at the end of the cycle. We send out some Service Technicians in these consumer rooms, and upon their analysis, what is discovered is that coins or other type of foreign objects are found in the pumps of the washing machine. That’s the example of a technical root cause—the coin is making the pump be stuck. As such, the pump cannot effectively operate the draining that happens at the end of every single cycle. As I said, that’s the technical root cause, but let’s make one step further. Let’s ask ourself, “Why didn’t we detect these in our labs?” Well, upon investigation, we could find out that we, for example, test only with clothes, but we don’t necessarily put in objects in the pockets of jeans and trousers during testing. The escape root cause in these case is there is not an appropriate test plan, including the real field usage. People forget objects in their jackets and in trousers, so it is very important that the validation master plan cover as much as the inference space of the customer usage as possible. This could be an example of an escape root cause, but let’s make even one step farther, the most important one, in fact. Let’s talk about how is it that we have forgotten that people can forget objects in their clothes. What comes handy is understanding how we collect requirements from our customers. For example, here are an example of a QFD of quality or whatever tool your company uses to translate the voice of the customer into the voice of engineering. Sometimes, there are needs that are unspoken, and it can be tricky to identify all of the different needs for the customer. This is a potential area of improvement in the future about making sure that we really capture all of the usage as it happens in the field.
Here is big idea number 3: The learning of an organization happens when we truly understand the system root cause. Here is why, let’s think about, in this example, we could definitely focus our efforts on putting better filters and screens that prevent objects to fall into the pump. That’s absolutely an action that we need to take and that’s definitely necessary, but what that creates is that we solved the problem for the washing machines that are currently into production or currently out in the field. We can definitely make those customers happier by solving their problem, but if we don’t ask ourself how to better capture the requirements of our possible future customers, we might miss missing really an opportunity not only to improve the the appliances of today, but the appliances of tomorrow. Even more, we might be missing the opportunity to expand our knowledge not only for washing machine, maybe we are learning a new methodology around how to collect customer requirements that we could later on apply to fridges and microwaves. Once again, it is very important to not forget that we need to identify the system root cause if we really want our organization to be a learning one.
As I already said, it seems pretty straightforward, but there are certain things that really brings me to say that organization are still failing in using properly the methodology. Why does that happen? Well, data often gets clustered and summarized in graphs and dashboards for executive to take appropriate decision moving forward. What I’ve seen happening over and over is the clustering of the data according to the technical root cause.
Here is an example for appliance not draining type of symptom and some of the possible technical root causes. As we have already mentioned, for an object in the pump, and the pump could be broken, there could be an electrical fault, like, for example, the pump not being properly connected with the electrical system, the cycle could have been interrupted, and never reaching the draining phase, and so many other possibilities. This is how a data typically gets summarized by problem solving teams. Think about the difference if you instead would see data clustered in this way. This is an example of how data can be clustered, according to the systemic root cause. Now, all of a sudden, the information that you have is not anymore necessarily about the object in the pump, but it’s much more about the fact that maybe the organization doesn’t necessarily know how to fully capture customer use, or maybe there is a problem around which samples get tested during validation, or maybe there are process steps that are missing in how we develop products. It could be that some of the personnel is trying their very best but isn’t trained, and so on. As you can imagine, the two graphs, even if could be the outcome of the same type of symptoms, represent a very different picture and trigger very different questions from the executives.
Here comes big idea number 4: How data is presented matters. In order to drive action in the right way, the type of question and the type of actions that you will be asking your team to date is completely different, depending on which of the chart is presented to you. What are we going to do about it? The first section is very simple. Ask yourself and your team if the data that you’re reviewing points at predicting or at preventing steps. Is it about clustering the different technical root causes or is it about clustering different systemic root causes? That’s the very first important starting point for you to drive discussion in the right way.
The second suggestion that I have is to set up the information systems for data collection that direct and help the problem solver to analyze the system root causes. What I mean by that is, ever system wherever you put your data about issues and mistakes and problems that your organization faces, organize them to ask always the three different question has to go through the technical, the escape, and the systemic root cause, so that people understand that their job is not done until they don’t ask the three different questions.
Suggestion number three is look at every technical issues that access as an opportunity to learn more about what your systemic opportunities are. The symptoms that you are analyzing will be the same, but driving the investigation in different ways, and really focusing on the systemic root cause will show you how to make your organization grow moving forward.
Once you have done all of this, here is the biggest idea: You need to fall in love with learning and you need to help your organization understanding that this is the way to improve every single day. When you ask them, “What is the systemic root cause?” You want to do it not [inaudible] blaming anyone, but really trying to understand what in the process in the system in a decision making in the way we operate the business is creating the problem in the first place. This is really looking at every single issue as an opportunity. It can really be a change agent in every organization. It’s not only for quality, it is not only for Engineering, these methodology can really apply to every area of the organization. It can be applied to HR, it can be applied to Finance, it can be applied to Project Management, it can be applied to Communication. Understanding the true, deep root cause in a systematic way will really boost your organization learning to the next level.
Thank you so much for spending your time with me today. I have really enjoyed the conversation. Please don’t forget to leave questions and comments here below. I look forward to seeing and answering all of your comments. Thank you once again for the gift of your time today.
Get full Q/N Access
Sign up to Q/N with a few details to watch this presentation.