Issues with Process Mapping

I’ve been using process mapping for over a decade now. I’ve probably been the recipient of more process maps than I’ve created, as I’ve had to implement changes that have already been designed by others. I’ve also had to talk many business users through the intricacies of their redesigned processes, especially if they (wrongly) hadn’t been designed by them. The most common scenario for me is where I’m asked to review process maps and assess how easily they could be implemented, bringing together knowledge of people, processes and IT/ICT.

Over that time, I’ve seen many sides for and against process mapping. I’ll discuss some of the issues and some of the methods for mitigating the risks associated with mapping processes.

1. Takes too much time

Mapping a process takes a long time. If that’s the only method that’s being used, then it will take longer than you expect. The only exception is that if you’ve been through similar exercises before, then you should already have some idea of how long it can take. To get a high level map is easy, to get to sufficient detail that a reader can understand the process takes a lot more time. This is time is extended if there is interaction with IT systems and different locations.

2. No standards

Some people map processes for a living. Worth bearing that in mind if you’re new to it. You can generally tell how much relevant experience a person has by looking at their output and any comments they attach to it. Have they picked a standard notation? Do all the decision points have two or more outputs? Are decisions labelled differently to process steps? And so on. Whatever the standard, a process map should be internally consistent. If a decision is a shaped as a diamond in one part of a map, then all decisions should be diamonds.

3. Conflicting standards

Assuming that the process-map author used a standard, it often doesn’t conform to the standard that the rest of the team are meant to be working with. The level of rigour required – as driven by an evaluation of potential risk – determines how closely diagrams have to conform to the standard. Some deviation is often permissible, and may even introduce new ideas, just bear in mind that a process map is a communication tool. The more standards people have to learn, the less concise and the less effective the tool becomes in communicating.

4. Not enough detail

The most common issue I see is that I receive just a process map. There has to be more information. The process map is a diagram of the process, but it isn’t the process itself, nor is it a complete description of the process. It is one tool for communication, there are others and analysts should some of these should be used. For instance, there should be a process description supporting the process map. This would provide the detail of each process step, providing elements that couldn’t be included in the diagram. Remember that a process map is a diagram and you’ll often need words to describe the process more completely. Words or pictures alone are often not sufficient, the combination of the two together work really well.

5. Too much detail

Better too much detail than too little. I’m always curious if there’s such a thing as too much detail in process maps since the aim is to capture everything so that it can be understood, replicated, changed and/or implemented.

My current answer to this is “yes”. Once you’re into the realm of mapping something that’s rarely done, has very little associated risk and you know you’re going to change it, then you don’t need much detail.

You also don’t need much detail if you’re just trying to scope out the activities of an organisation.

Another indication of too much detail is when an analyst has focussed on one area more than another such that most maps are high level and one is too detailed in comparison. So unless there’s reason to concentrate on that one area such as you know you’re going to be doing that in the following stage, I’d start to think that there’s too much relative detail.

6. Users don’t understand them

Process maps should be easy for users to understand. If they’re not, then question the standard; are you using the most appropriate standard? For instance, I noticed that early versions of UML Activity Diagrams confused users due to the diagonal lines making the sequence of events unclear. Many of those Activity Diagrams still included horizontal and vertical lines, but the standard permitted diagonals. Compare that to later versions of the Activity Diagrams. Now, I’ve no idea if it’s the standard or just best practice that means that most lines are horizontal or vertical, but either way, I’ve seen a change towards that practice.

It is also worth taking a key or legend with you or at least explaining it in person. Mention what a process step is, what a terminator is, what a gateway is and how to read them. Especially talk through the difference between parallel and sequential processes.

7. Users aren’t involved with them

This is stake-holder management. By and large, people resist change. Not involving users in the process mapping exercise increases the risk of resistance and increases inaccuracy. The fewer users, the greater the risk. Fortunately, it’s rarer nowadays to see the creation of process maps not involving any users. But take it a step further, instead of a review process, move some of the ownership or responsibility onto the users. That doesn’t mean that they should be responsible for creating the maps, but that they should be happy with their content and happy that they represent what they do.

8. Don’t have the tools

You can’t do process maps well in MS Powerpoint. You can get so far and do a very high-level sketch, but you can capture detail that way. Trying to results in a mess, a divergence from standards and a confused user.

At worst, use MS Visio. This should be the lowest level of IT tool you should use. Better still, find a purpose-built tool. Make sure you can export into a format that your audience can open and read. Test the export and read process a few times. Visio used to be a bit unpredictable in its export output, but that seems to have settled down a lot. All depends what version you’re using and what the diagram includes.

If you’re a bit old-school and use post-its on brown-paper. Tape the post-its down once the process is agreed.

9. Use PowerPoint

In contradiction to the previous point, PowerPoint has a very useful feature in that its main deficiency as a drawing tool can be thought of as an advantage; i.e. it constrains the complexity of the diagram. I use it to show value chains and simple process maps. The diagrams usually have 6-10 steps and little branching. For this brief, overview type of process map, PowerPoint is ideal.