Take the 2-minute tour ×

I'm writing a document describing process improvement recommendations. I have some best practices I've learned so far. I use those practices most of the time. But I suppose there are other ways to approach the task of writing formal process description document.

So, how do you usually structure your documentation? As you could already find out, I'm especially interested in structuring formal process description documents which are usually created by QA and sometimes Project Managers. What sections should it contain?

My documents usually contain following sections:

  1. Content
  2. Goal
  3. Scope
  4. Terms and abbreviations
  5. Inputs
  6. Process description
  7. Artifacts
  8. Outputs

What else should there be? Did I forget something? Are there other approaches for structuring formal documents? Link to best practices descriptions are greatly appreciated.

share|improve this question
add comment

1 Answer

My only recommendation is to remember the old adage "a picture is worth a thousand words", especially when describing a process. Make liberal use of flowcharts and such instead of long, wordy process descriptions that no one will want to read. The people who use the document will thank you.

Here is some good information on some of the elements that make up a good process flow diagram.

A simple flow chart:

enter image description here

share|improve this answer
Simple and obvious answer, therefore, really useful) But the problem is that sometimes it is not possible to use diagrams because you need to invent your own notation. –  altern Mar 16 '12 at 15:38
@altern What do you mean by "invent your own notation"? Can you please expand on that? –  CFL_Jeff Mar 16 '12 at 15:58
Here is what I mean: altern-kiev-ua.1gb.ua/images/scm/… –  altern Mar 20 '12 at 17:09
add comment

Your Answer


