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 beneﬁt from

your ideas. From one perspective, it can be

seen as a network optimization problem where the best ﬂow

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 paper’s 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 ﬁrst 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 ﬂow of ideas throughout the paper are

critical. In fact, the ideas are what ﬂows. 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-

ﬁcult 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 ﬂow from you, the

source, be ampliﬁed 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 reﬁning 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 ﬁlling 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-deﬁned modular units, but the

task of writing in these modular units can disconnect the ﬂow

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 ﬂow 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.

γST

(supply)

(demand)

, T

, C

)

: = Flows/Ideas

γst

: = Gain Multiplier

: = Upper Bound

: = Time Spent (duration)

: = Cost of Development

April 2019 | ISE Magazine 47

of our problem. We need to transmit our ideas (ﬂows) 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 efﬁcient 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 ﬁrst 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, deﬁnitions 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

∑

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,” deﬁned by Horst W.J. Rittel

and Melvin M. Webber in “Dilemmas in a General

Theory of Planning,” Policy Sciences, 1973.

• There is no deﬁnitive 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 ﬁnite 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 conﬁdence 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 ﬁnd 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 conﬁdence intervals?

Summary and conclusions. What did you tell the audi-

ence? How did you tell them? What should or could you tell

them but didn’t? These following issues should guide the ﬁnal

section of the paper.

• What are the summary results?

• What are open questions for future research? Are there ex-

tensions?

• What ﬁnal 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 ﬁnal coda

section.

• Where should ﬁgures 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 ﬁgures

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 ﬁgures and features, and any problems in compilation

such as with spelling errors, equation numbering, orphan

sentences, misplaced graphics, awkward table position and so

forth.