The Simulation Model Life Cycle (Part 7) - Report on Findings

Updated: Jul 26

From start to finish, best practices and practical advice for doing a simulation-based project


This post is part 7 of a 7-part series about the Simulation Model LIfe cycle. You can catch up on the previous post here




Life cycle of a simulation model

  1. Defining the Problem

  2. Working the Data

  3. Building the Model

  4. Verification and Validation

  5. Experimentation

  6. Analyze the Results

  7. Report on the Findings

This post focuses on the seventh step, and final step of the simulation life cycle You can start watching the lecture from step 7 here, or continue reading the blog post.


Note: Although one does go "back" in later steps to do some activities during previous steps, you by no means redo the entire step. The steps listed above are guidelines of the general steps that a typical project follows. On all steps, you can go backward and revisit previous steps, but unlikely that you will skip a step or move forward before completing a step to at least 80%-90%.

For a more insightful discussion on the matter, read here


7) Report on Findings


This is arguably the most important step in the simulation life cycle. If we are not able to report on our findings and provide insight, what was the point of the entire project? We love doing simulations and analyses but in the end, what will leave a meaningful impact long after the simulation model has stopped running is the conclusions made from the analysis. Reporting these conclusions and findings is the final hurdle before you can state that you have successfully completed a project!



Be sure that by the time you get to present your findings, you have something to say ;-)


1) Prepare a report/presentation tailored for your audience

As you will see in the next point, it is of critical importance that you tailor your presentation or report based on the audience you will be presenting for. Otherwise, your message might be lost along the way and you end up wasting your time and your audiences.


For example:

  • Presenting to your team

  • Take them step-by-step through your analysis process, allowing them to comment and provide guidance and ask questions

  • You will typically take them on the same journey you had while doing the analysis

  • Presenting to executives or managers

  • Use the pyramid method (see next point) - it is the complete opposite of your analysis journey. You start with the conclusions and work your way back to the analysis as needed.

  • Here you need to condense your presentation as much as possible and keep supporting slides as a backup.

  • Presenting at a conference

  • Only do a very high-level overview of the why, the what and the how of the project.

  • Keep in mind that your audience is mixed and possibly not familiar with the industry or project specifics

If you are unsure of whether or not your presentation has the right level of detail or structure, the best option is to check with one of your future audience members, if possible, or a more experienced presenter.


2) Use the pyramid method

The pyramid method, created by Barbara Minto, is the complete opposite of what typical engineers and scientists like to use when presenting. We typically want to start with all the details, supporting arguments, and data analysis and then guide the audience to make the same conclusions as we did.


The pyramid principle turns this approach on its head and have you start with the summary and conclusions first and then only dive into the supporting details as needed based on the questions the audience asks or might ask.


Source: https://blog.presentationload.com/present-better-pyramid-principle/


2.1) Start with the final outcome

This is critical when presenting your findings to managers and high-level executives who don't have the time (or attention ;-) ) to go through your analysis in detail. Most executives think big-picture and “top-down.” So you start with the answer to the original questions and the reason for doing the project in the first place. Remember the model purpose and problem definition from step 1!


Using our example of the retail shop, the problem definition was:


A retailer wants to quantify the impact on the customer average queue waiting time in their shop when moving from a queue per server setup to a single queue for multiple server setup.

So our presentation should start with something like:


Moving from a multiple queue to a single queue setup will reduce the average queue length by 1% and the maximum queue length by 5%.

2.2) Supporting statements

In this section of the pyramid, you have all the supporting statements, findings, charts etc that show why you can confidently make the statement in 2.1.


Continuing with our example, we can use a histogram of the queue length for the two different setups or, even better, just the simple table we created in the previous step


This table contains all the necessary information we require to proof the conclusion we made.


2.3) Data

Most of the time, I put all supporting data, tables and other artifacts inside backslides and only show them during a presentation if the discussion requires it. They will be available for readers pre or post-presentation. Showing detailed slides during an executive presentation can often derail the entire discussion.


Most of the time, the creation of intense data-driven slides is mostly to improve my understanding of the data and to create the eventual summary slide. This slides, although significant effort goes into them are sometimes never even seen by the client.


Beware of death by PowerPoint!

gif


Summary

In the post, we reviewed some guidelines for reporting your findings. Without proper reporting on the findings, the entire project could be a waste of time and none of the brilliant modeling and analysis work you did would have any meaningful impact.


There are a lot of resources available, but being a good presenter usually comes with practice. Find a mention if possible, always get feedback from your audience after a presentation, and learn from your mistakes.


I hope this series of posts proved valuable and that readers would be able only to create more value from their simulation projects but also use this framework to plan their projects better.


Keep modeling

Jaco-Ben Vosloo

 

Looking forward to a future series of posts?

Remember to subscribe, so that you can get notifications via email or you can also join the mobile app