Series: Executing a Kaizen Event

If you read this title and were immediately reminded of that ONE miserable project with a bad team (or team member), then you will probably be responding to this post. But, this post isn’t about bad team members or how to avoid them. Instead, it is about how to select a group of people that can fill the roles required by a project’s scope (be sure you read the post: Kaizen is not Japanese for Free Lunch) effectively and increase the probability of success.

For the sake of discussion, the selection of a Kaizen team will form the foundation for my thoughts. After the project scope has been defined and the project charter has been developed, the next step to leading a successful Kaizen Event is team selection. Thinking through all of the tasks that may be required to achieve the goals of the project and making a list of the skills that will be needed to accomplish those goals is a great way to start. Listing the skills first will allow you to keep your mind open and may lead to selecting a team member that you never would have considered otherwise.

Once the necessary skills have been identified, it’s time to start thinking of individuals that may have a desire to be involved with the team. Remember, you can’t force someone to participate passionately and you can’t fake desire, so it is rarely beneficial to force someone to be involved. Match the individuals that have the needed skills with those that have the desire, and the selection of the team will usually be easy.

An often overlooked team member is the “ringer”. I use this term to refer to the individual that comes from a completely unrelated part of the organization and knows very little of the processes that the team will be working to improve. It might seem strange that I recommend including one or two of these individuals, but these folks often turn into the real gems of the group. They ask the most important question of all… WHY? They are not encumbered by knowledge so they ask questions that no one else on the team would even think to ask. They see those forms of waste that others have grown to accept as part of the process and they challenge the rest of the team. Be sure to encourage them. The idea they bring to the table may seem crazy, but the idea that surfaces because of their off the wall suggestion may be the next “BIG ONE”.

A quick note on team size: my magic number is 6-8 team members and 1 team leader for Kaizen Events. If you have a co leader, be sure to count them as a team member. Any more and the team becomes less nimble; any less and you lose the critical mass needed to generate creativity. I realize that project scope and organizational culture is going to impact this significantly, but in a perfect world, 6-8 is an ideal team size.

Series: Executing a Kaizen Event

Planning can be drudgery, but it doesn’t have to be. In fact, if we involve the team (particularly for Kaizen events), it can be used as a time to educate, train and involve those that will ultimately be involved in the changes. Since we have been discussing Kaizen events lately, I would like to discuss Kaizen Event Planning.

Even though a typical Kaizen event lasts about a week (although, they can be as short as a few minutes or as long as several weeks), the upfront planning may begin weeks (or even months) ahead of the project. Depending on the scope of the project, somewhere between several days and a few weeks may be needed to properly prepare for the event. Of course there are logistics (war room space, schedules, catering, etc) to prepare for, but the really important tasks relate to team preparation. In another post, we cover the importance and structure of a project charter, so I will assume that a good charter has been developed. Once the charter has been developed, the preparation can begin. If the charter has left the project scope a little vague, this is the time to clarify any lingering details.

If the charter has been developed without a value stream map (not recommended) one will most likely need to be developed during the planning process. Before the Value Stream or Process Maps can be developed, the team may need to be trained in these tools. For that matter, they may need to be trained in other lean tools such as 5S, Flow, etc. While some of the training that is specifically related to the event (such as an overview of Kaizen) may need to be delivered during the event, but I really prefer to complete as much of the training during the planning phase as possible.

During the planning phase, it is also important to confirm that the scope and boundaries of the project are consistent with the sponsor’s expectations. Additionally, details such as scheduling the final report out, meeting with union officials (if applicable) and introducing the team to the value stream should be completed. A schedule for the event should be developed and team availability should be confirmed. “The devil is in the details” never fails and the more time and effort I devote to the planning phase, the better my Kaizen projects go.

Series: Executing a Kaizen Event

After I had led several Kaizen events, it hit me that I probably had eaten more Pizza served in the name of team lunches than I had outside of work. To be fair, I’m not a big Pizza eater anyway, but it seems that when a team is working together 10-12 hours a day during a Kaizen event, lunch is a great time to relax a little and process any thoughts the team has on the even we are currently performing. Pizza seems to help with this task.

One of the most common thoughts that most people new to properly executed Kaizen Events have is around the structure and the discipline of the event. They believed that executing a Kaizen Event just means locking yourselves in a room for a day, debating ad nauseam and coming out with some corrective action. Unfortunately, they also believe that the best thing you get out of these events is the free lunch. This is usually due to Kaizen events executed improperly, sometimes being led by people who think they are fighting fires, not carrying out a long-term improvement and corrective actions that may or may not work because the cause of the problem is usually conjecture with no evidence to back it up.

