There is a particular silence that settles over a work cell about five weeks after a kaizen event. The banner is still on the wall. The before-and-after photos are still pinned to the board, curling slightly at the corners. And the tooling is back on the shelf it was on before, because the shadow board never got its second set of tools and somebody needed a spanner in a hurry.
If you have run more than three or four improvement events, you have seen this. The week itself went well. People were engaged, the numbers moved, the presentation on Friday afternoon had a genuinely impressive slide on it. Then the team went back to their jobs and the improvement quietly came undone.
The uncomfortable part is that kaizen events fail in predictable ways. Not random ones. After enough of them you start to recognise the shape of a collapse before it happens, and almost all of the warning signs are visible during the event itself, if you know where to look.
The event week is almost never the problem
Ask a room of continuous improvement people why an event failed and most will point at the week. Not enough time. Wrong people in the room. Scope too big. Maintenance was not available on Wednesday.
Those things happen, and they hurt. But they are rarely fatal. A kaizen event with a mediocre Tuesday and a good follow-up process will still be delivering results a year later. An event with a flawless week and no follow-up process will be gone by the end of the month.
What actually kills these things is what happens in the boring interval afterwards, when nobody is watching, no facilitator is present, and the area supervisor has fourteen other problems. So that is where the diagnosis has to start.
Failure one: nobody owned the thirty days
Almost every event produces a list of things that could not be finished during the week. Something needs purchasing. Something needs engineering time. Something needs the night shift trained, and the night shift was not there.
This list gets written on a flipchart on Friday afternoon, photographed on somebody’s phone, and never seen again.
The fix is unglamorous and it works: the follow-up list gets a named owner per line and a date, it gets published, and somebody reviews it. Not the team collectively. A person. “The team will follow up” is functionally identical to nobody following up, and everyone in the room on Friday knows it, which is part of why the energy drains out of the last hour of an event.
Give it a review date too. Thirty days is conventional and it is about right, because it is long enough for the change to have been tested by real conditions and short enough that people still remember why they made it.
Kaizen & Continuous Improvement Templates — 10 Excel Workbooks with Dashboards
Failure two: the baseline was fiction
This one is more embarrassing and much more common than people admit.
Somebody pulls a number out of the reporting system before the event. Changeover takes 48 minutes. The team spends the week attacking it, does genuinely good work, and reports an improvement to 18 minutes. Sixty-two percent. Everyone applauds.
Except the 48 minutes came from a system that only records stoppages over five minutes, and it was measured on a day shift running one product variant. The real average across both shifts and all variants was 41 minutes, and the 18 was measured once, by the best operator, on a Friday, with the whole kaizen team watching.
You have not improved by 62%. You might have improved by 30%, which would still be excellent, but you have now put a number into the business that will not survive contact with next quarter’s data. When it collapses, the credibility of the whole programme collapses with it.
Measure the baseline yourself, before the event, across the shifts and variants you actually run. Then measure the result the same way. If the after measurement was taken under conditions the before measurement was not, you have compared two different things.
A related trap turns up in equipment work. If you calculate Overall Equipment Effectiveness and the performance component comes out above 100%, your ideal cycle time is wrong — it is set slower than the machine genuinely runs. It is not a rounding artefact and it does not average out. It means the denominator of your improvement claim is fictional, and everything built on it is too.
Failure three: the improvement only exists on one shift
The team was drawn from days. The standard work was written on days. The training happened on days. The night shift came in on Monday, found the layout different, nobody had told them why, and quietly moved things back to where they could find them.
This is not obstinacy. It is a completely rational response to being handed a change you did not help design, were not trained on, and cannot ask anybody about at two in the morning.
Two things prevent it. Put someone from every affected shift on the team, even if only for part of the week. And treat “trained on the new standard” as a line item with a date and a name against each shift, not as an assumption. When you audit the area afterwards, audit it at three in the morning occasionally. A standard that only holds between eight and four is not a standard.
Failure four: you reported a forecast as a saving
An event finishes and somebody writes $41,000 in a cell on a slide. It goes into the programme total. The steering committee sees a healthy annual figure and everyone feels good.
Then Finance goes looking for $41,000 and cannot find it, because the saving was 27 minutes per changeover multiplied by a machine hour rate, and the machine was not the constraint that quarter, and no headcount changed, and no cost left the building.
Once that happens, every number your programme produces gets discounted, including the real ones. This is the single fastest way to lose a continuous improvement budget.
Keep forecast benefit and realised benefit in separate columns and never let a figure move from one to the other without somebody in Finance agreeing to it. You will report smaller numbers. They will be believed, which is worth considerably more.
It also helps to be honest about the difference between hard saving — cost that genuinely leaves the business — and capacity or time that has been freed up. The second one is real and valuable, but it only becomes money if there is demand to fill the capacity. Say so.
Failure five: the root cause was a guess in a good suit
A team runs a Five Why, writes a tidy chain on a flipchart, arrives at something plausible, and builds a countermeasure on it. Nobody tests any link in the chain.
Two months later the problem comes back, because the actual cause was a component burr that varies between supplier lots, and the countermeasure was aimed at operator technique.
The discipline that prevents this is trivially simple and almost universally skipped: mark every level of the chain as verified or not verified. If the last why is unverified, you do not have a root cause. You have a hypothesis, and you are about to spend money on it.
The same applies to a fishbone. Listing forty possible causes feels productive and tells you nothing. Score them, rank them, and go and test the top three against reality before committing to anything.
What to do differently on the next one
None of this requires a bigger budget or a different culture. It requires a handful of specific behaviours, most of which take minutes rather than days.
Measure the baseline yourself, across every shift and variant, and measure the result identically. Put someone from every affected shift on the team. Write the follow-up list with a person and a date on every line, publish it, and review it at day thirty. Separate forecast benefit from verified benefit and let Finance hold the pen on the second column. Verify each link in your root cause chain before you spend anything on it.
Then audit whether the change held — at a time of day when nobody expects you.
Kaizen events fail because the mechanics of sustainment are boring, and boring work is what gets dropped when everyone is busy. The events themselves are the fun part, which is exactly why the follow-up is the part that needs a structure holding it up.
Kaizen & Continuous Improvement Templates — 10 Excel Workbooks with Dashboards
Download Kaizen Continuous Improvement Checklist for Microsoft Excel
Be the first to comment