Continuous Improvement: Definition, Models and How to Get Started

Every team improves its processes eventually. The question is whether the improvement is deliberate, measured and kept, or whether it happens by accident, gets lost when the person who made it leaves, and has to be rediscovered by the next team eighteen months later.

Continuous improvement is the discipline of making small, frequent, measured changes to how work is done, keeping the ones that help and discarding the ones that do not. It sits underneath most of the well-known operations frameworks, from the Deming cycle to kaizen, Lean and Six Sigma, and it is the mechanism by which a good process stays good after the people who designed it have moved on.

This guide is for operations, IT, HR and team leads at companies of 10 to 500 people who have some processes documented, suspect several of them are slower or more error-prone than they need to be, and want a method for fixing that which does not depend on a consultant or a six-month transformation programme. By the end you will be able to choose an improvement model that suits your team, run one improvement loop end to end, put the numbers in place to know whether it worked, and build the habits that make the second and tenth loops easier than the first.

What Is Continuous Improvement?

The formal definition is an ongoing effort to improve products, services or processes through incremental changes over time. The practical definition is more useful: continuous improvement is a loop. Look at how a process performs today, change one thing, measure whether the change helped, and either make it the new standard or undo it. Then go round again.

Three words in that loop carry the weight. One thing, because changing five things at once tells you nothing about which of them worked. Measure, because an improvement that feels better but does not move a number is an opinion. And standard, because an improvement that is not written into the process is a personal habit that leaves with the person who has it. That last point is why continuous improvement depends on process standardization having happened first: you cannot improve from a baseline you do not have.

Continuous improvement is not the same as fixing things when they break. Fixing a broken process is maintenance, and every team does it. Continuous improvement is applied to processes that are working, on the assumption that working is not the same as working as well as they could. It is also not the same as a transformation programme. A programme has a start, an end and a budget. Continuous improvement is meant to be a permanent feature of how the team operates, which is why building the culture around it matters as much as choosing the model.

Incremental vs Breakthrough Improvement

Improvements come in two sizes, and confusing them is the source of a lot of wasted effort. Incremental improvement, which Toyota calls kaizen, changes one step, one form, one handoff. Breakthrough improvement, kaikaku in the same vocabulary, redesigns the process from scratch. Business process reengineering, the approach Michael Hammer set out in 1990 with the instruction to obliterate rather than automate, is breakthrough improvement in its most aggressive form.

The legacy version of this article offered a useful test for deciding which kind of change you are looking at. Ask two questions: if someone else were making this change, would you expect them to talk to the team first? And could it cause confusion or problems for anyone else who runs the process? If the answer to both is no, make the change, record it, and mention it at the next review. If the answer to either is yes, it needs the people who run the process in the room before it happens.

Most teams need both kinds, in a specific ratio: a great deal of incremental improvement, and a breakthrough every few years when the incremental changes have stopped paying off or the business has changed around the process. An onboarding process that has been refined weekly for two years may still need rebuilding when the company opens a second office in another country. Our guide to business process reengineering covers the breakthrough end; this guide is mostly about the incremental end, because that is where most teams get most of their gain.

The Continuous Improvement Models and When to Use Each

The models below share the same loop and differ in emphasis, vocabulary and the amount of statistical machinery. You do not need to adopt one wholesale. Most teams that do this well borrow the loop from PDCA, the culture from kaizen, the waste categories from Lean, the root-cause tools from Six Sigma, and the focus from Theory of Constraints.

PDCA (the Deming cycle)

Plan, Do, Check, Act. Plan a change and predict its effect. Do it, on a small scale. Check the result against the prediction. Act: adopt the change as the new standard if it worked, abandon it if it did not, and in either case start the next cycle. Deming later preferred "Study" to "Check" to stress that the point is to learn, not to tick a box, and the variant is usually written PDSA.

Use it when: you need a lightweight structure that any team can follow without training. PDCA is the default for teams new to continuous improvement, and the seven-step loop later in this guide is a PDCA cycle with the steps spelt out.

Kaizen

Kaizen is less a method than a stance: everyone, every day, looks for small things to improve in their own work, and the organisation makes it easy to act on what they find. In its Toyota form it includes suggestion systems, short daily improvement discussions, and kaizen events, which are focused two-to-five-day workshops that take one process apart and put it back together better.

