Fix the Process First, or Document the One You Have?

You have decided to write things down. Reasonable. The question nobody answers first is whether the workflow you are about to document deserves to be preserved, and getting that backwards is expensive in a quiet way.

Should you document a process or fix it first?

Document when the workflow works and simply lives in someone's head. Repair first when people are already routing around it. Writing down a broken workflow is how a workaround becomes policy: it gets signed, laminated, and taught to every new hire, and now the bad version has institutional backing it never had before.

Why does documenting a broken process make things worse?

Because documentation confers legitimacy. Before it is written, a bad workflow is something people tolerate and quietly improve around. After it is written, it is the standard, and the improvements people were making become deviations from the standard.

You also lose the diagnostic signal. The workarounds were telling you where the process failed. Formalize the process and the workarounds go underground, where you can no longer see them.

What is the one-pass test?

Walk the steps once with the person who does the work, not the person who owns the outcome. That single pass tells you which situation you have:

• The steps are sound and merely undefined, and people follow them when they know them: document it.
• People know the official steps and have built a shorter path around them: repair the path before writing anything down.

One walkthrough, one afternoon. You are not looking for efficiency opportunities. You are looking for whether the written version and the practiced version are the same version.

What is the tell that a process is broken?

The phrase "supposed to." It arrives mid-sentence, usually from whoever is describing the workflow, and it never shows up when the written version and the real version match. "So then it goes to scheduling, and they're supposed to confirm within a day."

When you hear it, stop. That sentence marks the exact point where the process and reality separated, and the person saying it can usually tell you why in about thirty seconds.

How do you tell an inefficient process from a broken one?

An inefficient process is slow but honest: everyone runs it the same way and it takes too long. A broken one produces different outcomes depending on who is doing it, and it is the second kind that has to be repaired before documentation.

The reason is simple. You can document a slow process accurately. You cannot document an inconsistent one at all, because there is no single thing to describe. The attempt just picks a winner arbitrarily and calls it policy.

What if it is broken and you document it anyway?

Then you have chosen a version, and it will be the version that got described by whoever was in the room. That may be the right one. Nobody checked. Six months later new hires are trained on it, the exceptions have their own undocumented workarounds again, and the documentation project has to be redone.

Where should you start?

Take the process you were about to document and walk it once with the person who runs it. If they get through it without saying "supposed to," write it down this week; it is a genuine documentation job and it is worth doing.

If they say it twice, you have found something more useful than a missing document. Fix that first, then write. The order costs nothing to get right and a great deal to get wrong.