One of the most interesting things I encounter working with creative services organizations is how they view process. This covers a broad spectrum, from "we're creative, we don't DO process" to organizations with multi-level process diagrams in full Business Process Modeling Notation (or some other modeling language just as exact). But, two organizations, at different ends of this spectrum, may actually be operating very similarly. As a Six Sigma Black Belt, I've seen process maps for creative services that have resulted from Six Sigma improvement projects, but now just sit in a notebook or on someone's hard drive. So, even though the processes have been mapped, they are not being used in any effective way.

So, why should you document processes? Here are a few reasons:

  • Process Improvement--the first step to improving processes is to document the current process. Improvements can only really be made if the current state is understood.
  • Standardization--Standardizing processes is a way to help improve resource utilization and get better control of customer expectations.
  • Job Status Tracking--It's pretty hard to track job status if you don't know what the steps in a job are or what comes next.
  • Creation of Standard Operating Procedures (SOPs)--This is closely related to standardization, but it encompasses all of the information people need in order to correctly do their job.
  • Automation--A final reason for documenting process is for defining requirements for an automated workflow tool. If you can't define the process, there is nothing to automate.


Now, what should process documentation include? Well, a good starting point is process mapping. I like to use cross-functional swim lane maps since they really point out the cross-functional touch points, which are key places to look for misunderstandings that lead to process problems. But the process maps are just the start. High-level maps can be used to show cross-functional communications and dependencies.

Detailed maps, which capture all the activities or tasks, can be very valuable and can form the basis for operational definition. At this level, activities or tasks should also include things like inputs/outputs, resources, dependencies, checklists, and estimated durations. These can be used to help develop project scheduling, for training, for building SOPs and much more.

Finally, the process documentation can be used to drive requirements for automation. The trick here is to use the proper level of process granularity. Usually the detailed maps are too granular. I've seen organizations try to implement very detailed processes in workflow systems, and it usually results in lack of adoption because it requires more work to keep track of activities than it does to just do the work. So it's important to make sure the implemented workflow system isn't causing more work for users and actually negatively impacting efficiency.

Process documentation seems like a lot of work and, it is. But its benefits, when used properly, make it well worthwhile.