Process Improvement: Why Gains Fade (The Documentation-Reality Gap)
Avery Brooks
July 20, 2026
Seventy percent of process improvement initiatives fail. Not "fail completely"—most projects deliver some value. But they fail to stick. A Lean Six Sigma team completes a project. Cycle time drops 30%. Process variance decreases. The improvement team celebrates and moves to the next project. Six months later, cycle time has drifted back up. Performance has improved relative to the baseline, but the full benefit has eroded.
The reason improvement initiatives fail to stick isn't that the methodology is wrong. Lean and Six Sigma methodologies are solid. The reason they fail to stick is that the improvement team designed a better process based on the documented process, not the actual process. And when the actual process reasserts itself, the improvement erodes. This is how the transformation knowledge gap manifests in process improvement—for a complete look at how this challenge shows up across different transformation contexts, read "Transformation by Type: How Knowledge Gaps Manifest Across Different Transformation Contexts."
Most process improvement projects follow the same pattern. A process is mapped. Waste is identified. The process is redesigned. The improvement is implemented. Metrics improve. The project concludes.
But this pattern assumes that the process was correctly mapped. That the documented process is the actual process. In most organizations, this assumption is wrong.
Process documentation focuses on the main workflow. "Receive order → Pick product → Ship order." But there are exceptions. Orders with missing information. Customers who don't want the standard shipping method. Products that are on back-order. These exceptions are real work, but they're invisible in happy-path documentation.
An improvement project optimizes the happy path. They reduce steps, eliminate redundancy, improve coordination. The happy path becomes much more efficient. But the exceptions remain. The exception workflow still requires manual steps, workarounds, and hand-offs.
The result: the happy path is faster, but the overall process hasn't improved because exception handling is still inefficient.
Process documentation shows the formal workflow. What's missing is informal coordination. A formal process is "Pass completed work to the next team." The informal process is: "Pass completed work to the next team, then call the team lead to make sure they got it, then follow up if you don't hear back."
An improvement project sees the informal steps as waste and eliminates them. But the informal steps exist for a reason. They're a workaround for communication gaps or reliability issues in the formal system. When improvement eliminates the informal steps but doesn't fix the underlying issue, people re-create the informal steps.
The result: the formal process looks efficient, but teams have recreated the workarounds because the system needs them.
A process improvement consultant observes a workflow and asks: "Why do you do this step?" The response is: "Because the system doesn't handle it automatically." The consultant thinks: "That's a constraint we can design around." The process is redesigned without that step. The improvement is implemented.
But at go-live, the constraint reasserts itself. The system still doesn't handle it automatically. The step is necessary. The team recreates the step manually, and the improvement unravels.
A process improvement team designs a better way of working. They implement it. They train the teams. The project concludes. But the teams didn't participate in discovering the problem, designing the solution, or testing it. They adopted an improvement that was designed for them, not by them.
When the improvement team leaves, the knowledge of why the new process works, how to maintain it, and how to improve on it leaves with them. The frontline teams don't have that knowledge. When something breaks or a circumstance changes, they can't adapt the improvement. They revert to the old way.
A process improvement project redesigns a workflow around a system's capabilities. The system can track inventory in real-time. The improvement eliminates manual inventory checking. But six months later, the system has an outage. Inventory tracking is down. The team has no manual process to fall back on. They have to improvise. And when the system comes back up, they're not confident the real-time data is trustworthy. They revert to manual checks.
The improvement depended on system reliability that wasn't guaranteed. When the assumption was violated, the improvement failed.
Process improvements that stick share a common characteristic: they were designed based on understanding how work actually gets done, not just how it's documented.
Interview frontline staff about how they actually do work. Ask about the informal steps. Ask about the exceptions. Ask about the workarounds. Ask what they do when the system doesn't work the way it's supposed to.
Record the actual workflow, including the informal and exception cases. This is the process improvement should be based on.
Each exception and workaround exists for a reason. An order with missing information exists because the data entry system doesn't have required fields. A manual check step exists because the system sometimes produces unreliable data. An informal coordination step exists because teams can't rely on the formal communication channel.
Improvement shouldn't eliminate exceptions and workarounds. It should eliminate the root causes. Fix the data entry system so it captures the required fields. Fix the data reliability issue so teams can trust the output. Fix the communication channel so informal coordination isn't necessary.
A process improvement assumes the system will work reliably, staff will be consistent, and nothing will change. Reality is messier. Staff changes. Systems have outages. Customer demands shift. Business conditions change.
Design the improved process with fallbacks and flexibility. "If the system is down, here's what we do." "If this step fails, here's how we recover." "If circumstances change, here's how we adapt."
Don't design an improvement and hand it to teams. Design it with teams. Have them participate in discovering the problem, designing the solution, and testing it. When teams understand why the improvement works, they can maintain it and adapt it.
Don't conclude the improvement project and assume the improvement will stick. Build a mechanism to monitor how the improvement is performing. Weekly huddles where teams surface issues. Monthly metrics reviews to check if improvement is holding. Quarterly deep-dives to identify new opportunities.
If the improvement is degrading, you'll know quickly, and you can intervene. If circumstances change, teams have a mechanism to request adjustments.
Organizations that design improvements based on actual processes see dramatically different outcomes:
60-70% of improvements still in place 6 months after implementation. Because the design accounted for exceptions, constraints, and the informal structures that make work real.
40-50% improvement in employee engagement with improvement. Because employees participated in discovering the problem and designing the solution, rather than having an improvement imposed on them.
30-40% reduction in implementation rework. Because the design was tested against actual conditions before implementation, and fallback procedures were built in.
Significantly higher adoption of continuous improvement culture. Because teams experience improvement that sticks, they become more engaged with the next improvement initiative.
Process improvements fail to stick because they're designed based on happy-path documentation, not operational reality. Improvement teams don't see the informal coordination steps, the exceptions that represent 20-30% of actual work, or the constraints that make workarounds necessary. When improvement eliminates these invisible elements, teams recreate them.
ClearWork enables improvement design based on actual processes through AI-driven interviews with frontline staff. The platform surfaces the informal coordination steps teams use, the exceptions and edge cases they handle, the workarounds they've created and why, and the constraints those workarounds manage.
This intelligence becomes the foundation for improvement design. Rather than optimizing the happy path, improvement teams can design for the full complexity of actual work. When you understand why a workaround exists, you can fix the underlying constraint instead of eliminating the workaround. When you know that exceptions are 20% of volume, you design the improved process to handle them. When you capture the informal coordination that makes the system work, you can redesign it rather than eliminate it.
The result: improvements are designed for how work actually happens, which means they stick.
A: Most process improvements fail to stick because they're designed based on happy-path documentation (60-80% of work) and ignore the exceptions, workarounds, and informal coordination that represent 20-40% of actual workload. When improvement eliminates workarounds without fixing the constraints that created them, teams recreate the workarounds. When improvement eliminates informal coordination steps without addressing the underlying communication gaps, teams reinvent them. When improvement doesn't account for exceptions, exception work remains. Within 6-12 months, improvement erodes as the invisible 20-40% reasserts itself.
A: Sustain improvements through continuous monitoring and governance: (1) Weekly huddles where teams surface emerging issues and whether improvement is holding; (2) Monthly metrics reviews to measure if benefits are stable or eroding; (3) Quarterly deep-dives to identify new improvement opportunities and refresh the team's engagement; (4) Investigate if teams start reverting to old approaches—usually it's because the underlying constraint hasn't been fixed; (5) Build flexibility into improvement to account for system changes and business condition shifts. Organizations that monitor improvement continuously catch drift early and can intervene.
A: Processes with many exceptions need improvement design that accounts for exception volume. First, understand what percentage of work is exceptions (often 20-40%). Second, understand why each exception exists—what constraint or variation makes it necessary. Third, design improvement for both the happy path and the key exceptions. Rather than eliminating exceptions, eliminate the constraints that make them necessary. If an exception is 15% of volume, the improved process must handle it efficiently, not treat it as an outlier. When improvement accounts for exceptions, the improvement sticks because the full reality of work has been addressed.
A: Build continuous monitoring into improvement governance. Weekly huddles where teams surface problems. Monthly metric reviews to check if the improvement is holding. Quarterly deep-dives to understand if workarounds are re-emerging. If teams start reverting to old approaches, investigate why. Usually it's because the underlying constraint the workaround managed hasn't actually been fixed, or a new constraint has emerged.
A: Identify what gaps the workarounds are managing. If teams manually maintain a spreadsheet because the system doesn't have a report, design the improvement to either build that report into the system or establish a formal, efficient process for maintaining the spreadsheet. Don't assume system gaps will be fixed. Design improvement with the system's actual capabilities in mind, or design with a specific plan to fix the gap.
Before your next improvement project starts, spend two weeks interviewing frontline staff about how work actually gets done. Ask about the informal steps, the exceptions, the workarounds, and the constraints. Map the actual process, not the documented process. Your improvement will address the real problems, not the ones on paper.
Seventy percent of process improvement initiatives lose 50% of their benefits within a year because they're optimized around happy-path documentation and don't account for the exceptions, workarounds, and informal coordination steps that represent actual work. Organizations that design improvements based on how work actually happens—including exceptions, constraints, and workarounds—see improvements that stick: 60-70% of improvement benefits remain 6 months after implementation. When improvement teams understand why workarounds exist and design to eliminate the constraint rather than the workaround, improvements are sustainable.