Accendo Reliability

Your Reliability Engineering Professional Development Site

  • Home
  • About
    • Contributors
  • Reliability.fm
    • Speaking Of Reliability
    • Rooted in Reliability: The Plant Performance Podcast
    • Quality during Design
    • Critical Talks
    • Dare to Know
    • Maintenance Disrupted
    • Metal Conversations
    • The Leadership Connection
    • Practical Reliability Podcast
    • Reliability Matters
    • Reliability it Matters
    • Maintenance Mavericks Podcast
    • Women in Maintenance
    • Accendo Reliability Webinar Series
    • Asset Reliability @ Work
  • Articles
    • CRE Preparation Notes
    • on Leadership & Career
      • Advanced Engineering Culture
      • Engineering Leadership
      • Managing in the 2000s
      • Product Development and Process Improvement
    • on Maintenance Reliability
      • Aasan Asset Management
      • CMMS and Reliability
      • Conscious Asset
      • EAM & CMMS
      • Everyday RCM
      • History of Maintenance Management
      • Life Cycle Asset Management
      • Maintenance and Reliability
      • Maintenance Management
      • Plant Maintenance
      • Process Plant Reliability Engineering
      • ReliabilityXperience
      • RCM Blitz®
      • Rob’s Reliability Project
      • The Intelligent Transformer Blog
    • on Product Reliability
      • Accelerated Reliability
      • Achieving the Benefits of Reliability
      • Apex Ridge
      • Metals Engineering and Product Reliability
      • Musings on Reliability and Maintenance Topics
      • Product Validation
      • Reliability Engineering Insights
      • Reliability in Emerging Technology
    • on Risk & Safety
      • CERM® Risk Insights
      • Equipment Risk and Reliability in Downhole Applications
      • Operational Risk Process Safety
    • on Systems Thinking
      • Communicating with FINESSE
      • The RCA
    • on Tools & Techniques
      • Big Data & Analytics
      • Experimental Design for NPD
      • Innovative Thinking in Reliability and Durability
      • Inside and Beyond HALT
      • Inside FMEA
      • Integral Concepts
      • Learning from Failures
      • Progress in Field Reliability?
      • Reliability Engineering Using Python
      • Reliability Reflections
      • Testing 1 2 3
      • The Manufacturing Academy
  • eBooks
  • Resources
    • Accendo Authors
    • FMEA Resources
    • Feed Forward Publications
    • Openings
    • Books
    • Webinars
    • Journals
    • Higher Education
    • Podcasts
  • Courses
    • 14 Ways to Acquire Reliability Engineering Knowledge
    • Reliability Analysis Methods online course
    • Measurement System Assessment
    • SPC-Process Capability Course
    • Design of Experiments
    • Foundations of RCM online course
    • Quality during Design Journey
    • Reliability Engineering Statistics
    • Quality Engineering Statistics
    • An Introduction to Reliability Engineering
    • An Introduction to Quality Engineering
    • Process Capability Analysis course
    • Root Cause Analysis and the 8D Corrective Action Process course
    • Return on Investment online course
    • CRE Preparation Online Course
    • Quondam Courses
  • Webinars
    • Upcoming Live Events
  • Calendar
    • Call for Papers Listing
    • Upcoming Webinars
    • Webinar Calendar
  • Login
    • Member Home

by Dianna Deeney Leave a Comment

QDD 098 Challenges Getting Team Input in Concept Development

Challenges Getting Team Input in Concept Development

This is the wrap-up, final episode of our series – the 7th episode in our series about generating ideas with a team toward action.

Since the start of 2023, we focused on a few quality tools and methods to both generate ideas and then choose which idea to pursue.

We’ve talked about:

  • Changing our scope to a closed world, to failures or questions, or design heuristics
  • Brainstorming within a problem-solving framework
  • Grouping many ideas and then further refining them
  • Prioritizing many ideas by comparing them to 2 criteria or by using team voting
  • Choosing an idea by using paired comparisons or a structured decision-making solution like DMRCS
  • Giving individuals a process to create a full design concept

We also interviewed an expert in brainstorming and learned the importance of planning for teamwork, including choosing our team.

What have we learned through the last few weeks? Let’s highlight take-aways and next steps.

 

View the Episode Transcript

 


Reminders when evaluating ideas with a team

We need to Mind our Mindset