Use it when: you want improvement to come from the people doing the work rather than from a central team. Kaizen is the right model for a support desk, a warehouse or an HR operations team where the practitioners see the problems long before management does. It fails when management asks for suggestions and then does nothing with them.

Lean

Lean, as codified by Womack and Jones in Lean Thinking, is built on five principles: specify value from the customer's point of view, map the value stream, make the work flow, let the customer pull, and pursue perfection. Its distinctive contribution to continuous improvement is a taxonomy of waste, the seven or eight categories of activity that consume effort without adding value, which gives a team a shared vocabulary for what to remove.

Use it when: the process has obvious waiting, handoffs, rework or overproduction. Lean's value stream mapping is the fastest way to see where time goes in a multi-team process. Our guide to lean manufacturing principles covers the origins; the principles transfer to office work with surprisingly little adjustment.

Six Sigma and DMAIC

Six Sigma, developed at Motorola in the 1980s, treats improvement as a statistical problem: reduce variation until defects are vanishingly rare. Its improvement loop is DMAIC: Define the problem and the customer requirement, Measure current performance, Analyse the data for root causes, Improve by testing and implementing solutions, Control by putting the gains into the standard and monitoring them.

Use it when: the process runs at volume, the defect is measurable and the cause is not obvious. A manufacturing line, a claims-processing team or a high-volume support desk can justify the measurement discipline. A ten-person team improving its monthly reporting process usually cannot, and will find the machinery gets in the way. Our manufacturing quality control checklist shows the Control phase in practice.

Theory of Constraints

Eliyahu Goldratt's Theory of Constraints, set out in The Goal, starts from the observation that every process has one bottleneck that limits its throughput, and that improving anything other than the bottleneck does not improve the process. Its five focusing steps are: identify the constraint, exploit it (get the most out of it as it is), subordinate everything else to it, elevate it (invest to increase its capacity), and then, once it is no longer the constraint, find the new one.

Use it when: the team is making improvements that do not seem to move the overall result. A support desk that speeds up first response but still has a five-day resolution time has been improving a non-constraint. Theory of Constraints tells you to find the step where the queue forms and work on that.

A Worked Example: Cutting IT Support Resolution Time

The following is a composite drawn from the kind of improvement loops IT teams run regularly, simplified enough to follow in one sitting. The numbers are illustrative rather than from a published study; the shape of the problem is very common.

An internal IT support team of six engineers at a 250-person company handles around 500 tickets a month. Median time to resolution is three and a half working days. Users complain that tickets sit for days; engineers complain that users never give them the information they need. The team lead has been asked to improve it and has been told, without further detail, to "look at automation".

Baseline

Before changing anything, the lead pulls three months of ticket data and looks at where the time goes. Resolution time splits into three states: waiting for an engineer to pick the ticket up (median four hours), engineer working (median three hours across the life of the ticket) and waiting for the user to respond (median two days). The bottleneck is not the engineers. It is the round trips to the user.

Root cause

Five whys on a sample of long-running tickets: why did this ticket wait two days? Because the engineer asked the user which device they were on. Why did they have to ask? Because the ticket did not say. Why not? Because the request form has a free-text box and nothing else. Why is that? Because the form was set up in an afternoon three years ago. Why has nobody changed it? Because nobody owns the form. A fishbone diagram would have arrived at the same place with more ceremony; for a problem this size, five whys is enough.

One change

The team standardises the first-response step. Every ticket, on pickup, is triaged with a short checklist that requires the engineer to confirm four things before doing anything else: device, operating system, whether the issue is reproducible, and the last time it worked. If any are missing, a single templated message asks for all of them at once. The team resists the temptation to also rebuild the request form, change the SLA and buy a chatbot in the same month.

Measure

After four weeks: median waiting-for-user time falls from two days to under one, because one round trip replaces two or three. Median resolution falls from three and a half days to just over two. Engineer working time is unchanged, which is what you would expect, since the engineers were never the problem. The improvement is written into the standard support ticket response checklist and the team lead picks the next constraint, which is now the four-hour pickup delay.

