How to Diagram a Workflow

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

  1. 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.
  2. 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.
  3. 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?
  4. 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.
  5. 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.
  6. 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.
  7. 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.

Click here to learn more about the Visual Model Sample Pack

Stay informed about new articles and course offerings.

(You'll get a free step-by-step BA career planning course too).

Click here to learn more

your details are safe with us

Books and Courses You Might Be Interested In

Comments

  1. Wouter Nieuwenburg says:

    Hi Laura

    I totally agree on using diagrams.

    My addition/advice would be to start at the end of the process (often the trigger point), your step 3. A workflow will be triggered at some point and has to deliver something. So first find the trigger and if there is no trigger what is the point of the process? Next, who/what is/are the customer(s) of the process result and are the requirements for the end product
    Now find out what steps to take from the available information in this process in order to realize the end product. And every step has to add some value to the customer, this way your workflow will stay lean.

    Kind regards,
    Wouter

  2. mike Lachapelle says:

    Laura;

    A coupe of years ago I led a process mapping exercise for a large organization. This project involved 8 sectors of the National Office and 5 regions across Canada. We were very successful but is was a struggle, and in completing the project we learned some very valuable lessons that I have carried with me (and a great case study for the talks I give on business process modelling).

    1 – capture the story – to complete the project we had to work with 25 operations people who knew nothing about process mapping. Our first big challenge was aligning the view of analysts (schema based view) with business operations people (experience based view). To do this we started by taking the schema out of play, and concentrated on capturing the story (what has to be done and who does it).

    2 – Business is not always linear – much of the work flowed in a linear fashion that was easy enough to translate into process maps. There comes a point in the administration part of the process where the work becomes ad hoc, event driven and unpredictable. Force-fitting this into a linear mapping can lead to loss of credibility or loss of engagement with the clients. This was where BPMN and its approach to mapping events became a great solution.

    3 – Business is not logical – I have recently been on the client side of a process mapping exercise and watched two very experienced analysts drive every business person in the room crazy by telling people that this is how you map things. I almost lost it when they mapped 3 options as decision 1:y-n – decision 2: y-n – decision 3: y-n. Stop it. People do not think that way. Business is not done through a series of logical gates. When mapping decisions, do them the way business works – 1 decision, 3 options (this is another feature of BPMN). When working with business people, think like business people not automated solutions.

    Cheers