Recognize that it’s difficult to evaluate ideas from a brainstorming activity into actions for next steps.

We’re handling ideas systematically with our team to get the maximum benefit from our creative phase.

We want to control our itch for a quick decision on the best idea – to do so would ruin our efforts toward creativity and innovative ideas.

We aren’t looking to eliminate ideas. We’re looking to develop them to the best solution we think there could be.

 

Yes, we approach activities with the  spirit of developing creative ideas. We say things like, “That’s a great idea, what can we do to make it work?” or “What is it about this idea we can use?”

No, we don’t want to just eliminate ideas. We try to avoid first jumping to say things like, “That’s a great idea, but here’s why it won’t work.”

Discussing Ideas

We’d like consensus on a clear option, which is that place where everyone supports the decision, even if it wasn’t their first choice.

We discuss to clarify ideas. If it’s not clear, then let’s make sure that everyone understands the information about some ideas.

We don’t need to pressure anyone to change votes, but we do need to ensure we’re all voting on the same idea, or the same understanding of an idea.


7 Steps for Teamwork Design Engineers can use for Concept Development

1. Frame our Challenge / Write the Problem Statement: Have the goal in mind, propose criteria for judging, and collect information or plan to collect it as part of the process.

2. Choose and invite our team: 3-7 people, mix experienced & non-experienced, involve cross-functional people, and involve Deciders!

3. Select a method for brainstorming: Provide a process that is bound by time, create space to recharge (schedule time, physical breaks), and collect materials needed.

  • If it’s simple, consider brainwriting on post-its. (Ep. 1 and 2)
  • If it needs a big idea, consider the 4-step sketch. (Ep. 6)
  • If it’s a large or critical project, consider DMRCS. (Ep. 5)
  • If a new design concept is needed, consider a Design Sprint. (Ep. 6)
  • Consider a different prompt (problem, failure, question, closed-world, design heuristics – Ep. 1)

4. Generate ideas: The endpoint or goal is always displayed. Keep ideas anonymous and keep the activity individual and silent but doing it together (e.g. brainwriting or sketches).

5. Group and prioritize ideas: Display all ideas at once and do activities silently (e.g. no talking or clarifying during sorting or voting). Discuss to clarify ideas (no debates or presentations).

  • If ideas need to be grouped, use an affinity diagram (Ep. 3)
  • If ideas need to be further explored, use a fishbone or tree diagram (Ep. 3)

6. Define and refine: Vote for stand-out ideas or prioritize ideas.

  • If ideas can be evaluated against 2 criteria, use a 2×2 chart (Ep. 2 and 4)
  • If stand-out ideas are needed, use Multivoting (Ep. 4 and 6)
  • If ideas need to be prioritized, use paired comparison (Ep. 5)

7. Choose actions and assign owners: Choose an option or choose two options with pros/cons, and don’t let the Deciders cede their authority!


Previous episodes in our series about generating ideas with our team toward action:

Episode 1: Ways to Gather Ideas with a Team

Episode 2: Product Design with Brainstorming, with Emily Haidemenos (A Chat with Cross Functional Experts)

Episode 3: After the ‘Storm: Group and Explore Ideas

Episode 4: After the ‘Storm: Pareto Voting and Screening Methods

Episode 5: After the ‘Storm: Compare and Prioritize Ideas

Episode 6: Brainstorming within Design Sprints


Episode Transcript

Hi, it’s Dianna. How can design engineers use the creativity of the cross-functional team to help develop a design concept? If we jump into engineering designs and creating prototypes, we’ve already missed out on an opportunity to develop something creative and innovative with our team. And let’s be honest, that idea is likely better than anything we could have designed on our own. Design engineers can and should facilitate sessions with their team, but how do we do that? How do we get our cross-functional teams information about a new concept design, inviting them to a happy hour at Applebee’s? We’ll get people to show up and they might share some ideas about some new concept and new design ideas, but we’re really not going to get the output that we are really looking for in order to engineer designs. Instead, we can use some frameworks. What we’ve been exploring in the previous six episodes of this podcast is using quality tools to further explore ideas, brainstorming, grouping, reducing, combining, and deciding which idea we should move forward with. So let’s pull it all together. Let’s pull together everything we’ve been talking about in the last six episodes, and I’ll have steps that you can take as a design engineer, and I’ll also give you a reminder of how what we’ve been covering fits into the big picture. You won’t want to miss this episode because this is where it all happens and where you can step out from here.

