Process Improvement Methodologies: The Gap They All Skip

Think of a process improvement project the way you think of a building renovation. The architects survey the flaws, draft the new blueprint, the contractors rebuild, and the owner walks through the finished space on the final day and signs off. The renovation is done. What nobody plans for is what happens on day two: whether the people who work in the building use the new layout the way it was designed, or drift back to the old paths because the old paths are still there.

Process improvement methodologies are four of the most rigorous tools management science has produced. Six Sigma, Lean, Kaizen, and the Theory of Constraints each solve a real problem in a real way. Understanding what each one does is worth your time. What is worth even more time is the question the renovation analogy surfaces: what happens after the project closes?

Process improvement methodologies are structured frameworks for making a repeated process better: they find defects, eliminate waste, or remove bottlenecks and then design a superior standard. The gap they share is that none of them measures whether people are running the new standard after the project team packs up.

What does each process improvement methodology actually do?

Start with W. Edwards Deming’s PDCA cycle, because it is the scaffolding the other four sit on. Plan, Do, Check, Act: design the change, run a pilot, measure the result, then standardize or adjust. Deming built it on Walter Shewhart’s statistical quality work in the 1930s, and every methodology below is essentially a specialized application of the same loop (Deming, Out of the Crisis, 1982). The cycle is the logic; the methodologies are the instruments.

Six Sigma. Motorola engineers invented it in 1986 as a continuous improvement methodology to solve a specific problem: variation in manufacturing outputs that caused defects. The goal, encoded in the name, is to reduce defects to 3.4 per million opportunities, which corresponds to six standard deviations from the mean. The operational tool is DMAIC: Define the problem, Measure baseline performance, Analyze root causes, Improve the process, and Control the improved state. GE’s Jack Welch famously made it a management religion in the 1990s, and it spread from factory floors to hospitals, financial services, and software teams. Statistical rigor is its strength. The Control phase is designed to hold the gain. What it controls for is variation in the output, not the question of whether frontline workers are running the new procedure.

Lean and Lean Six Sigma process improvement. The Toyota Production System developed across the 1950s and 1960s under Taiichi Ohno, and James Womack and Daniel Jones named and codified it as “Lean” for Western audiences in The Machine That Changed the World (1990). Organizations that combine both frameworks call the pairing Lean Six Sigma. The core question is: what steps in the current process add no value from the customer’s perspective? Waste, or muda, comes in seven forms in the original Toyota framing: overproduction, waiting, transportation, over-processing, inventory, motion, and defects. Lean’s tool set, Value Stream Mapping, standard work, 5S, pull systems, speeds value to the customer by removing the steps that slow it down without adding anything. Ohno’s standard work, in particular, is the best-known attempt to capture and enforce the right way to do a task. The challenge is that a Value Stream Map on a wall is not the same as the process being followed on the floor.

Kaizen methodology. Masaaki Imai introduced the term to Western management in his 1986 book Kaizen: The Key to Japan’s Competitive Success. Where Six Sigma runs periodic, project-based improvements led by certified specialists, Kaizen is daily, incremental, and owned by frontline workers. The idea is that the people closest to the work see the waste first, so improvement is most reliable when it is built into their daily habits rather than handed down from a project team. Kaizen events (or “blitzes”) are intensive 3-to-5-day sprints where a cross-functional team redesigns a work area or process. The limitation is the one every practitioner recognizes: gains made in a Kaizen event erode when the event ends, because the conditions that created the old behavior (habit, tool layout, missing signal) return faster than the new behavior takes hold.

Theory of Constraints. Eliyahu Goldratt introduced it in his 1984 novel The Goal, and it is the most contrarian of the four. Rather than improving every step of a process, TOC argues that there is always one constraint, the single bottleneck limiting total throughput, and that improving anything other than the bottleneck is waste. The five focusing steps are: Identify the constraint, Exploit it (get the most from it), Subordinate everything else to the constraint’s pace, Elevate it (invest in removing it), and repeat. It has been applied to manufacturing, project management (Critical Chain), and supply chains. The insight is sharp and often missed: organizations routinely optimize local steps while leaving the actual bottleneck untouched. What TOC does not tell you is whether the bottleneck fix was adopted by the team, or whether the new priority ordering is being followed when the consultant leaves.

What gap do all process improvement methodologies share?

Here is the pattern, and it holds across all four. The methodology runs a project: data is gathered, root causes identified, a better standard designed. The project closes. And then, somewhere in the space between the project’s end and the next measurement cycle, the improvement either sticks or it does not.

A 2007 McKinsey study of 1,200 organizations found that 70% of large-scale change programs fall short of their goals. The most common explanation was insufficient attention to the organizational and people elements: whether people understood the new way, whether they had the support to adopt it, and whether adherence was inspected (McKinsey Quarterly, “The irrational side of change management,” 2009). A process improvement project is a change program. The McKinsey finding applies directly.

Six Sigma has a Control phase precisely because Motorola knew this problem. But Control, in practice, means tracking output metrics for a period after the project closes, not measuring whether each person is running the new procedure on each piece of work. The DMAIC project does not have a field for “is Alex following the revised call review checklist on the twelve deals in his pipeline right now?”

