On the surface, simulation projects are not that different than any other project you need to complete in business or academia.  You need to:

1. Define the Project
2. Gather the necessary data
3. Develop models to answer stated problem
4. Verify the model is working correctly
5. Validate that your customer agrees with the model’s representation
6. Experiment with the parameters of the model
7. Report conclusions and recommendation with respect to the stated problem

 One of the biggest challenges in a simulation project is to define a project that can succeed.  The common downfalls are making a scope that is too wide or too narrow, answering the wrong question, or selecting the wrong software.

 When defining the scope of the project you need to focus on the questions being asked.  If you are building a simulation model just so a model can exist, the project is doomed to fail.  You can build a great model but without a stated goal you will never know when you are done and there is no definition of success. As a consultant, it’s especially important to define the criteria that will measure the success of the project.  All too often, customers will continually reach for the next possible application of a simulation.  I like to say that “simulation will expand to meet the time allotted”.  The only problem is that people will get half way through a project and try to answer questions that are not supported by the model scope or the data that was collected.  This is one of the best ways to get a wrong answer from a good model.

 Another downfall is answering the wrong question.  Be wary of people that “want a simulation to show” anything. 

 ”Hey, I need a simulation to show that we need more conveyor before our bottleneck operation”. 

 This sounds like a person who has made up their mind already and they are trying to recruit you to their cause.  Be specific with these requests about how the “need for more conveyors” will be measured and it makes the decision making process less personal and more analytical.

 Last and probably least on this list is software selection.  Vendors (and I’m one of them) will praise the features of their software with good cause.  Certain packages are better and more efficient than others for certain types of problems but the reality that a skilled user can model almost anything in almost any software.  If you have a choice and the skill set to back it up.  You probably already have a firm opinion on the best course of action.  It does make sense to review this choice when defining a project.  You might be surprised by the results.

I prefer to generate a specification document at the start of any project.  In fact, we’ll often get a signature from the client on the specification.  We do this for three reasons, quality, money, and participation.  We find that people review documents more closely if they have to sign them.  You are less likely to get “revisions” to your assumptions if the specification is read closely at the beginning.  Second is money.  If customers go outside the scope, you can point to the document and ask for more money.   You have to choose carefully when you want to play this card but having support is invaluable if you need it.  Last is participation.  If a signature is required, you are more likely to get the right decision maker in the room from the start.  Many times I have seen a simulation project hijacked in the middle by a manager who should have been in the process from the beginning.  Asking blunt questions about each person’s role from the beginning and requiring signatures on scope documents are two good ways to avoid this pitfall.