There’s a version of your process that lives in the documentation. Clean steps, clear owners, logical sequence. Someone spent time on it. It looks right.
Then there’s the version that actually runs.
These two things are almost never identical. The real process has workarounds nobody wrote down, timing dependencies that aren’t visible in the diagram, and handoffs that work because two specific people have an informal agreement.
The documentation isn’t wrong, exactly. It’s just describing something that doesn’t fully exist anymore — or maybe never did.
The problem isn’t that processes drift. They always will. The problem is when organizations mistake the map for the territory and start making decisions based on the documented version rather than the running one.
Scott Andrew Alpaugh calls this the quiet failure mode: everything looks fine on paper right up until something breaks, and then nobody can explain why, because the explanation lives in the gap between the diagram and reality.
Good process work starts with watching what actually happens — not what’s supposed to happen. Where do people pause? What gets done out of order? What step always triggers a side conversation?
That’s your real process. Document that one.
The map should follow the territory, not lead it. When you reverse that, you’re not managing a system. You’re managing a fiction about a system.