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:
- Content
- Goal
- Scope
- Terms and abbreviations
- Inputs
- Process description
- Artifacts
- 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.
Best 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: