Course 1: Design for Problems and Risk

Welcome to the next module. We are now in lesson three, which is “Design as controls” and here's what we're going to be talking about today.

• We're going to be able to describe controls as layers of protection from an undesired event. I have a model to review with you that helps us to easily visualize this.
• We're going to identify common sources of controls, and
• will contrast prevention and detection controls and understand their effect on F M E A.

Defining controls as layers of protection

Let's start with our topic number one, which is defining controls as layers of protection. Remember we had talked about product design as solving a problem. We can also think of it as designing a system. When we're designing, we're also defining a system in which our product is working.

• We have the product itself that we may be designing.
• Our users are interfacing with our packaging or it's ensuring that it gets transported safely to where it needs to go - for that kind of thing.
• The labeling that we use helps communicate what's in the box, any special storage requirements and any handling kind of information that our users need to know.
• It may also include tools or instructions for how to assemble and use it.
• Finally, we may even consider our service department as part of the product design surrounding our product design.

We also have several interfaces that we don't necessarily have control over but that we need to understand in order to create our design.

• We have our users. We have our end users that are people that are working with the product. We may also have other users that we need to identify and design for. We can also consider the people that are unpacking and displaying our product or storing it in a controlled environment if it needs it. People that perform maintenance or repairs on our product and finally the people that need to dispose of our product properly in the proper waste streams. These are all potential customers of our product design.
• Those other users may be working in a place where they have to comply with some standards and regulations and maybe even their company policies. Think of standards or regulations associated with workplace safety.
• Our design may need to comply with environmental regulations within the use environment of our product.
• There could also be other equipment, things that need to interface or interact with our product in order for it to work. Or maybe our product is just one piece of a larger system of products that are performing a procedure.

Considering this whole system, the way that we design the product controls some things about our system. With any system there are things that could go wrong or not as we intended. So we start to layer in controls, barriers to letting the bad things happen.

There are situations, failures of our product and decisions that our users make that can pose a threat to our product design system. It could affect the safety, performance or functionality of what we're designing. We can use an arrow to represent a potential of harm. If the arrow happens to get through, we could have a bad effect: something that we don't want to have happen. We don't have to just let things happen. In fact, a part of product design is making sure that bad things don't happen. So we design barriers to our threats. Those barriers could represent a design control an action or a policy that's put in place as a barrier to risk, including actions that lessen the consequences of an error.

Our controls aren't perfect. There can be holes in our barriers which are the shortcomings or failures of our risk barriers. We can think of these failures in three different ways.

• A latent failure can be considered an underlying cause. It's a failure of the systems design that can increase the chance of harm.
• Active failures can also be thought of as immediate causes or specific actions involving people making decisions.
• Pre-conditions can be situational. Are the conditions of the situation just right to promote a risk event?

If the arrowhead makes it through all our barriers, it means that the risk barriers failed and the harmful event was allowed to happen. The more barriers we add the more likely the shortcomings (or the holes) will not line up and the undesired event will not turn into harm. We can also fix the shortcomings (or plug the holes) in our barriers to reduce the chance of harm. This is the Swiss cheese model of accident causation and it's credited to James T reason in the 1990s and 2000's.

For product design, this model can be used when thinking about controlling risks of a design. Each slice of cheese would be a component of an organization that's involved in the creation and use of our product design.

• It includes the end user, including their understanding of the product and their skills. There may be a baseline education that would be expected, something that should be communicated to everyone. For example, I'm not trained to perform medical procedures, so no one would be designing those products for my knowledge set. They would be designing for nurse practitioners or doctors, people with degrees or certifications that they have a baseline skill set for the end users. We also want to remember those other users, the stockroom people and the retailers, the maintenance people in the waste handler and recycler.
• Another barrier that we can design for is the use environment. We talked about work policies that users may need to follow. Those guidelines can provide some controls for bad things happening when they're using our product. Again, this expectation should be communicated to everyone. The use environment also includes those standard parts and equipment that would be used with our product.
• And our threat barriers can also be part of the product design itself: was it made right? Did our suppliers and manufacturers make the product to specs? Are they monitoring it? And is it the right product? We designed it to solve a problem. Does it really solve the problem or does it introduce more problems?

