So how does a good simulation project go bad? We will address some of the most common issues we have encountered in simulation projects across a wide range of industries.

The Undefined Project – defining your scope

The undefined project is probably the biggest reason a simulation project will fail.  The undefined project is the project that begins in the simulation tool through dragging and dropping model constructs but is never mapped out or defined in a functional specification document.  Without a functional specification, the project has no limits or bounds, and inevitably no clear objective or timeline.  The model grows like kudzu and becomes entirely unmanageable. It’s left to languish on someone’s hard drive. If by some miracle the model is completed, it becomes very difficult to validate against an existing or proposed system.

Without any documentation to define the model of the given system, the development process becomes a headache and requires an inordinate amount of unproductive time trying to figure out how to fix the model.  But how can you fix this issue?  It’s like driving off into the wilderness with a blindfold and then trying to reference a map (no cheating with GPS) while having no clue where you are because you don’t know how you got there in the first place.  How do you prevent this?  Creating a functional specification (check out the project guide) of the project and outlining the project objectives and defining what will and will not be modeled along with assumptions about the system can keep you on the planned path and out of the woods.  

Garbage In/Garbage Out – and how to clean it

Garbage in/garbage out, also known as bad data or lack of data, is another reason projects go bad.   This can be divided into a lack of understanding of the system being modeled and a lack of real data against which to validate the system or to use in your analysis.  Lack of understanding is easily fixed by asking questions and having more than one person involved in the project.  Asking questions from different perspectives can also lead to a better understanding of the system: ask the management of a facility, engineers, and the workers how the system functions.  As for obtaining the real data, find out who has it and set time lines on when you expect it to be delivered and then follow up on the timeline.  It’s 2015, technology allows us to barcode and track just about everything. The data is there, you just need to get it or assign someone to get it.  If anything, you may find yourself inundated by data and find that you need to sort through it and find the right data for the project at hand.

Boiling the Ocean – or managing your objective

The last reason a project goes off course is due in part to trying to model everything and optimize it all!  Sounds great, but you are only human.  A project with 50 different objectives and 1,000 key performance measures is more likely to increase your blood pressure than your throughput.  Keeping objectives manageable and reasonable may not solve all the problems at once but it will allow you to begin solving them productively and effectively. Just remember not to try to boil the ocean.