One day early in my business analyst career, I was facilitating a meeting to resolve a gnarly technical issue. After much back and forth, some debate, and some arguing, I stood up and starting drawing the process – first from the user’s perspective (or the business process) and then from the technical perspective (or the system process).
It was a simple drawing, rather crude actually, but soon we understood where the gap was between technology we had and the business requirements. Soon we were having a very productive discussion about how to build a solution to the requirement.
As I matured as a BA, I learned to prepare these types of workflow diagrams before going into a meeting in the first place and use them to generate meaningful and focused discussion, as well as identify what questions needed to be answered. My meetings got more efficient and productive. I got assigned to more complex projects. All was good in the world.
A workflow diagram may capture a functional, technical, or a business process. It’s one of the many visual models that BAs use in their work. In what follows, I’ll list out the 7 steps that have served me well in creating workflow diagrams that improve project communication and lead to solutions to business problems.
7 Steps to Diagram a Workflow
- Identify the process. A process captures any repeatable set of steps. It is different from a project which captures a collection of work completed a single time to achieve a specific result. Look for work or activities that happen again and again in your organization.
- Name your process. When naming your process be clear and specific. Most often it makes sense to start with a verb. For example, “Collect Past Due Payments” is much more clear and specific than “Past Due Payment Process.” We have a tendency to use broad names to capture related activities, but as we’ll see in the next step, that leads to all kinds of problems.
- Identify a clear start point and end point for the process. The most common mistake we find while reviewing deliverables from Business Process Analysis participants is that they do not have a clear starting point or ending point. Visually this leads to models that have boxes off to the side and not integrated into the workflow diagram. Ask yourself: What’s the first activity that happens or what must be true before the process can start? What’s the last activity that happens or what signals that the process is complete?
- Identify your purpose for diagramming the workflow. Many of the decisions you’ll make in terms of granularity of detail and workflow scope will be driven by your reason for diagramming the workflow in the first place. You might be looking for the root cause of known errors, preparing for a automation project, or initiating a business process improvement project.
- List or draw out a series of steps that happen between the start point and the end point. Make sure that every step actually integrates into the diagram. Use decision boxes to capture variant flows. I highly suggest using pen and paper or the whiteboard for your first draft and avoiding complex tools, which only slow down your thinking and distract you from capturing the process-related information. (When I diagrammed the Business Analyst Career Roadmap, I created no fewer than 3 rough drafts on paper before capturing the diagram electronically.) In Business Process Analysis we frequently review first drafts that are scanned in from paper drawings. We’re easily able to correct any errors in thinking before the participant has committed the diagram to an electronic tool.
- Look for exceptions or rules that are possible at each step in the process. For example, if your main flow is to receive requests by phone, is email also an option? How is an email request handled differently than a phone request? Add this information to your visual model. Often a simple decision box, will be adequate to capture the variations.
- Refer to the standard elements of the Business Process Model and Notation (BPMN) and leverage any relevant symbols in your model. Don’t feel obligated to use more than 2 or 3 elements. Most BAs do not use the vast quantity of options available in the notation because they find it only confuses their stakeholders. As Adrian Reed mentioned in Avoiding Elitism in Your Business Analysis Techniques and Templates, your SMEs probably don’t care whether you use BPMN or a UML Activity Diagram. They want a flowchart they can easily understand.
That’s it. Follow these 7 steps and you’ll create workflow diagrams that improve project communication, help solve business problems, and move you forward in your business analysis career – because you’ll be the one getting noticed for being in the trenches getting real work done.
>>Get a Real-World Sample of a Workflow Diagram
We provide more detail about workflow diagrams and 21 other models BAs use in the Visual Model Sample Pack. The Pack contains 22 real-world visual model samples covering everything from UML diagrams to whiteboard drawings shared from the files of a working BA. You’ll be able to more easily incorporate visuals into your requirements process and get the process moving faster.