Why flowcharts are awful for business process mapping?

In business analysis, flowcharts are the standard method of uncovering and capturing workflows. We use them for mapping business processes, user journeys, automation logic and many more. And yet, flowcharts are the worst tool for business process mapping, and for business analysis in general.

Here is my full list of grievances: 

• Flowcharts fail as a tool for requirement analysis
• Flowcharts teach you wrong habits and lead you to ask wrong questions
• Flowcharts fail as a good communication tool with the stakeholders 

In the coming paragraphs I wish to persuade you to ditch flowcharts and convert to Universal Process Notation instead. Let's begin. 

Purpose of diagramming in business analysis

I recently came across a wonderful quote from Jodi Hrbek, author of 'Rock your role as a Salesforce admin":

“If you can't put it on a whiteboard, you can't put it in the system.”

― Jodi Hrbek

The role of a business analyst is to understand the 'why?'. Why does a customer/stakeholder need a particular feature? Why that feature and not another? Why solve this problem and not another? Why should it work this way and not another way? There is plenty of nuance and detail that we need to uncover when asked to implement a solution.

It is not to say that other questions, the 'What?', the 'How?' or 'When?' are not important. But without the Why? you could take any feature request verbatim (meaning exactly as stated) and execute the What? and the How? rather effectively. And with a good project manager, well-organized team, and good DevOps practices you could even nail the 'When?'. But that would delegate the IT team to a mere feature factory.  

Photo by Arno Senoner on Unsplash

When you operate as a feature factory, ironically the worst thing you could do is be an efficient feature factory. Because that means you will be contributing to feature creep and technical debt at an alarming rate. Within a few years or sooner the systems will not be used, performance will nose-down, and in effect the system will either have to be replaced or completely rebuilt. And then the cycle would continue yet again.

“There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.”

― Peter Drucker

The 'Why?' is the most important question business analysis is meant to answer. 'Why?' has the power of uncovering the hidden needs and changing the direction of the implementation. The tools and methodologies employed by business analysts should therefore focus on helping answer that most fundamental question. And it is for that precise reason why flowcharts fail as a tool for business analysis. They were not designed and are not being used to answer the "Why?"

Visualizing and understanding requirements

Let's take a look at a typical flowchart example:

Flowcharts capture What? happens. First A, then B. If true, we go to C, if false we go to D etc. Flowchart is nothing more than a visual algorithm. But they do not capture desired user outcomes or success conditions for capturing an event. We don't know Why? all those steps need to be performed, why in this order, and what is meant to be achieved. And you can pick up any example of a flowchart from the internet and you will usually see the same story. Different shapes with a yes/no conditions and barely anything else:

How is someone supposed to interpret those diagrams? How do we even begin to capture user stories or other development tasks to implement the solutions required to support those processes? Where will the test scripts and success criteria come from? They will come either from someone's imagination or a series of follow-up calls between the business analyst and the stakeholder and then the business analyst and the development team. Either way, there will be plenty of wasteful and unproductive activity.

While we are on the subject, I need to add that flowcharts are used extremely poorly to capture the 'What?' as well. As seen in the examples above, flowchart steps usually capture a general category of an event (e.g. “Brainstorming”), not the detailed activity or the how (e.g. “Use problem-solution mapping to come up with 10 different ideas”). They leave too much to interpretation and imagination. That is what I meant when I said that flowcharts teach bad habits.

In the craft that requires precision, flowcharts introduce, standardize and normalize ambiguity and confusion. 

 

Complexity

Ok, let's assume you are one of the unicorns. The business analysts who actually capture all the detail, conditions and scenarios. The business analyst who recognizes the difference between a 'token picture' and a detailed working document. Then your flowchart / BPMN diagram might look something like this:

Which leads us to the 2nd biggest issue with flowcharts: even when used well, they look poorly. A detailed flowchart is big and complex to read. You don't know where to start, where to find the information you are looking for, and you are constantly distracted by presence of elements and logic not relevant to the issue at hand. And it is not just inconvenient. It introduces unnecessary cognitive complexity and risk to your analysis.

Uncovering the hidden needs, jobs to be done and required workflows is hard enough without us making it even harder for ourselves. The more complex the picture we are working with, the more likely we are to make a mistake or miss important detail. The diagrams we use for analysis should be relatively small. Small enough to make the analysis easy.

Communication

Which brings us to the final reason we engage in diagramming: communication. Diagrams are extremely useful to help us, the business analysts and product managers, to understand the problem and design the solution. But once we understand it, we need to communicate it back to stakeholders / customers (to confirm we are correct) and to the development team (so they know what to build, how it should work, and why). And here is where flowchart's ultimate demise lies.

Photo by charlesdeluvio on Unsplash

Big and complex flowcharts overwhelm stakeholders. They are difficult to follow and make it unnecessarily hard to find relevant information. And on top of that, flowcharts by definition almost always require a legend to explain the symbols or colours being used. And on top of that, most of the time the description of What? actually happens is so vague or generic (e.g. "Evaluation", "Brainstorming", "Testing"), that it offers very little insight at all. I have never seen someone present a flowchart that did not need a guided explanation through the diagram.

Therefore flowcharts fail to serve as an independent, self-explanatory medium of communication. While we think of flowcharts as logical, detailed analytical tools, in reality they are more often than not just personal mind maps. If a diagram requires constant translation, is it not really serving its purpose as a medium of communication. We need a more effective method, a method that truly bridges the gap between us, our stakeholders, and the development team. 

Universal Process Notation to the rescue

Universal Process Notation is a modelling technique, officially endorsed by Salesforce as an essential skill for business analyst certification, that has two unique features:

• It supports only one shape : the box 
  
  
• It is hierarchical notation
  
  

UPN is the superior standard for diagramming business processes, job diagrams, user flow diagrams, and any content required to better understand the problem because:

• UPN is unique in that it puts emphasis on capturing verifiable outcomes/ success conditions for each step (the why? at the end of each box)
• U in UPN stands for Universal. The notation in UPN is extremely simple and easy to remember (one line, one box). Which means every diagram always looks the same. Stakeholders and even BAs do not have to learn each diagram with its unique legend anew. 
• Thanks to hierarchy, a complex, big workflow can be broken down into many diagrams in a hierarchy. Meaning we never stare at one big diagram, we can focus on a particular area of the process or wofklow. We work with a lot of simple pictures linked together, not one big and complex picture. This allows for process composability.  

The same process captured in flowchart and UPN

Ok, I am convinced. What’s next?

While UPN is simple and the most powerful modelling technique for business analysis, it is not a simple matter of just switching to this new notation. There are 2 things you will need:

• A proper tool: most diagramming tools are not built to support UPN notation which is still rather niche. To get the most out of it you should invest in a dedicated UPN tool. Right now I would recommend Skore or Elements.cloud, and with Elements.cloud there is the ability to register and use a free personal playground.
• Practice: UPN is simple to use but if you have never used it before or you are used to flowcharting then it requires practice to adopt new practices to get the most out of it.

If you would like to master Universal Process Notation, but even go beyond that, and become an expert in capturing and understanding the user problems, job to be dones, user flows and system automations, all as part of a unified, easy to read picture, then I would like to recommend my masterclass in Total Story Visualization: