Course 1: Design for Problems and Risk

It's good to see you here for this lesson, which is called causal chain and root causes. Here's what we're going to cover in this lesson.

• Recognize that problems are really what's at the heart of engineering design
• identify the differences between symptoms, problems and causes and understand how important it is to get it right.
• How to distinguish root causes from other causes and diagram causal chains with an event tree analysis to help determine causes.

We're going to be building upon what we learn in this lesson in the next lesson.

Recognize that problems are really what's at the heart of engineering design

Let's start with problems within engineering design. Two thirds of creating new product designs is about solving problems. We want to discover problems and we want to solve problems with our product design. One point of view of our problems is from the perspective of our customers, we create products because customers have problems sometimes, they can't voice what they need because they don't even realize what it is they really want. Think about the invention of the automobile or the evolution of boomboxes and Walkmans to the simpler iPod.

We question and discover what problems need to be solved and other problems are from the point of view of our products' performance. Our designs themselves might have problems that we need to fix. It's not performing like our customers think it ought to or how we expect it to perform.

Focusing on problems is a practical point of view, not a pessimistic one and it doesn't conflict with a third important part of the design, which is the creative and artistic inputs, making the design beautiful. We're not forgetting that engineering design can also be about tweaks and continuous improvement. That's not always about big problems. Nonetheless, continuous improvement should also have its own clear definition of problems.

Recognizing that problems are a big part of the engineering design journey is a way to think of product design in a way that allows us to measure design progress, make assessments of different choices and to ensure that we're customer focused.

Identify the differences between symptoms, problems and causes

We all need to be on the same page when it comes to recognizing what's the problem, what's a symptom or cause, which brings us to our second objective today, identify the differences between symptoms, problems and causes. Why is this important? Because we can design actions around problems to find solutions and that's how we make a difference.

I have a favorite quote from Steve Jobs who said, "If you define the problem correctly, you almost have the solution." Putting effort into truly understanding the problem is the way to make improvements and make a difference. It takes awareness and some diligence to do it right. Because our true problems are sandwiched in between symptoms and causes. If we start acting from symptoms, we're not going to have an effective fix. If we're acting on what we think are causes, we may not be addressing our true problem or getting to the root cause.

Let's talk more about these three parts of an issue. A symptom is a signal that something is wrong and it's usually the first thing that we notice. The problem describes a deviation based on facts. And the cause is a factor that if we don't control it, it could lead to an undesired event. To really and truly fix the problem, we would want to get to its root cause.

Let's talk about an example. We're driving our automobile and notice that the check engine light is on the last time this happened, it was because we didn't tighten the cap on our gas tank. We just make a mental note to tighten it the next time we fill up with gas. We've just jumped to a conclusion which is our common mishap number one. We've noticed a symptom is repeating and we've experienced this symptom before, so we just assume that it's going to be the same cause. If we hear ourselves saying things like, "I believe", "I think," "I know," - those are clues that we are jumping to a conclusion and really haven't truly identified the problem or we at least haven't verified what we think the problem is. Our memories can be biased. So this is a gotcha that you want to look for.

I've got another common mishap for you and that's solving the symptom and then celebrating the quick fix. If we suspect we're solving symptoms and celebrating the quick fix, we can ask ourselves some questions. Did we learn something from the event? Have we prevented it from happening again, will customers be pleased? Have we made a difference and has our behavior changed? If our answer is NO to some of these questions, we may be solving symptoms instead of causes, and we've fallen into the common mishap trap.

Since we don't want to just fix our symptom and we don't want to jump to conclusions, we need to get serious about defining our problem. To be thorough, we want to be able to explain problems in two parts. A problem statement and a problem description.

