How to write a great SD conference paper
Let me start by introducing myself, for those who don’t know me. I’ve been involved in system dynamics since the late 1970s, got my PhD at MIT in 1983, and have been a full-time independent SD consultant since 1990. I live in New York’s Hudson Valley, about an hour’s drive from Albany. I’ve been a member of the SD Society continuously since its inception, have read scores of conference papers as a reviewer and Thread Chair, and have now been appointed VP for Professional Practice.
My VP position is largely concerned with elevating the quality of work we see in conferences, publications, and educational materials. I think there’s plenty of room for improvement, and that improvement is possible if we focus on a small number of guidelines and expectations. Here I’d like to talk specifically about writing a paper for our annual conference.
But, you may ask, don’t we have plenty of guidelines already? At the Society website you will find Contribution Requirements, describing what a submission should contain. You’ll also see references for more information, including no less than 40 excellent tips from our colleague Tom Fiddaman, which you can find here and here.
The problem, I think, is not a lack of guidelines but rather, ironically, that we have so many that it is hard to focus on what matters most. So, I’d like to try to narrow things down. First, my primary concern as a reviewer, frankly, is the paper’s main narrative rather than its behind-the-scenes technical details (as found in an appendix or supplementary materials). If you were writing a paper for a scholarly journal, it would be important to get everything in perfect shape. But things are a little different for a conference paper.
As it says at the Contribution Requirements page, “The expectations for conference papers are, of course, not quite the same as those for a peer-reviewed journal, particularly with regard to detailed model documentation and reporting. We recognize that many conference papers report works still under development and not yet complete.” This statement should not be taken as license for sloppy technical work, but rather simply an acknowledgment that the main narrative is the thing people will see at the conference.
What about that main narrative? Here, I need to distinguish between Application papers (describing a model) and Methodological papers. For both types of papers, you should make sure to include all recommended sections, write clearly and to the point, and identify your research question or systems problem. This includes citations to the SD and non-SD literature as needed to show that your topic is solid and worth pursuing.
Application papers should next present a model structure and numerical assumptions. Reviewers like myself will want to see clear supporting evidence for your assumptions, citing the literature or experts. Then, if the model is a running simulation, you should present base-case outputs, and show comparisons with historical time-series data or other reference mode information. Next comes policy and sensitivity testing. Reviewers will want to see that the policy simulations directly address the stated problem, and that adequate sensitivity testing has been done. They will also want you to give clear structural explanations for why the model behaves the way it does.
For Methodological papers, you should make sure that the proposed approach is described in plain terms and makes practical sense. Also, reviewers will expect to see helpful examples of use cases; that is, how the proposed methodology has been applied or could be applied.
I’ve tried here to boil down the guidelines to what I think is essential for making a conference paper flow logically and persuasively. I look forward to seeing everybody presenting great papers at the next conference!