The Sales Execution Gap

Process Improvement: You Cannot Improve a Process Nobody Runs

Process improvement usually means redesigning a process that was never followed in the first place. Deming's PDCA loop breaks at Check without a measured baseline. Fix the order.

Process improvement is the disciplined practice of making a process produce better results over time, and it fails most often not at the redesign but before it, because you cannot improve a process nobody runs the same way or measures honestly.

A team decides the sales process is broken. They convene, whiteboard a better one, build the new stages, train everyone, and roll it out with real conviction. A quarter later the numbers look the same. The conclusion, drawn with a sigh, is that process improvement is overrated, or that this team is uniquely resistant. The truer conclusion is harder to swallow: they improved a process that was never being run, so there was nothing to improve. They optimized a ghost.

Process improvement is the disciplined practice of making a process produce better results over time, and it fails most often not at the redesign but before it, because you cannot improve a process nobody runs the same way or measures honestly. Sit with that, because it reorders the whole exercise and explains why so much improvement work produces so little.

The numbers behind that failure rate are not small. Studies of organizational change efforts have for years put the failure rate around 70 percent, a figure popularized after McKinsey’s transformation research and repeated so often it became received wisdom (McKinsey, “Changing change management”). The standard explanation is resistance, weak sponsorship, or poor communication. Those matter. But a large share of the failures are stranger than that: the change is designed well, communicated well, sponsored from the top, and still nothing moves, because the thing being changed was never happening in the first place. You can run a flawless improvement program on a process that exists only on paper, and the result will be a flawless improvement of nothing.

What does the PDCA cycle actually require?

To see why, it helps to know where improvement methodology came from, because the field has known the answer for ninety years and keeps half-forgetting it. The lineage runs from Walter Shewhart at Bell Labs in the 1920s, who built the first statistical control charts and insisted you could not improve a process you had not first brought into a state of statistical control, a state of being predictable. His student W. Edwards Deming carried that idea to postwar Japan and turned it into the management philosophy that rebuilt Toyota and, through it, modern manufacturing. From Deming came the Plan-Do-Check-Act loop. From Toyota came Lean and kaizen. From Motorola and GE in the 1980s and 1990s came Six Sigma, with its own loop, DMAIC, whose first letter is Measure. Every serious improvement school, across a century, opens with the same instruction: measure the real process before you touch it. And every century-old instruction gets skipped the same way, because measuring is slow and redesigning is fun.

The dominant improvement methodology is Deming’s Plan-Do-Check-Act loop, and it is elegant: plan a change, do it small, check the result, act on what you learned (Deming and the PDCA cycle). The trouble is that the loop has a load-bearing step everyone treats as decoration, and it is Check.

The PDCA cycle and the step everyone skips: a four-circle loop of Plan, Do, Check (highlighted in magenta), and Act, with arrows connecting them clockwise; Check needs a measured baseline, no standard means no honest Check; most teams Plan and Do then guess at Check, so the loop never closes and nothing improves.
Most teams Plan and Do, then guess at Check. Without a measured baseline the loop never closes, so nothing improves. Deming’s Check is the load-bearing step.

Check requires a baseline. To know whether a change helped, you have to know what the process produced before, measured honestly, with everyone running the same motion. If the old process was followed inconsistently, the baseline is noise, and comparing your new version to noise tells you nothing. So the loop stalls at Check, the team guesses, and the next cycle is built on the guess. The methodology is sound; the missing measurement breaks it.

Shewhart had a name for this. A process in statistical control varies only by common causes, the ordinary background noise of any system, and against that stable baseline you can detect whether a change made a real difference. A process out of control varies by special causes, by one rep doing discovery and another skipping it, by one region qualifying hard and another waving deals through. Run a change against an out-of-control process and the signal of your improvement drowns in the noise of inconsistent execution. You changed something. You cannot tell if it helped. That is not a measurement inconvenience; it is the reason the loop cannot close.

There is a deeper, more human version of this failure, and two Stanford professors named it. In The Knowing-Doing Gap, Jeffrey Pfeffer and Robert Sutton studied why companies that clearly know what to do so rarely do it, and found that organizations habitually substitute talk for action: making a decision feels like progress, writing the new process feels like running it, and the planning meeting becomes a stand-in for the work (Pfeffer & Sutton, The Knowing-Doing Gap, HBS Press). A redesign workshop is the purest form of this trap. It produces a deck, a sense of momentum, and the comfortable belief that the process is now better, when all that has actually changed is a diagram. Knowing a better process is not running it. That gap is exactly where improvement programs go to die.

Why does process improvement come second, not first?

Because adherence is the prerequisite, and it is the step the whiteboard skips. The order that fails is the natural one: redesign, roll out, hope. The order that works is unglamorous: measure whether the current process is followed, secure that it is genuinely run, and only then improve what is real.

The right order, adherence before optimization: what teams do (redesign the process, roll out the new version, see no change in results, because the old one was never run); what works (measure adherence first, get the current one run, then improve what is real, because you cannot improve a ghost); you cannot say a process does not work if you never truly ran it.
You cannot say a process does not work if you never truly ran it. Measure adherence first; improve what is real second.

