How I Grade Kaizen Event Performance

Many of us have embarked on an exciting journey to facilitate kaizen events for our company. I’m a true fan of kaizen events when done correctly.

Kaizen events give organizations time to pause, come together as a team, and solve a key problem impacting important metrics.

(Source: Lean Reflecions)

Every week I listen to 1-2 kaizen event report outs. After listening to hundreds over my career, I’ve noticed a few key topics that I always pay attention to. I have divided these key topics into 10 categories. Now, I don't physically had out any grades. I just measure these components to teach and drive lean thinking. So no matter if it's a kaizen event, TPM initiative, or just regular problem solving on the floor, I review these 10 categories to ensure the team has a sound understanding of how to solve problems.

1. Event Selection. The first thing I look for is how the kaizen event was selected. It should have an impact on the business, location, and/or department metrics. There will always be a set of issues in our organization, but it is vital that we learn how to focus on the items that negatively impact us the most.

Pareto charts and data come in handy when selecting a kaizen event. Follow the data to select your project. When the data doesn’t allow you to do that, gather your team and agree on what your top issues are. That should be the focus. I am not suggesting that you shouldn’t work to solve the problems you see. I am saying that due to limited time and resources, you should choose your battles wisely.

·      Good: You chose to select a “Defect Reduction” kaizen because 10% of your output results in defects. You decide to focus on this event because the issue is decreasing your output capacity, you’re losing sales opportunities because your demand in higher than what you can produce, and the cost of quality issues are impacting the bottom line significantly.

·      Not so Good: You choose to select a “Defect Reduction” kaizen because you saw a few defects; however, there’s no real data pointing to defects being a reoccurring issue, there’s no capacity constraints causing you to miss customer demand, and the cost of quality is low. You might have bigger fish to fry.

2. Target Setting. The target should be set strategically. If you assign an arbitrary goal such as “Reduce Defects by 50%” without any analysis, you may be shooting for an unreachable goal. Setting an arbitrary goal could also cause you to under set a target. The proper way to set a target is to look at the data and decide what you want to focus on.

For example, if you are looking to reduce defects, figure out the key categories causing the defects. If the defects are being caused by one top issue accounting for 30% of the problem, you should use that as a starting point. Keep in mind you may not eliminate the top issue completely, so you may want to set your target a little lower. Also, make sure you have the right metrics. Each event should have quantifiable targets to measure the performance of your future improvements. I shoot for at least two metrics per kaizen event.

3. Event Scope. Again, we are not boiling the whole ocean. There are a million things that could cause a defect. “Defect Reduction” is too broad of a scope for a kaizen event. You should bring it down to a specific defect category, a point in a process, or even a product. Most of your improvements can be applied to several issues outside of the scope, but to keep the kaizen event focused and on track, you must be selective on what you bring into the discussion. 

4. Team Selection. I usually look for a well-rounded team. If you have only one department represented in a kaizen event, you might miss key insight. Having a cross-functional team gives you the ability to look at an issue from all angles. Also, bring in people from other sites, customers, and suppliers. Keep the team small when possible and remember to be careful of the personalities you bring together. I usually cap my attendees off at eight. If I have more than that, we are breaking out into smaller teams.

Allow your team to monitor, manage, and sustain kaizen events all in one place within minutes.

5. Current State Observation and Methods. Okay, now that I’ve sized up how well you planned the kaizen event, it’s time to understand how well you executed the event. My expectation is that a team carefully observes and maps a problem out from start to finish. At times, this may require pre-work. The goal here is to take away all assumptions about the current issues and use data to help see the real problems. I’m looking to see if you watched, timed, observed, interviewed people, and/or mapped out the process.

If I do not see any evidence of your observations, I am going to assume that you just went in a room and brainstormed some ideas and that is not a kaizen event. I repeat that is not a kaizen event. I understand at times, you have a good idea of some things you would like to implement; however, you must still do your work to make sure you thoroughly understand why and how people are currently performing this process. If you immediately jump to improvements, I promise that you will miss some very important data. The current state observations should result in a list of identified issues and bottlenecks in the process.

