Process improvement consulting: what it delivers, and why the gains fade

Process improvement consulting is the business of finding the waste in how a company operates and redesigning the work to remove it, using methods such as Lean, Six Sigma and business process reengineering. The gains during an engagement are usually real, and the record after the consultants leave is weaker. Satya Chakravorty of Kennesaw State University described in The Wall Street Journal an aerospace company that implemented more than 100 improvement projects and found that more than half failed to have a lasting impact. A review of 125 studies of health programs, published in Implementation Science, found that partial continuation of new programs was more common than full continuation, even where the program had first been fully implemented. A buyer of process improvement consulting is buying a redesign, and the question worth asking before signing is what will keep it in place.

What process improvement consulting delivers

The methods are old and well tested. Lean comes from the Toyota Production System, developed after the Second World War; the term itself was coined by John Krafcik, then a researcher at MIT, in the late 1980s, and The Machine That Changed the World made it widely known in 1990. Six Sigma began at Motorola, which says it invented the Six Sigma quality improvement process in 1986. Business process reengineering took its name from Michael Hammer's 1990 Harvard Business Review article, "Reengineering Work: Don't Automate, Obliterate", which argued for removing work rather than speeding it up, an argument we take up in Don't automate. Obliterate.

The same work is sold under several names. Operational excellence consulting usually signals a longer program built around Lean and a culture of continuous improvement, operational efficiency consulting usually signals a cost target, and business process improvement consulting usually signals a focus on office work rather than the factory floor. The methods overlap almost entirely, and so does the problem this piece is about.

The engagement follows a familiar shape. The consultant maps and measures the process as it runs, finds the delays, the rework and the steps that add nothing, and designs a better version. The new version is piloted, the staff are trained, and the company receives new standard procedures, a set of measures and a plan for keeping them. The savings are usually visible by the end of the engagement, because the consultants are still in the building to make sure the new procedure is followed.

Why the gains fade after the consultants leave

The evidence on what happens next comes mostly from studies of improvement programs that were followed for years afterwards. England's National Health Service rolled out a ward-level improvement program called the Productive Ward from 2008, and a study by Sarah Sarre, Jill Maben and colleagues, funded by the National Institute for Health and Care Research, looked back over the program's first ten years and found that most hospital trusts had stopped financial and management support for it, and 61 percent of nursing directors said it was no longer regularly used. The Implementation Science review found a related pattern: in the studies that measured it, fewer than half of the providers sampled continued the practice at a high level of fidelity.

People who study improvement programs describe it the same way. Matthias Holweg of Oxford, who has researched Lean, Six Sigma and similar programs, told Harvard Business Review that these programs work well initially, but often the gains fade very quickly. The methods hold up; what the evidence shows is that the redesign is the easier half of the job, and holding it in place is the harder one.

The process lives in people's habits

A redesigned process that people run depends on those people continuing to run it the new way. That dependence has two weak points, and the first is drift. Scott Snook, studying a military accident in Friendly Fire, gave the pattern a name, practical drift, which he described as the slow, steady uncoupling of practice from written procedure. In an office, drift is a workaround that saves time on a busy day and becomes the normal way within a quarter. We describe how the documented version of a process falls behind the performed one in why documented processes rot.

The second weak point is turnover. The Bureau of Labor Statistics reports that US office and administrative support workers had been with their employer for a median of 3.6 years in January 2024, down from 4.1 years in January 2020. A redesign trained into one team is being run, a few years later, largely by people who learned it second-hand from colleagues, with whatever drift those colleagues had already introduced. The procedure survives in the binder while the practice changes with the people.

What changes when software runs the redesigned process

A process run by software doesn't drift in the same way. Its steps are encoded, so the redesigned version is the version that runs, whoever joined the finance team last month. The exceptions go to a person through a defined route, rather than to whoever is sitting nearest, and every step leaves a record, so the measures that proved the improvement keep being taken after the consultants leave. A drop in performance shows up in the numbers the week it happens, rather than at next year's review. Take an approval rule from a redesigned purchasing process, such as a limit above which a second signature is required. In a people-run process, the rule holds until a busy month teaches the team to approve first and collect the signature later. In a software-run process, the rule is checked on every invoice, and a request to relax it becomes a decision someone makes on the record.

The redesign still matters, since automating a process that was never redesigned produces a faster version of the old waste. And the measurement has to start before anything changes, with a baseline taken the way we describe in baselining a process for outcomes. What changes is who holds the gains. In a people-run process, the gains depend on habits. In a software-run process, they depend on the software staying correct, which is a narrower problem and one that can be checked.

What to ask a process improvement consultant before signing

Four questions separate a consultant who has thought about sustainment from one who hasn't. The first is evidence: results from past engagements measured a year or more after the consultant left, rather than at hand-over. The second is the baseline: how the process will be measured before the work starts, so that the improvement can be proven later. The third is ownership: who will own each new procedure and measure after the engagement, and what happens when that person leaves. The fourth is the fee.

Most process improvement consulting is priced on time and materials or as a fixed fee per project, which pays the consultant in full at hand-over. Outcome-based fees exist, though Source Global Research found in 2019 that they were growing only very slowly, and McKinsey said in November 2025 that about a quarter of its global fees came from outcomes-based pricing. A fee partly paid on results measured a year later gives the consultant a reason to design for sustainment. We set out the adjacent choice, between firms that advise, firms that build and firms that run the result, in business process automation consulting.

A reasonable counter, answered

A reasonable counter is that the best improvement programs don't fade, because they build a culture in which people improve their own work continuously, and that moving a process into software removes the very people who would improve it. Toyota is the standing example: the company says all its employees implement daily incremental kaizen, and its gains have lasted for decades. The culture is real, and it took Toyota decades to build. A mid-market company buying a twelve-week engagement is buying the redesign, and the culture was never part of the contract. Software can be changed as readily as a procedure can, and more visibly: putting the repetitive steps into software makes each change to the process deliberate and measured, and it moves the people who ran the old steps toward the exceptions and the improvements, which is where a culture of improvement does its work in the first place.