Use Mini-Reports to Better Communicate, Organize and Recruit
As Quality and Reliability Engineers we are asked to analyze data for others. We know we can perform an awesome analysis that is technically accurate and relevant. Do we realize that how we present the analysis is important, too?
Our analysis should be summarized with mini-reports, complete with a brief summary of the problem statement, an analysis with discussion and a conclusion with any forward-thinking recommendations. We should not be emailing Minitab file attachments with the subject “looks good”. We should instead be using a report format as a tool to better communicate and helps us stay organized. I’m using the ‘mini-report’ name to highlight that we may not need full-blown, complicated reports every time we do an analysis. However, our analyses (no matter how complicated or not) are deserving of a few minutes to put into a report format and there are many benefits of doing so.
What is useful about putting every analysis into a mini-report?
Most importantly, a mini-report is an effective way of communicating technical information to others to make good decisions. It is easier for reviewers to understand technical information when it is all laid out before them as a whole. This is in contrast to reviewing just the end result, cherry-picked information, or by getting bits and drabs over several slides of a projected presentation. Let’s consider some of the technical communication methods of Edward Tufte and, consequently, Jeff Bezos and Steve Jobs: prior to a technical meeting, we hand out our mini-reports (or full reports) as a way to present our analysis to our reviewers, giving them all information at once and allowing three to four minutes per page to read and understand the content. This allows the reviewers to see the analysis as a whole, lets them digest the information at their rate, proactively answers some questions, and better prepares everyone for a meaningful discussion and use of the technical data.
Our mini reports are tools we can create to help ourselves. Having mini reports to reference can help us stay current and organized so that we can be better prepared and influential. It can also save us time from trying to decipher our analysis time and again. For example, you’re being asked to analyze data, but it sure looks familiar and you remember that a similar test method had some issues. When you ask if this testing was performed before, you learn that it was performed on a prototype design six months ago that ended up being scrapped. Wouldn’t it be useful for you to have that original analysis to reference, if only for yourself? Or, you’re working on three different projects that are at similar development stages: having these mini reports available can help keep ourselves aligned with a particular project.
From a broader standpoint, consider that our reports can serve as a training aid. It makes the types of analysis from QEs and REs more approachable to others. Imagine a team of young engineers ready for challenges, giving analysis a try on their own and coming to us for advice. We could be their introduction into the world of Quality and Reliability engineering. It can be a type of recruitment tool for the next generation of QEs and REs.
What’s the minimum content for a mini-report?
Our name: we take ownership and responsibility for our analysis. This also lends credibility to the information in the report and allows follow-up.
We know to make sure we understand the real question. Just in case and to ensure we’re aligned with others, we put it into writing at the top of our mini report: the problem statement, what we’re trying to learn, or the question being asked. Once we start collecting these reports for ourselves, it will also serve as a quick reference to what it is we were analyzing.
This technical information includes not just an answer or recommendation, but also includes access to the source data and analysis methods used (both very important!). Our analysis and discussion is clear. We should not over-simplify our analyses, no matter the intended audience. The original data set is made available: we describe where the data is coming from, referencing lab reports or dates so it can be found, again, if needed. This lends credibility to our work and also allows others to verify our analysis. We have generated graphs, plots or figures to help make our decision, so we include those results and describe what we’ve learned from it using full sentences. For additional reading on how to make the best use of graphics to communicate technical data, I recommend looking into books from Edward Tufte.
Our conclusion should include any other recommendations besides the bottom-line answer. We’re experienced and forward-looking. Is there a response we find troubling and want to further investigate? Were the number of parts tested adequate or should it be changed for future testing? Were the results this time alright but there looks like there may be risk of a drift that can cause issues later? We are thinking of what information our customers need to be successful and ensuring that we’re communicating it.
We needn’t make this over-complicated. A mini-report can take minutes to generate which is very little compared to the time and experience we put into the good, thorough analyses that we perform. Considering the benefits of having a tool for better communication and our own organization, a few extra minutes is worth the investment.