Welcome back. We're starting the next lesson, which is called symptoms breakdown to assess risk.
Knowing the symptom-problem-cause model helps us with lots of things. Root cause analysis of test failures, field failure analysis, continuous improvement and other things. It also helps us during concept development.
When starting just from a concept, it's difficult to know what questions to ask our cross functional team. "But we don't have a prototype! We're engineers, that's what we do!" We want to create prototypes and show them to others. But at the concept phase, we don't have one yet. We may fall into the trap of starting to engineer solutions before we really have the information we need for proper solutions. And it's hard to know what's most important to work on. We may choose the activity that's the most fun for us. But is it really what the project needs?
We want our work and our analyses to matter. Our time matters! We want to be contributing to what the project needs, not doing busy work. We want to develop products that the end users will love and that will work.
In this lesson, we're going to focus in on the system level part of our issues and learn to use it to prioritize design efforts and ask questions. This will also be the beginning of an analysis that we can iterate throughout the project to manage risks of the product. No time wasted here!
Here's what we're going to learn today.
- We'll describe symptoms as an outcome plus its impact will identify different drivers for symptoms that lead to different actions to prevent risks or reduce losses.
- We'll assess the risk of symptoms to prioritize design actions, draft design inputs and plan for risk analyses for the project. We're going to break down the symptom into its parts so we can start analyzing risks and prioritizing efforts, getting better information about what it is for engineering. Using that information to help us create technical inputs like user needs and requirements, understanding what specific questions we can ask our cross functional team and building a baseline of risk management for us to continue to use.
Describe symptoms as outcome and its impact
Let's talk about how we can describe symptoms as outcome and its impact and this is going to help us better understand the situations and evaluate them for risk. If you remember in a previous lesson, we talked about our symptom-problem-and cause framework where we actually want to fix problems. And problems answer "what is wrong with what" and we want to get to the root cause to fix the problem for good.
We also briefly talked about symptoms, but this is really what I want to focus in on today is the symptom. Our symptom from last time, was that the customers cannot assemble the bike stand, it delays their use of it and uses their time to resolve. Actually, our symptom is in two parts. If we look at it a little bit closer, we can break it into its two separate parts:
- that customers cannot assemble the bike stand and
- it delays their use of it and uses their time to resolve.
The way we can break this out is into outcome and impact. We can give ourselves a simple equation that we can help ourselves remember this, that our symptom is really the outcome plus the impact, given that the outcome has occurred.
This helps us do a lot of things with ourselves in the way that we're thinking in our mindset, and it also helps us with team exercises and helping our team to understand and prioritize and rate risk events. Breaking out the symptom like this into its two parts that helps us to better think about the likelihood of something happening. We can more easily think about the probability of the outcome if we just think about the outcome. And we can more easily think about the probability of the impact given that the outcome has occurred. When we're thinking about how severe something is, we're usually rating it on the impact, and this is also another helpful reason why we break out the symptom like this.
It also helps us to identify ways to block risks and reduce losses and here's why: there are different drivers for the outcome and the impact. The outcome drivers are fact based and they are reasons that we think this could be an outcome. The impact drivers are different, they are reasons that we think that this is the impact, given that the outcome has occurred, This difference is important because we can look to block risks with our outcome drivers. We look at our drivers and these are the things we want to prevent from happening and we can further evaluate these as potential causes to a risk. The impact on the other hand, with the impact drivers, we can look at those to help us develop prevention controls to both reduce the loss and the likelihood and the impact to occur.
Identify different drivers for symptoms that lead to different actions: to prevent risks or reduce losses.
Let's take a different look at the drivers so that we can develop actions out of this. After all, this is what we want to do with these analyses. We want to get information to be able to make decisions on what to do next or how much we need to do. In our example, we have our outcome and impact. Customers can't assemble the bike stand is the outcome and the impact is that it delays their use of it and uses their time to resolve. When we think about drivers, we want to get to those, we can think of them as asking this question: "What can drive the outcome to occur?" and, "What can drive the impact to be more likely to occur to affect its severity?"
Remember, our outcome is customers cannot assemble the bike stand, potential drivers for this outcome is that the parts are wrong, parts are damaged, there are missing parts from the packaging. The instructions are confusing to the customers who are expected to assemble it. There are too many parts in the packaging or there is maybe a lack of tools that's preventing the customer from assembling the bike stand. Those are all fact based things, potential things that could drive the outcome to occur.
Now let's look at impact: them not being able to assemble the bike stand is going to delay their use of it and uses their time to resolve. So a driver to that is that them actually being able to get the healthy need in a timely manner and the kind of health that's going to be able to actually help them finish the project. So another driver for this impact could be the customer service availability and the customer services ability to help troubleshoot the problem and get to the root cause of their experience. Another driver for this impact could just be spare part availability if they can't assemble the bike stand because the wrong product was packaged or there was a damaged component in the package. How fast can we get them a replacement part. These are all drivers that can affect the likelihood and the severity of the impact that our customers are experiencing
In looking at these different lists of drivers for outcome versus impact. We can start to see where we would have different activities to address both sets of drivers for the outcome driver. We want to block risk, we want to prevent the bad things from happening. We want to solve the problem for the impact drivers, we want to reduce the loss, so these are a lot of prevention controls. When it does occur, how can we make it better?
Assess symptom risks to gather information and prioritize design actions.
Let's take this to the next step and analyze the symptom risk so we can start prioritizing activities. We can assign a risk priority number to a design function or a feature based on symptoms. Now this is not the classical R. P. N. Number from FMEA. It's just a priority number that we're assigning to a risk that we're evaluating. We can create a simple table that captures our symptom and it's two different parts the outcome and the impact. We can capture the two different probabilities, the probability of the outcome and the probability of the impact given that the outcome has occurred and we can capture any severity of the impact. For our example, I created a simple severity rating scale that's numerical, but it's really based on quantitative information. So we're going to keep that in mind and realize that the severity that we're going to list on our table is just a quantitative measure that we've decided to use based on the impact. There are two calculations we can add to our table. We can add the likelihood of the symptom which is a product of the two probabilities that we have and we can have our risk priority which is the product of the severity and the likelihood of the symptom happening. In our example, we evaluated the customer cannot assemble the stand, it delays their use of it and uses their time to resolve and our risk priority measure is .72. This doesn't really mean a whole lot on its own. So let's create some more examples and scenarios so we can compare them.
We came up with three other scenarios for our bike stand. I came up with these scenarios by looking at review data online of different bike stands so we could think of these scenario inputs as something that our customers are experienced with competitive bike stands in our scenario, the lower the risk priority number, the less risk our symptom is carrying. One of the scenarios includes a symptom with an outcome that the stand doesn't fit bicycles with extra large frames and the impact of that is that the customer uses the bike stand but it loses some safety features. After consulting with our team and evaluating this outcome and impact combination and assigning a severity of the impact. Our risk priority for this symptom is a 2.88. We have two other scenarios listed on our table, which we have calculated risk priority numbers to be a 1.44 and a .72.
Now, just a reminder that we're not evaluating any particular problems or causes, We're just looking at the high level symptoms, things that could happen or that our customers could experience if there is a problem, considering our tree diagram, we're really focusing in on the first things that we notice when something's wrong. Just given this information, we can begin to better understand what are the riskiest things or design features or start to understand what questions we may want to ask our customers and our customer representatives from the cross functional team like marketing and commercial operations.
We could go ahead and just use the risk priority and prioritize our activities and our design inputs based on that number. But we might be missing out on some other key factors, like just the likelihood and the severity of impact. We can also map risks using, well, a risk map on the X axis. We're going to have the severity of the impact from low to high. It could be numerical, it could be just descriptive on the Y axis, we're going to have the likelihood of the risk occurring from 0 to 100%. And then we create a scatter plot of our different symptoms. In this scenario, we can see that B2 not only had the highest risk priority number in our previous table, but here, it also has the highest severity. The likelihood of occurrence looks to be about equal to some of the other risks given these symptoms are symptom be to stand, does not fit bicycles with extra large frames would be a priority that we would want to focus in on in developing our concept. We also see that are symptom. B3 might be something we want to focus on. It has a high likelihood of occurrence or at least as high as the previous symptom we were looking at. And as brisk priority level is in the medium area are symptom outcome is that the customer must remove attachments to use to stand and the impact is that the customer needs to permanently modify the bike attachments to fit the stand when we're talking and working with our cross functional team, we may decide that these two things are a high priority to address. If we don't get these things right, then we won't have happy customers or a quality bike stand. What are some other next steps in this story?
Our user needs should include that the bike stand is suitable for extra large bicycles. Or make it clear that our bike stand is suitable for certain sized bikes. Do we need to limit our customer base or design it for a bigger customer base? We also need to consider the type of bike the customer is storing. Is it a cruiser bike with fenders? They sometimes don't fit in these stands unless the users take off the fenders. What about the latest bike accessories, like radars, lights, bike racks and bags. These are the things that take a high priority to address. If we don't get these things right, then we won't have happy customers or quality bike stand. We want to talk with marketing and field operations to understand more about our customers, How many of them use? Extra large bikes, smaller bikes, cruisers, electronic bikes. What types of accessories are they using daily? We can do our own technical investigations to what are the interfaces of the bike with our bikes stand? Maybe the wheel size, thickness and frame size? What are those for different bike sizes? And when we get a better understanding of accessories, where are they placed on the bike? What areas of the bike may be off limits for our bike stand? Because of these accessories? And when we get a better understanding of accessories, where are they placed on the bike? What areas of the bike may be off limits for our bike stand because of these accessories.
We can get all of this just from taking a closer look at potential symptoms that our customers baby experiencing when they get to a problem. As we've seen with this example, the results of this type of analysis are preliminary user needs specific questions about the customers that we can ask our cross functional team or the customers themselves. We have questions about interfacing products and accessories that we can start investigating. We have a starting point for technical information needed for design and we now have information about what's important to this design, what features may be more important than others and where we can focus arts we're reviewing a relatively simple example. We want to keep the risk priority exercise simple remember we're using it to inform our decisions what is most important for the design and for our customers. We're going to use this information to help us develop user needs and requirements which are inputs into the design process itself. Before we're choosing components or creating engineering drawings, even though this is a simple example.
Remember that I got these scenarios from real life customer complaints about existing bike racks, A team didn't consider these things. It's easy to think that we'll know what to do when we're designing, especially with this example after the fact it was missed by another engineer. So that is something to consider.
We can use the symptom breakdown to understand outcomes and their impacts and this can help us capture and prioritize our early activities. What did we review today? We describe symptoms as an outcome plus its impact and this helps us to break apart our symptoms so we can think about different probabilities and also severity of the impact itself. We identify different drivers for symptoms that lead to different actions. Are drivers for our outcomes can reduce risk and our drivers for our impact can reduce the severity and help us come up with some prevention controls. We also analyze system risk by using a different matrix risk priority number and a risk map from that. We were able to evaluate these different scenarios and prioritize design actions, get design inputs questions to ask our customers and customer representatives and things that we need to investigate for technical requirements and user needs. Thanks for joining me today, I look forward to seeing you in the next lesson.
