Process mapping: where to start when nothing is written down

Most organisations that need process documentation have very little of it. The work has been done by the same people for long enough that writing it down felt unnecessary. Then someone leaves, or the team doubles, and the absence of documentation becomes a real problem. Starting from scratch is less complicated than it sounds, but the order in which you do things matters.

Start with the process that would cause the most damage if it broke ¶

The instinct is to start with something easy, to build momentum. That is understandable, but it tends to produce documentation for low-stakes processes while the high-stakes ones stay undocumented. A better starting point is to ask: if the one person who knows how to do this left tomorrow, what would break first? That is the process to document first.

This is not about pessimism. It is about prioritisation. Once you have identified the highest-risk process, everything else can be sequenced around it.

Interview the person who holds the knowledge, not the person who manages them ¶

The most common mistake in documentation projects is interviewing managers rather than practitioners. Managers often have a good understanding of what a process is supposed to look like. Practitioners know what it actually looks like, including the workarounds, the exceptions, and the steps that are not in any official guide.

Sit with the person who does the work. Ask them to walk you through the last time they completed the process, step by step. Record the conversation if they are comfortable with that. The goal is to capture what they actually do, not what they think they should do.

Write for someone on their first week ¶

Once you have the raw material from the interview, write the document for an audience of one: a person who is competent and motivated but has never seen this process before. That means defining terms that feel obvious to insiders, spelling out steps that feel too small to mention, and being explicit about who is responsible for each action.

Test the draft by asking someone who does not know the process to follow it. Where they get stuck is where the document needs more detail. This round of testing is the step most documentation projects skip, and it is the step that makes the difference between a document that gets used and one that sits in a shared drive.

Build in a review date before you publish ¶

A process document without a review date is a document that will be out of date within a year and trusted by no one within two. Before the document goes live, add a review date, a named owner, and a short note on what to check at that review. Six months is a reasonable default for most operational processes; twelve months for anything more stable.

The tools you use for this matter less than the habit of doing it. A well-maintained document in a shared folder beats a sophisticated knowledge management system that no one updates.