What is a flowchart: examples, definition, and a practical guide for PMs

Most project managers and analysts we know lean on flowcharts more than they'd admit, the way you'd lean on GPS in a city you only half know. Instead of digging through a long doc or a spreadsheet with many tabs, you look at one picture, and the sequence of steps is right there, together with the places where work usually gets stuck (ideally before somebody misses a deadline because of it).

We run projects ourselves, and over the years we've noticed that a useful flow chart takes a lot more than boxes and arrows; it's honestly a skill you get better at with practice. So in this guide, we'll go through the main types, say when we'd pick each one, show a flow chart example from a real project of ours, and share a few tips our team picked up the hard way.

TL;DR

• Think of a flowchart as a visual representation of the information flow in a process. Our rule of thumb: whatever you can't see, you won't fix, and a flowchart is the cheapest way to make a process visible.
• Each type of flowchart is good for one question. A process chart tells you the steps, a swimlane tells you who owns what, and some charts help you figure out why something broke, so pick the one that matches the question you've got on the table.
• The worst flowcharts we've seen tried to fit everything on one screen. Nobody read them. Split a big process into layers instead, so a person gets the picture in a few seconds and opens the detail only if they need it.

What's a flowchart?

A flowchart is a visual representation of a workflow, process, or system. It uses standard shapes and symbols like circles, rectangles, and arrows to map out steps, decisions, and handoffs. Each box in a flowchart represents a single process step, making even complex workflows easy to scan. This way of mapping a process creates a shared reference point that the whole team can use: PMs see the sequence, analysts validate the logic, and everyone understands what comes next.

Fun fact: the idea of flowcharts is about a century old. 

Back in 1921, the industrial engineers Frank and Lillian Gilbreth showed their “flow process chart" to the American Society of Mechanical Engineers, mostly as a way to describe factory work and spot wasted motion on the shop floor. 

About twenty years later, Herman Goldstine and John von Neumann picked up the same idea for planning early computer algorithms, and by 1970, ANSI had published a standard set of flowchart symbols that people in software engineering still use. Funny enough, the shapes have barely moved since then, even though what we draw with them has changed completely.

Why PMs and analysts use flowcharts

In our experience, most of the value comes from the conversation the team has while drawing the chart, because that's usually the first time everyone agrees on how work really moves instead of how each person imagines it does. That, to us, is the main role flowcharts play in a project, and it's why we sometimes call a flowchart a business process model you can put together in about 30 minutes.

For project managers

• Mapping project workflows. As soon as the process is laid out as a flowchart, you can see how a request gets from “new” to “done”, who picks it up at each stage, and where it tends to fall apart.
• Visualizing approval processes. When a request has to go through several departments, you want that route to be controlled and fairly predictable. On a flowchart the request has an obvious owner at every step, so when it stalls, you know whose desk it's sitting on.
• Onboarding new people. More often than not, new employees stare at a 12-page process doc for an hour and then ask the same questions anyway. Give them a single-page diagram and most of them get the basics before their first coffee break.
• Getting stakeholders on board. You'd rather show a director one picture than talk for twenty minutes. When stakeholders can actually see the plan, they get it faster, and they're a lot more relaxed about letting you run it.
• Picking between two options. Put two approaches side by side on the board, and the trade-offs usually become obvious within minutes, which makes decision making a lot less painful. A team we know had to choose between two technical options for a mobile feature, which is a pretty common situation in software development, and once both were drawn as flowcharts, it was clear which one had fewer dependencies and a shorter timeline.

For business analysts

Analysts we've worked with use flowcharts a bit differently. To them it's a process map: a way to take a business process that lives in twenty emails and turn it into something you can point at in a meeting. It also helps to organize information that comes out of interviews and old documents, which is usually a mess.

• Making the logic visible. Logistics, order processing, and workforce management: in business operations like these, a wrong step costs real money, and having the whole logic on one page helps people catch it.
• Checking efficiency. You can identify inefficiencies pretty quickly once you see where time and resources disappear inside complex processes, often in places nobody suspected.
• Spotting process improvements. Once the full workflow is up on the wall, it gets easier to identify areas worth fixing. Usually, it's a step nobody needs anymore, a loop where the same work gets redone, or a stage where tickets just pile up.

What are the common flowchart symbols? A quick reference

You can get surprisingly far with just six basic flowchart symbols. Here's the cheat sheet we keep pinned in our team space:

Ovals go at the very start and at the end point. Rectangles do most of the work, since each process represents one action someone takes and you'll end up drawing lots of them. A diamond means you stop and ask something: yes or no, approved or rejected, pass or fail. Write the answer on each exit from the diamond shape, and the flow continues along whichever exit fits.

Arrows set the directional flow. A step is allowed to have a bunch of incoming paths, like a rework loop sneaking back from QA, but there should never be any doubt about where things go next. Parallelograms mean something comes in or goes out of the process, say user input, a data entry form, or a report. And the small circle is a connector, handy when the chart spills onto a different page or when two parts sit so far apart that a long arrow would cross half the drawing.

Now and then, there's a rectangle with double-sided lines, too. It marks a predefined process that someone already documented, so you point to it rather than redraw it. Consider being pretty strict about one thing: every step gets its corresponding symbol, so people can see the decisions before reading any labels.

📌 Pro tip: before anything else, agree on a one-page note about what each shape means for your team. Half an hour, tops. We once had three people reading the same diamond three different ways, and that cost us a sprint review. Forget about Unified Modeling Language (UML) notation; a plain list does the job.

Types of flowcharts, with flow diagram examples

There isn't one type of flowchart that fits every situation, since different flowchart diagrams are made for different jobs. We usually pick one based on what we need right now, what we're trying to get out of it, and what the chart has to explain. Nothing wrong with mixing them either, we often layer two diagrams or create a custom flowchart diagram that steals a bit from each. Here are the ones we see teams use most, each with flowchart examples.

Process flow diagram: the basic flowchart

Good for: showing how users move through onboarding, checkout, support requests and other user experiences. It's also what most teams reach for with standard operating procedures, release processes, and pretty much any case where the question is just “What are the steps?” and you'll see mechanical engineers, software teams, and operations managers all using it.

A process flowchart, which some people call a flow process chart, lays out the different stages of a process in sequential order from start to finish. You'll come across this type more often than any other process chart, and chances are you'll draw it more often, too.

For almost any sequential process, a simple flowchart is more useful than a text description, because gaps and missing steps show up right away. If your team hasn't built a basic flowchart before, we'd start with this one, since it's the easiest to draw and the hardest to misread, which makes it great for simple processes and a decent first draft for the complicated ones.

Swimlane flowchart

Good for: processes where ownership really matters. For us, that's feature delivery, where one feature can bounce between four or five people before it ships.

In a swimlane flowchart, the process diagram is sliced into horizontal strips, one per person, team, or department, so it looks a bit like a pool. Lane names go on the left side of the chart, and each step lands in its owner's lane. So you get the steps plus the owners plus every handoff, all in one picture. Some people call it a cross-functional flowchart. What I like about a swimlane diagram is that it answers “who does what” in one look.

Most flowchart tools come with a swimlane flowchart template you can tweak to fit your team structure.

Workflow diagram

Good for: the business process your team repeats every single day, the kind you'd love to automate. It shows where time goes on repetitive tasks, and we use it for document flow too (who reviews what and when).

A workflow diagram is basically a process flowchart with more detail. On top of the order of stages, it shows who handles each one, which tools they use, and what triggers the next step.

Decision flowchart

Good for: approvals and triage. We've used one for “Do we escalate this bug or not?”, and a friend of mine drew one to pick a hotel in Hawaii, so the range is wide.

A decision flowchart (people also say 'decision tree' or 'decision map') opens with a single question. Each yes or no sends you either to the next question or to one of the potential outcomes at the bottom. If that sounds like code, it is. Computer algorithms are built on exactly this kind of branching, and anybody who's written an if/else in software engineering or computer programming will feel at home.

Data flow diagram

Good for: integrations and migrations, mostly, although we also pull one out whenever product teams or stakeholders start asking where customer data actually lives and who's allowed to touch it, because honestly nobody ever knows that offhand.

A data flow diagram (DFD), or a data flowchart as some people call it, doesn't really care who does what or in which order, and what it tracks instead is how data moves through an information system, from the place where a piece of data enters, through the processes that change it and the places where it gets stored, to wherever it finally leaves. That's why you won't find decision diamonds on it, only the data flows between parts of the system, and the whole thing is built from four kinds of blocks: external entities (users or other systems), processes, data stores, and arrows labelled with whatever data is travelling along them.

