Fewer errors, less waiting and less rework in the tasks a team repeats: that is what process improvement is for. It is the deliberate work of changing how a recurring task gets done, then checking with evidence whether the change made it better. For most managers it starts with one process that keeps going wrong, such as onboarding a new hire, paying invoices or handing work between teams. In a randomized trial published in 2013, Indian textile plants that got help adopting basic routines, such as recording defects by type and reviewing them every day, raised their productivity by about 17 percent within a year.¹

What is process improvement? Fixing the system behind a repeat problem

Process improvement treats a problem that keeps coming back as a property of the process, not of the person nearest to it, and changes the process on purpose. In health care, Paul Batalden and Frank Davidoff defined the related idea of quality improvement in 2007 as the combined, unceasing efforts of everyone involved to make changes that lead to better patient outcomes, system performance and professional development.²

The reason to look at the process is repetition. A process runs again and again, so a flaw in it produces the same failure every time, whoever is on duty. Blaming the person who happened to be there fixes nothing, because the next person meets the same flaw.

An illustrative case: new hires at a small company keep arriving to find no laptop ready. Each time, someone chases IT. Look at the steps and the cause is plain: no step says who orders the laptop when an offer is signed. Adding that one step, with a name next to it, removes the problem for every future hire.

Economists treat this habit as a mark of a well-run firm: the World Management Survey of Nicholas Bloom and John Van Reenen scores whether firms actively seek out process improvements or make them only when problems arise.³

Process improvement also differs from a project. A project to fix onboarding ends; onboarding itself keeps running, which is the distinction behind how projects differ from ongoing operations. What this means for you: when the same problem turns up a third time, ask which step allows it before asking who caused it.

Plan, do, study, act: the loop underneath the methods

Many improvement methods, Lean and Six Sigma among them, build on one small loop: plan a change and predict its effect, try it on a small scale, study the results against the prediction, then adopt, adapt or abandon it. The loop grew out of the work of Walter Shewhart and W. Edwards Deming, a 2014 systematic review in BMJ Quality & Safety explains.⁴

1. 1Planone change and a written prediction
2. 2Dotry it small: one team, one week
3. 3Studycompare what happened with the prediction
4. 4Actadopt, adapt or abandon, then plan the next test

Then repeat from “Plan”

The loop is the scientific method shrunk to the size of a team. A written prediction turns a hunch into a test. Starting small limits the damage if the idea is wrong and leaves room to adjust it. Measuring over time, rather than once, shows how much a process naturally varies, so a lucky week is not mistaken for progress.⁴

In practice, many published projects that report using it do not follow it closely. Among the health-care articles in the review, fewer than one in five documented a sequence of linked cycles, where the lessons of one test shaped the next, and very few reported an explicit prediction before testing.⁴ Without a prediction, almost any result can be read as a success after the fact; a single big change with no prediction is not a cycle but a hope.

The study step needs the right kind of evidence. A run chart, which plots one measure in time order, helps a team judge objectively whether a change improved the process, and it is of more use than summary figures that ignore time order, according to a 2011 methods paper by Rocco Perla and colleagues.⁵ A whiteboard with one dot per week is enough.

The practical lesson: before you change anything, write one sentence that starts “We expect…”, such as “We expect the next new hires to find a laptop waiting”, and plot one number weekly so the study step has something to study.

What a randomized trial of factory routines teaches managers

In a 2013 randomized trial by Nicholas Bloom and colleagues, Indian textile plants chosen at random for months of free, hands-on consulting adopted basic routines, such as recording defects by type and reviewing them every day, and became markedly more productive than comparison plants. The authors’ likely explanation for the fall in defects is speed: a fault now reached people who could fix it by the next day.¹

Randomization is what makes it matter. Earlier management evidence compared well-run and badly run firms, and profitable firms might simply find good practice easier to adopt; assigning help by lottery removes that explanation.

The study

Moderate evidence

Management help by lottery in Indian weaving plants (Bloom et al., 2013)

After a month of diagnosis in every plant, consultants spent four months helping the treatment plants adopt routines such as recording defects by type and reviewing them daily, maintaining looms on a schedule and keeping inventory records. Compared with control plants, quality defects fell by more than 40 percent and productivity rose by about 17 percent in the first year.¹

Almost every treatment plant already wrote defects down before the study; most did not look at them daily or sort them by type, and none had a standard way to act on what they showed. The authors give an example: a faulty loom causing weaving errors now showed up in the daily numbers and was dealt with at the next day’s quality meeting, instead of going unnoticed for weeks. The main caveat is scale: one small trial, in one industry, with firms that chose to take part.¹

A larger randomized trial in small and medium firms in Mexico, published in 2018, also found that access to a year of consulting raised productivity, though there the practices that improved most prominently were marketing, financial accounting and long-term planning.⁶

The idea travels beyond looms, because most teams already log failures somewhere: reopened support tickets, late payments, start dates that slipped. A log alone only tells you, weeks later, how often the same fault repeated. What turns it into improvement is a short, regular look by people who can fix the cause while it is fresh.

A review like this only helps if the meeting works, which is where why meetings fail and what fixes them comes in.

Further reading

• 

  The Machine That Changed the World

  by James P. Womack, Daniel T. Jones, Daniel Roos

  The study of car plants that coined 'lean production', the book this article credits with spreading Lean beyond Japan.

As an Amazon Associate WiserHours earns from qualifying purchases.

