Often times, we ask our clients what their proactive or preventative activity is. Most of the time, we get a blank stare. Others provide a list of risks, but no real activity geared towards mitigating those risks.
In the past, we would push the use of Process Failure Modes and Effects Analysis (PFMEA) as a method to achieve a prevention or risk mitigation plan. PFMEA is an excellent tool for doing just that, in addition to tying those risks in with the current issues, to figure out what is most important to be worked on. You can learn more about PFMEA's through our training material.
However, we are taking a step back, instead of jumping right into an FMEA approach. There are easier steps that should be taken first.
First, gather up the stakeholders, customers, and process experts, and facilitate a group discussion on what things could potentially cause problems in the near future. This is essentially a brainstorming exercise. If you get stuck, you could look to the Cause and Effect Diagram approach, and talk about the People, Machines, Processes, Environment, and Materials, and how they can bring about new problems. Once a list of risks are generated, the team should try and informally rank them, and develop an action plan for the top 1-3 issues only. Any more than 3, and you shouldn't be surprised when nothing gets done. Another rule of thumb we like to hold to: no more than one action per person at a time. Again, any more than that, and your asking for those items to be deprioritized, so that nothing gets completed.
After the list of risks are identified, the group should look at the list, and decide if they covered most of the risks or not. If they feel they did, and the list is manageable, then setting up a regular cadence to review these items is probably sufficient. If the team feels that there are other risks out there, then it may require additional sessions. Here is where the FMEA approach can help. It is an effective tool because it walks systematically through the process under evaluation, and forces the team to review the ways each process can fail to meet its intended output. This makes it less likely that an issue will "slip through the cracks". Again, after the list is expanded to include these additional risks, the list can be re-prioritized (this time more formally using Nominal Group Techniques, multi-voting, etc).
Finally, if the list identifies many additional issues, and the team is having a hard time prioritizing the top risks, a formal PFMEA may be needed, to iron out the details, and provide a more objective assessment of which risks are the highest ones needing an action. This is also useful if the team feels the risks are not fully captured, and the formal FMEA approach would bring these risks to the surface.
Again, the key to all of this is to align the complexity of the process to the complexity of your risk assessment. If you have a simple process, a simple approach may be sufficient. If your process is complicated and risks are high, then a more formal risk assessment may be needed. We recommend starting small, and expanding as the list of risks expands and gets more complicated.
When you jump right into a formal FMEA event, and want to spend hours of a team's time and energy, it's often difficult to justify the need to go through that much detail of a process. However, when you start small, it's easier to later justify the need to dig deeper, and get more formal with your risk analysis, once the team sees how much risk is out there that is not being managed.
The key to success is that the risks are added into a regular review or cadence process, preferably the same place where the regular activities are being reviewed. For example, if you have a staff meeting, devote 5 minutes to risk actions. If you have a program review, add 2 slides to discuss risks and actions taken on those items. Maybe start by looking at your personal life. Do you own a house? What actions do you need to complete to prevent a major issue at home? Are you keeping up with your vehicle maintenance? Are you anticipating and planning for upcoming or suprise bills?
The only way you can move away from a "firefighting" mentality is to allocate some of your time working on actions that are proactive or preventative in nature, otherwise you will continue to react to everything that comes along. Discussing the risks, assigning actions, and reviewing those actions are the key steps to make that transition happen. Just get started doing something, then worry about whether it is the biggest risk later on...
Tuesday, September 7, 2010
Wednesday, January 6, 2010
Don't "check the box" with soft improvement tools
We recently were reminded of a problem that comes up every so often in regards to process improvement tools. The "check the box" mentality.
You train, teach and mentor individuals on which tools to use, and when they finally decide to use the right tool at the right time, they try to shortcut the process just to get it completed, missing the entire purpose of the tool!
Let's use the fishbone diagram. Our clients will identify the need for a fishbone or maybe we'll have to suggest it. Instead of gaining the benefits of the team discussion and brainstorming, someone sits down at their desk and starts to fill out the diagram.
"I worked on that last night, and finished it, then emailed it to everyone. Now which tool do we need to do next?"
Process Improvement tools, like fishbone diagrams, are not the end result. The purpose of the tool is to provide a framework in order for the process of evaluation to take place. When we perform a fishbone diagram, we are actually doing many different things without realizing it:
1) we gather up the right resources from cross-functional areas
2) we clearly define the problem statement (often overlooked)
3) we openly talk about problems and variables that cause the problem we are trying to solve
4) we brainstorm why it could be happening (without fear or insults) using commonly used categories (Man, Method, Material, Machine, etc)
5) we generate a very thorough list of potential variables to go investigate
The REAL output of a fishbone diagram comes down to two main things:
1) a plan to go investigate some of the most likely variables
2) an opportunity to interact with a diverse group of stakeholders in the problem, get to know them, and see their unique perspectives and hear how that problem impacts them
Notice we didn't mention a nice looking fishbone diagram with a fish outline around it, with color-coded labels for each category.
Even if NOTHING is done after the fishbone diagram meeting, there still was value in creating the fishbone. Most likely, you will have actions that come out of the effort, but don't overlook the PROCESS that took place to create it, which is where much of the value came from.
We use the fishbone diagram as an example, but it applies to many of the tools, especially ones we consider "soft" (little to no data analysis involved).
The inspiration for this article came from a group we worked with that was trying to quickly complete a Current State Value Stream Map (VSM) because they were running out of time before the scheduled Future State Mapping event. This event had a hard date due to individuals who were flying in from out of town. The team was suggesting that they could quickly draft the Current state map on their own, then have the actual owners of the proceses review it right before the next event, then jump into developing the Future State.
We politely reiterated that the completion of the current state map is not the end result. It is the PROCESS of developing the current state map where the value is created. The most important part is the time spent with a concurrent group of people defining the process, talking about the issues, understanding that the process is broken, and hopefully building relationships with these other stakeholders. Those relationships are really the key to the VSM. Now when future issues come up, they can be avoided or better anticipated, since the perspective of others are now better understood, and they can include or discuss the impact with them BEFORE a change or issue occurs.
For example, during the VSM, you might discover that leaving off the account number on a form causes 10 minutes of work for a later process run by Judy, who was at the event. After the event, you run into an account number that looks unfamiliar. You call Judy and discuss, and she recommends you return the form to the owner before processing it. You've saved yourself time processing it, and cut the wait time from when you completed the form, until she would find the error, and have also given instant feedback to the form originator that there was an error. You also saved Judy time reviewing the document to find the error. Obviously, you would want to permanently resolve this issue. However, this probably was not even a major issue that came out of the event, yet the benefits are already being seen because of the VSM event. If you and Judy had not gone through the VSM process, you would have never been able to anticipate those kinds of issues.
Spending time in an event will also give people a chance to think clearly about how they do work. It will also allow them time to digest the fact that the process is indeed broken, and that they will have to change the process in order to make it better, especially if their process is the one causing the most problems. If you speed through this process, you'll miss the entire change management process, and you won't have the commitment you need going forward.
We also see people get wrapped up over the format of the template. On an FMEA, they argue over the title of a column (Key Product Characteristic or Critical to Quality), or whether the Severity ranking is a 6 or a 7. The FMEA creates a nice spreadsheet for prioritizing the effort, but the value lies in the concurrent discussion between all stakeholders. After the event, the individuals in the event are much more likely to think differently, and talk directly to each other about other issues they encounter, than they were before the event. The FMEA was just a process developed that forced this group collaboration to take place.
In a perfect world, all processes would be linked together where this communication and discussion was happening constantly between all stakeholders, but we know that's not realistic. Companies get siloed away from each other via departments and budgets and physical locations. These soft tools are necessary to bring thsse groups back together, even if for just a day or two.
The tools that are more about the process, rather than the actual end result include: FMEAs, 5 Whys, Affinity Diagrams, Force Field Analysis, Process Flow Diagrams, Value Stream Maps, and Fishbone (Cause and Effect) Diagrams. This doesn't really apply to the "hard" analysis tools like control charts, histograms, statistical analysis, etc. Those can be performed by an individual without a team, as long as the results are shared and digested as a team.
Bottom line: The process improvement tool is not usually the end result. The process to get there is where most of the value is created and discovered, so don't try and shortcut the process just to "check the box".
You train, teach and mentor individuals on which tools to use, and when they finally decide to use the right tool at the right time, they try to shortcut the process just to get it completed, missing the entire purpose of the tool!
Let's use the fishbone diagram. Our clients will identify the need for a fishbone or maybe we'll have to suggest it. Instead of gaining the benefits of the team discussion and brainstorming, someone sits down at their desk and starts to fill out the diagram.
"I worked on that last night, and finished it, then emailed it to everyone. Now which tool do we need to do next?"
Process Improvement tools, like fishbone diagrams, are not the end result. The purpose of the tool is to provide a framework in order for the process of evaluation to take place. When we perform a fishbone diagram, we are actually doing many different things without realizing it:
1) we gather up the right resources from cross-functional areas
2) we clearly define the problem statement (often overlooked)
3) we openly talk about problems and variables that cause the problem we are trying to solve
4) we brainstorm why it could be happening (without fear or insults) using commonly used categories (Man, Method, Material, Machine, etc)
5) we generate a very thorough list of potential variables to go investigate
The REAL output of a fishbone diagram comes down to two main things:
1) a plan to go investigate some of the most likely variables
2) an opportunity to interact with a diverse group of stakeholders in the problem, get to know them, and see their unique perspectives and hear how that problem impacts them
Notice we didn't mention a nice looking fishbone diagram with a fish outline around it, with color-coded labels for each category.
Even if NOTHING is done after the fishbone diagram meeting, there still was value in creating the fishbone. Most likely, you will have actions that come out of the effort, but don't overlook the PROCESS that took place to create it, which is where much of the value came from.
We use the fishbone diagram as an example, but it applies to many of the tools, especially ones we consider "soft" (little to no data analysis involved).
The inspiration for this article came from a group we worked with that was trying to quickly complete a Current State Value Stream Map (VSM) because they were running out of time before the scheduled Future State Mapping event. This event had a hard date due to individuals who were flying in from out of town. The team was suggesting that they could quickly draft the Current state map on their own, then have the actual owners of the proceses review it right before the next event, then jump into developing the Future State.
We politely reiterated that the completion of the current state map is not the end result. It is the PROCESS of developing the current state map where the value is created. The most important part is the time spent with a concurrent group of people defining the process, talking about the issues, understanding that the process is broken, and hopefully building relationships with these other stakeholders. Those relationships are really the key to the VSM. Now when future issues come up, they can be avoided or better anticipated, since the perspective of others are now better understood, and they can include or discuss the impact with them BEFORE a change or issue occurs.
For example, during the VSM, you might discover that leaving off the account number on a form causes 10 minutes of work for a later process run by Judy, who was at the event. After the event, you run into an account number that looks unfamiliar. You call Judy and discuss, and she recommends you return the form to the owner before processing it. You've saved yourself time processing it, and cut the wait time from when you completed the form, until she would find the error, and have also given instant feedback to the form originator that there was an error. You also saved Judy time reviewing the document to find the error. Obviously, you would want to permanently resolve this issue. However, this probably was not even a major issue that came out of the event, yet the benefits are already being seen because of the VSM event. If you and Judy had not gone through the VSM process, you would have never been able to anticipate those kinds of issues.
Spending time in an event will also give people a chance to think clearly about how they do work. It will also allow them time to digest the fact that the process is indeed broken, and that they will have to change the process in order to make it better, especially if their process is the one causing the most problems. If you speed through this process, you'll miss the entire change management process, and you won't have the commitment you need going forward.
We also see people get wrapped up over the format of the template. On an FMEA, they argue over the title of a column (Key Product Characteristic or Critical to Quality), or whether the Severity ranking is a 6 or a 7. The FMEA creates a nice spreadsheet for prioritizing the effort, but the value lies in the concurrent discussion between all stakeholders. After the event, the individuals in the event are much more likely to think differently, and talk directly to each other about other issues they encounter, than they were before the event. The FMEA was just a process developed that forced this group collaboration to take place.
In a perfect world, all processes would be linked together where this communication and discussion was happening constantly between all stakeholders, but we know that's not realistic. Companies get siloed away from each other via departments and budgets and physical locations. These soft tools are necessary to bring thsse groups back together, even if for just a day or two.
The tools that are more about the process, rather than the actual end result include: FMEAs, 5 Whys, Affinity Diagrams, Force Field Analysis, Process Flow Diagrams, Value Stream Maps, and Fishbone (Cause and Effect) Diagrams. This doesn't really apply to the "hard" analysis tools like control charts, histograms, statistical analysis, etc. Those can be performed by an individual without a team, as long as the results are shared and digested as a team.
Bottom line: The process improvement tool is not usually the end result. The process to get there is where most of the value is created and discovered, so don't try and shortcut the process just to "check the box".
Subscribe to:
Posts (Atom)
