Don't Just Simulate, Solve! (page 4)
4. Don't drown your audience in statistics.
Getting back to your final presentation, don't forget that the statistical analyses are your job, not that of the audience. I like to have ANOVA and other statistical results on backup slides, and only pull them out if someone asks. Otherwise, you tend to drown your message and reduce the impact of the cleverness of your proposed changes.
Also, don't bore your audience with all the failures. If you tested 20 what-if scenarios, and only three showed improved functionality, show the three. Unless you were specifically charged with testing specific alternatives that turned out to be losers, focus on the winners. If all 20 turned out to be winners, show the top three or four, or perhaps the three or four most different approaches. Keep the rest for backup in case someone asks.
5. Don't fall in love with methodology.
Finally, remember that your task wasn't to build a simulation, it was to improve the functionality of some real-life system. If it turns out that simulation is not the best approach, don't be afraid to change direction. In some situations, operations research techniques may be more applicable. In others, the necessary solutions can be determined with a spreadsheet. In some cases, you will even find a closed form analytical solution to the problem at hand. Just because you own a hammer, not everything you come across will be a nail.
This rule especially applies if you are a hired-gun consultant brought in specifically to develop the simulation. No client wants to be taken advantage of, and I have found that they always appreciate a better approach than the one they asked for, particularly if it saves them time and money.
SOME FINAL THOUGHTS:
Whittling down appropriate modeling technique to five dos and don'ts is a bit arbitrary, of course, so here are some other odds and ends that we might also keep handy in the backs of our minds, in no particular order: take some time to ensure the integrity of your input data, or you'll suffer from the GIGO syndrome; decide up front if you need a discrete or a continuous simulation, based on the nature of your system; select the software tool most appropriate for the current task; don't forget to do a cost/benefit analysis on your recommended changes; don't be too disappointed if none of your suggestions are ever implemented (this happens a lot!); and remember the words of George E. P. Box: "All models are false, but some models are useful."
If you've read all this way, you might as well shoot me an email and let me know how we can put these ideas to work for you!!