The same gap opens in Lean. Womack and Jones described “islands of excellence” in Lean Thinking (1996): areas of a factory or office that ran Lean beautifully while the departments around them did not, and the island eventually reverted because the system around it stayed the same. Standard work captures the best-known way to do a task, but standard work posted in a binder is not standard work being done. Ohno knew this: the Toyota Production System included daily rounds by managers (Gemba walks) specifically to observe whether the work was being done as designed. The observation is the thing.

Kaizen makes the same assumption: that once a better method is found in the event, it will persist. The research says otherwise. A study published in the Journal of Manufacturing Systems (2008) reviewed Kaizen events across multiple industries and found that approximately half of the gains eroded within six months, largely because the event-based change was not integrated into daily measurement and reinforcement (Melnyk, Calantone, Montabon, et al., 2009). The event designed the new behavior; nobody inspected it afterward.

Why does adoption fail after a process improvement project?

The cognitive science here is not flattering to pure information-based change programs. In 2001, Jeffrey Pfeffer and Robert Sutton published The Knowing-Doing Gap, which documented systematically that knowing the right thing to do and doing it are separated by a gap that talk alone cannot close. Their research across dozens of organizations found that lectures, presentations, and even well-received training sessions rarely changed what people did when they returned to work, because the conditions at work (habit cues, friction, immediate feedback, what the manager tracked) outweighed what was taught in the room (Pfeffer & Sutton, The Knowing-Doing Gap, 2000).

This is the underlying reason the McKinsey 70% failure rate exists. The methodology redesigns the process correctly. The team learns the new standard genuinely. Then they return to the same physical workspace, the same CRM, the same manager who asks the same questions in the weekly meeting, and the old behavior paths are still the fastest routes. Behavior is sticky because behavior is a system, not a decision.

The practical implication: a process improvement project that does not answer the question “how will we know if this standard is being followed, by which person, on which unit of work, in real time?” has designed a solution and left adoption to chance. Chance has a 70% failure rate.

What the methodology cannot do, and what you have to add

Here is where the conversation gets concrete for knowledge-work teams, which is most of the organizations running Lean or Six Sigma today in non-manufacturing contexts.

In a factory, the work is visible. A manager doing a Gemba walk can see whether the operator is following the standard work or not. The act is observable. In a sales team, a service team, or an operations team working through software, the work is largely invisible. Whether a rep followed the discovery protocol on a call, whether an onboarding specialist ran the right checklist on a new account, whether a customer success manager logged the right information after a renewal conversation: none of that is visible to a manager without either sitting in on the call or pulling individual records to reconstruct what happened.

This is the problem that the methodology’s Inspect phase was not designed to solve, because in manufacturing, inspection was a physical observation. In knowledge work, you need a system that makes the process visible at the moment it is being executed, not a week later in an audit.

The answer is to treat adherence as its own measurable output. Define what “following the new standard” looks like at the level of a single unit of work. Build the inspection into the flow of work rather than into a separate audit cycle. And give managers a signal that surfaces drift before it becomes a six-month erosion.

That is not a new methodology. It is the adoption layer that every methodology assumes is someone else’s problem.

For sales and revenue teams, the closest analog is process documentation that lives where the work happens. A standard buried in a wiki requires a tab switch and a memory cue, two things that do not reliably occur under quota pressure. A standard that surfaces in the tool the rep is already using at the moment they need the next step is a fundamentally different object, because it reduces the friction between knowing the right action and taking it.

Supered is one concrete instance of this: the Behavior Layer that sits inside HubSpot or Salesforce and surfaces the process requirement in the moment of work, then inspects whether it was followed, deal by deal. Whether or not that is the right fit, the question it answers is the one every process improvement methodology leaves open.

For a deeper look at the standard-work approach that underpins all four methodologies, the post on standard work covers Ohno’s three elements and why the stable baseline matters before any improvement cycle runs. For the process documentation side, workflow documentation shows how to capture the handoffs that matter most.

What we recommend

Apply the right methodology to the right problem, then treat adoption as a separate discipline that begins where the project ends.

• Process is slow or cluttered. Start with Lean. Map the value stream, name the waste, redesign the flow.
• Outputs are inconsistent despite a clean flow. Six Sigma’s DMAIC is the right instrument. Measure variation, find root causes, control the gain.
• Improvement stalls at the team level. Kaizen events build the habit of continuous improvement from the floor up. But plan the post-event inspection cadence before the event closes.
• Speed is not improving despite local optimization. Theory of Constraints will find the constraint nobody is talking about. Elevate it before touching anything else.

In every case, the project ends at the design of the new standard. The adoption question starts there. Name the unit of work you will inspect. Define what following the standard looks like at that level. Build the inspection into the flow of work. Measure adherence alongside outcomes. Accept that a 70% failure rate is not an indictment of the methodology; it is a measurement of what happens when adoption is left to chance.

The renovation is finished. Whether people use the new layout is a different project. Run both.