Hello and welcome to Quality During Design, the place to use quality thinking to create products, others love for less. Each week we talk about ways to use quality during design, engineering, and product development. My name is Dianna Deeney. I’m a senior level quality professional and engineer with over 20 years of experience in manufacturing and design. Listen in and then join us. Visit quality during design.com.

Do you know what 12 things you should have before a design concept makes it to the engineering drawing board where your setting specifications. I’ve got a free checklist for you and you can do some assessments of your own. Where do you stack up with the checklist? You can log into a learning portal to access the checklist and an introduction to more information about how to get those 12 things. To get this free information, just sign up@qualityduringdesign.com. On the homepage, there’s a link in the middle of the page. Just click it and say, I want it

To wrap up this short series about idea generation, we looked at some best practices for brainstorming and spoke with an expert. We talked about ways to further explore ideas, and we looked at ways to explore the ideas with a team. Because we do need to recognize that these activities are structured ways to capture creativity of our team. We need structured ways to do that because it’s hard getting into the minds of people from different backgrounds, different areas of the organizations that are bringing with them different experiences. We work with very creative people and it’s difficult teasing out design ideas and design concepts from them, and especially as a team. And then when we do get a bunch of ideas and we start deciding which action to take, that’s a difficult task. So we want to handle ideas systematically so that we can get the maximum benefit from our creative phase, which is really what concept designs are all about.

We have a whole quality profession that promotes use of team tools, the very ones we discussed, quality managers, quality engineers, six Sigma practitioners and other quality professionals use them.

We heard from Emily, who is an engineering project manager. She uses brainstorming during new product development. Her team was stuck in a problem. She planned for a structured brainstorming session, generated lots of ideas. They implemented a handful and they were working on implementing the last one. They were able to solve this tricky problem. Her team was happy and management was happy.

We revisited a structured decision method, DMRCS, developed by statisticians working in STEM fields. It’s a method for a team to work through complicated problems and analyzed decisions with statistical plots.

We also talked a bit about the book “Sprint”. The authors of “Sprint” are investors that help teams innovate new ideas. They use a five day design sprint to efficiently move from defining a target, collecting information, coming up with ideas, deciding what to do, prototyping and testing. The whole goal is to fast track learning about a new product, getting information about the product and user interface, the surface in learning what works and what doesn’t within their process. They use many of the same team tools that we’ve been talking about.

Our ultimate question is how can design engineers use the creativity of the cross-functional team to help develop a design concept? And the answer is through using these structured teamwork approaches.

What are the basic steps that we need to take when we want to do this with our teams? Let me go over these seven steps and then we’ll revisit each one and I’ll remind you the topics that we covered that correlate with that step. Step one is to frame our challenge and write our problem statement. Step two is to choose and invite our team. Step three is select a method for brainstorming. Step four is to generate ideas. Step five group and prioritize ideas. Step six, define and refine. And step seven, choose actions and assign owners.

With step one, frame our challenge and write the problem statement: We want to have our goal in mind. What is it that we want to accomplish? What are we having problems with? With this goal, we want to start thinking about the criteria that we might want to do for judging ideas and we need to collect some information, background information, information about what’s going on now. We either plan to collect it before the meeting or we build that in as part of the process that we’re going to take with our team.

Step two, choose and invite our team. We want to look for three to seven people. We want to mix experienced people and non-experienced people together. We want to involve cross-functional people, especially if we are doing design concepts and especially we want to involve the deciders. If there is a CEO, a vice president, a project manager, who is the ultimate decider on what decision or what idea gets promoted, what the team is going to work on, we need to involve them in the process.

Step three, select a method for brainstorming. We’re doing this as part of the preparation for our meeting. We want to provide a process that’s bound by time, so it gives people time limits on certain activities that they’re doing. It keeps the meetings efficient and a deadline puts a little bit of pressure onto the idea creation process and actually helps a lot of us out. We also want to plan to create space to recharge so we can schedule time, we can schedule activities on different days, we can schedule breaks, and the third thing we want to do is just to collect the materials that are needed.

Now with selecting a method for brainstorming, this is a step that I used to get hung up on. What method of brainstorming are we going to do for this particular problem or situation that we’re having? In this mini series, we sort of took a deep dive on a lot of these methods, so let’s go over what those methods are and when you might want to use them.

