Your Reliability Engineering Professional Development Site
When we’ve identified a risk to our design or user process – and that risk can pose a potential harm – how many controls do we need to add?
We discuss prevention vs. detection controls, ALARP, as low as possible, and some scenarios where we could (and maybe couldn’t) justify a risk as acceptable without adding additional controls.
How we describe and approach the issues we need to solve can affect how we react to them. We know we’re supposed to be solving for root causes. But are we, instead, really just addressing symptoms? Are we celebrating the quick fix and then moving on without addressing the root of our issue?
“If you define the problem correctly, you almost have the solution.” – Steve Jobs
Recognize the common mishaps of us solving symptoms instead of really getting to the causes. And, clearly describe our problem in two parts (statement and description of facts) to be confident that we’re moving toward solving the causes.
Objectives are goalposts of what it is we’re trying to accomplish. Though they’re only a part of planning a project, if we don’t have well-defined and clear objectives, it could lead to us not having the stellar project results we want. Our objective should be a SMART ACORN. We review these two, complementing acronyms as ways to check that we’re setting up our project for success.
Standards are everywhere, and lots of organizations are sourcing and creating them. The U.S. Federal Trade Commission held a workshop 2019 that recently made the news, again, in July 2021. It was called “Nixing the Fix: a Workshop on Repair Restrictions”. Here’s what it’s about: manufacturers are not creating products with standard parts, or their design is created so its difficult for consumers to repair.
Are standards part of the answer? How can we proactively use them for design? Why should we?
Before we can link customer needs to design, production, and service of our products, we need to listen to and understand the voice of the customer. We review 6 common VOC collection strategies, and talk about their pros and cons. We also discuss an affinity diagram process, which may help our team organize all of the data to get to customer needs.
We can look at test methods like a product in and of itself. Because tests also have requirements and need to produce usable results, we validate against those requirements. Validating our test method also ensures that they are precise and accurate.
We talk about things to consider when looking at product tests: tying test methods to the product’s use environment, standards, and cumulative effects of testing.
Creating specs for suppliers and producers is generally at the forefront of our thoughts about the activity. But, it’s also important to design for our QA friends, too, for inspection.
We talk about what acceptance sampling is all about. We also step through a thought process for identifying and creating design features for inspection using FMEA.
When designs fail we can take on damaging mindsets while we’re deciding our next steps, and this can lead us to bad decisions. We explore this and give some examples of pitfalls. We also talk about what to do within the design-realm to prepare for and combat those mindsets. Finally, I share my mantra when designing activities get tough with failures.
In the quality world, kaizen is a tool for continuous improvement under the umbrella of a Lean philosophy. The quality-tool kaizen is just one layer of a larger, overarching idea that we benefit from small, incremental improvements made consistently.
Kaizen as a tool involves all employees of the company toward continuous improvement. The way kaizen events are done helps to promote the continuous improvement philosophy throughout the business through its effect on culture, time, proof, and teamwork. We talk more about how this all fits together in the podcast.
A Fishbone Diagram is named for its looks because it resembles the bones of a fish drawn on paper. Its less creative names are Cause-and-Effect Diagram and Ishikawa Diagram. It’s popularly known to help with root cause analysis. But, we can also use it to help with goals and to evaluate a potential solution.
Why is it a Supertool? Just creating its headings helps us to better define our question. Writing it out as a graphical organizer helps organize jumbled thoughts. And, when paired with a 5W2H approach and the 5-whys, it can help us dig to the root causes.
I’ve included some abbreviated examples of fishbone diagrams; click the thumbnail for a larger version (notice that my root causes follow the 5-whys). And, listen to the podcast (or read the transcript) to learn more about Fishbones and their construction and uses.
We’re in the middle of our design process and we’re getting some of the first parts in hand, from prototyping or benchtops or our manufacturing cell. Let’s test them and finish our verification testing! Maybe we shouldn’t.
We talk about the concept of production equivalent: what it means and when it’s important to consider.
“A picture is worth a thousand words” is an old saying, and it holds true! Visual standards, visual aids, and quality standards are a great tool, especially in design when communicating the limits of acceptability. This episode explores areas to capture this type of information and how it can be used not just for Quality Assurance and Production, but also for design verification protocols, FMEA, root cause analysis, and future field defect investigations (to name a few).
The likeness of the Pareto Principle can be compared to Murphy’s Law and the Peter Principle: it’s a curious phenomenon. So, how did it make its way into quality? If using it to make decisions, there are some common pitfalls which can lead to delays in fixing a problem or even misdirect our efforts. So, what is it, and how can we use it for design?
Get to know the Pareto Chart. If it’s built and applied properly, it can help us prioritize: root cause analysis, new design features based on user input, or to help us tackle a problem that just seems too big to even start (just to name a few examples).
We review the Pareto Principle, what a Pareto Chart is, what we need to consider when building one, and how we need to be careful when interpreting its results.
I’m a fan of cross-functional teams. My main reason is that the different perspectives that each person brings from their respective areas of the business helps create a more complete vision of product and performance risk. Part of quality (and design!) means assessing and managing risk, and I’ve seen time and again the power of bringing people together: better understanding, greater alignment, and improved designs (to name just a few).
Part of being an effective team member is knowing what the other teammates are responsible for doing. It’s important because we need to know who to ask or interface with at certain points in our design process.
This podcast is about Who’s Who of your Quality Team. A Quality Engineer or Reliability Engineer may be part of a cross-functional team for a project. A Supplier Quality Professional, Calibration Technician, Quality Technician, and Quality Inspector may not be, but they are performing functions and duties that have an effect on the success of a product design. The podcast gets into who does what in these Quality roles, and why designers should involve them during the design process.
When trying to fit a probability distribution to quantitative results, sometimes the normal probability doesn’t fit. Minitab has a wealth of distributions to pick from. Do you just pick whichever one Minitab tells you fits the best? Maybe not. Just because the distribution fits your data doesn’t mean it’s a good one to use. We review my top 3 distributions for product testing and some other ones that come up but may not be appropriate to use.
We’ll also share what you need to think about when picking a distribution:
