There are two basic audiences for process documentation: - Process Engineers (those who define and document the processes) and
- Practitioners (those who have to follow the processes).
The process engineers are very interested in the overall process architecture, inputs/outputs, interfaces, etc. In contrast, the practitioners simply want to know exactly what they have to do in order to get their jobs done. When you read the purpose of Organizational Process Description (OPD), one of the key messages is establishing and maintaining a USABLE set of processes and process assets. Therefore, in order for your processes and process assets to be usable by the practitioners, it doesn’t help if you provide them all of the process architecture, inputs/outputs, interfaces, etc. that the process engineers need and want. The simplest approach that I have seen for the practitioners is to provide a “swim lane” process flow chart. Then it is very easy for the practitioner to see where they fit into the process. Also providing good, as well as bad, examples of how a template or checklist should be filled out is also a good idea.
But keep in mind, that an approach that works in one organization for achieving “buy-in” may not work in another. You really need to work with the organization and jointly determine the best method for the organization. If most of the practitioners, for example, do not relate to visual process flows, then the “swim lane” approach may not work.