If it’s a singular problem or it’s rather simple, then we can consider brain writing on post-it notes and we cover that in episodes one and two of this series.

If it needs a big idea, we can consider the four step sketch that we reviewed in episode six.

If it’s a large or critical project, we can consider DMRCS, which we revisited in episode five.

If a new design concept is needed, we can consider a design sprint, which is a five day idea creation, prototype, and test process, which we covered in episode six.

And finally, we may want to consider different prompts. We can look at the problem or a particular failure. We can switch that, turn it on its head. Instead of looking for solutions. Now we’re looking to create questions. We can use systematic inventive thinking, which uses the closed world thinking, and we can use design heuristics. These are all different prompts that we discussed in episode one.

The fourth step is to generate ideas. Now, the endpoint or goal is always displayed and any ideas that are generated, we want to keep them anonymous. The creators aren’t going to take credit for their ideas in these activities. We also keep these activities individual and silent, but we’re doing it together. Emily demonstrated this to me in her workshop that she hosted. She used brain writing where we were divided into groups, provided a problem, and then asked to come up with some ideas for solutions. We each quietly sat and generated our own ideas and then we moved on from there. This is also something that was heavily emphasized in the design sprint book and in other articles from Harvard Business Review and Miro. Individual idea creation with a time bound, but yet doing it together in a team combats a lot of the problems that many of us may have experienced with brainstorming in the past.

Step five is to group and prioritize ideas. Now, we’re going to display all ideas at once and do these sorting and prioritizing activities silently, meaning we’re not going to talk about the ideas and we’re not going to make clarifying statements during sorting or voting. If we do discuss, its after a voting or prioritizing and it’s meant to clarify ideas. This isn’t a time for debates or presentations. We really want to be efficient with our brainstorming and concept evaluation. A couple of quality tool ideas for this step is if ideas need to be grouped, we can use an affinity diagram and if ideas need to be further explored, we can use a fishbone or a tree diagram. We covered both of these methods in episode three.

The sixth step in design engineers getting design concept ideas from from their cross-functional team is to define and refine the ideas that we’ve come up with here. We want to vote for standout ideas or prioritize them. The bulk of these activities are going to be done silently and individually, and then we come together at the end and take a look at the results. We’re going to observe where people voted, and if there is anything standing out to us, we can discuss it for clarity. We want to make sure that everybody is voting on the same idea or the same understanding of an idea. Here are some general tools that we can use in this step.

If ideas can be evaluated against two criteria, we can use a two by two chart. We talked about a two by two chart in episode two and four.

If standout ideas are needed, we could use multivoting. We talked about multivoting in both episodes four and six.

If ideas need to be prioritized either against each other or against criteria and each other, we can use paired comparison and we cover that in episode five.

Finally, in step seven, we want to choose actions and assign owners. The whole reason we’re meeting is to come up with ideas and then make a decision so we can choose an option or choose two options with pros and cons. An important part about this step is the deciders. They have the authority and the responsibility to make the final decision. We don’t want to let the deciders cede their authority during the teamwork by saying, “Oh, majority rules. I’m going to go with the team,” because it’s been experienced by me and many others later that that decider can change their mind to their preferred choice later, anyway. Their job is to decide, so let them decide with the information that the team has given them.

Some extra tips for design engineers for running these kinds of meetings.

Having a facilitator might be helpful if there’s big ideas being shared. A scribe could be useful too. Enlist the help if you feel like you need it to keep the meeting running efficiently and smoothly when scheduling.

I mentioned putting time bounds around certain activities of this brainstorming process that you choose. It’s been my experience, others have given me input, and from everything that I’ve been reading, the general timeframe is about 5, 10, 15 minutes. An exception is some of the big ideas that need to be sketched out or fully formed. That might take a little longer, maybe 30 minutes to an hour. Another thing that we can do is once we’ve gotten to a certain step, say we’ve generated a bunch of ideas and we know that they need to be grouped, we can give the the group 10 minutes to sort the ideas and then move on. There’s also some instances where it makes sense to leave it posted on the wall for a day or two, and as people come and think about it, they can move the post-its around. It really depends on how efficient you want your process and which way would work best may also be dictated on the topic that you’re working on and its scope.

We need to remember the mindset that we should have when conducting these meetings and participating in them. What can we do to make this idea work? Or what is it about this idea we can use? We want to avoid picking apart ideas.

