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

Send us a message

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

Get the full framework.
Pierce the Design Fog 

ABOUT DIANNA
 Dianna Deeney is a product development process strategist with over 25 years of experience in regulated industries. She is president of Deeney Enterprises, LLC, where she helps product development teams make better decisions upstream — before costly design mistakes get built in. 

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 .

Documenting Work for Communication and Inspiration

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.