Tips for Successful Practice of Simulation

It's wise to also be aware of an "hidden agendas". Is the real reason for performing simulation analysis that someone required them to build a model? Sometimes a customer or source of funding will require a simulation model be built as a condition of a contract. In this case, the stakeholder's main objective may be to have a model that supports what they intend to do anyways. To quote a popular robot… "Danger, Will Robinson!" Starting out with the answer you must "prove" is a situation to be avoided at all cost.

Knowing how your most important stakeholders define (and hopefully even measure) success, now you are ready to write your high-level objectives. This will be the starting point for further project discussions so that everyone has a shared vision. This information also provides a good start for the detailed functional specification you will be doing at a later point.

3. UNDERSTAND THE SYSTEM

If you are lucky, this is your system that you are modeling and you know it well. More typically, even if the system is owned by your company, you do not know it well enough to accurately model it. Every system has subtleties which are often important. While it is not reasonable to expect a simulationist to know every system, a good simulationist should know the important questions to ask and be able to understand the answers.

One good way to start is to review the process so that you understand the key aspects. What are the entities? How are they being transformed? What are the constraints? If possible, take advantage of the opportunity to literally walk through the actual or similar facility to discover things that might be missed in a discussion or diagram review.

Ask questions. Ask more questions. Ask different people the same questions and don't be surprised that you get different answers. Your goal at this stage is not to solve the problem, but to understand the problem and the system well enough that you can describe and estimate the work. Part of this stage is to identify what you don't know so that you can allow time and risk in the project for that enlightenment.

4 CREATE A FUNCTIONAL SPECIFICATION

There is an old adage that says "If you don't know where you are going, how will you know when you get there?" That is especially true in simulation projects. A functional specification clarifies the model scope and level of detail. And most importantly, it clearly defines the deliverables. It defines the objectives as well as the deliverables and determines how everyone will know when you are done.

A functional specification should clarify the project and bring everyone into a common understanding of the deliverables. Topics should include:

• Objectives – Summarize from your initial high-level objectives what you are intending to solve and what you are not intending to solve.
• Level of detail - A model is always just an approximation of reality and can always be improved. It is important to define the limits of this model. For example, the level of detail for a particular model might be suitable for comparing the relative productivity of alternate designs, but might have insufficient detail to provide a reliable prediction of absolute system productivity.
• Data requirements - Identify what data will be necessary to support the agreed level of detail. Where will this data come from? Who will be responsible for providing it? When will it be provided?
• Assumptions and Control Logic - Summarize your understanding of the logic in various points in the system. List any assumptions that you will be making so that you and all stakeholders have a common understanding of how much detail will be modeled for each part of the system. For example, details of dispatching, queue priority, and resource allocation should be agreed upon before modeling begins.
• Analysis and Reports – Determine who will be involved in the analysis phase of the project. Define the form and content of the results to be delivered. A mock-up of a final report is an important part of a functional specification. On review of the mockup, the stakeholders will almost certainly identify things that are missing and things that are unnecessary. It is much better to identify such items at this point than at the final project presentation.
• Animations – A certain level of animation is generally necessary for model development and validation. How important is animation to the stakeholders? In many cases stakeholders initially may indicate that animation has little importance to them. My general experience is that once stakeholders have seen the 2D or 3D animation done in development, they appreciate its value for communication and later demand it as part of the deliverable.
• Due Date and Agility – Simulation is often a process of discovery. As you model and learn about the system you will find new alternatives to explore and possibly areas of the model requiring more detail. Adequately exploring those areas can potentially make the project much more valuable. But the best results possible have no value if they are delivered after the decision has been made. When are results expected? When is the absolute "drop-dead" date after which the results will have no value? You might think that your project doesn't need a functional specification or that it is too much formality for a small project or an internal project. It does not necessarily have to be formal. But every project needs a functional specification and it should take about 5-10% of the total project time to finalize. Even a project that is expected to complete in a single day should devote perhaps 30-60 minutes of time defining scope and detail. This time spent thinking ahead will more that pay itself back later in the project.

Developing a prototype during the functional specification phase can be enlightening to all parties. You might find that it is easier or harder than you thought. Even on the smallest project it is generally worth showing a quick model and asking the question: Is this what you mean? You might find that you have a totally different understanding than the stakeholders. Often a prototype model can be made that addresses a large percentage of what the stakeholders say they need. But as soon as they see the prototype, they remember the complex situations and all the other needs that they neglected to identify earlier.