April 2019 | ISE Magazine 45
Writing a technical paper in ISE:
A network perspective
Identify your audience, then create a framework for the problem and its solution
By J. MacGregor Smith
Writing a technical paper in ISE:
A network perspective
Identify your audience, then create a framework for the problem and its solution
By J. MacGregor Smith
46 ISE Magazine | www.iise.org/ISEmagazine
Writing a technical paper in ISE: A network perspective
Writing a technical paper in industrial and sys-
tems engineering for publication is a complex
challenge. Not only must you have something
creative to say, you should have a clear idea
of your audience and how it will benefit from
your ideas. From one perspective, it can be
seen as a network optimization problem where the best flow
of ideas is created. Viewing the problem from this perspective
is challenging, informative and ultimately constructive.
I have authored many papers over my lifetime and I felt that
it might be useful to distill my ideas and techniques for com-
posing technical papers for those starting out in their careers.
Writing papers should be a fun task, but it is normally painful.
If one has a set of principles and a guiding framework for an
activity, it often becomes more pleasurable and less uncertain
or arduous, and the same is true for writing. I will attempt
to explain the principles and framework I use in my writing.
For the outline of the paper, the sections below describe
the background and some of the guiding principles for the
challenge; the network optimization framework; the spiral
feedback process; and the papers summary and conclusion.
Background, key principles
Writing is an act of communication. There are some simple
basic principles for communication that have been developed
by many authors of writing technical papers. These are: have
something to say; know your audience; outline, outline, out-
line; and write and rewrite in spirals.
The first principle is that you should have something to say.
An idea is “an abstract thought or suggestion as to a possible
course of action,” according to the Oxford English Dictionary.
The generation and flow of ideas throughout the paper are
critical. In fact, the ideas are what flows. This may seem trite,
but unless you have something to say, it may be best to be
quiet. Your ideas should help solve a problem, present a new
way to think about something or be principles themselves for
solutions.
These basic principles have been reiterated
many times over by many authors. Steven
Krantz, in “A Primer on Mathematical Writing
(2016), is the most recent exemplar of this
principle. In industrial and systems engineer-
ing, the methodology of solving problems is
often the key concept in improving a system.
How to do something is essential in ISE and
if you have new ideas to solve these prob-
lems, they are worth hearing about.
Writing a technical research paper is a dif-
ficult problem for a number of reasons (see
accompanying article on page 48). One con-
cern is that not only do you need a minimum
of ideas – one – you should provide a limit
on the number of ideas and not overwhelm the reader with
too many. So in essence, the ideas should flow from you, the
source, be amplified and multiplied through your language
and arrive at the audience, hoping to improve its understand-
ing and situation.
The second principle is know your audience. This again
may seem obvious, but the language of the audience is critical
to understanding the ideas you are trying to communicate.
The audience receives and demands new ideas to gain an un-
derstanding of what you have done. That the ideas should be
new to the audience is also critical, and the argumentative
form or proof of the ideas is highly dependent upon the so-
phistication of the audience. If you are not on the same wave-
length, there is no real value added to what you have to say,
and the audience will dismiss your ideas.
The third principle is outline, outline, outline. Structure
and logic are crucial to understanding your ideas. If your ideas
appear disorganized and not sensible, their clarity and impact
will be lost. Outlining the paper and rening the outline over
and over helps decompose the communication problem into
smaller modular units but leaves the organization whole and
intact so the modular units of writing remain coherent and
connected. If the outline structure is well-designed, the writ-
ing in even smaller modular units becomes fun, like filling in
the blanks.
The fourth principle is to write and rewrite in spirals. This
spiral feedback principle was originally formulated by Paul
Halmos in “How to Write Mathematics” (1970) and has been
one of the most useful to me in my compositions. Based upon
the outline, one will have well-dened modular units, but the
task of writing in these modular units can disconnect the flow
of ideas so that one loses sight of their coherence. However,
going back and forth in spirals and reconnecting the ideas as
they are developed begins to ensure they are clear and coher-
ent and still flow from one modular unit to another.
Figure 1 illustrates the basic underlying network structure
FIGURE 1
Delivering the message
The basic underlying network structure that displays the need to transmit ideas from
a source to an audience.
F
S
F
T
γST
(supply)
S
(demand)
T
(U
st
, T
st
, C
st
)
f
st
: = Flows/Ideas
γst
: = Gain Multiplier
U
st
: = Upper Bound
T
st
: = Time Spent (duration)
C
st
: = Cost of Development
f
st
W
April 2019 | ISE Magazine 47
of our problem. We need to transmit our ideas (flows) from
our source to the audience to provide new knowledge. The
number of ideas are bounded, take time to develop, and the
costs of development should not be so great they hinder our
ability to deliver them in a timely and efficient manner.
Guiding framework
If we are to go beyond the simple basic principles embod-
ied in Figure 1, we need to enhance our network structure
and delineate the framework referenced earlier. Figure 2 il-
lustrates this suggested framework. It is important to see there
are phases or stages of development of the framework. It is
akin to a dynamic programming problem where we begin
at the end with a summary and conclusions of our ideas and
put them forward at the beginning of the paper so the audi-
ence knows full well what the paper is all about. See A.S.C.
Ehrenberg’s, “Writing Technical Papers or Reports” (1982)
for an exposition of this concept.
After our starting node, the first node α represents the
title and abstract which then naturally leads to the introduc-
tion and problem background π nodes. After those sections,
we have the notation and assumptions for our mathematical
model formulation and this often-theoretical section natu-
rally leads to the systematic procedures and any algorithms
A for realizing the mathematical models and logically to the
experimental results Xn. Finally, we have our summary and
conclusions sections Ω and end matter.
Title and abstract. The title and abstract provide a mini-
summary of the paper. There should be no jargon or acro-
nyms. Usually 10 lines or sentences of text is a good upper
limit (Victor Li, “Hints on Writing Technical Papers and
Making Presentations, IEEE Transactions on Education,” May
1999).
The following are issues or key questions to help structure
the title and abstract. Brevity and con-
ciseness are important.
What is the main idea(s)?
Why is it innovative?
What was the methodology?
What are the main results and con-
clusions?
Introduction. The introduction is a
key foundation for the paper. It should
clarify the overall purpose/objectives of
the paper, the problem addressed and its
eventual resolution. The following are
issues or key questions one should use to
help structure the introduction.
What is the problem addressed and
what are the objectives of the paper?
Why is the problem important? What is the complexity of
solving it?
What is a brief outline of the paper?
Problem background. The problem background sec-
tion should clarify to the audience what has been done in the
past, what literature is relevant and what new ideas you are
presenting. For technical topics, articles in the last 10 to 15
years are probably most relevant. The following are issues or
key questions one should use to help structure the problem
background section.
Who is the audience?
Where does the problem arise?
What have people done in the past?
How have they done it?
What is new here?
Mathematical models. This section should summarize
the mathematical formulation of the problem and the proper-
ties necessary for its solution. This is usually the most techni-
cal part of the paper. The following are issues or key questions
one should use to help structure the mathematical model sec-
tion.
• What assumptions, denitions and symbolic notation are
needed?
What is the problem formulation, performance and opti-
mization?
What are the key theoretical properties and their convex-
ity, reversibility and proofs?
Algorithms and heuristics. How the problem was
solved and by what methodologies is often critical in an ISE
paper. Not all papers will have algorithms or heuristics, but if
FIGURE 2
The framework of your paper
The suggested structure of a technical paper. The node α represents the title and abstract;
π is introduction and problem background; is the notation and assumptions for a
mathematical model formulation; A is the systematic procedures and algorithms for
realizing the mathematical models; Xn is experimental results; and Ω is summary and
conclusions.
Introduction Formulation Algortithms
Background Theory Results
α
Ω
π
I
n
A
t
X
p
48 ISE Magazine | www.iise.org/ISEmagazine
Writing a technical paper in ISE: A network perspective
The ‘wicked
problems’ of
technical papers
The challenges in writing a technical paper
share many of the characteristics/dilemmas of
“wicked problems,” defined by Horst W.J. Rittel
and Melvin M. Webber in “Dilemmas in a General
Theory of Planning,” Policy Sciences, 1973.
There is no definitive problem formulation. In
chess, mathematics and puzzle-solving, there are
unique formulations; however, in ISE, there can be
many formulations.
There is no list of permissible operations. In chess
and mathematical programming, there is a finite set of
permissible operations to start the problem, but for most ISE
problems, no list of permissible operations exists.
Every ISE problem is symptomatic of every other problem.
Problems are nested together. Inventory problems are related to
queueing and resource-constrained problems, and again all these are
related to facility layout problems. You are never sure you are tackling the
right problem.
There are many alternative solutions to the problem. Different solutions have
different performance trade-offs.
There is no single criterion for success. Solutions to ISE problems are either
good or bad, not true or false. There are many multiple criteria to consider along
with their trade-offs.
There is no immediate or ultimate test of a solution. While important for confidence in a
solution, digital simulation models are an approximation to reality.
There is no stopping rule; you can always do better. In chess, you either win, lose or draw.
In mathematical programming, you either find the solution, show the problem is either
infeasible or unbounded. In ISE problems, you can always improve the system.
Finally, we have no right to be wrong. Scientists can accept or refute hypotheses and
mathematicians can disprove conjectures, but ISE professionals and academics
are morally responsible for their actions.
April 2019 | ISE Magazine 49
they do, clear articulation of them is important. The follow-
ing are issues or key questions one should use to help structure
the algorithms and heuristics section of the paper.
What is the step-by-step process to solving the problem?
What methodologies or paradigms were critical?
Is this a methodological contribution? Proofs?
What are the worst-case theoretical complexity results? An
average case? Storage?
Theoretical or experimental results. What are the key
ndings and what is the best way to present them? This also
can be a very technical section and can be as important as
the previous two subsections. The following are issues or key
questions one should use to help structure the experimental
results section.
How can you best show the results for the reader with
proofs?
What are the data trends? Are there tables?
What are the key functional relationships? Are there
graphs?
What are the worst-case computational run times? Are
there 95 percent confidence intervals?
Summary and conclusions. What did you tell the audi-
ence? How did you tell them? What should or could you tell
them but didnt? These following issues should guide the final
section of the paper.
What are the summary results?
What are open questions for future research? Are there ex-
tensions?
What final conclusions can be drawn?
Figures, acknowledgements, bibliography, appen-
dices. End matter is important to wrap up the paper and
include other miscellaneous items. Figures can be placed at
the end although placing them where they are referenced in
the text is often best. Appendices can sometimes be helpful for
complex proofs, tables or graphics. The following are issues or
key questions one should use to help structure the final coda
section.
Where should figures be placed?
Whom should you acknowledge?
What number of references is appropriate? Are dates in-
cluded?
What details can be put in an appendix? Proofs?
Feedback process
As mentioned earlier, the spiral feedback process is very im-
portant to keeping continuity and consistency in the thought
process and streamlining the content. Starting with the ab-
stract, then the introduction and continuing on with the oth-
er sections, continuous feedback helps streamline the ideas.
Feedback is important in ensuring quality of the thought
process.
Another important consideration is the word-processing
tools and the ease with which the revision process can be ac-
complished. I utilize the PDFTexify process in Latex and the
editing tool WinEDT to process my drafts. It is a time-saving
product because I can include all the equations and figures
and bibliographic citations and process the paper thoroughly
and quickly in a large document such as a book with many
chapters. I can easily gain feedback as to what the document
looks like, its organization, graphics with pictures, tables and
other figures and features, and any problems in compilation
such as with spelling errors, equation numbering, orphan
sentences, misplaced graphics, awkward table position and so
forth.
Other questions to consider:
How should you systematically revise the paper?
How often should you do so?
What is the best word processing software?
Final disposition
To streamline the final product, it is always wise to have
someone read over the paper to catch any typos, poor word
choices and other syntax or grammatical problems or organi-
zational issues. Presenting the paper at a seminar or confer-
ence meeting is always desirable before submitting for publi-
cation. For this paper, I created the presentation first. If one
has considered the audience carefully, the publication outlet
will probably already be decided, at least narrowed down to
a few alternatives.
Questions to ask:
Should you have friends and colleagues review the paper?
Should you present it first at a seminar, conference or other
meeting?
When should you send it out for publication and where?
I hope the ideas in this article are helpful to the readers of
ISE. Any errors or omissions are due solely to my not follow-
ing my own guidelines. The references included are really
quite helpful and Li has also some very good points about
presentations.
J. MacGregor Smith is a professor in the Department of Mechani-
cal and Industrial Engineering at the University of Massachusetts in
Amherst, Massachusetts, and an IISE member.