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 060 3 Tips for Planning Design Reviews

3 Tips for Planning Design Reviews

Many presentation books and guides seem to focus on presentations that we see at conferences, for sales pitches, or for executive meetings about business topics.

They don’t seem applicable to the technical design reviews that engineers host.

But they do relate.

We talk about just 3 ways that we can change how we can plan technical design reviews, using some of the principles of presentations.

 

 

View the Episode Transcript

Three things to consider when planning for your design reviews:

  1. It’s about the audience, not us (the engineer).
  2. Focus on recommendations instead of the methodology.
  3. Rely on the technical report for technical information. Use presentation slides to share simple, big diagrams to help the team understand a concept. Or maybe show a photograph of a product feature you’re talking about.

What is one thing you do during technical design reviews that you think would benefit other engineers? Share by commenting, below.

Citations:

Check out this other QDD episode: About Using Slide Decks for Technical Design Reviews

Books I mentioned:

Data Story by Nancy Duarte

Beyond Bullet Points by Cliff Atkinson

Helpful website for formatting reports into digital documents for ‘digestion’ (not presentation):

Slidedocs®: Spread Ideas With Visual Documents (duarte.com)

 

3 fingers photo created by freepik – www.freepik.com

Episode Transcript

As a product design engineer, you’re likely going to have to present at some point where you may have to present every day, if you really think about it, you’re presenting technical information to people to make decisions or to understand something so they can help you with the design. Or maybe even with your customers so they can give you feedback on your concept. What are some things you might be able to do to improve the way you present your information? Listen in after this brief introduction.

Hello, and welcome to Quality during Design the place to use quality thinking to create products others love for less. My name is Dianna. I’m a senior level quality professional and engineer with over 20 years of experience in manufacturing and design. Listen in and then join the conversation at qualityduringdesign.com.

Today, I’m coming off of a four month coaching experience about public speaking and developing speeches and the different kind of speeches, which is making me think about presentations in general. And when I think about product development, engineers and design engineers, we have to do a lot of presentations. Now, the speeches that we need to do in work, we may not even really think of them as speeches or formal presentations, but aren’t, they now they’re not the same as a keynote speech, which is the kind of speech where you would go to a conference and someone’s on a stage and everybody that’s attending the conference is watching them. Those are inspirational and are trying to make a bigger impact with your ideas and how you do things. And we’re usually not trying to convince somebody of anything. Uh, you’re not trying to sell somebody something or convince them to do something different.

Our engineering presentations are usually about showing the facts, talking with people about it, and then coming to a consensus at the end of what to do next, or what decision to make, what part to choose. We don’t necessarily wanna think of our engineering presentations as salesy, because that doesn’t seem true to the scientific method and the principles that we adopt for design. But I can tell you that from doing design reviews, hosting them participating in lots of design reviews and also presenting at conferences and hosting workshops. There is an overlap between the technical design reviews or the design reviews and those keynote speeches. Some of the books that are popular and out there about presentations and using PowerPoint and how information is transmitted to people. Well, they’re focused on those keynote presentation styles or those influential and sales and marketing type of presentations. The two books I’m thinking about most are data story from Nancy dote and beyond bullet points by cliff Atkinson, we can take these lessons that these authors are giving us about speaker and audience and presentation and delivery and apply it to technical design review.

Let’s do just that today. Let’s take these general presentation principles and figure out how we can apply it to a technical design review for our purposes. And that it makes us feel good about transferring the information that we want. I’m going to give you three guidelines.

TIP ONE: It’s not about you. It’s about them.

So let’s start with number one. First of all, we need to recognize that a technical design review is not for us. It’s for the attendees to review data, assess choices and our recommendations and make a decision based on data. We need to make our technical design reviews about the audience. First step toward that is knowing your audience. There might be standard operating procedures at your business that dictate which functional groups need to be part of the technical design review or design reviews. In general, you may need to have a representative from marketing, from manufacturing, from field or commercial operations and an independent reviewer to provide feedback on your recommendations.

Once you know your audience, you need to allow them to prepare, to help them to prepare for the meeting at least 24 hours in advance, give them a technical report and an agenda for the meeting. We definitely don’t want to water down or dumb down our reports for anybody on our team. You know, as engineers, we do get hung up in all the technical stuff, but we also have a responsibility to make it accessible to those that need to make a decision. And that includes giving them and allowing them to see our full technical report and synopsis, give them the information and let them study it and develop questions about it. So they can prepare for the design review meeting. The rest of the people on your team have a different viewpoint, a different way of looking at things. And that’s the beauty of a cross-functional team. These design reviews are a way for you to communicate what, you know, bring them up to speed so that you can all make a decision together.

To summarize trick number one for awesome design reviews: It’s not about you. It’s about them.

