The final part of the functional specification phase is the sign-off. It should be made clear to everyone that this functional specification defines the project and that the project will be considered complete and successful when all of the aspects of the functional specification are delivered. Ideally, the final specification should be formally approved by at least the primary stakeholders to avoid later controversies.
While the best time to start a simulation study is very early in the associated project's lifecycle, that is unfortunately not the most common situation. It is far more common that simulation is first considered when problems are encountered late in the cycle; perhaps a short time before the final decisions must be made. At this point, everything becomes urgent, and you may even be "late" before you have started.
In such a situation, the temptation is to go into reactive mode, letting the urgency pull you in first one direction and then another. And there is always pressure to skip important steps like deciding exactly what you want to accomplish (the functional specification phase). This tends to result in less than optimal work flow and even an incomplete project.
Manage the project, don't let it manage you. A project that is completed just after the decision is made is of little value. It is part of your job to manage the simulation project so that you provide valuable insight in a timely fashion. Note the words "valuable insight". All simulations are an approximation. Although a close approximation has more value, a rougher approximation can still provide valuable insight. If there is insufficient time to do the entire project well, then select a subset or a rougher approximation that you can do well in the time allotted. This should be reflected in the assumptions of the functional specification.
Simulation is often a process of discovery. You will gain knowledge as you go from the effort to accurately describe the system to the early simulation results. Often this new information may move the study in new directions. A certain amount of agility is appropriate in responding to such needs; however, too much agility can prevent project completion. At such times, you must take the difficult step of telling your stakeholders "no" and deferring such requests to a later project phase. While no one likes to hear the word no, most stakeholders would prefer an honest no to a misleading yes which basically says "Yes, I will do what you request, but as a result the project may not return any useful results within your deadline." Budget your time so that the important tasks will be completed and only then allow the project to explore some unanticipated directions.
The topic of input data often catches simulationists by surprise. And it can easily be cause for project failure. In the days before the prevalence of computers and automation, it was typically the case that little or no data was available. Now, it is much more likely that you will be overwhelmed by data. Organizing and making sense of that data is often the challenge.
The first challenge is to know your data. Here is a simple, but fairly common example: Perhaps you collect some machine downtime data and when you analyze it you find that it has a minimum repair time of 8 minutes, a mode of 32 minutes and a maximum of 9.5 hours. Without additional study you might not discover that the maximum repair time also included an 8 hour off-shift time when the repair started near the end of a shift. It would be easy to use such data incorrectly in the model and generate bad results. It is important to know your data and how good it is, "scrub" it clean of any invalid data, and perform appropriate input analysis.
Since collecting data can be expensive, the objectives of your simulation study should be evaluated to determine where you need the most accurate data. For example, if you are evaluating operator utilization, it is important to have enough data related to the specific tasks for which the operators are responsible. However, the data related to another area of the system with no impact on operators may be able to be approximated.
You can also use your model and some pilot runs to help determine where you need better data by determining how sensitive the model is to different data values. You should check sensitivity to both the magnitude (e.g. the mean) and the variability (e.g. the range) – if the model results have little change when you use other reasonable input data, then your present numbers may be good enough. However if you notice a significant change in results, with a relative minor change to magnitude or variability, then that may be an indication that you should spend more time and effort in assuring that you have the best data possible for that parameter.