Kaizen Cycle

Every organisation has things that could work better. The Kaizen Cycle gives you a structured, repeating process for finding those things and improving them - not through big transformation programmes, but through small, steady changes that add up over time.

What is the Kaizen Cycle?

Kaizen is a Japanese word meaning "change for the better." As a practice, it's built on a straightforward idea: small, continuous improvements are more sustainable - and often more effective - than large, one-off change efforts.

The approach originated in post-war Japan, where manufacturers needed to rebuild with limited resources. Rather than waiting for perfect solutions, teams made small adjustments every day. Toyota built much of its production system around this thinking, and Masaaki Imai brought the methodology to a global audience in the 1980s through his book Kaizen: The Key to Japan's Competitive Success.

What makes Kaizen distinctive is that it's not a project with a start and end date. It's a way of working. Everyone in the organisation - from senior leaders to front-line teams - is expected to spot opportunities for improvement and act on them. The improvements don't need to be dramatic. A simpler handover process. A shorter meeting format. A clearer way of sharing information between teams. These small changes, repeated consistently, compound into something significant.

The Kaizen Cycle is the structured process that makes this happen. Six steps, repeated continuously: identify a problem, understand it properly, find a solution, try it, check whether it worked, and make it the new standard. Then start again with the next improvement.

How the Kaizen Cycle works

The cycle has six steps. Each one leads naturally into the next, and the sixth flows back to the first - that continuous loop is the whole point.

1. Identify

Every improvement starts with noticing something that could be better. This might be a bottleneck that slows delivery, a complaint that keeps coming back, a process step that everyone works around rather than through, or simply a team's sense that "there must be a better way to do this."

The best way to find these opportunities is to go and look. A Gemba Walk - observing work as it actually happens rather than relying on reports and assumptions - is one of the most reliable ways to spot what needs attention. Customer feedback, team retrospectives, and data all help too. The goal is to be specific: not "our communication is poor" but "the handover between the morning and evening shift loses information three times a week."

2. Analyse

Once you've identified something worth improving, the next step is understanding what's actually happening. Map out the current process. Where does it slow down? Where do errors creep in? Where are people doing extra work to compensate for something that isn't working?

Process mapping is useful here - drawing out the steps visually often reveals things that aren't obvious when you're inside the process every day. The 5 Whys can help you dig past the surface problem to find what's causing it. The temptation is to jump straight to solutions. Resist it. Time spent properly understanding the problem almost always saves time later.

3. Develop

With a clear picture of the current process and where it breaks down, you can start working on a solution. This doesn't need to be perfect - it needs to be good enough to test. Brainstorm options, evaluate them against what's realistic, and choose the one most likely to make a difference without creating new problems elsewhere.

Keep the solution proportionate to the problem. Kaizen isn't about redesigning entire systems. It's about targeted, practical changes. If the solution requires a six-month project plan, it's probably too big for this cycle. Break it down.

4. Implement

Put the solution into practice. This means being clear about what's changing, who's involved, and how you'll know whether it's working.

A couple of things matter here. First, communicate the change to everyone it affects - not just the people who designed it. Second, keep the implementation tight. Kaizen improvements work best when they're quick to try and easy to reverse if they don't work. You're running an experiment, not making a permanent commitment.

5. Adjust

Give the change enough time to show results, then look at what happened. Did it solve the problem? Partly? Not at all? Did it create any unintended side effects?

Gather data where you can, but don't ignore what people are telling you either. The team doing the work will often know before the numbers do whether something is working. If the solution isn't delivering, adjust it. Try a different approach. This isn't failure - it's exactly how the process is supposed to work.

6. Standardise

When you've found something that works, make it stick. Document the new process. Train everyone who needs to follow it. Update any checklists, templates, or systems that reference the old way of doing things.

This step is where improvements either last or quietly fade. Without standardisation, teams drift back to the old process within weeks. The documentation doesn't need to be elaborate - a one-page process update or an adjusted checklist is often enough - but it needs to exist, and people need to know about it.

Then you start again. The cycle continues with the next opportunity for improvement.

How to use the Kaizen Cycle

The cycle works at different scales. Here are three common approaches.