This model helps us think of our product design as a system. We can take into account the users, the use environment and our product design. It also helps us identify controls, thinking of them as layers or barriers of protection of risk. They can also help us think about shortcomings of the controls. Thinking about where the holes could be, not just in our product design but of the whole design system. This model also helps us communicate those ideas with other people.

Common Sources of Control

Now let's talk about common sources of controls during product development. We have different phases. Typical phases are to have a design input, then a design process where we're honing our concepts and then finally, we have the design outputs.

Design inputs could be things like statutory or regulatory requirements. Our design inputs could be developed from user needs to ensure that we're making the right product. Our product design is actually going to be performing the way our users intend and the way that we advertise. Our manufacturing friends might have needs about how things are assembled, in-process tests, and other design for manufacturing considerations. And our inputs might include a design for environment. Generally, the design inputs capture that broader system design aspects, things that we need to understand and to find the scope for in order for us to design our product.

After the design process, we're going to have outputs and those are usually in the form of specifications, assembly drawings and drawings with toleranced dimensions, material specifications, manufacturing specs and equipment settings and an identification of features that are critical to the safety or functionality of our product. Critical features are the things that we define to ensure we're making the product right. Ensuring that we're making the product right can also control risks and be one of our barriers.

Inputs and outputs can be created to eliminate or control risk. Not all inputs and outputs are tied to risk. With risks that we've identified, we want to apply controls proactively. First, we identify a risk, then we design a control for it. Do we have a risk that's not properly controlled? Maybe we need to change our design requirement or features to be able to eliminate or reduce the risk.

Contrasting Prevention and Detection Controls

This brings us to our topic number three: contrasting prevention and detection controls. Quality and reliability practitioners define controls as being in two categories or buckets: detection controls and prevention controls. These different buckets, the detection and prevention, are different ways to control issues and reduce risk measures. It may not be enough to have one control. We may need to have prevention and detection controls or the control that we have may not be sufficient.

Prevention controls are part of the design. Even considering the broader system design, it could be a feature of a design that could fail or they could be the lack of a feature. Prevention controls require someone to do it right or something to function properly. When we implement prevention controls in our design, it's usually linked to better quality products that are easier to use and less waste overall. Considering risk, prevention controls work to design out the issue, essentially eliminating the failure mode. We can rate the effectiveness of our prevention controls on the likelihood that they'll prevent an issue and its subsequent failure from ever happening.

Detection controls affect our ability to notice or pick out when there's been an error or issue. It requires someone or something to be a monitor. It could be inspection performed by quality personnel or an automated vision system. It may be an internal system check that monitors and reports on inputs or outputs with risk. We can rate the effectiveness of our detection controls on the likelihood that they'll help us or some other monitoring system notice an issue.

Generally, it is better for us to create prevention controls over detection controls. Thinking this way also gives us a different mindset toward design because now we're looking for ways to eliminate and reduce failures and mistakes. And the designs can be linked to better quality products if they're preventing problems. It's also linked to products with a user process that's easier because we're designing for the user. Prevention controls may also reduce waste and recalls and scrap.

Now, we can't prevent all failures, but we can prevent the failures that cause the most damage, create the most problems and frustrate the user the most. If we want to design for detection, we can use some poka-yoke quality principles to do this. We evaluate the user process design and think of ways to quickly correct the problem if a problem occurs.

And that brings us to the end of this lesson. Here's what we covered today.

• We learned to describe controls as layers of protection from an undesired event using the swiss cheese model of accident causation.
• We can identify common sources of controls between design and manufacturing, information and systems, and
• we can contrast prevention and detection controls and what their effect on FMEA would be.

Thanks for joining me today and I'll see you in the next lesson.

[progressally_media media_id="2"]