Idea exchange on how to make simulation and scheduling projects more successful.

Main menu

Monthly Archives: May 2008

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.

When I first started modeling, my boss came to me and said “Model this…” and then proceeded to describe an area of the plant that he thought “might benefit from having a model”. Unfortunately there were no specific objectives beyond that.

To me, a new simulationist, that sounded like an ideal project. Nothing to prove… Nothing specific to evaluate… No one waiting on specific results (because none were asked for)… It even sounded like a good opportunity to learn how to model. But it was not.

“Model this” generally results in a useless project. A waste of time. Without clients or clear objectives, I could not know what to model. Without clear objectives, I had little motivation to learn how to model tricky situations; I instead tended to bypass them to work on aspects more fun or interesting. In fact, for the same reason I often did not even recognize modeling challenges, so I never learned to deal with them.

Moreover, when it was all done, what did I have to show for my time? Perhaps a cool-looking animation. It probably did not have many aspects of reality to it. Reality is driven by close interaction with the stakeholders – oops, I did not have any of them. Why should anyone waste his or her time sharing domain knowledge with me, when I was basically just modeling for fun?

And worse, after I “finished” the model, I was overconfident of my modeling skills – after all, I modeled everything I set out to model, right? Of course I was never forced to really verify and validate against the real system, so I never really had any idea how good the model really was.

Avoid “model this”. Always push for clear project objectives. More on that next time.

We will be using this space to help each other become more successful in our simulation projects. We will be sharing information and initiating discussions that will prove interesting and helpful to both experienced and novice simulationists.

When I say “we”, it is because I cannot do this alone – I need active participation from the user community. Your comments, topic suggestions, and article submissions are welcome.

This blog is not about any particular product, nor is it intended to be in any way commercial or sales-oriented.

Success in Simulation is available to all simulationists in industry, service, military, academic and other application areas, as well as anyone who wants to become a simulationist or who just wants to learn more about simulation. While I intend to focus mainly on discrete event simulation, articles on the related fields of agent-based modeling, system dynamics, and emulation will also be included.

The articles will be intentionally be kept short for a quick read, and will be written in an informal style for easy reading. I encourage you to subscribe to the RSS feed so that you will automatically receive new articles as soon as they are posted.

This article continues a brief exploration into how you can be more successful in your simulation projects. (Look here for part 1.)

Here is a second set of important issues that should be considered.

Agility – You can count on the fact that what you are modeling will change. If the system itself is not changing, the detailed project objectives will. Use a technique that allows you to stay agile enough to cope with the inevitable changes.

Solve Problems – Don’t see yourself as just a model-builder. See yourself as a problem-solver. Think outside the box. Recognize opportunities. Don’t simply provide a service, add value.

Software – Software selection is often difficult, particularly if budgets are tight. Domain-specific or generic? Easy to use or flexible? Established product or state-of-the art technology? Many factors must be considered.

Know Your Stakeholders – Who is funding the project? Put yourselves in their position and determine what their concerns are and what they would like and need to see from this project.

Credibility – While simulation provides a degree of objectivity, to many it is still a “black art”. At the end of the day if you don’t have personal credibility, all the backup data possible will not be able to sell your ideas.

Certainly this was a very brief treatment of only a few key factors to success. Future articles will discuss these and others in more detail.?

Many people new to simulation rightfully inquire how they can be successful. This first article will identify some of the issues associated with simulation projects. Later articles will explore these and other issues in greater detail.

So, to get started, here are five of the more important issues that should be considered.

Project Objectives – “Model this” is not a good objective. “Prove this” is not much better. A clear objective is essential to a meaningful project. Hopefully it would include the phrases “evaluate …” and “as measured by …”.

Know Yourself – What are your strengths and weaknesses? How about those of any other team members who will be involved? Be honest. Then come up with a plan to capitalize on the strengths and overcome the weaknesses.

Domain, Tool & Process Knowledge – It is not enough to be proficient in a simulation tool. Nor is it enough to have comprehensive domain knowledge of what is being modeled. While having project participants with both of those skills is a prerequisite to success, you also need to know how to conduct a simulation project and deliver validated, valuable results.

Project Planning and Management – A project that produces results after the decision is made has little value. And an over budget project may be cancelled before completion. You must pay appropriate attention to completion dates and project costs.

Team/Reviews – Even though “No man is an island”, too often simulation projects are conducted by a single person with little or no team interaction. Find a way to get others involved.

Look for five more success factors next time. Future articles will discuss these and others in more detail.?