.jpg)
Quality during Design
Quality during Design is a podcast for product designers, engineers, and anyone else who cares about creating high-quality products. In each episode, we explore the principles of quality design, from user-centered thinking to iterative development. We introduce frameworks to make better design decisions and reduce costly re-designs. We explore ways to co-work with cross-functional teams. We also talk to experts in the field about their experiences and insights.
Join host Dianna Deeney in using quality thinking throughout the design process to create products others love, for less. Whether you're a seasoned designer or just starting out, looking to improve your existing designs or start from scratch, Quality during Design is the podcast for you.
Quality during Design
Effective Team Meetings: From Chaos to Cohesion
Ready to transform your team meetings from chaotic to cohesive? Discover a method used by Six Sigma practitioners, continuous improvement teams, and design sprints to make your meetings more effective and efficient.
We’ll guide you through the phases of discovery, examination, and prioritization to streamline idea generation and ensure that every team member’s input is valued. You’ll learn techniques for individual brainstorming, anonymous idea sharing, and collective refinement, making your meetings not just productive but a crucial part of your design process.
But that's not all. We dive into the utilization of quality tools for superior team decision-making during design Failure Modes and Effects Analysis (FMEA). Explore how to categorize and evaluate potential failures, assign severity ratings, and use tools like tree diagrams and fishbone diagrams to organize complex discussions. By focusing on collaboration and consensus, you’ll be setting your team up for effective failure analysis. Join us to elevate your team meetings and turn them into a powerhouse of creativity and efficiency.
Visit the podcast blog for this episode.
Other episodes you might like:
Brainstorming within Design Sprints
Ways to Gather Ideas with a Team
Product Design with Brainstorming, with Emily Haidemenos (A Chat with Cross Functional Experts)
Give us a Rating & Review
**NEW COURSE**
FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling students now. Visit the course page for more information and to sign up today! Click Here
**FREE RESOURCES**
Quality during Design engineering and new product development is actionable. It's also a mindset. Subscribe for consistency, inspiration, and ideas at www.qualityduringdesign.com.
About me
Dianna Deeney helps product designers work with their cross-functional team to reduce concept design time and increase product success, using quality and reliability methods.
She consults with businesses to incorporate quality within their product development processes. She also coaches individuals in using Quality during Design for their projects.
She founded Quality during Design through her company Deeney Enterprises, LLC. Her vision is a world of products that are easy to use, dependable, and safe – possible by using Quality during Design engineering and product development.
Team meetings. They can be messy, complicated and a waste of time, and we don't want any of that with our team meetings, especially if we're in control and we're facilitating some of the conversations. Let's talk about some different options when we need to have meetings with a cross-functional team for design inputs. After this brief introduction, hello and welcome to Quality During Design, the place to use quality thinking to create products. Others love for less. I'm your host, diana Deeney. I'm a senior level quality professional and engineer with over 20 years of experience in manufacturing and design. I consult with businesses and coach individuals in how to apply quality during design to their processes. Listen in and then join us. Visit qualityduringdesigncom. Yay, team meetings.
Dianna:Most of us don't have that kind of reaction when we say, hey, let's have a team meeting and discuss this, although there are some places and organizations and departments and companies that really do this well. When it comes to product development, product design, if you're the designer, you need to get inputs, design inputs from your cross-functional team, and that also extends to some of the end users and customers that you might be working with. Sometimes it seems so difficult that we would rather just sit in our cubicle and do our own thing, or we develop something and then we just kind of share it with the cross-functional team as a review later and hope that they'll sign off on it in which case they may not hope that they'll sign off on it, in which case they may not but in both instances we're losing out on an important aspect of product design, which is the cross-functional teamwork. It really does have a big effect on the early homework of a new product. Sometimes we will try to work from whatever endpoint that we're targeting. For example, if we're doing risk analyses like a design FMEA, we may try to get the team involved in helping us populate this table. That doesn't even really work that well either. Those kind of tools and reports are really just that. It's an analysis of information that was gathered during a different process, a process where we're working through ideas and gathering information, with our team Filling in the end analysis or results in a table, as the process doesn't work.
Dianna:So what do successful facilitators do? For answers to that, I first turn to the quality professions. There are a lot of Six Sigma professionals that use quality tools in their teamwork. There are continuous improvement teams in companies that use quality tools to discuss and generate ideas. But I didn't want to just stick with quality. I wanted to find out what other people are doing. So I looked at concept and product development in product design and discovered Sprint not agile software sprints, but design sprints, where a team will come up with an idea from just concept idea to prototype testing with a user in five days. And there's also inside the box, where teams are given some restrictions on what it is. They can change about a design to come up with new ideas. And then, lastly, I was recommended to review articles from HBR, harvard Business Review. They have a lot of teamwork articles on their website related to project management and businesses.
Dianna:I found some commonalities among all of these things that we can adopt for ourselves and make things a little easier when we're having team meetings. Make it a more valuable meeting for our cross-functional team to be able to share their ideas and for us to understand them and to not waste anybody's time to do it to get the information that we need. Here are some of the commonalities of how people have been successful with team meetings. Yes, we want to have an agenda and we want to define the scope and we want to do all those normal meeting things. The differentiator with generating ideas with a team, are really two steps, maybe extending into three. One step is to discover ideas. What is it that they know and what are their ideas? The second step is to examine those ideas let's come to a common understanding and what is it about this idea we can use? And the third is to prioritize those ideas to be able to make decisions and move forward, take action with our meeting and what we've been discussing. Let me describe a little bit more about this discovery and examination phase, and then I'm going to give you some examples of what quality tools to use.
Dianna:When Discovery is the first activity of the meeting, besides agenda, reminding everybody about the scope and getting everybody on the same page, discovery is what comes next. This is really an individual idea creation. People are generating their ideas alone, by themselves, but they're together in the meeting space. As a facilitator, you are constricting their ideas by time and scope. So you are saying I want you to develop ideas about this particular thing and you have three, five, 10 minutes to write down your ideas in a way that you can later share with the group, in a way that you can later share with the group After ideas are shared with the group anonymously.
Dianna:The team examines what everybody came up with and they discuss to clarify the ideas that they're looking at. There's no debates and there's no presentations of ideas. Usually the facilitator would summarize the ideas for everybody in the room for better understanding and clarity. The clarity and understanding is important because then everybody prioritizes what it is that you're working on. What is the end result of all these ideas that you've generated? There is a key consideration that you need to take as a facilitator, or the team needs to take together between discovering ideas and examining ideas, and it's this ideas and examining ideas and it's this With what we've discovered, can we discuss these ideas in order to clarify them and better understand them? If the answer is yes, then let's go ahead and examine them. If it's no, if it's just a bunch of disorganized ideas and we wouldn't even know where to start to examine and clarify them, then we're not done in the discovery phase yet. We need to stay in the discovery phase to group, define and refine the ideas so that we can examine them together to be able to make a decision.
Dianna:A common example of this is you ask everybody to brain write. So brain write is a term used for the individual brainstorming, where you're writing your ideas on separate post-it notes so that you can share it later. When everybody puts their discoveries on the whiteboard or on the wall and you have a mess of post-it notes and lots of ideas, you're likely not going to be able to discuss or examine any of those things. So you need to stay in the discovery phase a little bit longer and instead organize and group those ideas into subheadings that make sense. What you're doing is you're creating an affinity diagram from your first brainwriting step. After you've created the affinity diagram with the team, which could be done quietly, it could be done with a little bit of discussion, but everybody is involved. After you've created your affinity diagram, then everybody sits back and the facilitator summarizes the ideas that the team came up with. By summarizing the ideas and having everything on display, the team is able to examine the ideas and the possibilities to be able to decide what to do next.
Dianna:Let's go through some example scenarios of where you're running a meeting and let's just say that you're trying to do an FMEA meeting. A lot of people have a hard time getting a cross-functional team to work through an FMEA without just filling in the table. So let's talk about that scenario just filling in the table. So let's talk about that scenario. Tackling the entire FMEA at once is difficult. So you are going to set up an agenda and align everybody on different pieces of the FMEA. For one team meeting, you may discuss failures, because you want to collect all the failures, potential failures associated with a certain function or certain five functions, whatever it is that you want to do. That would be one meeting where you would do a discovery and an evaluation phase. You then have another meeting which gets into effects and a severity rating and you could have a third meeting to evaluate the failure cause relationship and further meetings like this, breaking out the FMEA into pieces and getting the team to interact with the information and ideas together.
Dianna:Let's start with the first scenario, with our team meeting number one, where we have a list of functions for our requirements and we want to capture all the potential failure modes for that. With all of these meetings, we're going to make sure that the team is aligned on the scope of what we're looking at, that they're familiar with the requirements, that they have any schematics or models, all of that stuff that the team is trying to start at the same place with the scope of what it is we're talking about. Now we want to discover what ideas our team has. So we are going to ask them to brain write for three minutes what are failure modes of these two functions? And everybody is going to write on post-it notes one failure on each post-it note. And they're going to do this for three minutes and at the end of three minutes, everybody puts their ideas on the virtual whiteboard or the physical whiteboard.
Dianna:Now we're going to ask ourselves can we discuss to clarify these ideas? If there is a mess of post-it notes with no organization, chances are likely that we will say no, we cannot discuss to clarify these ideas. So let's take a next step with an affinity diagram, which is a common quality tool. After a brainstorming or brainwriting, we're going to ask our team within the failures that we discovered, are there similar failures that can be grouped together? Everyone will be involved in moving post-it notes around. If there is a post-it note that should be in two places, then somebody makes a copy of it and puts it up.
Dianna:After this is done, we will have some different failure types or subsystems to look at and we ask ourselves again can we discuss to clarify these ideas. Ch chances are. Yes, we can. But if we can't, then we go back and further refine, group and define these ideas. When we're ready to examine all the ideas that have come up, we want to discuss, to clarify them. Are some failures that we've identified really a lower level cause? Which failures are new, different or unknown?
Dianna:The end goal of this first meeting that we're having with our team is to identify the potential failures, so that's what we're going to prioritize at the end. At the end, we're going to have a list of potential failures associated with the functions that we started with. We may also have some potential causes lingering in the FMEA table or we may have decided to put those in a parking lot area to address when we get to that discussion. All right, so first scenario we got our first meeting done. The team's feeling great, they got warmed up to this whole discover and evaluate idea. So let's do it again. Let's do it with failure modes linking to its effects and a severity rating.
Dianna:We are going to align our team again with what it is we're doing. We're trying to define the effects of these particular failures and we eventually want to assign a severity rating to it. So we're going to define the scope for our team a little bit better. We're going to list out our failures separately on a whiteboard virtual or real or we could create a Google Doc that everybody has access to, with different tables. Each table has its own failure. Under each failure, we may have different columns that are associated with a severity rating scale we're going to be looking at later. In this example, we're working toward a design FMEA. Our severity rating scale for our design FMEA includes categories like performance and end user. So under each failure, we're going to have two columns one for performance and one for end user.
Dianna:Now we want to discover what it is our team knows and their ideas about the effects of each of these failures. So we ask them to brain write again, either on Post-it notes or in that shared Google Doc. They're going to look at each failure mode and think about what could be the effects to performance and what could be the effect to the end user, and they're going to write that down. Everybody's doing it individually, but yet together You're also going to limit the amount of time they have to do this and you sort of want to put some pressure on them to hurry up and get their ideas out. So keep it to three, five, 10 minutes if you want to, but limit the time for people to get their ideas out of their head and into some place that could be shared in a bit.
Dianna:Now, at the end of this, can we discuss to clarify ideas? We think maybe yes. So we start to examine these ideas. We go through each failure mode and we look at the different performance effects and the end user effects and we start to get stumbled and get hung up on some of the ideas.
Dianna:We're not really getting clarity and understanding with the group. We realize that there are too many effects that are contingent on each other. We've listed a bunch of effects but we've realized that, well, this effect could happen, but only if this happened first and that could happen only if this other thing could happen first. We can't really discuss these ideas for clarity and understanding unless we do a little bit more discovery. So we're going to kick our team back into the discovery phase and ask them to create a tree diagram. Within the effects listed for a failure is there a cause-effect relationship? You may break your meeting attendees into different groups or teams and then divvy up or assign different failure modes for the team to create these tree diagrams. So you are discovering what it is they know about. What happens first, and then you're going to examine this. You're going to examine not only the list of potential effects, but also the tree diagram on what is dependent on what.
Dianna:Again, when you're examining these things, you want to discuss, to clarify ideas and to come to a common understanding about these ideas. You're not debating and you're not presenting anything. You want to be able to discuss these things so everyone can make a decision about what to do to move forward. We're working on collaboration and we're working toward a consensus on a clear option, which is that place where everyone supports the decision, even if it wasn't their first choice. Now we've gotten to prioritize. Now we've gotten to prioritize, we can display our severity rating scale, one for each failure mode, and ask our team what is the most serious effect and what is its severity. Have everyone write on the severity rating table and put one check mark against what their choice would be. Now take a look at it again. Do you have congruency? Are people in agreement? In that case, you can move forward. Is there a lot of discrepancy in the answers that you're getting? That's a good indication that people have a different understanding of the effects that you just reviewed. You may need to go back and re-review and re-clarify.
Dianna:Finally, let's look at an example where we are trying to list out potential causes for a failure. Remember, we're going to get everybody aligned I think we're old hats at that at this point Now to discover we're going to ask our team what are potential causes of the failure modes of this function. We're going to give them two, three, five minutes, write down all the potential causes you can think of and share them. Then we ask ourselves can we discuss to clarify these ideas? If it's too messy and we can't, then we decide we're going to use a fishbone diagram to better organize our ideas. Everybody is moving things around, copying ideas, organizing things into a fishbone diagram, and now we ask ourselves can we discuss to clarify these ideas about our causes to a failure With a fishbone diagram? Chances are pretty good that, yes, we can do that. So we're going to examine what we've come up with together. What are the causes? What is new and different and unknown here? And the prioritize for this step is just listing the potential causes for the failure mode. So there you have it.
Dianna:There are some ways that you can use quality tools during productive team meetings to generate ideas and come to a consensus. We reviewed some scenarios where we're starting an FMEA with our team. We generally started out with brain writing just to get ideas out of people's heads and onto something else where other people can look at it, but then we used a lot of quality tools to be able to group and refine these ideas so that we can examine them for our actions. What is it that we want to decide to do? Our actions? What is it that we want to decide to do? We looked at an affinity diagram, a tree diagram, a fishbone and some voting, depending on the ideas that you're trying to develop with your team. Other quality tools you could use may be a two-by-two matrix in order to prioritize ideas. You can use multi-voting to identify ideas that are standout that everybody really wants to pursue.
Dianna:With other ideas that we evaluate, we may start with a quality tool or a model to help us define the scope before we start even doing any kind of brain writing. If we're evaluating a process, we may have a high-level process flow diagram and then we brain write ideas under that. If we're further along in our product development, we may use a P diagram as a way to define the scope of our discovery and examination. I found that teams that are trying to evaluate something that is not concrete a concept or an idea they do better with evaluating and making decisions about those things if they have some sort of model to reference. The model defines the scope of what it is that they're talking about and it is. Even though we're talking about intangible things, it kind of turns them into something tangible that they can modify, add to or tweak. It really helps the team to discover each other's ideas and it helps them to come together in the end to examine those ideas and make decisions.
Dianna:What's today's insight to action? Facilitators in different areas of business product management, quality and product design all use a similar method where they ask a group of people to discover what it is they know with each other and then examine those for possibilities for decisions. You can use this methodology with quality tools to help you with your cross-functional team. Members for design. Members for design. On the website qualityduringdesigncom. For this podcast episode, I will include some links to other resources and other episodes that you may find helpful. Please visit the website and, if you haven't yet signed up for the weekly newsletter. This has been a production of Dini Enterprises. Thanks for listening.