What we'd suggest is starting with a context diagram, where your whole system is squeezed into one box with the outside world around it, and only zooming in once that's clear, because half the time that single box is already enough to notice two tools that aren't connected and somebody retyping customer addresses by hand.

System / program flowchart

Good for: software design, technical documentation, and getting a new developer through complex programs or some legacy code that nobody has touched in years.

While a DFD stares at the data, a system flowchart looks at the machinery around it, so you'll see the inputs coming in, the programs that handle them, what ends up in storage and what comes out at the other end, with hardware, software and databases all on the same sheet. I like having one of these before anybody starts changing complex systems, since it shows what might break. A program flowchart is more like its zoomed-in cousin because it takes one piece of code and walks through the logic loop by loop and condition by condition.

Both of them use the usual flowchart symbols, plus a couple of technical ones you might not have come across yet, like the cylinder, which stands for a database, and the rectangle with a wavy bottom edge, which means a document.

Flowchart vs. other diagrams PMs use

People call a lot of things “a flowchart” that really aren't, and we've been guilty of that more than once. The easiest way to tell them apart is to ask which question you actually need answered, so it's worth glancing at the table before you start drawing, since there's nothing more annoying than spending an hour on a flowchart and only then realizing that the problem called for a timeline or a root-cause map.

Strictly speaking, the last two rows aren't flowcharts at all; they just keep turning up in the same meetings.

Fishbone diagram. You write the problem at the head of the fish and then work backwards, sorting the possible causes into bones like people, process, tools, and environment, and in our team it has become a regular part of retros and post-mortems. It gets really useful when you combine it with a flowchart, because the fishbone tells you why things broke, and the flowchart then helps you redesign that exact step, and if you want to see it in action, there's a full walkthrough in our fishbone diagram guide.

Influence diagram. This one tells a visual story about how decisions, uncertainties and goals push on each other. There's no beginning and no end, just a web of dependencies. We reach for it in risk analysis and strategic planning when we need to see which factors the result really hinges on and which “if-then” scenarios come with them.

How to make a flowchart in 7 steps

You really don't need any fancy flowchart software to get going, since sticky notes on a wall, a whiteboard, Miro, PowerPoint or Visio will all do the job, and most tools come with a flowchart template you can tweak anyway. When creating flowcharts, more important is who's in the room than the tool, so make sure the people who actually do the work are there.

1. Name the process, and make it one specific name at the top of the board, something like “Customer bug fix delivery". Though it seems trivial, a surprising number of arguments later on happen simply because two people had slightly different processes in their heads.
2. Set the boundaries and the level of detail. For us that usually means a five-minute debate about what kicks the process off and when it counts as done (say, “Client submits a request → Request fulfilled”), followed by a second one about zoom, i.e. whether you want one page for the overview or a close-up of a single phase. And if nobody can say where it starts and ends, put the markers down for now; you're not ready to draw.
3. Put each step on its own sticky note, one action per note, written as a verb plus an object, so you'd write “Reproduce the bug” rather than just “Bug”. Don't bother with shapes yet because right now all that matters is what happens.
4. Arrange the steps in order. We just shuffle the notes around until the sequence feels right and stick a little mark wherever the process can go two ways, and it's funny how often the forgotten steps pop up at exactly this point.
5. Add shapes and arrows when the arguing about order has died down. Each note gets swapped for its proper shape, the flow goes one way only (top to bottom or left to right, pick one), and every branch coming out of a decision gets a label.
6. Walk through it with the people who run the process, which means managers, of course, but also the folks doing the work every day and whoever's on the receiving end. It means literally walking it step by step and asking what happens after a request comes in, since they're the ones who'll point out the steps that only exist in real life.
7. Test it on real cases and revise. Grab two or three recent cases, ideally including one that went sideways, and push them through the chart. Anything that doesn't fit sends you back to step 3, and you can call it finished once anyone on the team can trace a case from start to finish without pinging you.

What to look for once it's done

A finished chart is really a diagnostic tool, so try to go through it slowly and keep an eye out for the following things:

• Unclear steps, meaning boxes that two people read in two different ways
• Bottlenecks tend to look like a box with arrows piling in from every side, because every case has to squeeze through that one step or person
• Waiting time: the gaps where work just sits there (it helps to mark them with the delay symbol)
• Rework, which you'll spot as arrows looping back to an earlier step
• Gaps in skills or authority, where you've got a step nobody has the know-how or the right to make the call on
• Duplication, like the same check being done twice in two different places
• Too many handoffs, with work bouncing between people or teams a lot more than it needs to
• Long cycle time, which is simply how long it takes to get from the first box to the last one
• Legacy steps, the ones still there only because “we've always done it this way”

Whatever you find goes into your improvement backlog, and in our experience fixing even one bottleneck does more for your team's efficiency than any shiny new tool would.

Example: from a flowchart to a working plan

Let's make this concrete with a bug a customer reported and follow that one process flow from a messy sketch to an actual schedule.

Step 1: Start with the basic flowchart

Ours went like this: Customer reports a bug → Support reproduces it → Is it critical? (yes: hotfix; no: next sprint) → Dev fixes it → QA tests the build → Did it pass? (no: back to Dev) → Release → Support lets the customer know. That's eight boxes and two diamonds, and it's probably the only time all quarter that everybody agreed on something right away.

Step 2: Split it into swimlanes

Once you split the same chart into four lanes, Support, Dev, QA, and Release, you see right away that the bug changes hands at least four times, or even more if QA bounces the build back, and every one of those handoffs is a spot where a ticket can sit for a day just because nobody noticed it had landed in their lane.

Step 3: Check it against the list above

Once we ran our bug flow through that list, three problems jumped out at us almost immediately.

First, there was a bottleneck. We had one QA engineer testing builds for three teams, so pretty much everything ended up waiting in line for that one poor guy.

Then there was rework. That “QA failed → back to Dev” arrow kept firing way more often than any of us expected, which basically means a lot of builds were getting tested twice.

And finally, waiting time. Bugs would just sit between Support and Dev for a day or two, and the reason was kind of embarrassing: nobody actually owned triage.

To be fair, the diagram did half the thinking for us. We picked a triage owner, asked devs to do a quick self-check before throwing a build over to QA, and spread QA time more evenly across the teams.

Step 4: Put it on a timeline

Here’s the thing a flowchart can’t do for you. It shows the order of the work, sure, but it tells you nothing about dates, or whether anyone even has time for it. The flowchart says “QA reviews the build after dev is done.” The plan says “QA reviews the build on Thursday, and Maria has four free hours for it.” Big difference.

So this is where we’d bring in a planning tool. Your boxes turn into tasks, lanes turn into assignees or teams, and arrows turn into dependencies. 

In Planyway for Jira, you’d see all of that on a Jira timeline grouped by assignee, with the dependencies drawn in. Then you open the Workload view and see right away if Maria’s Thursday is already packed.

Flowchart tips from real projects

Here are a few more tips from our team, things we picked up while building and using flowcharts on real projects.

Tip 1: Compare 3 possible scenarios

Harrington Emerson came up with a method he called “process idealisation”. You first draw the ideal version of the process, with no waste and no workarounds, and then draw the process the way it actually runs today. Every gap between the two goes straight into your improvement backlog.

While you're at it, sketch the failure paths as a third version. In our experience, a flowchart pays off most when it shows you the edge cases before they wreck the project.

Tip 2: If your flowchart doesn't fit on one screen, it's probably two flowcharts or more

Scope creep hits flow diagrams, too, believe me. Nobody can hold forty boxes in their head at once, so do one general flowchart for the overview and then a separate, detailed one for each phase.

Tip 3: Draft with sticky notes first

We almost never start with a tool. Sticky notes on a Miro board or on an actual wall let you move steps around without thinking about alignment, and all your attention stays on the logic. Make it pretty later.

Tip 4: Design for the reader, not for yourself

Before drawing a single box, think about who'll read it. A developer will happily trace every branch, but if you show the same chart to your CEO, you'll lose them by box six, so it's normal for one process to end up with two very different charts.

Turn your flowchart into a live plan with Planyway

A flowchart gets you about halfway. The other half is turning the process you mapped into a plan the team can follow, with real people, real dates, and real capacity.

That’s what we built Planyway for. Once you’ve moved your steps into Trello or Jira as tasks, Planyway puts them on one timeline across all your projects. You can check how loaded each person is in the Workload view and link tasks with dependencies, which shift on their own when something slips. And when the plan and reality stop matching, you just drag things around.