To overcome this issue, it is important for me to explain to the team what Kaizen is and what the structure of a Kaizen Event looks like as the first part of the event. And that is what I’d like to do for you in this series of posts.

Kaizen is a Japanese term that means unceasing change for the better. It is an iterative philosophy of continuous improvements (often very small in nature), rather than an attempt to make a process perfect based on tools like long term research, modeling and capital investment. The learning that takes place through these small, incremental changes may be more important than the improvement, because it is the foundation that leads to the next Kaizen and the next and so on. Kaizen doesn’t let the hope of becoming perfect get in the way of getting better.

Although it is based on the same philosophy, a Kaizen event is a bit more formal and of a larger magnitude. A Kaizen Event is typically a 1 week event that includes:

• Training: A brief training session to cover topics specific to the event
• Planning: A short planning session to determine specific activities that will take place and what the timeline will be (the timeline is typically done in hours since the events are usually 1 week or less)
• Doing: A period of implementing improvements
• Checking: Implementation of standard work and other methods to ensure improvements are sustained

Although it is based on the same philosophy, a Kaizen event is a bit more formal and of a larger magnitude. A Kaizen Event is typically a 1 week event that includes:

• Proper up-front planning
• Completing a project charter
• Selecting a great team
• Discovering causes (if it isn’t obvious)
• Creating solutions
• Managing the follow-up action item list
• Keeping the team on schedule
• Giving a good management presentation to celebrate the team’s success

Properly executed, a Kaizen Event is not a one-day meeting, were we get in a room, have some discussions on what’s wrong without any data or visibility into the problem and some corrective action that may as well be guess-work. It is about the discipline to plan, gather data, dig deeper into true causes, try a fix and measure how well (or even just if) the problem was fixed.

Finally, a quick note about nomenclature. Although he term Kaizen Event has been widely adopted, other, similar terms are also used: Blitz, Kaizen Blitz, Breakout, Spike, CIE (short for Continuous Improvement Event) and many other terms all represent essentially the same activities. The name really doesn’t matter. It is the goal of continual improvement and the discipline to carry it out in a well-organized manner with a good amount of preparation is what is important.

I will be posting each topic in ‘keys to a good kaizen event’ list above future posts. You can follow them by clicking on the items or just Executing a Kaizen Event series. Until then, feel free to comment on your experiences during improvement events (even if they weren’t officially Kaizen events)? What were some keys to success or factors for failure that you experienced?

Series: Executing a Kaizen Event

You do if you are a project leader. I know that creating a project charter can be a little bit of a pain and it may seem tedious, but it really is the first step to a successful project. We discussed a basic structure for Kaizen events in a previous post titled “Kaizen is not Japanese for free lunch”. Periodically, I plan to revisit this topic and discuss various components of a successful Kaizen. Depending on the response we get, we may accelerate the discussion or drop it, so be sure to let us know what you think.

A project charter is more than just a summary document. Of course, it contains all the particulars about the project, and since the concept is so well documented, I won’t bore you with a detailed description. Rather, I will list some key components of a good charter (with a slant for Kaizen event planning) and then we can explore why we need them. A good charter should contain:

1. Project summary including the problem statement, issue to be solved or improvement opportunity, dates and project and location.

2. Organizational Metrics that will be impacted. Current state and expected results. This is critical to attain buy in.

3. Team: include champions, sponsors, team leaders/co leaders, members and support peronell

4. Cost and financial impact summary

5. Current and Future state descriptions. Pictures,drawings, value stream maps and process maps should be used rather than lengthy/wordy descriptions if possible.

6. Other items as needed.

A good charter serves several purposes. First, it ensures alignment with the sponsors and champions. A team leader is wise to use this document to ensure that all key stakeholders are in agreement of scope and expectations before the project begins. The school of hard knocks has taught me that the final report out is probably the worst place to discover that the champion’s expectations conflict with the team’s.

Charters also provide guard rails for the team and make sure that efforts are directed at the areas of highest impact. As a team leader, the charter is your main tool to keep your team on task. There are always many opportunities that arise and it is difficult to tell a team that the great idea needs to go to the parking lot. If it isn’t part of the scope and everyone has agreed to the charter, this task becomes much simpler.

Finally, developing a charter forces us to think through the project in detail and gives us an opportunity to plan the event in detail. While no amount of planning with keep the unexpected from happening, a good plan will certainly make dealing with the unexpected much simpler. Charters lead us through the planning, team selection and even project selection process. They help us tie the projects to the big picture and help ensure our success. I can think of no better insurance policy to protect us from project failure than that.