Quality during Design

The Mighty Power of Mini Reports

Dianna Deeney Season 5 Episode 20

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 14:39

When you perform analysis and share it with others to make a decision, do you sometimes just send the file with a blurb in an email? Only to not quite remember what you did later, when you need it most.  

There's a simple, relatively fast thing to do: a Mini Report. And it provides so much more than just jogging a memory.

Mini reports are a valuable tool for communication in engineering. By using them, engineers can enhance team collaboration, streamline decision-making, and provide mentorship opportunities to junior colleagues.

We talk about: 
• Importance of maintaining records for future reference
• How mini reports improve team communication
• Elements every mini report should contain
• Benefits of organized documentation for teams
• Role of mini reports in mentoring junior engineers
• Potential for using mini reports in professional presentations

If your team is still catching problems too late — let's talk.
→ Schedule a free discovery call: Dianna's calendar

Want insights like this?
→ Subscribe to my newsletter: qualityduringdesign.substack.com

Get the full framework.
Pierce the Design Fog

ABOUT DIANNA
Dianna Deeney is a quality advocate for product development with over 25 years of experience in manufacturing. She is president of Deeney Enterprises, LLC, which helps organizations and people improve engineering design.

Utilizing Mini Reports for Improved Communication

Speaker 1

Have you ever been sitting in on a project meeting and you're thinking I've seen this before or I know something about this, we looked at this before, or this happened with another product, and you start digging through your files to try to find it and you can't really find it. Or maybe you find an analysis file, like a mini tab file, and you open it and start to try to reacquaint yourself with what happened, reanalyze the data. Or your project manager or someone else is asking you hey, a couple months ago you decided to do this because you did this test. Well, what was the reasoning that you did that? And you don't really have a straightforward answer because it's lost, it's gone. Really have a straightforward answer? Because it's lost, it's gone. Well, I have something that you can do, an activity that you can do with every analysis, every test. It won't take very long, just a few minutes, and you'll start collecting this information and archiving it so you can get it later and it's also going to help you with better communication. Let's talk more about this mini report after the brief introduction.

Speaker 1

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 and how to apply quality during design to their processes. Listen in and then join us. Visit qualityduringdesigncom. Thanks for joining me here on the Quality During Design podcast. Thanks for joining me here on the Quality During Design podcast. Here at Quality During Design, we talk about how to use quality tools and methods during the design process to improve our communication, to improve our designs. This podcast started in 2021.

Speaker 1

And before that, I had started with a blog. I started the blog in winter of 2018. And I remember it clearly because I was traveling to Milwaukee. I was at a hotel, I had some extra time and I thought I'm going to pull the plug and I'm going to start a blog. I found the computer room in the hotel, which was really like a closet with three seats and a way that I could connect to the ethernet to my computer, because the Wi-Fi wasn't so great, and I sat there for hours and I just typed and typed and I typed up about three articles, three initial blog posts. One of them was about how we should use mini reports as tools to help ourselves. I used to do this frequently. Well, I didn't used to do it, but I started doing it and saw the benefits of doing it and I just kind of refined and decided what the minimum was for this. Now, just at the end of last year, I was talking with Fred Schenkelberg on the Speaking of Reliability podcast and we were talking about things that people could do to help them set up for success with consulting, and one of them was treating your internal customers, or any analysis that you do sort of as a customer, as if you were their consultant, and this kind of ties right into that. So my discussion with Fred made me rethink about this blog post that I did so many years ago, so I want to talk to you about it here. It's just a mini report Now.

Speaker 1

I know engineers don't really like to write. Some of us don't like to write, some of us don't like to do reports. When we're doing any kind of test, we need to write the test protocol and then we need to write the test report and we're doing presentations. So just part of our job is being able to communicate, and sometimes we do that through our writing. Sometimes we do it through talking and presenting Something that helps with all of those things is what I'm calling these mini reports.

Speaker 1

The mini report is really just the problem statement, an analysis with discussion and a conclusion with recommendations. And I'll tell you why this is important. Earlier on in my career I would be asked to analyze some data and I would analyze it in Minitab and I would send over like a snapshot with an email and tell people, hey, this looks good or these are my recommendations, and then even just a few weeks later it gets lost and then I have to recreate it. And then I have to recreate it or whatever I had in the email, like the context was there when we were looking up the information, but then afterwards it was lost. So whether it was a benchtop test to just make a quick decision, or if it was an official test that just got delayed with the official report, things ended up kind of getting lost. And at the beginning of the episode I talked about, you know, having some sort of a memory like we've done this before or if I've experienced this before, and something that helped me with that is, after I'd started doing these mini reports, I had like a record, an archive of things that we had done before and it was really helpful in understanding current and the future situations that we were dealing with.

Speaker 1

So these many reports there's a lot of use for them. One benefit is just better communication. Instead of just floating out some data and some results and talking in a meeting, we actually have it recorded. It's all together in one report. Like I said, it doesn't have to be complicated. I'm not talking about, like the official test reports that we file in our design histories. These are just something that we do. That's a one pager, maybe two pages, that summarizes the analysis that we did for information that we'd gathered. Another benefit of this is just organization. Like I mentioned, being able to recall previous experiences and apply them to what we're doing now and also just being able to reference what is it that we did a couple months ago and why did we make that decision.

