If you’ve been on one of our public training courses you’ve probably met me, hi! I drop into training a lot, it’s a great opportunity to meet our users which I always enjoy. I also get lots of great insight for our product development, most of our ideas come from these sessions watching our users in action.

When I drop in I’m almost always asked for my top tip for building simulations. My answer, only ever ask your simulation one question. 

I can’t claim credit for the tip, it was one of the first things I learned in my Operations Research degree. You must identify the key question your analysis is to answer. Do not let the client leave the kick off meeting without both having agreed what it is, that’s what my Professor taught me. A vital lesson for any analyst.

It’s the soft side that will cause most studies to fail

I was lucky, learning to be a consultant was part of my degree. My Operations Research faculty recognized that to successfully complete any study, whether the client was internal or external, whether they were paying me or not, you have to be a great analysis facilitator, a consultant. As a result they spent a lot of time teaching you the soft skills that would help your projects be successful. So when I say I learned to be a consultant I don’t mean I learned to schmooze you! I learned how to work out what the client needs, not what they want. I learned how to take the client on a journey of discovery. I learned how to craft reports senior management would read and understand.

Most analysis goes wrong not because the data is bad, or the choice of analysis tool was wrong, but because the soft side failed. The consultant didn’t understand what the client wanted, the client just knew they wanted their problem solved, all of them. The client felt the need to ask for hundreds of results just in case they need them, the consultant wants to keep the client happy so they build them in, the analysis gets too complicated, errors creep in, the client loses faith. You know how it goes, I’m sure we’ve all got ourselves stuck in this deep dark hole before, if you were lucky you managed to climb back out!

Your question is your guiding light for your study

To avoid this you define your analysis question. What is the single question your analysis must answer. It can still be quite open, but not too open! For example:

• How can I double the throughput of my process?
• How can I reduce average patient time in my process?
• If demand doubles can I still meet my SLA of all calls answered within 15 minutes?

If you have this single question it can act as a guiding light for your entire simulation study. Whenever you go to add more process detail to your simulation, do I need this detail to answer my question. When you go to add another user configurable input, ask does that data impact on the decision we need to make. When the client asks you look to add another result, ask them, will this information help me answer my question.

Having a question defined gives you and your client a touch point to keep referring back to again and again.

Put the question in your simulation and all reports

The first thing I do when I start building any simulation is add the question in big bold text right at the top of my simulation window. I then add it to any custom report I generate. We’ve actually considered making it a mandatory field you have to answer in SIMUL8. So you click File /New and then a dialog opens that says “what is the key question you are trying to answer?” and you’re not allowed to start till you completed it. That’s how much I believe this is crucial to your simulation study, I am prepared to really annoy users and that is something I never, ever consciously do.

We’re not smart enough for more than one question!

Why this blog post? I was talking with a customer who is embarking on simulation for the first time, but interestingly has been a consultant their whole career. I asked him what were ALL the questions he wanted his simulation to answer. It’s a trick question that usually works really well for exposing the clients multiple and conflicting goals, but it backfired this time. His response? “Oh, I only have one question, I’m not smart enough to deal with multiple questions at one time”. My reply (after I’d stopped laughing) “John, none of us are, it’s just that only a few are smart enough to realize they’re not that smart!”.