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.


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

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.