• The problem statement is what we want to solve, like answering the question, "What's wrong with what?" The problem description is describing the location, timing and other details like the change that's occurring. Let's take a closer look at the problem statement, the, "What's wrong with what?" Here, we want to be able to capture the object and the deviation. Let's look at an example. We have a symptom that we're having trouble inserting a key. The object that we're having trouble with is the driver's side, van door and the deviation. Is that the key does not fit? So our problem statement or, "What is wrong with What" is that the key does not fit the driver's side van door. With problem statements, sometimes, if we have more than one deviation, we may decide to choose the one that's dominant or the one that seems to be causing us the most problems most often. Now we want to exclude anything that specifies, or even implies what the causes or maybe such as how or why the problem occurred. That information is likely premature or inaccurate and could cause the diagnosis to go in the wrong direction. For example, if I'm going to the doctor and I self diagnose what my problem is from web M. D. Instead of describing my symptoms to the doctor, I'm telling them what I think it might be. I'm jumping to conclusions by including a cause in my problem statement and that's something that we want to avoid.
• The problem description: It gives us direction for what we want to analyze and further investigate. And that could include things like timing, how serious or expensive it is or where we observe it and especially description of any physical evidence. When we have physical evidence we have better understanding and it's easier to convince people when they can see and touch it. Physical evidence also gives us a benchmark to verify that whatever we did to fix the problem or corrective actions really did fix the problem. The problem description is also used to design actions. It also invites learning opportunities. So we want to be able to include enough description about our problem so that we can begin to see or get curious about what the causes could really be.

Once we have a clear problem statement and description, we can start thinking about actions to uncover and evaluate the causes. Remember in defining the problem correctly, we almost have the solution.

One of the quality tools we can use to help us visualize and understand the layers of causes associated with our problem is a graphical tool. We can diagram causal chains with a tree diagram to help understand causes. A tree diagram is a graphical tool that helps us analyze a situation, probe for causes, analyze logical steps and help us communicate with our team. Tree diagram is a generic tool which is the basis for a whole lot of other quality tools, such as a Why-Why diagram, a fault tree analysis, event tree analysis, work breakdown structure and even organizational charts. Today we're going to use it to branch off an event or problem into its varying causes.

Distinguish root causes from other causes

So let's talk about how to distinguish root causes from other causes. There are several layers of causes that we're going to encounter. It's important for us to investigate and get to the root cause so we can have lasting effects and fix our problems for good. Root causes are specific fact based causes that we can address. We may start with a symptom but then as we investigate, we're able to fully define our problem statement and description, We need to continue to investigate potential causes. To narrow our focus to a significant cause and then continue to investigate until we get to the root cause in knowing the root cause. We can start to define actions to correct or prevent our original problem. To help define what a root cause is. Let's think of it as a switch. If we switch our root cause off, then the problem goes away. When we switch it on, the problem comes back and when we switch it off and on, we don't create negative side effects.

Another method, we can walk through to understand a root cause is called the Why-Why the Five Whys. This is a method where we continue to ask ourselves and our team "why?" The answer to one Why becomes the problem statement. And then we ask ourselves, "Why?" again. We do this until we get to a root cause. Let's say we have a problem and we figured out that we have a problem because the hole was drilled in the wrong location of our part. That's our first layer of a cause. Now we ask ourselves, "Why? Why did the machine drill the top hole in the wrong location?" Our team has broken off and investigating came up with an answer. The machine was running the wrong program. Now we ask ourselves, "Why? Why was it running the wrong program?" We ask "Why?" multiple times until we get to the root cause. Most teams stop at setup was incorrect and then require operators to do retraining. But we know to keep going with our Whys because we realized that people are not root causes and pointing fingers isn't useful. In this example, if we hadn't continued our Why-Why investigation past an incorrect set up, we would have never gotten to the cause that the program names are difficult to distinguish. We might have had the same problem again in the future. But because we got to the root cause, we can fix it for good.

This brings us to the end of the lesson. We covered a lot of things today. Let's go over what it is that we did talk about in this lesson.

• We talked about how engineering design can be looked at as solving problems, which helps us to think about potentials.
• We can identify the differences between a symptom a problem and the causes and why defining problems is really a great first step figuring out what action we need to take next. We can also distinguish root causes from other causes and understand that the root cause is really what we're after for lasting change.
• And we can use tree diagrams to understand all the causes that we're looking at to ensure that we're getting to the root cause.

Now it's your turn to create a tree diagram to explore symptoms, problems and their causes. You can create one from a problem that you're having right now or you can use a scenario that I've provided. Start with what you know and start asking "Why?" to get to the root cause. If you're working on your own problem, you'll probably not be able to get to the root cause in your first sitting, you'll need to do some investigative work and that's okay. And it's expected. Just capture what you know and understand what you need to figure out. We'll be building something new off this tree diagram in the next lesson.

Thank you so much, and I'll see you in the next lesson.

[progressally_media media_id="4"]