Simulation Stakeholder Bill of Rights

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

Prove This

On my second professional model, now that I thought I was an expert 😉 , my manager came to me and said “Prove this…”. He had the very common situation where an associate wanted to make a major investment, but could not convince upper management. This is a perfect application for simulation – a model can provide objective information on which to base such a decision.

This was a much better situation than my first experience. This time I had a motivated, involved stakeholder. I had a clear objective. I had important meaningful work. Life was good.

For a while.

Until the model started to “dis-prove this”. Experimentation led me to believe that other alternatives might be better. I told myself that I must be wrong. I double checked but I could not find any errors. Then my boss and the stakeholder told me I was wrong. I triple checked but I could still not find any errors. Life was no longer so good.

What went wrong?

We started with the result. When I set out to prove a conclusion, I put my integrity at risk. The best I could hope for was that the model actually “proved” what they wanted. A typical client reaction to that situation is an empty “I already knew that!” feeling and the perception on his part that I provided very little value. Worse is when the model contradicts their conclusion. It does not support a “known fact“. In that case, stakeholders might think I am incompetent or that simulation offers no value.

But the worst case of all would have been if the model disproved what the stakeholder wanted, but I kept “fixing it” until it supported their conclusion. My client may be satisfied, but do you think he will ever bring me real work? Unlikely. I would have just proven to him that a model can be made to produce whatever result you want, and that my integrity is low enough to do that.

When similar situations arose later in my career, my responses were:

    –I will be happy to evaluate that situation for you, but I cannot promise what the results will be.
    –If what you really want is just a supporting statement, I cannot provide it without objective criteria on which to base it.

While the above does not always create good will, it does allow me to keep my integrity. As much as I hate to admit it, intentionally misusing a model to create invalid results is often easy. Integrity is often the most important thing that you and I can provide as simulationists. A simulationist without integrity should look for another line of work.

Dave Sturrock
VP Products – Simio LLC