Three things to notice. The loop began with measurement, not with an idea. It changed one step, so the result was attributable. And the change was to a human step, captured in a checklist, not an automation, even though automation was the initial brief. Automating the old form would have produced the same missing information faster.

The Improvement Loop in Practice: 7 Steps

This is the loop from the worked example, generalised. It is a PDCA cycle with the steps made explicit enough to hand to a team lead who has never run one. Budget four to six weeks for one loop on a process of moderate complexity, most of which is waiting for enough runs to measure.

Building a Continuous Improvement Culture

A single improvement loop can be run by one determined team lead. Continuous improvement, the permanent kind, needs the team to want to do it, which is a question of culture. Four things make the difference between a team that improves and a team that was once told to.

Psychological safety

Improvement starts with someone saying "this step is a waste of time" or "I made a mistake here and I think the process made it likely". Neither will be said in a team where problems are treated as personal failures. The practical version of psychological safety is that when a process fails, the first question is what in the process allowed it, not who did it. Amy Edmondson's research on teams in hospitals found that the units reporting the most errors were not the worst performers but the ones where staff felt safe to report, which is exactly the property an improvement culture needs.

A suggestion system that visibly acts

Toyota's suggestion system is famous for the volume of ideas it receives, but the volume is a consequence of something else: the ideas are acted on, quickly, and the person who suggested them can see the result. Most corporate suggestion schemes fail on that second half. If you ask a team for improvement ideas, commit to a response on every one within two weeks, and make a visible list of the ones that were adopted. A suggestion that disappears into a spreadsheet teaches the team not to make the next one.

Retrospectives with a follow-through owner

Software teams borrowed the retrospective from agile, and it transfers to any process: after each cycle, or each month, spend 30 minutes on what went well, what did not, and what one thing to change. The part most teams get wrong is the last step. A retrospective that produces a list of eight actions with no owners produces nothing. Pick one, assign it, and check it at the start of the next retrospective. Our sprint planning checklist shows how the retrospective feeds the next planning cycle.

Visible wins

Improvement is invisible by default: the ticket that did not bounce, the onboarding that did not stall, the error that did not happen. Make it visible. A simple chart of the target number over time, on a wall or a dashboard, does more for a culture of improvement than any amount of training. When the team can see the resolution time falling month by month, the next loop needs no selling.

Culture also needs the organisation to be clear about who is responsible. The lead for continuous improvement does not need to be a dedicated role, but it does need to be somebody's named job, whether that is the operations manager or a team lead with a day a month ring-fenced for it. Our guide to what operations management is covers where improvement sits in that role.

Continuous Improvement Metrics

There are two families of metrics: those that tell you whether a specific improvement worked, and those that tell you whether the improvement programme itself is alive. Teams usually track the first and forget the second.

Process metrics: did this change work?

Cycle time is the elapsed time from trigger to completion, and its spread matters more than its average. Improvements often show up first as the slow outliers disappearing. Track it per step as well as per run, because the step with the longest wait is the next constraint.

First-time-right rate, or its inverse, the rework rate, is the proportion of runs completed without having to be reopened or corrected. For onboarding, it is starters who had everything on day one. For invoice processing, it is invoices paid once, correctly, without a supplier query.

Throughput is runs completed per period with the same resources. If cycle time falls but throughput does not rise, you have improved a step that was not the constraint.

Adherence is the proportion of runs that followed the current standard. It is the control metric: an improvement that is only applied in half the runs will show half the effect, and you will conclude wrongly that it did not work.

Programme metrics: is improvement happening?

Loops completed per quarter, counting only loops that reached step six, standardised or reversed. A team doing one a month is doing well. A team with six loops open and none closed has a follow-through problem.

Time from suggestion to decision, measured for every idea raised. Under two weeks keeps a suggestion system alive. Over a month kills it.

Proportion of improvements originating from practitioners rather than management. A rising share is the best single indicator that kaizen has taken hold.

If your processes run as tracked checklists, most of the process metrics come out of the completion data automatically, and a reporting dashboard turns the monthly review into a five-minute glance. If they do not, collecting the baseline in step one will be the longest part of every loop, which is a strong argument for standardising first.

Common Continuous Improvement Mistakes

Most continuous improvement programmes that stall do so for one of these reasons. Each is easier to prevent than to recover from.

