Writing an SD Conference Paper

It’s review time for SD conference papers again. As usual, there’s a lot of variance in quality: really good stuff, stuff that isn’t SD, and good ideas imprisoned in a bad presentation. A few thoughts on how to write a good conference paper, in no particular order:

  • Read a bunch of good SD papers, by browsing the SD Review, Dynamica, Desert Island Dynamics, or past conference plenary papers. You could do a lot worse than picking one as a model for your paper.
  • Start with: What’s the question? Why do we care? Who’s the audience? How will they be influenced? What is their prevailing mental model, and how must it change for things to improve? (If your paper is a methods paper, not a model paper, perhaps the relevant questions are different, but it’s still nice to know why I’m reading something up front.)
  • If you have a model,
    • Make sure units balance, stocks and flows are conserved, structure is robust in extreme conditions, and other good practices are followed. When in doubt, refer to Industrial Dynamics or Business Dynamics.
    • Provide a high-level diagram.
    • Describe what’s endogenous, what’s exogenous, and what’s excluded.
    • Provide some basic stats – What’s the time horizon? How many state variables are there?
    • Provide some data on the phenomena in question, or at least reference modes and a dynamic hypothesis.
    • Discuss validation – how do we know your model is any good?
    • Discuss “Which Policy Run is Best, and Who Says So?” (See DID for the reference).
    • Provide the model in supplementary material, if at all possible.
    • Use intelligible and directional variable names.
    • Clearly identify the parameter changes used to generate each run.
    • Change only one thing at a time in your simulation experiments (or more generally, use scientific method).
    • Explore uncertainty.
    • If your output shows interesting dynamics (or weird discontinuities and other artifacts), please explain.
    • Most importantly, clearly explain why things are happening by relating behavior to structure. Black-box output is boring. Causal loop diagrams or simplified stock-flow schematics may be helpful for explaining the structure of interest.
  • If you use CLDs, Read Problems with Causal Loop Diagrams and Guidelines for Drawing Causal Loop Diagrams and Chapter 5 of Business Dynamics.
  • Archetypes are a compact way to communicate a story, but don’t assume that everyone knows them all. Don’t shoehorn your problem into an archetype; if it doesn’t fit, describe the structure/behavior in its own right.
  • If you present graphs, label axes with units, clearly identify each series, etc. Follow general good practice for statistical graphics. I like lots of graphs because they’re information-rich, but each one should have a clear purpose and association with the text. Screenshots straight out of some modeling packages are not presentation-quality in my opinion.
  • I don’t think it’s always necessary to follow the standard scientific journal article format, it could even be boring, but when in doubt it’s not a bad start.
  • If your English is not the best (perhaps even if it is), at least seek help editing your abstract, so that it’s clear and succinct.
  • Ask yourself whether your paper is really about system dynamics. If you have a model, is it dynamic? Is it behavioral? Does it employ an operational description of the system under consideration? If you’re describing a method, is it applicable to (possibly nonlinear) dynamic systems? If you’re describing a process (group modeling, for example), does it involve decision making or inquiry into a dynamic system? I welcome cross-disciplinary papers, but I think pure OR papers (say, optimizing a shop-floor layout) belong at OR conferences.
  • Do a literature search, especially of the SD Review and SD bibliography, but also of literature outside the field, so that you can explain how the model/method relates to past work in SD and to different perspectives elsewhere. Usually it’s not necessary to report all the gory details of other papers though.
  • Can’t think of a topic? Replicate a classic SD model or a model from another field and critique it. See Christian Erik Kampmann, “Replication and revision of a classic system dynamics model: Critique of ‘Population Control Mechanisms’ System Dynamics Review 7(2), 1991. Or try this.
  • Rejected anyway? Don’t feel bad. Try again next year!

5 thoughts on “Writing an SD Conference Paper”

  1. Tom,

    I really enjoyed your tips and happy to have discovered your blog. (via Google alerts – “System Dynamics”) I have started a consultancy after 25 years in the financial industries. I hope to incorporate System Dynamics into my work in strategic planning, process redesign and risk management.

    I look forward to the dialogue.


    PS: I like your approach with the anti-spam test, though I spend a few minutes trying to enter 3+3!

  2. Bill – I’m glad you pointed to a good example of what I meant by “more generally, use scientific method.” To refine my point a little, I think the key is to avoid confusion about attribution, both for yourself and for the reader. One good way to confuse yourself is to change A and B, and attribute the new dynamics only to B, without checking changes to A and B independently. There’s an example of this in the SD literature somewhere – possibly in the Kampmann critique I cited above – but I don’t remember the details. Good experimental design is meant to avoid attribution problems, even when you’re varying several parameters at once. Also, it is of course useful to vary lots of things at once in uncertainty experiments, even if you’re not interested in attribution of the total uncertainty in the outcome to particular inputs. Thanks.

  3. Tom, I figured you may mean that, but I did want to clarify.

    BTW, I normally point student’s to Jay’s article (Jay W. Forrester. “System dynamics-the next fifty years”. System Dynamics Review. Volume 23, Issue 2-3 (p. 359-370)) on nine points of doing good SD work. Yours is a bit more concrete, which may help them.

Comments are closed.