Speaker 1

A mentoring or recruitment tool, especially if you're in a niche technical field, if you have a certain specialty and you're doing analyses for your team, having it in a mini report and showing how you did the analysis and the kind of things that you considered can be a roadmap or an example for other people on your team to follow. So maybe that junior engineer that has been seeing your mini reports for a while really thinks that kind of work is interesting and may want to consider a career path in adopting the same specialty that you did. Now, after my talk with Fred, I also thought these mini reports could also be used as a baseline for any kind of technical papers that you could present at conferences. Conferences need people, they need people to attend, they need people to run and organize it and they also need presenters. Having a library of these mini reports can help you with ideas for what it is you could present to contribute to the engineering community and to help other people. So these are all benefits of these mini reports.

Speaker 1

I did mention communication, but I want to kind of loop back and talk about that some more, because usually these mini reports are centered around some sort of technical information, test data or a technical analysis. We're using this information to help us and likely other people make decisions about whatever we're doing. Whether we're choosing a vendor, making a design decision, figuring out what to change about our process, we're using this information to be able to make a decision. Having all of the information whole in a report is very beneficial for your team to be able to assess the information, to make that decision. They can read it and digest it at their own rate. These mini reports are in addition to any kind of presentation that we would do. If we don't provide these mini reports, if we don't provide this information whole, we're kind of dripping the information at our own pace through a presentation over several slides. We're cherry picking the information that we want to show on the slide, so we may be omitting some things. Even if it's not nefarious, we are probably still omitting things, and these are techniques during presentations that don't do well at communicating and sharing information. So having everything organized in a mini technical report also helps our team better understand the information.

Speaker 1

Hopefully I've convinced you to at least give this a try. But let me explain more about what these mini reports contain. They only really contain four things, and the first thing is really easy. It's going to have our name on it. We're going to take responsibility for analysis. Adding our name lends credibility to the analysis and the recommendations that we have, and it also just allows follow-up.

Speaker 1

If there's a mini technical report floating around and someone has a question, who do they go to talk to about it? You, because you have your name on it. The other thing that it has should also be relatively easy. If you've already done the analysis, and that's the question or the problem statement, and that's something you want to have right at the top of this mini report. State it as a sentence, the problem statement, the what's wrong with what or the question that you were given and asked to analyze. Not only is this going to align the reader with whatever you're doing, it's also going to act as a quick reference, because once you start collecting these many reports, you want to be able to flick through them pretty easily, whether they're on a file or however you're storing them. Having the question or problem statement at the very top with your name is going to be helpful for you to find it later.

Speaker 1

Next is like the meat of what it is that you've been doing the technical information you want to answer the question Include graphs, plots, figures the sort of things that we looked at and analyzed in order for us to make a decision. We want to describe what it is we learned in full sentences, no bullet points. Use full sentences as if you're talking to somebody, and also give reviewers access to the source data, whether you recreate the data or you tell them where they can go get the data and the analysis method that you used. Both providing the source data and the analysis method you use lends credibility to your analysis and it also lets others verify the results of what you got. A note here for this technical information.

Speaker 1

Do not oversimplify, because you think your audience may not understand it. The people that you work with are generally very smart people and can figure it out, especially if it's within the context of all this other information that you're with. Are generally very smart people and can figure it out, especially if it's within the context of all this other information that you're giving them. So I suggest that you not oversimplify, and dumb it down is a term that some people use. Don't dumb it down, put it out there, all right.

Speaker 1

So this mini report, it's got our name, it's got the problem statement, it's got our technical analysis with links to information and, finally, the last thing we want to include in it is just our conclusion what's the bottom line answer to the question? And we're going to even do one better than that. We're going to make our recommendations, we're going to put our experience to work. After seeing this information, what should our next steps be? Should we run another analysis using different criteria? Do we need to test more samples in a different way? Do we need to go back to the customer and ask some clarifying questions? Go ahead and put your recommendation on this mini report questions. Go ahead and put your recommendation on this mini report. You're not showing off. You're being helpful and you're being forward thinking and trying to help the team decide. So with that, I hope you can see that these mini reports are just that they're mini reports. Maybe you would copy paste some sections of this mini report into an official report, but you've already started the process of documenting and keeping track of whatever analysis that you did.

Speaker 1

Don't just send the mini tab file and say looks good. Create a mini report for yourself and for the people that you're analyzing for. If you're hosting a technical design review and you're reviewing these results, provide this mini report to your reviewers ahead of time. Let them read through the information so you can have an active and meaningful discussion during the technical design review. Doing these mini reports shouldn't be overly complicated. Doing these mini reports shouldn't be overly complicated. It should take just minutes compared to the time and experience that we put into doing the testing and performing the analysis.

Speaker 1

So what's today's insight to action? You're doing the work. Take an extra minute to just document it so that you have it for posterity, for communication, for organization and to even inspire other people to do the kind of things that you do. If you like this kind of information, please visit qualityduringdesigncom and subscribe to the monthly e-newsletter digest. It'll be a compilation of what we cover here in the podcast, plus a little more. On the subscription form. There's a link where you can see some examples of previous newsletters. This has been a production of Dini Enterprises. Thanks for listening.

Podcasts we love

Check out these other fine podcasts recommended by us, not an algorithm.