Defining and Documenting Processes

I have previously been a process owner. I've improved existing processes via different tools and techniques. Audited practices and interviewed actors, even chopped down the activities to a value stream map. But never before (that I can recall) have I been involved in the definition of a process.

In this case the actual process exists (people do actions in a certain order and with a desired outcome in mind), but it isn't documented. There are neither no metrics defined to see if the process is working fine or not.

To be honest, there is documentation. The problem is that there is too much documentation and it's scattered around different places in the intranet. So, in this case I'd be willing to abandon the old documents, try to extract the current process through interviews and workshops and write it down as simply as possible. Fortunately there are very nice tools available in the parent company that can be utilized.

Some general tips to avoid pitfalls (that seem rather common):

1. Keep things simple. Don't go too much into details.
2. Integrity. You don't want to have 18 different ways to describe a process flow.
3. Visulization is power. Figures clarify the message.
4. Somebody should have ownership of the documentation. That will help keep it alive.

 The list isn't exhaustive. But it will get you started.