Back to Insights

    The 30-Minute Process Map Your Team Draws

    Most process documentation is written by someone who does not do the work. Here is a half-hour method that surfaces the disagreements that matter.

    September 12, 20265 min read
    process documentation
    operations
    workflow design
    smb growth
    operational efficiency
    sop

    Why does most process documentation fail?

    Because it is written by someone who does not do the work. An outside interviewer asks one person how the process runs, writes it down accurately, and produces a document that describes what one person believes. Everyone else reads it, notices it does not match their day, and quietly ignores it.

    The document is not wrong about the steps. It is wrong about who it asked.

    What does the half-hour version look like?

    Put the three people who actually touch the process in the same room with index cards, and run it in five moves.

    1. Each person writes their own version of the steps on their own cards.
    2. No discussion while they write. Discussion produces consensus, and consensus is what you are trying to avoid at this stage.
    3. Lay the cards side by side in sequence.
    4. Read across. The places the cards match are the settled part of the process. The places they disagree are the process.
    5. Write the one page from what survives.

    Why do the disagreements matter more than the agreements?

    Because the matching cards describe work that already runs without intervention. Nobody is losing time there. The gaps between the cards are where the work actually gets decided, and where it silently gets decided differently depending on who is on shift.

    A flowchart that shows only the agreed steps is a picture of the part that was never broken.

    Does this replace a real SOP?

    It produces a better one, and faster. The page that comes out of this session describes the process as it runs rather than as anyone imagines it, which is the difference between documentation people follow and documentation people work around.

    If the process turns out to be broken rather than merely undefined, that shows up here too, and it shows up before anyone has spent a month writing a manual for a workflow that needs redesigning.

    Why no software?

    Because the tool becomes the project. A process mapping application asks for a structure before anyone has agreed what the structure is, and the session turns into a discussion about swimlanes. Index cards impose nothing. That is the whole reason they work.

    Who should be in the room?

    The people who touch the process, not the people who own the department. Seniority in the room changes the answers, because juniors write down what they believe the senior wants to see. If a manager needs to attend, they observe and do not write a card.

    What do you do with the result?

    Take the largest disagreement and settle it, in writing, with a name attached. One decision, one owner, one line. Then rerun the exercise on the next process.

    Most operations have somewhere between six and ten processes that matter. At half an hour each, the whole map is a couple of afternoons, and it was drawn by the people who have to live inside it.

    Curious how we think about operations work?

    Our alignment framework shows where strategy, work, and systems drift apart — and how to close the gap.

    See the framework

    Related Insights

    Yes, There Is an API. Does It Carry the Numbers You Need?

    The software has an API. The numbers you want may not be in it. What to ask before anyone promises an integration, and what an honest scope looks like.

    Why Can't We Use the Feature the Demo Showed?

    The demo showed it working. Your account does not. The three forms the demo gap takes, and the checks to run before you plan anything on a system.