Along with that, we’ll keep our teams’ “yes’s” as the choice that means the most desirable. We can use this when we are choosing our criteria or setting the weights that we’re using during a paired comparison. The yeses mean the most desirable. It will keep us consistent, and your team will thank you.

In the last six weeks. We’ve covered a lot of material in a pretty short amount of time, considering the length of these podcasts. I hope that I’ve been able to take away some of the mystery out of conducting systematic reviews and brainstorming to develop a design concept, and I hope that I gave you some frameworks that you can use with your cross-functional team to help develop those ideas, those early design concepts. In this short series. We tried to break it down as much as we could and still give you enough of the information that you can make the activity worthwhile for both you and your team.

Is it important to learn this kind of stuff? I think so. These are proven methods to work creatively with a team.

Is it going to take practice for us to get really good at it? I think that’s also the case. Through this series, we’ve pulled from other experts that have had a lot of practice and distill their advice into something that we might be able to use for new product development.

Now, I want to invite you, if you are a product design engineer or you’re managing product design engineers and you would like this to be something that your team can practice, or if you have any questions about any particular idea that we’ve been discussing, please reach out to me. Let’s start a dialogue where I may be able to help you more individually.

I appreciate you participating in this mini-series, and I hope it’s yet another step toward using Quality during Design.

If you like this topic or the content in this episode, there’s much more on our website, including information about how to join our signature coaching program, the Quality during Design Journey. Consistency is important, so subscribe to the weekly newsletter. This has been a production of Deeney Enterprises. Thanks for listening.

Filed Under: Quality during Design

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Quality during Design podcast logo

Tips for using quality tools and methods to help you design products others love, for less.


by Dianna Deeney
Quality during Design,
Hosted on Buzzsprout.com
Subscribe and enjoy every episode
Google
Apple
Spotify

Recent Episodes

QDD 102 Get Design Inputs with Flowcharts

QDD 101 Quality Tools are Legos of Development (and Their 7 Uses)

QDD 100 Lessons Learned from Coffee Pod Stories

QDD 099 Crucial Conversations in Engineering, with Shere Tuckey (A Chat with Cross-Functional Experts)

QDD 098 Challenges Getting Team Input in Concept Development

QDD 097 Brainstorming within Design Sprints

QDD 096 After the ‘Storm: Compare and Prioritize Ideas

QDD 095 After the ‘Storm: Pareto Voting and Screening Methods

QDD 094 After the ‘Storm: Group and Explore Ideas

QDD 093 Product Design with Brainstorming, with Emily Haidemenos (A Chat with Cross Functional Experts)

QDD 092 Ways to Gather Ideas with a Team

QDD 091 The Spirits of Technical Writing Past, Present, and Future

QDD 090 The Gifts Others Bring

QDD 089 Next Steps after Surprising Test Results

QDD 088 Choose Reliability Goals for Modules

QDD 087 Start a System Architecture Diagram Early

QDD 086 Why Yield Quality in the Front-End of Product Development

QDD 085 Book Cast

QDD 084 Engineering in the Color Economy

QDD 083 Getting to Great Designs

QDD 082 Get Clarity on Goals with a Continuum

QDD 081 Variable Relationships: Correlation and Causation

QDD 080 Use Meetings to Add Productivity

QDD 079 Ways to Partner with Test Engineers

QDD 078 What do We do with FMEA Early in Design Concept?

QDD 077 A Severity Scale based on Quality Dimensions

QDD 076 Use Force Field Analysis to Understand Nuances

QDD 075 Getting Use Information without a Prototype

QDD 074 Finite Element Analysis (FEA) Supplements Test

QDD 073 2 Lessons about Remote Work for Design Engineers

QDD 072 Always Plot the Data

QDD 071 Supplier Control Plans and Design Specs

QDD 070 Use FMEA to Design for In-Process Testing

QDD 069 Use FMEA to Choose Critical Design Features

QDD 068 Get Unstuck: Expand and Contract Our Problem

QDD 067 Get Unstuck: Reframe our Problem

QDD 066 5 Options to Manage Risks during Product Engineering

QDD 065 Prioritizing Technical Requirements with a House of Quality

QDD 064 Gemba for Product Design Engineering

QDD 063 Product Design from a Data Professional Viewpoint, with Gabor Szabo (A Chat with Cross Functional Experts)

QDD 062 How Does Reliability Engineering Affect (Not Just Assess) Design?

