Mapping actual work vs planned work: why the gap is always larger than you think
Most organisations have process documentation. It exists in one form or another: a swimlane diagram on a shared drive, a Confluence page updated during the last audit, a PDF from the system implementation consultant. The documentation describes how work is supposed to move from intake to completion. What it almost never describes is how work actually moves.
The gap between planned process and actual process is a well-understood phenomenon in operations management. What is less well understood is how large the gap typically is, and how much of it is actionable. In our experience connecting Fluency to new customers' workflow data, the gap is consistently larger than the team expected, and the causes are consistently addressable once they are visible.
Where the gap comes from
Planned processes are built from assumptions. The person who documents a process writes down how it works when it works well, with the information that should be available, handled by people who know the system, in normal volume conditions. That version of the process is real; it is just not the only version, and often it is not the most common version.
Actual processes accumulate variance over time. A step that was supposed to take one day now takes three because the team it was assigned to grew without the process being updated to reflect the new ownership structure. An approval tier that was added after a financial control review in 2021 became redundant when the ERP controls were upgraded in 2023, but nobody removed it. An email step that was a temporary workaround for a system limitation became a permanent fixture because changing it required IT involvement and was never prioritised.
These variances accumulate quietly. Nobody decides to make the process worse. Each individual change makes sense in context. The result, over two or three years, is a process that looks like the documentation and operates very differently.
What the gap typically looks like in data
When we pull workflow event data for a process and compare it to the process documentation, the most common discrepancies fall into four categories.
Extra states: steps that occur in the actual workflow but do not appear in the documentation. These are usually workarounds, informal quality checks, or coordination steps that emerged organically. In one procurement process we analysed, the documented process had six steps. The event data showed an average of nine distinct states per transaction, with the three undocumented states accounting for 31% of average cycle time.
Skipped steps: documented steps that rarely or never occur in practice. Sometimes these are steps that were made redundant by a system change but not removed from the documentation. Sometimes they are steps that feel optional in practice and get skipped under time pressure. When a skipped step is a control step, this is a compliance risk. When it is an unnecessary step, it is documentation debt that is misleading future decisions about the process.
Wrong sequence: steps that occur in a different order than documented. This is less common but more consequential. If the documentation says step B follows step A but the data shows that B and A often happen in parallel or that B sometimes precedes A, then any automation built against the documented sequence will need exception handling for the actual sequence.
Different volumes by path: the documentation shows a single process flow, but the data shows that different transaction types take materially different paths through the process. A purchase request under $5,000 might touch three steps. One over $50,000 might touch seven. If your baseline calculation treats all transactions as following the documented single path, your volume and cost estimates will be wrong.
Why the gap is usually larger than teams expect
People who work in a process are not in a good position to observe the gap. They know their own part of the process well. They know the pieces they interact with directly. They do not have visibility into how the entire transaction moves from start to finish, across all the people and systems it touches.
This is not a failure of diligence. It is a structural feature of how complex processes work: no single person sees the whole thing. The only way to see the whole thing is from the data, and most organisations have not routinely looked at their process data from this angle.
When you show the full actual process map to a team that has been working that process for years, the reaction is consistently one of recognition: people see their own workarounds reflected in the data, they see the steps they knew existed but were not official, and they see the delays they had always attributed to individual variation but the data shows are structural. The map is not a surprise in its details; it is a surprise in its totality.
Closing the gap before automating
The practical reason to close the planned/actual gap before automating is straightforward: automation built against the documented process will encounter the actual process at runtime, and the discrepancy will generate exceptions. Those exceptions require human handling, which is exactly what the automation was supposed to reduce.
Closing the gap does not mean making the actual process match the documentation. In most cases, the actual process reflects adaptations that made sense. The goal is to understand what the actual process is, decide which elements are intentional (and should be formalised) and which are unintentional (workarounds and accumulated variance that should be eliminated), and then document and automate the actual intentional process.
This is not a month-long exercise. With event log data covering three to six months of process history, a well-structured workflow analytics tool can reconstruct the actual process in a matter of days. The review and decision of what is intentional versus unintentional is a facilitated conversation with the process stakeholders, usually one or two sessions of two hours each.
The gap is not a failure of your organisation. It is a normal consequence of how processes evolve over time. Measuring it systematically, rather than discovering it during an automation implementation, is the difference between a project that delivers its projected savings and one that spends half its budget on exception handling.