As a daily practice. Some teams build Kaizen into their regular routines - a standing item in daily huddles or weekly planning sessions where anyone can raise a small improvement idea. These tend to be quick wins: a form that could be simplified, a meeting that could be shorter, a step in a process that's no longer needed. The cycle might complete in a day or a week.

As a focused event. A Kaizen event (sometimes called a Kaizen blitz) brings a team together for a concentrated period - usually two to five days - to work through the full cycle on a specific problem. You identify the issue beforehand, then use the event to analyse, develop, implement, and standardise the solution. These work well for problems that have been lingering because nobody has had dedicated time to address them.

As a team rhythm. Some teams run the cycle on a monthly cadence, picking one improvement to focus on each month. This sits between daily micro-improvements and intensive events. It builds the habit of continuous improvement without requiring dedicated workshop time.

Whichever approach you use, two things make the difference. First, involve the people closest to the work. They understand the process better than anyone and they're the ones who'll need to sustain the change. Second, keep improvements small and specific. The power of Kaizen is in accumulation, not in any single change.

Example

A customer service team in a financial services organisation notices that call resolution times have been creeping up over the past quarter. They decide to run a Kaizen cycle on it.

Identify: The team lead spots the trend in the weekly metrics and raises it at the Monday planning meeting. Average call times have gone from 4.5 minutes to 6.2 minutes over three months.

Analyse: Two team members map out the typical call flow and sit in on a dozen calls each over two days. They find that the increase is concentrated in one call type - account queries - where agents are switching between three different systems to find the information they need.

Develop: The team designs a simple one-page reference sheet that consolidates the key information from all three systems for the most common account queries. It won't cover everything, but it should handle about 70% of the cases.

Implement: They trial the reference sheet with four agents for a week, tracking their call times against the rest of the team.

Adjust: After a week, the four trial agents have average call times of 4.8 minutes for account queries, compared to 6.1 for the rest of the team. Two agents suggest adding a section for the next most common query type. The team updates the sheet.

Standardise: The revised reference sheet is rolled out to the full team with a 15-minute walkthrough. It's added to the onboarding pack for new starters. The team agrees to review it monthly and update it as systems change.

The improvement didn't require new technology, additional budget, or management approval. It took a team two weeks from identifying the problem to standardising the solution - and it shaved roughly 20% off resolution times for the most common call type.

Limitations of the Kaizen Cycle

Kaizen is simple by design, and that simplicity has boundaries.

It suits incremental problems. If your organisation is facing a fundamental strategic challenge - a shifting market, a merger, a complete service redesign - Kaizen won't get you there. It's designed for steady, continuous improvement within a broadly stable system, not for transformation. For bigger shifts, you'd be looking at something like Kotter's 8 Step Change Model or a structured change management approach.

It needs a culture that supports it. Kaizen only works when people feel safe raising problems and suggesting changes. If the organisational culture treats problems as failures rather than opportunities, or if suggestions disappear into a void with no response, the process stalls quickly. Leaders set this tone - not by announcing a Kaizen programme, but by responding well when someone says "I think this could work better."

Small improvements can miss systemic issues. Kaizen's focus on specific, bounded problems means it can miss patterns that sit across multiple processes. A team might optimise five individual processes beautifully while the real problem - that those five processes shouldn't be separate in the first place - goes unaddressed. Pairing Kaizen with a wider systems view helps. The Iceberg Model is useful for checking whether you're working at the right level.

Standardisation can become rigidity. There's a tension in step 6. Standardising improvements is essential for making them stick, but over-standardisation can make processes brittle and resistant to further change. The standard should be "how we do this now" - not "how we do this forever." Keep standards light enough to revise.

Getting started

Pick something small. Not the organisation's biggest challenge - something specific and bounded that your team encounters regularly. A process that takes longer than it should. A handover that loses information. A meeting format that nobody finds useful.

Walk through the six steps with your team. Be disciplined about analysing before solving - it's the step most people want to skip, and it's the one that makes everything else work. Use the PDCA Cycle alongside Kaizen if you want a tighter structure for the test-and-learn phase - they're natural partners.

The first cycle will feel slow. That's normal. By the third or fourth, the process becomes instinctive and the improvements start compounding. The goal isn't to get the cycle perfect. It's to build the habit of looking for ways to make things better - and then actually doing something about it.