At the very highest levels of abstraction, all projects involve four critical stages.

Our approach is more than just a diagram and a description.  It’s the experience to know when to go “off script” and modify elements as needed for a given project. 

Along with our experience in project management and knowledge of the tools we use, our approach allows us to avoid many of the common pitfalls of model-building or business analytics projects (such as getting lost in the data, building a model that only a few people understand, using a tool that no one will use, solving the wrong business problem, providing an answer that fails to convince).

1. Hypothesis.  The first step in the process is the creation of a hypothesis — a restatement of the problem which is often in the graphical format of data over time. Graphics succinctly capture the particular problem to be studied, and more importantly, what is not to be studied.

   Sample activities
   •  Conduct facilitated sessions to develop hypothesis
   •  Identify the boundaries of the business problem
   •  Develop related graph(s) and diagrams to describe hypothesis
   •  Confirm scope of model or analysis

2. Qualitative Model.  The hypothesis becomes a platform for the creation of a qualitative model. As the name suggests, the qualitative model doesn’t use numbers, but rather in words and pictures describes the underlying physics of the problem at hand. This is often in the form of process flow diagrams, causal diagrams, and simple graphic illustrations.

   Sample activities
   •  Confirm stakeholders and sources of data/information
   •  Collect any relevant pre-existing documentation
       (process maps, transaction records, policy documents, management reports, etc.)
   •  Conduct interviews and/or facilitated sessions to develop the qualitative model
       (interdependencies/relationships across the elements of the business problem)
   •  Identify and document relevant business rules
   •  Identify and discuss scorecard and/or evaluation criteria
   •  Develop qualitative model document(s)
   •  Test early concepts of the quantitative model
       (using mock-ups or previous examples)

3. Quantitative Model.  The qualitative model then becomes the blueprint for a quantitative model. We will use data and equations to “layer” onto the qualitative model to make it “come to life” analytically. The quantitative model will use visualisation to help increases its communicative powers for executives.

   Sample activities
   •  Collect, clean-up and integrate data
   •  If necessary, build data model or database
   •  Confirm underlying mathematics or calculation rules
   •  Identify and confirm tools to utilize
       (algorithms, UI tools, data and calculation tools, etc.)
   •  Discuss and identify the scorecard metrics
       (and how the simulation experiments will be evaluated)
   •  Build and test the simulation model
       (algorithms, code, calculations, visualization, UI, etc.)

4. Analysis.  With the quantitative model complete, we will work with the team to conduct experiments. This is the model analysis stage of the project.  Analysis involves changing parameters in the model to reflect real world policy (replace supplier A with supplier B; relocate facility 37 to Bolivia, etc.).  Many experiments can be conducted in “real time” with the project team present – some may require off-line runs.  In any case, all simulation runs will be captured for recommendation support.

   Sample activities
   •  If necessary, develop analysis framework
   •  Conduct sessions to describe the model or analysis
   •  Review original hypothesis
   •  Conduct experiments and collect results
       (often in a facilitated session)
   •  Deploy/deliver model

Simulations can be integrated into existing management systems. We build and deploy such systems using a 10-step simulation development process. The need for such a process emerged immediately with our first major assignments. Our process was not, and is not, an effort to control the creative process of our team, but to align that process with the expectations of the client, a client who is used to doing business a certain way as it relates to controlling software projects. The fact that a good methodology is all about collecting and using the best practices of the discipline to make development more efficient and effective is a beneficial, but secondary, objective.

Please contact us to request a copy of our white paper on Simudyne’s simulation development methodology.