TIP TWO: It’s not about the methodology. It’s about the recommendations and being able to choose between the different recommendations to make a decision.

Trick number two: I’ll tell you another thing that it’s not about is it’s not about the methodology in design reviews. We tend to rehash the journey that we took to get to the data. Now, for posterity sake and for thoroughness, we do want to create a technical report, something with a executive summary and an introduction and background, a type of document that would allow somebody else five years from now to recreate the same results that we got. Presenting this information to someone else, or another group of people, is not to place to start from the top of the technical report and take them on that same journey.

We need to start somewhere else.

We start with our overall problem and topic. Why are we meeting today? What are we here to discuss?

Then we discuss the relevance of this meeting to the rest of the project and to other decisions that were made.

We describe the challenge that we had and what it is that we want to solve.

Then we consider our options. We lead with our recommendation, then we explain it. And then we describe the methodology of how we came to our recommendation, giving your audience the problem and topic.

The relevance, the challenge, and what it is you want to accomplish in the design review: that gets the audience warmed up to the topics and for the discussion, even if they’ve studied and prepared for the meeting, they’re likely coming from somewhere else where they’ve just had a discussion about a completely different topic.

So warm them up, get everybody on the same page and aligned with thinking about the topic of your design review. Making the recommendations, then explaining it, and then getting into the methodology helps people to evaluate the recommendations as you’re discussing them and talking about them. If we start with a methodology first, it leads to overwhelm, and we lose focus on what it is we’re trying to evaluate and choose between.

To recap, tip number two for awesome design reviews: Realize that it’s not about the methodology. It’s about the recommendations and being able to choose between the different recommendations to make a decision.

TIP THREE: Share the technical results separately in their natural format, all together, and significantly pare down the content on the presentation slides.

Tip number three, for up-ing your game in design reviews, use your technical report to communicate the technical data, refer to the report in the meeting, within your report, your data is within the context of everything else, the methodology, the results, and other facts that you’ve uncovered.

Give them a copy of your full report. The whole sha-bang. Now, you would’ve emailed this 24 hours in advance for them to look at, but make sure they have a copy of it. At the top of the meeting, you can provide paper copies or you can email them just before the meeting starts so that a copy of your report is in the top of their email and they can access it easily. Consider mapping out the recommendations all together. You’re going to be mapping out your recommendations during the presentation verbally. You could also choose to map it out on paper or on an electric file that you send with your report. Keep it brief and high level because you’re going to be talking about the details and all the details should be in your technical report.

Giving your audience all the technical information early and together in their natural formats helps do two things for your design review.

  • Most importantly, because it’s about them and not you (our principle number one), it’s making sure that we’re able to communicate this technical information adequately for discussion. It not only helps our communication to our teammates. It also helps us because now we know that everyone has the technical information and we don’t have to cram it on a PowerPoint slide. The kind of slide with a big graph and tiny print that nobody can read. Anyway, if we’re using slides at all, we can use them to feature big graphics, maybe a photograph of a failure that we saw during tests or visual aids and graphics to help our team better understand the information that we’re sharing, but we’re not using the slides to share the information that’s already been done by sharing our reports.
  • Psychologists and sociologists study the information transfer between a presenter and their audience. And there are limits of working memory. A fallacy that we have is that if we put it on the screen and talk about it, that all the information on that screen is going to be transmitted to our audience. And that’s just not the case. Our audience is getting just bits and pieces of what it is that we’re presenting and talking about from a slide with our audience. There is also visual and verbal synchronizing going on in their minds, which also makes it difficult to assimilate and understand information, especially technical information.

You can think of it as sort of guiding the attention of your audience through the information so they can assimilate it and make a decision.

So, tip number three for stepping up your game for design reviews: Share the technical results separately in their natural format all together, and maybe include the recommendations with it. And significantly pare down the content on the PowerPoint slides so that you can best communicate with your audience.

SUMMARY

And those are my recommendations for your design reviews. For today. We reviewed three things today, but really there is one overarching theme over all of them. And that is, is that these design reviews aren’t for you, therefore the audience. So decisions about how you’re presenting the data in what order, what you’re showing on the slide versus what you’re handing out. It’s all about having your audience in mind.

I’d love if you would visit this blog post at qualityduringdesign.com and leave a comment for me and the other readers. What is one thing that you do during your technical design reviews that you think would benefit other engineers?

Please go to my website at qualityduringdesign.com, you can visit me there. And it also has a catalog of resources, including all the podcasts and their transcripts. Use the subscribe forms to join the weekly newsletter, where I share more insights and links in your podcast app. Make sure you subscribe or follow Quality during Design to get all the episodes and get notified when new ones are posted. 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 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.