QDD 061 How to use FMEA for Complaint Investigation

QDD 060 3 Tips for Planning Design Reviews

QDD 059 Product Design from a Marketing Viewpoint, with Laura Krick (A Chat with Cross Functional Experts)

QDD 058 UFMEA vs. DFMEA

QDD 057 Design Input & Specs vs. Test & Measure Capability

QDD 056 ALT vs. HALT

QDD 055 Quality as a Strategic Asset vs. Quality as a Control

QDD 054 Design Specs vs. Process Control, Capability, and SPC

QDD 053 Internal Customers vs. External Customers

QDD 052 Discrete Data vs. Continuous Data

QDD 051 Prevention Controls vs. Detection Controls

QDD 050 Try this Method to Help with Complex Decisions (DMRCS)

QDD 049 Overlapping Ideas: Quality, Reliability, and Safety

QDD 048 Using SIPOC to Get Started

QDD 047 Risk Barriers as Swiss Cheese?

QDD 046 Environmental Stress Testing for Robust Designs

QDD 045 Choosing a Confidence Level for Test using FMEA

QDD 044 Getting Started with FMEA – It All Begins with a Plan

QDD 043 How can 8D help Solve my Recurring Problem?

QDD 042 Mistake-Proofing – The Poka-Yoke of Usability

QDD 041 Getting Comfortable with using Reliability Results

QDD 040 How to Self-Advocate for More Customer Face Time (and why it’s important)

QDD 039 Choosing Quality Tools (Mind Map vs. Flowchart vs. Spaghetti Diagram)

QDD 038 The DFE Part of DFX (Design For Environment and eXcellence)

QDD 037 Results-Driven Decisions, Faster: Accelerated Stress Testing as a Reliability Life Test

QDD 036 When to use DOE (Design of Experiments)?

QDD 035 Design for User Tasks using an Urgent/Important Matrix

QDD 034 Statistical vs. Practical Significance

QDD 033 How Many Do We Need To Test?

QDD 032 Life Cycle Costing for Product Design Choices

QDD 031 5 Aspects of Good Reliability Goals and Requirements

QDD 030 Using Failure Rate Functions to Drive Early Design Decisions

QDD 029 Types of Design Analyses possible with User Process Flowcharts

QDD 028 Design Tolerances Based on Economics (Using the Taguchi Loss Function)

QDD 027 How Many Controls do we Need to Reduce Risk?

QDD 026 Solving Symptoms Instead of Causes?

QDD 025 Do you have SMART ACORN objectives?

QDD 024 Why Look to Standards

QDD 023 Getting the Voice of the Customer

QDD 022 The Way We Test Matters

QDD 021 Designing Specs for QA

QDD 020 Every Failure is a Gift

QDD 019 Understanding the Purposes behind Kaizen

QDD 018 Fishbone Diagram: A Supertool to Understand Problems, Potential Solutions, and Goals

QDD 017 What is ‘Production Equivalent’ and Why Does it Matter?

QDD 016 About Visual Quality Standards

QDD 015 Using the Pareto Principle and Avoiding Common Pitfalls

QDD 014 The Who’s Who of your Quality Team

QDD 013 When it’s Not Normal: How to Choose from a Library of Distributions

QDD 012 What are TQM, QFD, Six Sigma, and Lean?

QDD 011 The Designer’s Important Influence on Monitoring After Launch

QDD 010 How to Handle Competing Failure Modes

QDD 009 About Using Slide Decks for Technical Design Reviews

QDD 008 Remaking Risk-Based Decisions: Allowing Ourselves to Change our Minds.

QDD 007 Need to innovate? Stop brainstorming and try a systematic approach.

QDD 006 HALT! Watch out for that weakest link

QDD 005 The Designer’s Risk Analysis affects Business, Projects, and Suppliers

QDD 004 A big failure and too many causes? Try this analysis.

QDD 003 Why Your Design Inputs Need to Include Quality & Reliability

QDD 002 My product works. Why don’t they want it?

QDD 001 How to Choose the Right Improvement Model

© 2023 FMS Reliability · Privacy Policy · Terms of Service · Cookies Policy

This site uses cookies to give you a better experience, analyze site traffic, and gain insight to products or offers that may interest you. By continuing, you consent to the use of cookies. Learn how we use cookies, how they work, and how to set your browser preferences by reading our Cookies Policy.