Checklists as the Vehicle: Every Run Produces Data

Every step in the improvement loop is easier if the process runs as a checklist rather than from a document. This is not a coincidence; it is the reason checklists are the natural vehicle for continuous improvement in teams that do not have a statistics department.

A process run from a document leaves no record of how it went. To establish a baseline you have to interview people and reconstruct runs from email. To measure a change you have to do it again. A process run as a tracked checklist records, for every run, when each step was started and completed, who did it, and what values were captured in the required fields. The baseline is a report. The measurement after the change is the same report, filtered to a later date range. The data collection that consumes most of a manual improvement loop simply does not exist.

The checklist is also the standard itself, which closes the gap at step six. When the improvement is written into the template, every subsequent run includes it automatically, and adherence is visible because runs that skipped the new step show up as incomplete. And because templates are versioned, you can see exactly when the change went in and compare the runs before and after it without arguing about whose memory is right.

There is a subtler benefit. A checklist with required fields turns every practitioner into a data collector without asking them to do anything extra. The engineer who records the backup size, the HR coordinator who records the date the laptop was shipped, the finance assistant who records the invoice approver: each is producing the measurement that the next improvement loop will need. This is what makes recurring checklists so valuable for improvement work: a process that runs weekly on a schedule generates fifty data points a year without anyone deciding to measure it.

• Every run is timestamped per step, so cycle time and waiting time are available without a stopwatch
• Required fields capture the values you will want to compare, at the moment they are known
• Skipped or incomplete steps are visible, so adherence is measured rather than assumed
• The template is the standard, so an improvement written into it applies to every future run
• Template versions mark exactly when each change went in, making before-and-after comparison honest
• Recurring schedules produce a steady stream of comparable runs without anyone remembering to start them
• A dashboard of active runs shows where the queue is forming, which is where the next loop should point

If your improvement work is stalling at the baseline step, the most effective single change is to move the process from a document into checklist software that records each run. Our guide to what business process management is puts this in the wider context of how processes are designed, run and improved together, and our IT change management checklist is a good example of a process that produces exactly the data its own improvement needs.

Free Continuous Improvement Templates

These three templates cover the improvement loop itself, the most common trigger for one (a defect that needs a root cause), and the high-frequency IT process from the worked example. Each runs as a live checklist with assigned steps, required fields and a completion record, so the data for the next loop is collected as the current one runs.

Continuous Improvement Cycle Checklist

Runs one PDCA loop end to end: baseline, problem statement, root cause, one change, measurement and the decision to standardise or reverse.

Defect Reporting and Resolution Checklist

Captures each defect with the fields a root-cause analysis needs, routes it to an owner and records the fix, so recurring defects become improvement loops.

Support Ticket Response Checklist

The standardised triage and response process from the worked example, with required fields that make waiting time and rework measurable per ticket.

How CheckFlow Fits

CheckFlow is business process management software that runs each of your processes as a template, so the baseline, the change and the measurement all live in one place. Every run of a template is a checklist with each step assigned to a named person or a role, due dates calculated from the trigger, and the values you decide to capture recorded as required fields.

For the baseline and measurement steps, the real-time dashboard shows every active run and where it is waiting, and analytics report cycle time, completion rate and per-step timing across any date range. The worked example's finding that tickets spent most of their life waiting for the user is the kind of thing that dashboard surfaces without a data export.

For the change and standardise steps, template versioning records exactly what changed and when. Runs already in progress finish on the version they started with; new runs use the new one. That gives you a clean before-and-after comparison, and it means an improvement, once written into the template, is applied by every future run whether or not the person doing it has heard about the change. Conditional logic lets you add a branch for the variant you discovered in root-cause analysis without duplicating the whole process.

Recurring schedules keep calendar-driven processes producing comparable runs, which is where most of your measurement data will come from. The audit trail records who completed each step and when, so adherence is measured rather than assumed. Zapier and the API connect CheckFlow to your ticketing, HR and finance systems, so a closed ticket or a signed contract can start the next run, and the automation you add later is applied to a process that is already stable and measured.

Pricing starts from $10 per user per month, with a 14-day free trial and no credit card required. Most teams have their first process running as a tracked checklist, and their baseline data accumulating, within an afternoon.

Frequently Asked Questions