This is the hidden lever almost no improvement program pulls. You cannot ask “what should we change?” until you can answer “is the process being followed?” The first question feels strategic and the second feels like nagging, so teams leap to the first and inherit a baseline of noise. The continuous improvement that compounds is the kind built on a real, adhered-to standard, which is the argument made at length in sales process adoption and standard work.

The field data says the prerequisite is missing almost everywhere. We asked 198 sales leaders, and 89 percent reported a defined sales process while only 36 percent said their reps actually follow it (The State of Sales Enablement 2026). That is a 53-point gap between the process on paper and the process in motion, which means most improvement programs are operating on the wrong side of it. They are tuning the 89 percent, the document, while the 36 percent, the behavior, is the variable that moves the result. The redesign is real work spent on the part that was already fine.

Why optimizing a ghost shows no lift: on the left, a process never truly run has a noisy jagged baseline, so a change rolled out produces a result that looks the same; on the right, one standard genuinely run gives a measured flat baseline against which a single change reads as a clean, visible lift. You cannot tell whether a change helped if the baseline was noise.
You cannot read a lift against a noisy baseline. Adherence first turns the noise into a floor you can improve against, which is exactly what Deming’s Check requires.

And the lift, once the baseline is real, is not theoretical. CSO Insights, the research group now inside Korn Ferry, found that as a sales process moves from barely adopted to broadly adopted, average win rates climb from roughly 40 percent to nearly 58 percent (Korn Ferry). Eighteen points of win rate, and not one of them came from a redesign. They came from the same process, run by more of the team, more of the time. The improvement was adherence. The redesign was a distraction from it.

How do you run a process improvement methodology that compounds?

Secure adherence to one standard within a segment first, so PDCA has a real Check to run against. Then change one thing at a time, measure it against the baseline, and re-standardize when it wins, which is the kaizen discipline of raising a known floor rather than guessing in the dark. Resist the urge to redesign before you have measured, because a redesign of an unrun process just creates a second unrun process.

The discipline here is borrowed straight from Toyota, and it is worth stating plainly because most teams invert it. Taiichi Ohno, the engineer behind the Toyota Production System, insisted that there can be no kaizen, no improvement, without standardized work first. The standard is not the enemy of improvement; it is the floor improvement stands on. Without a fixed, followed baseline, every “improvement” is a guess layered on a guess, and you can never tell which change helped because you never held anything still long enough to measure it. So the loop that compounds looks nothing like a quarterly redesign. It looks like this:

  • A measured baseline. One standard, genuinely run within a segment, measured at the level of the work. This is the floor, and until it exists, nothing above it is real.
  • One change at a time. Alter a single step, criterion, or field, never the whole map. Many simultaneous changes give you a result you cannot attribute, which is no result at all.
  • An honest Check against the floor. Compare the change to the measured baseline, not to a memory or a hope. If it does not beat the floor, discard it without sentiment.
  • Re-standardize the win. When a change beats the baseline, it becomes the new standard everyone runs, and the floor rises. The next cycle improves against the higher floor. That is how a process compounds instead of churning.

This is also why the most common improvement gesture, the big redesign, so rarely compounds. It changes everything at once, against no baseline, and re-standardizes nothing, so the team ends the quarter unable to say what helped, and the cycle never starts. Kaizen is patient and small on purpose. The patience is the mechanism.

What we recommend

Reverse the instinct. Before redesigning anything, measure whether the current process is being followed, because the most common cause of failed process improvement is that there was no real process to improve. Get one standard genuinely run within a segment, so your baseline is signal instead of noise, then improve against it with PDCA, one change at a time, keeping what beats the floor. Deming’s loop is not wrong; it is incomplete without the measurement that makes Check honest. The unglamorous truth is that adherence is the improvement, or at least its prerequisite, and the teams that skip it spend years optimizing ghosts.

From here: the adherence argument in sales process adoption, the baseline idea in standard work, and the documentation discipline in process documentation.

Frequently asked questions

What is process improvement?+
Process improvement is the disciplined practice of making a process produce better results over time, usually through a cycle of measuring, changing one thing, and measuring again. The most common methodologies are Deming's Plan-Do-Check-Act cycle, Lean, Six Sigma, and Kaizen. They all share one requirement that teams routinely skip: a measured baseline of how the process actually runs today, without which improvement is guesswork.
What is the PDCA cycle?+
PDCA is Plan-Do-Check-Act, a four-step improvement loop popularized by W. Edwards Deming. You plan a change, do it on a small scale, check the result against a baseline, and act by keeping the change or discarding it. The loop only works if Check is honest, and Check requires a measured baseline. Teams that skip measurement plan and do, then guess at check, so the loop never closes and nothing improves.
Why do process improvement efforts fail?+
Because they try to improve a process that was never actually run. A team redesigns the workflow, rolls out the new version, and sees no change, because the old version was followed inconsistently or not at all, so there was nothing to improve. The fix is to measure and secure adherence first, get the current process genuinely run, and only then optimize what is real rather than what is on paper.
What comes first, process adherence or process improvement?+
Adherence, always. You cannot say a process does not work if you never truly ran it, and you cannot tell whether a change helped if the baseline was noise. Securing that everyone runs the same motion within a segment is the prerequisite to every improvement question. Optimizing a process nobody follows is optimizing a ghost, which is why so much improvement effort produces no measurable result.

Your process, running itself.

Turn the playbook into rep behavior.

Book a demo Read The State of Sales Enablement