A flowchart written as sentences FLOW

Drawing a flowchart is the least useful part of having one

What matters is the set of steps and the arrows between them. Every minute spent dragging a box into alignment is a minute not spent noticing that one of your decisions has no “no” branch, and that is the defect a flowchart exists to expose.

So the diagram here is written rather than drawn:

Take the call -> Is it urgent?
      Is it urgent? -yes-> Dispatch now
      Is it urgent? -no-> Add to the queue

A line ending in a question mark is a decision and is drawn as one. Everything else is a step. Nodes come into existence by being mentioned, so there is nothing to create before you can refer to it, and the whole chart is one block of text.

Text is the format a chart should live in

Because it is text, it can be pasted into an email, put in a repository, compared between two versions with DELTA, and edited by somebody who has never opened a drawing package, which is most of the people who know whether the process is right.

That last point is the one that decides whether a chart stays true. A diagram locked inside a drawing file is updated by whoever owns the file, when they have time, which in practice means it is updated once and then describes a process that has since changed. A chart anybody can edit in a text box gets corrected by the person who noticed.

The layout is by longest path from the start, which is the arrangement that makes a flow read downwards in the order things actually happen rather than in the order they were typed. You get the tidy diagram without doing the tidying.

What to look for once it is on the screen

Read the decisions first. Every question needs both answers, and the missing branch is nearly always the unhappy one: what happens when the document is not there, when the person does not answer, when the payment fails. A process that only describes the expected case sends people to find somebody to ask, which is what it existed to prevent.

Then look for steps nothing points at, which are either unreachable or a missing arrow, and steps that point nowhere, which are either the end or a dropped thread. Both show up immediately in a laid-out chart and are invisible in the prose version of the same procedure.

Then count the hand-offs. Every arrow that crosses from one team to another is a place where something waits, and the number of those is usually the real answer to why the process takes nine days.

Nothing you type is uploaded. Nearby: SOP writes the procedure in words and names the defects a flowchart cannot show, ORGCHART builds a structure chart from an indented list the same way, Plan handles the critical path when the steps have durations, and CHECKLIST is what the flow becomes on the day.