Lean, Six Sigma and the theory of constraints: different starting points

Lean, Six Sigma and the theory of constraints are families of process improvement methods that start from different questions: which steps add value for the customer, how to run improvement projects with discipline, and what holds the whole system back.

Lean grew out of car manufacturing and starts by identifying and removing waste.⁷ The term “lean production” came from a 1990 book, The Machine That Changed the World, which helped spread the idea beyond Japan.⁸ Six Sigma’s tools are strikingly similar to earlier quality methods, a 2008 paper by Roger Schroeder and colleagues argues; what it added was an organizational structure that controls improvement work more rigorously.⁹ The theory of constraints was developed by Eliyahu Goldratt in the late 1970s.¹⁰

Take a slow expense-approval process as an illustration: Lean asks which approval steps add nothing for the person claiming, Six Sigma runs the fix as a formal project, and the theory of constraints asks which approver everything queues behind. The lesson for a manager is not to choose a brand first. Start with the problem in front of you and borrow the questions that fit it. Separate guides to each method are planned in the process improvement and business efficiency category.

Most published improvement projects report success; few are built to prove it

Published improvement results lean heavily positive, so treat any success story, a vendor’s or your own team’s, as a hypothesis to test rather than a forecast. A 2019 systematic review of 120 plan-do-study-act projects in health care found that almost all reported improvement, yet only about a quarter had set a specific, measurable aim and reached it.¹² A report of improvement, in other words, usually did not mean a measurable target had been set and hit.

Lean in health care shows the same weakness: a 2016 review by John Moraros and colleagues found almost no studies with a comparison group, and only inconsistent gains in measures such as patient flow.⁷

Why do weak designs flatter results? A before-and-after comparison credits the change with everything else that happened at the same time: a new hire, a quiet month, extra attention from managers.⁷ Projects that failed may also be less likely to be written up.⁴ A 2003 review of published theory-of-constraints applications, for example, found no reported failures at all.¹¹

If a vendor’s case study claims, say, that a client “cut onboarding time by more than half”, ask for the weekly numbers, not just the two averages. Ask your own team what it predicted before the change. A result that survives these questions is worth copying; one that cannot answer them deserves a small test first.

Why improvement stalls, and how to keep it going

Improvement programs often stall because daily firefighting crowds them out, not because the method was wrong. Nelson Repenning and John Sterman of MIT, drawing on more than a dozen case studies and simulation models, described this in 2001 as a “capability trap”: under pressure, people work harder and skip improvement, the process slowly degrades, and the pressure grows.¹³

The trap works because the two ways of closing a performance gap pay off on different clocks. Working harder raises output right away. Skipping maintenance, documentation or the weekly review frees time today and costs nothing visible for a while, so the shortcut looks free. Improvement works the other way round: it takes time from today’s work and pays back later.¹³

1. Work harder, skip improvement: performance rises at once, then sinks as the process wears down: better before worse
2. Protect time for improvement: performance dips at first, then rises and stays higher: worse before better

Managers often misread the resulting problems. The authors describe how a manager who sees a worker producing defects tends to blame the worker, who is close at hand, rather than a maintenance routine or training gap distant in time; blame brings more pressure, and pressure more shortcuts.¹³ How we make decisions explains when quick judgments like this mislead.

Myth

Improvement programs fail because the team picked the wrong method.

Fact

Repenning and Sterman's case studies suggest the tool matters little; programs stalled when pressure pushed out the time needed for improvement.

Gains also fade when the people carrying them leave. When researchers revisited the weaving plants nine years later, about half of the adopted practices had been dropped, although the treated plants still used clearly more of them than the controls; managerial turnover and a lack of the directors’ time were among the most cited reasons.¹⁴

Picture a team lead who cancels the weekly review “just this month” during a busy close. Nothing breaks at first, which is why the review never comes back. The lessons: fix a small, protected slot for improvement work; expect results to dip before they improve; give each new routine a named owner and a written description so it survives a change of staff; and, as leaders of the successful initiatives in Repenning and Sterman’s research often did, put resources freed by early wins back into further improvement.¹³ A team debrief, one of the habits in what makes a team effective, can host that slot.

A first project: one messy process, one number, one small change

The simplest way to start process improvement is to pick one recurring process that visibly goes wrong, measure one thing about it every week, and test one small change at a time. It is the plan-do-study-act loop with a short look at the work first.⁴

An illustrative month with new-hire onboarding: in week one, walk one real hire’s path from signed offer to first productive day, noting every wait and every time something is sent back, and pick one measure, such as working days until the hire has every account and device. In week two, write a prediction for one change aimed at the most frequent delay. In week three, try it on the next hires only. In week four, plot it and decide.

WiserHours

Your first process improvement project

• Pick one recurring process that visibly goes wrong
• Walk one real case through it and note every wait and rework
• Choose one measure and record it weekly
• Write a prediction before changing anything
• Test one change on a small scale
• Plot the results in time order, then adopt, adapt or drop
• Name an owner and write the new routine down
• Protect a regular slot for the next cycle

Find this checklist online:
https://wiserhours.com/process-improvement/what-is-process-improvement/#checklist-what-is-process-improvement-first-project

The bottom line

Treat a problem that keeps coming back as a question about the process: look at how the work really flows, change one thing, and check with data over time whether it helped. The best trial evidence suggests that plain routines, such as reviewing defects every day, can make a large difference. The hard part is protecting time for improvement when the pressure is on.