0

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.

1 Answer 1

1

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

3
  • 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
    Commented Mar 16, 2012 at 15:38
  • @altern What do you mean by "invent your own notation"? Can you please expand on that?
    – CFL_Jeff
    Commented Mar 16, 2012 at 15:58
  • Here is what I mean: altern-kiev-ua.1gb.ua/images/scm/…
    – altern
    Commented Mar 20, 2012 at 17:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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