One of the things that crops up pretty early when you’re creating a process map is the question of how much detail you need to go into. If you keep to the high level stuff only, you won’t provide enough detail for anybody following the process to know what to do. If you go the other way and put in massive amounts of detail, you will quickly clutter up your diagram. It will add to the confusion rather than simplify things. And that is exactly the opposite of what we’re trying to do here.
So, what we need is a guideline that will help us find the middle path. I guess you could refer to this as the Goldilocks rule. “Not too hot, and not too cold”. Or, in this case “Not too much detail” and “Not too little”.
First, let me define a couple of terms. A task is the most basic of useful descriptions of work. It’s sort of like the atomic level of process. An activity is a set of tasks. You can think of that as the molecular level.
An activity box is simply that rectangular thing on the process map. It typically has a verb and a subject. For example, “Review submissions”. Using our definition there could be many tasks involved in the activity of reviewing submissions.
But when is a task an activity in its own right? And sometimes can’t tasks have their own subtasks? How do you deal with all that?
What I have found works the best is to treat a single activity box on a diagram as a sort of checklist of tasks that an individual performs on their own and in sequence. There is a simple test. Is it accurate to say “Joe does this bit of the process all by himself”? If the answer is “Yes” then it is safe to abstract all those tasks into a single activity box. If the answer is “No” then you need to break it up into separate boxes so that it’s true for each box. That sounds more complicated than it is, so let’s look at an example.
Suppose we have a set of sixteen tasks that the process requires us to complete. Let’s say that a single individual can complete six of these and then performs a hand-off to somebody else who does the remaining 10. To me, it seems pretty straightforward. The right way to do this is to draw two separate activity boxes.
Now, of course, the job of a process mapping flow chart is to capture what goes on in the process. And you want to do that in sufficient detail that somebody else can read what goes on and do it. So you’re going to have to record all the activities one way or another.
That means you’re going to want to record all 16 tasks. What is the right way to do that in this case? What I recommend is that you create two checklists, one for each activity box. So you have a checklist of six items on it and another checklist with a set of 10 items on it. That way you have captured the right amount of detail but you haven’t completely obscured what’s going on the process map.
Once you have the activities, you’ll need to find a way to summarize and that makes sense. You will have to find your own “verb and subject” that accurately describes the checklist.
Finally, a word of caution. This is a guideline, but not a golden rule. There might be times when it makes sense to create more than one activity box even though the same person performs the activities. I would say that if a checklist were more than 20 items it would be very ungainly. Take a good look and you will probably find at least one logical break. Then you would separate them into separate activities. Or, it might be that there is a natural grouping within a set of tasks and of course it makes sense to use that as a way of deciding where to put the activity boxes.
See the Process Mapping Pitfalls video for more on process mapping flow chart productivity.