6. Root Cause Analysis. Now that you have your list of issues specific issues that caused your metrics to sink, the next thing I look for are the root causes of those issues. There are several root cause analysis tools out there. You should take some time to make sure you’re not placing Band-Aids in the process.

If you’re asking for more people or a large amount of money to do something, that’s usually a sign the root cause hasn’t been identified and you are masking it with resources. Not to say we don’t need both at times, but if you tell me that you're having defects because you do not have enough people to perform quality checks, then I am going to question your root cause.

A quality check is a reactive solution. If you tell me the root cause of a defect is due to a systematic issue that wasn't previously known until your observation, then it is much more believable.

Rule of thumb: You should be able to turn a root cause on and off. I always ask "So, if you fix "XYZ" you will never see that problem again?" Here's a great example of a root cause.

(Source: Windpower Engineering & Development)

7. Future State and Solutions. My standards may be a bit different here. I don't look for you to create some type of mind-blowing, fully automated robot to solve all of your problems here. Although, that would be pretty cool. I am looking for your solutions to directly solve the root cause of the problems you have identified. People struggle with this one the most. They come out of a kaizen event with a lot of "nice to have" solutions, but forget to directly solve the problem.

About 70% of the time, the root cause of an issue will point to the lack of process standardization. No matter if you're having issues with Safety, Quality, Delivery, or Cost most of the time it will always point back to a process improperly performed or defined. The key is to ensure you're fixing that issue directly.

For example, if your defects are occurring because your new employees do not know how to properly perform a process, make sure that issue is fully addressed. If you immediately focus your improvement on a new robot that brings water to employees, sweeps the floor, and counts defects, you'll just have a cool robot and still have the same defects.

8. Try-storm Activities. Now that you've identified the root cause of problems and found solutions to directly improve them, focus on trying them out. Build prototypes and staged scenarios to test out your theories. If all of the ideas we have worked out exactly how we planned them in our heads, we'd all be millionaires. It doesn't work like that. You have to try it out.

Test your new processes and measure to see if you'll actually get the results you expected. In a kaizen event, you get extra points from me if you find the time to do this. I'd rather for you to find out if an improvement worked now rather than 30 days later. This isn't possible all of the time, but push to get as many resources as you can during the event to give it a try.

9. Projected Results. This is similar to target setting. At this point, you should have a clearer vision of where your metrics will be if you implement the identified improvements. You may have also selected even more metrics to measure the performance of kaizen event improvements. You must calculate the projected change in metrics again, now that you know exactly what you are going to do to move the needle.

10. Action Plan. Finally, you have successfully finished the kaizen event. If you're really lucky, you will have zero items on your action plan. For all of us normal people, we usually end of with a list of actions needed to fully implement the improvements.

What I look for in your action plan is a closed loop system that drives completion to every action item. The tasks must be clearly defined, the right people should be identified, and the dates must be realistically set. Kaizen events are fun but if you don't execute your plan, you'll never see the results. Make sure you have a system in place that allows you to manage, track, and monitor the progress of an improvement. If you don't do this well, you'll have what I call the 8th waste: Forgotten Kaizen Events.

I use Kaizen Collab to help monitor metrics and action plans after kaizen events. Here's a screenshot of the metric charts the platform automatically created for my kaizen. The kaizen event was a warehouse error reduction project. We were looking to reduce freight cost and pick errors. I can immediately see how my project is performing in real time.

So there you have it. Those are the 10 things I use to grade a kaizen event. Let me know what you would add to this list and why. Looking forward to hearing your thoughts!

P.S. If you need a better way to manage, track, and monitor continuous improvement sign up for a demo at www.kaizencollab.com.

Happy Problem Solving,

Amery