There's a classic anti-pattern in process maps that I've seen a few times (thankfully, only a few). It's where you start, then you have activity A, followed by activity B, followed by activity C, followed by activity D, and so on until the end. What's wrong with this, you might ask? Well, there's no branching. Why do you even need a process map for that – a list of steps accomplishes the same effect? The problem is that it assumes that everything happens, in sequence, with no possible deviations. If only life was that simple.
A long time ago, I spent three months testing a voice system in Paris. I was a member of a dedicated testing team in London, and with the Paris office being smaller, they felt like they needed some help on a big, high-profile implementation. It was my first experience working overseas, and it was quite fascinating to experience the cultural differences – but never more so than my first meeting with the end client to review my draft user acceptance plan.
It wasn’t what they were expecting. They didn’t dislike it as such… but it was unlike any test plan that they had ever seen. I’d written test plan in line with the way that I was used to, which is to say it was almost completely focused on exception testing. Experience has taught me that developers usually get the main functionality right and check it in their unit tests... it's the things that they don't test that trip you up. My French colleagues loved the idea, they understood the reasoning immediately... it's just that they didn't do that. It turns out that their test plans went through each part of the specification and checked that it had been fulfilled. The idea of testing for what happened when the expected path wasn't followed was a completely new idea to them.
I'm telling this story because it is an example of the same cognitive bias that shows in the process maps that have no branches – we naturally tend to focus on the expected path for a given situation and neglect what might go wrong. Now, I have found that most people creating a process map have enough sense to know they should anticipate branching, but it's still surprising how often it is that even when people include branches, they only ever put in XOR gateways (as a reminder, these mean that the process progresses down exactly one path out of several, when it's entirely possible that a process might split to include two or more parallel paths). At the same time, the branches that a process shows often only consider alternative valid paths – what happens when something goes wrong gets neglected.
This is one of the key reasons why I think that what people most complain about with BPMN – its relative complexity – can actually be one of its main strengths. The existence of different types of branches (gateways, in BPMN jargon) should encourage us to think in terms of whether a given branch is single, multiple, or parallel. Likewise, the existence of different type of start event is a reminder to consider, are there multiple ways that this process could be triggered? If so, does the process always operate in the same way?
We're all prone to cognitive biases, off days and so on. This is why NASA astronauts do everything via checklists, not because they're morons who need to be micromanaged, it's because they're smart enough to know that we're all only human. In some ways, I find that the array of different BPMN
elements that exist work as a process mapping checklist – if you never, ever use the parallel gateway, then are you really sure that you're defining the processes correctly?