Here are some ideas to help you get started with process documentation. First, recognize two things about mapping your processes.

1. Process documentation is not difficult, but it does require a certain skill set and some level of training. After all, one of your goals is to describe your processes in a consistent, standardized way. That will require a basic methodology and some definition of the desired output. Either engage an outside resource, or pick someone in your organization who is interested in this kind of work and get them some training.

2. Process documentation will not be done (or done well), if it's someone's third priority. We all know that no one can really do justice to that kind of work. So, make it an important project and dedicate the appropriate resources. It won't take forever, but for some period of time you need to allow those resources to focus on delivering a high quality result.

The easiest way to get started in documenting your processes is to first define the types of projects you do, and try to do this both by actual type of deliverable and by complexity. That second point often can be determined by how much new creative work will be required, such as new design, new photography, new copy, etc.

Then, look at how you are tracking projects today. Often there will be major milestones such as "initial creative review" or "design complete." Those milestones can be used to break your processes into big blocks. You shouldn't have more than four or five divisions at this point. These should represent your major sub processes. Another way to define these blocks is to look at hand-offs between functional areas in your organization. Of course, this only works if you actually have hand-offs from one resource to another. At this point it should be obvious that projects with new creative have additional work and approval loops at the front end, and projects with similar deliverables look very similar as you get closer to production. With just this information you can start determining some standard deliverable times based on the complexity of the project.

Now comes the fun part (at least if you are a "process geek"!). It's time to start documenting the activities that make up each of those major process blocks. The usual starting point is to sit down with the people doing the work (not the people managing the work!), and talk about their jobs. The following questions can help frame that conversation.

  • How do you currently get assigned the work you do?
  • What do you need in order to get started? (Information, copy, briefs, etc.)
  • What are the activities you go through in doing your job?
  • Does anyone review your work, either for modifications or for approval?
  • What is the output of work?
  • Where does your finished work go?
  • Does work ever come back, even after it's been approved?

This list could go on, but the basic idea is to get an understanding of the tasks, the inputs, the outputs, and any repeated approval cycles. Then start capturing that information in a visual way, making sure the transitions between those big blocks you defined earlier are well understood.

There are many ways to go with process documentation and analysis, but you need to start with the basics. Hopefully the ideas here will help you get started and on a path to improving your processes and your bottom line.