Michigan Simulation User Group

In the Simulation Stakeholder Bill of Rights I proposed some reasonable expectations that a consumer of a simulation project might have. But this is not a one-way street. The modeler or simulationist should have some reasonable expectations as well.

1. Clear objectives – A simulationist can help stakeholders discover and refine their objectives, but clearly the stakeholders must agree on project objectives. The primary objectives must remain solid throughout the project.
2. Stakeholder Participation – Adequate access and cooperation must be provided by the people who know the system both in the early phases and throughout the project. Stakeholders will need to be involved periodically to assess progress and resolve outstanding issues.
3. Timely Data – The functional specification should describe what data will be required, when it will be delivered and by whom. Late, missing, or poor quality data can have a dramatic impact on a project.
4. Management Support – The simulationist’s manager should support the project as needed not only in issues like tools and training discussed below, but also in shielding the simulationist from energy sapping politics and bureaucracy.
5. Cost of Agility – If stakeholders ask for project changes, they should be flexible in other aspects such as delivery date, level of detail, scope, or project cost.
6. Timely Review/Feedback – Interim updates should be reviewed promptly and thoughtfully by the appropriate people so that meaningful feedback can be provided and any necessary course corrections can be immediately made.
7. Reasonable Expectations – Stakeholders must recognize the limitations of the technology and project constraints and not have unrealistic expectations. A project based on the assumption of long work hours is a project that has been poorly managed.
8. “Don’t shoot the messenger” – The modeler should not be criticized if the results promote an unexpected or undesirable conclusion.
9. Proper Tools – A simulationist should be provided the right hardware and software appropriate to the project. While “the best and latest” is not always required, a simulationist should not have to waste time on outdated or inappropriate software and inefficient hardware.
10. Training and Support – A simulationist should not be expected to “plunge ahead” into unfamiliar software and applications without training. Proper training and support should be provided.
11. Integrity – A simulationist should be free from coercion. If a stakeholder “knows” the right answer before the project starts, then there is no point to starting the project. If not, then the objectivity of the analysis should be respected with no coercion to change the model to produce the desired results.
12. Respect – A good simulationist may sometimes make the job look easy, but don’t take them for granted. A project often “looks” easy only because the simulationist did everything right, a feat that in itself is very difficult. And sometimes a project looks easy only because others have not seen the nights and weekends involved.

Discussing these expectations ahead of time can enhance communications and help ensure that the project is successful – a win-win situation that meets everyone’s needs.

Dave Sturrock
VP Products – Simio LLC

The people who request, pay for, consume, or are affected by a simulation project and its results are often referred to as its stakeholders. For any simulation project the stakeholders should have reasonable expectations from the people actually doing the work.

Here I propose some basic stakeholder rights that should be assured.

1. Partnership – The modeler will do more than provide information on request. The modeler will assume some ownership of helping stakeholders determine the right problems and identify and evaluate proposed solutions.
2. Functional Specification – A specification will be created at the beginning of the project to help define clear project objectives, deadlines, data, responsibilities, reporting needs, and other project aspects. This specification will be used as a guide throughout the project, especially when tradeoffs must be considered.
3. Prototype – All but the simplest projects will have a prototype to help stakeholders and the modeler communicate and visualize the project scope, approach, and outcomes. The prototype is often done as part of the functional specification.
4. Level of Detail – The model will be created at an appropriate level of detail to address the stated objectives. Too much or too little detail could lead to an incomplete, misunderstood, or even useless model.
5. Phased Approach – The project will be divided into phases and the interim results should be shared with stakeholders. This allows problems in approach, detail, data, timeliness, or other areas to be discovered and addressed early and reduces the chance of an unfortunate surprise at the end of a project.
6. Timeliness – If a decision-making date has been clearly identified, usable results will be provided by that date. If project completion has been delayed, regardless of reason or fault, the model will be re-scoped so that the existing work can provide value and contribute to effective decision-making.
7. Agility – Modeling is a discovery process and often new directions will evolve over the course of the project. While observing the limitations of level of detail, timeliness, and other aspects of the functional specification, a modeler will attempt to adjust project direction appropriately to meet evolving needs.
8. Validated and Verified – The modeler will certify that the model conforms to the design in the functional specification and that the model appropriately represents the actual operation. If there is inadequate time for accuracy, there is inadequate time for the modeling effort.
9. Animation – Every model deserves at least simple animation to aid in verification and communication with stakeholders.
10. Clear Accurate Results – The project results will be summarized and expressed in a form and terminology useful to stakeholders. Since simulation results are an estimate, proper analysis will be done so that the stakeholders are informed of the accuracy of the results.
11. Documentation – The model will be adequately documented both internally and externally to support both immediate objectives and long term model viability.
12. Integrity – The results and recommendations are based only on facts and analysis and are not influenced by politics, effort, or other inappropriate factors.

Note that every set of rights comes with responsibilities. The associated stakeholder responsibilities are discussed as part of the Simulationist Bill of Rights.

Give these expectations careful consideration to improve the effectiveness and success of your next project.

Dave Sturrock
VP Products – Simio LLC

Human Judgment, also known as Seat Of The Pants Analysis (SOTPA), is probably the least acknowledged but most widely used alternative to simulation. SOTPA is making decisions by instinct and feelings rather than using objective analytical tools. With SOTPA you never actually have to get out of your chair, or even spend any significant time to reach a decision.

I use SOTPA all the time and you probably do too.

When I am in a hurry to go out and want to know if I should wear a jacket or bring an umbrella, I might take a quick look out the window, reflect on the season and yesterday’s weather, then make a decision. That’s SOTPA. I know that there is a high likelihood that I will be wrong, but I don’t want to take the time to do the weather channel research to get more objective information.

Human judgment beat simulation in this case. But not always.

When I am going on an all-day outside outing and have the same decision to make; the importance of being correct increases. In that situation I will take the time to consult at least two weather sources and even step outside for some direct research. With this objective analysis I can make a more informed decision. Although such an analysis is never perfect, including objective data in my analysis dramatically increases the likelihood that my decision will be correct.

Now let’s say I am a manager and my staff comes to me proposing purchase of a new piece of equipment to solve an important problem in my facility. They may give me technical specifications, maybe some manual or spreadsheet calculations, perhaps even show me a case study about how that equipment was used in another facility. The easy thing for me to do at that point is to make a SOTPA-based decision. After all, I must be pretty smart to get to be a manager, right? Right?? And I know THE BIG PICTURE. So who better than me to make the decision? And why should I need more information?

If you haven’t read it, I’d suggest you pause now and read the blog on Predicting Process Variability. Did you pass the test? Don’t feel bad, almost no one does. My facility is much more complicated than that one. If I cannot predict the performance of such a simple system, why should I expect that I can predict the impact of adding this proposed equipment to my facility?

“But I don’t have time to simulate.” I don’t have time to research weather when the penalty of being wrong is low, but I make the time to do it when the penalties are higher. With modern simulation tools you can often get valuable results in a short period of time. In two or three days you can often provide an objective analysis that can save a few hundred thousand dollars. Let’s see, invest $3000, save $200,000 … I think I can make the time for that. How about you?

Simulation beats human judgment when it matters.

When someone else uses SOTPA you might say they bent over and pulled the answer out of their… um, … er, shoe. “What was he thinking?” Don’t let that be you.

Reserve SOTPA for decisions that don’t matter. Use simulation for the decisions that do.

Dave Sturrock
VP Products – Simio LLC