DESCRIBING CHANGES TO PROCESSES

Most times when you write a document that recommends changing a process, the reader is familiar with both the process and its problems. Accordingly, the introduction need only describe them briefly, and the document can be structured around the changes to be made:

S = Have X process now

C = Not working

D = How change?

The trick, as we saw in, Fine Points of Introductions, is clearly to visualize the steps in the "before" and "after" of the process, to ensure that you get the desired "changes" clear to yourself. There are two other situations in which you need to do this before-after analysis in order to write a brief but clear introduction.

- When the reader knows both the unsatisfactory old process and the desired new one, so that his question is either "How do I implement it?" or "Should I implement it?"

- When the reader has no idea of the workings of the process, nor even that problems with it exist, and whose question is not only "How do you want to change it" but also "Why does it need to be changed?"

The tendency in writing introductions in these cases is either to avoid describing the processes at all, or to over-describe them. This appendix shows you a poorly written example of each situation, and explains how to apply the before-after analysis to restructure them.