The Workflow That Exists on Paper and Nowhere Else

Somewhere in a shared drive is a document describing exactly how a particular process is supposed to run: seven numbered steps, clear ownership at each stage, a defined approval point before anything moves forward. Ask anyone who actually does this work day to day, and they’ll describe something with five steps, a different order, and an approval that happens informally over chat rather than through the formal step the document describes. Both versions are technically “the workflow.” Only one of them is actually happening, and it isn’t the one anyone would find if they went looking for documentation.

Two Workflows Living Side by Side

This split — a documented process and a lived process that have quietly diverged from each other — is far more common than most teams would guess, and it rarely happens through any single deliberate decision to deviate. It accumulates the same way most drift does: someone skips a step once because it seemed redundant in that specific case, it works out fine, and the shortcut becomes habit. Repeat that pattern a few times across a few different steps and, over a year or two, the actual workflow has diverged meaningfully from what’s written down, without anyone ever consciously deciding the documentation was wrong.

Why Nobody Notices Until It Matters

Day to day, the gap between the documented and the lived workflow causes no visible problem, because the people doing the work know the real version and follow it consistently enough that outcomes look fine. The gap only becomes a problem at specific, high-stakes moments: an audit that checks actual practice against the documented standard, a new hire trained directly from the document who then behaves differently from experienced colleagues, an incident investigation that assumes the documented process was followed and discovers, mid-investigation, that it wasn’t. In each of these moments, the gap goes from invisible to suddenly, uncomfortably central.

What Usually Causes the Divergence

Cause	How it shows up
A step was redundant in most cases, so it got quietly skipped	Fine most of the time, risky in the minority case it existed for
The tool referenced in the document was replaced, but the document wasn’t updated	People follow the new tool’s natural flow instead of the outdated instructions
An informal shortcut worked well and spread by word of mouth	The improvement never made it back into the formal record
The original document was written by someone no longer involved in the work	No one currently feels ownership over keeping it accurate

Interestingly, not every divergence is a decline in quality — some represent genuine improvements the team found informally and never bothered to formalize. The problem isn’t that the lived version is always worse. It’s that nobody can rely on the documentation to reflect reality either way, which undermines its value as a reference for anyone who wasn’t already doing the work.

Auditing the Gap Honestly, Without Assigning Blame

Closing this gap starts with an honest comparison, done without treating deviation as a violation to punish. Observing the actual current process, step by step, and comparing it directly against the document — ideally by having someone who does the work walk through it in real time rather than describe it from memory, since memory tends to default back to the documented version even when actual practice has moved on. Framing this as “let’s make sure our documentation reflects what actually works” rather than “let’s find out who’s been cutting corners” makes it far more likely that people will describe their real practice honestly rather than performing the documented version for the person conducting the review.

Deciding Which Version Should Win

Once the gap is visible, each divergence needs an actual decision, not an automatic default to whichever version is older. Some lived shortcuts genuinely are improvements and should be formalized into the updated documentation. Others exist because a real risk the original step guarded against simply hasn’t materialized recently, and reverting to the documented version is the right call even though it will feel like a step backward to people used to the shortcut. Treating every divergence as automatically legitimate because “it’s what we actually do” is just as much a mistake as treating the original document as automatically correct because it was written first.

Making the Documentation Something People Actually Update

The deeper fix is addressing why the documentation drifted from practice in the first place: usually because updating it wasn’t anyone’s actual job, wasn’t easy to do, or wasn’t something anyone thought to prioritize amid other work. Assigning clear, ongoing ownership of a given workflow’s documentation to someone currently doing or overseeing the work, and making a small update the default response whenever a genuine, lasting change to the process happens, prevents the gap from reopening again a year after the first correction closed it.

Treating Documentation as a Reflection, Not a Constraint

Teams that keep documentation and practice aligned over the long term tend to treat the document as something that should track reality, updated whenever reality legitimately changes, rather than as a fixed standard practice must always conform to regardless of whether the standard still makes sense. That mindset shift — from documentation as law to documentation as an accurate, living reflection of current best practice — is what actually prevents the quiet drift from recurring, rather than just fixing it once and watching it slowly reopen the same way it did the first time.

The Special Risk in Regulated or Audited Processes

In workflows subject to formal audit or regulatory review, the gap between documented and lived practice carries a sharper risk than in an ordinary internal process, because the consequence of divergence isn’t just internal confusion — it can be a compliance finding with real external consequences. Teams operating under this kind of scrutiny benefit from treating documentation review as a standing, non-negotiable practice rather than an occasional cleanup effort, precisely because the cost of discovering a gap during an actual audit is dramatically higher than the cost of finding and fixing it during routine internal review. Ironically, these are often the exact environments where documentation drift is most likely to happen, because the formality of the documentation process can make people less inclined to admit, even to themselves, that the lived practice has quietly diverged from what’s officially on file.

A Quick Gut Check Any Team Can Run

Teams unsure whether they have this problem can run a simple, low-effort test: pick three recent instances of a given workflow, and have someone walk through exactly what happened in each, then compare that account line by line against the current documentation. If all three match cleanly, the documentation is probably in reasonably good shape. If even one shows a meaningful gap, it’s worth assuming the rest of the documented process has likely drifted too, since a gap significant enough to surface in a small, informal spot check is rarely an isolated exception rather than a sign of broader, unaddressed drift throughout the rest of the document.