And there is the problem. We need to solve it.
Every business in existence has had a problem. Each one of the problems detour performance from optimal or desired results. So, what do
we do - try to solve the problem by some means. The approach we use can be the beginning of success or potentially failure. I am confident in this since I am going to 
make a broad assessment - each of us have identified a problem, put something into place, observed success to only find out that later we are still experiencing the same problem. What happened? Well, either we did not solve the problem or we did not sustain the actions which remedied the problem. Those are the only two possibilities. If the problem came back, but in a different form then we have a new problem to solve. If the same problem with the same criteria exists then we go back to the later, a) we did not solve the problem, or b) we did not sustain the actionables determined at the time. So, in short, we need a solid plan of attack. To get a plan of attack we must understand the gap, or the distance from our current state to the desired state. Essentially, any problem solving is about identifying the gap, and steps needed to execute against to get there.
Identify the problem. What is the problem exactly? Specificity is critical at this point. X happens at Y for Z duration while Process A occurs. We want to have it detailed out so that anyone picking up this statement can understand the reason for this event and the impact to your business.
Assemble the team. This should be a group of people which can relate to the problem in some manner, but do not need to be directly involved. It is good to have a cross functional team, along with ad-hoc members. The team should have a leader, facilitator, subject matter experts and or operators (depending if they are one in the same), and a couple other team members that could provide insight but not necessarily a part of the home team or department. For example, I may include another department, another experienced manager, etc. A team is not one person calling a group to the office to pound through the exercise to satisfy a required event. Many projects, such as a Six Sigma (Green or Black belt) use a team charter. The charter states the team members, the goal state, the current condition and rough time line (if applicable).
Research any history. This is not a common or traditional method for problem solving. Yet, I find it very beneficial. Remember earlier, when I mentioned issues that reappear or repeat? I have found that looking over previous problem solving data and events to be very rewarding. There have been times that I have switched the order up as well; I have performed this task upon identification of the problem.
During this step take a look at the history of this event. Has there been any problem solving or similar events around this problem? If so, look for the action items that were associated with the event. How many of the action items are still applicable - and are they still in place? What would it take to determine what it would take to put the items back into place or query as to what happened? Sometimes the solutions put into place are discontinued when new events take place. This could include, but not limited to: new crew members, new management staff, new machinery, lost standardized work, complacency since the problem "does not exist," and so on. If you have a group formed present this data to the group for review. You may find that some of the steps of this "new" event will go quicker - but I encourage you to walk through the steps in case that the originating group was not able to correctly identify the true root cause or that the nature of the problem actually changed thus, creating a different problem.
Identify potential contributors. For each problem there are cause and effects. Many times, at this point, we are not certain which levers control which outcomes so we have several items that need to be listed out here. Some people like to use the fishbone diagram. This cause and effect diagram (which sort of resembles fish bones) allows a group of people to list potential contributors. Many diagrams use the 6M criteria 
to categorize the ideas into buckets. These categories include: Man, Material, Method, Machine, Measurement, and Mother Nature (Environment). Although many issues have a root cause, it is possible that there are a sequence of events that lead to one problem. In statistics we would use multi-vary testing to identify correlation. (I will look at this in another entry coming soon.)If you have data collected, you could also use the Pareto Principle (80/20 rule) to isolate some of the key drivers. Having data at this point, will only benefit the process. It allows your potential contributors to become more of a hypothesis, or educated guess. In addition, quantity is the key. There are no "wrong" answers and the less than ideal ideas will phase themselves out over time. You have to consider that most people will not propose ridiculous ideas for fear that they will be critiqued.
Identify potential solutions. There are several methods which can be used to identify potential solutions for the problem(s) listed. I have found that it depends on the group. I know, that is very helpful, right? Let me explain. If the group is an outspoken group, or one which has quickly moved through the phases of assembly (forming, storming, norming etc.) I will let the brainstorming take place on a white board with an open discussion. If the group is slow to respond then I would propose taking sticky notes (Post-it notes) and give everyone a stack. Tell the group to write down as many ideas for solutions as they can which come to mind. Quantity over quality, again, at this point. We want to get the creative juices flowing. After the group has listed out items, start allowing ideas to be suggested from the notes and place the notes on the board. Try to categorize them as well while posting to the board. Many good ideas will "piggy back" another idea, or come to mind from another idea.
Rank the potential solutions. There are several different methods for ranking as well. Some of the ideas could be voted on one by one, or everyone rates their "top three," or by combining ideas you may be able to narrow down the group to a select few. After this task is completed - 
we need to move to a way to attack the ideas. For this, I prefer using a 2 X 2 matrix. For this we draw out a large square with 4 sections. They have X and Y axises ranking from low to high. It could be for lowest to highest cost, length of time to implement, ease of implementation, impact to problem or area... The criteria really depends on the actual situation. Once, this is created list the ideas that have made the cut beside the 2X2. With the group's direction place the ideas into the matrix. The goal would be to have solutions end up in the upper right quadrant. These ideas are the ones that the group will go after first. The lower left are the costly or difficult solutions. It could be the solution - but less likely if you are truly critiqued the ideas.
Pause and reflect. Now, I usually pause and address the group. I summarize where we are at, with the problem solving event. We have identified the problem, researched the problem, identified potential causes and solutions as well as rank the solutions in a priority order based on group consensus. So if we solve all the items within the 2X2, which should correlate to potential contributors, does the group believe the problem will be solved; have we nailed problems/solutions that are likely to be the root cause(s)? As the leader, it may need to be revised a bit at this point before we proceed. Once the group is in agreement, we can move forward. Let us be clear, though, that you are dealing with an experiment if you will. You have likely causes, effects, and educated guesses to solutions. Failure should be considered acceptable, if learned from, and the PDCA cycle (plan, do, check, act) may come into play. That is, we may need to come back together as a group and revisit some of the steps. The key is to document, and be sure that we are executing against what has been agreed upon.
Identify Action items. So at this point we have things designed so that we can take action steps. Activities have been mapped out, and now we need to assign SMART goals to the potential solutions. Smart goals are specific, measurable, assignable, relevant, and time bound. List out steps that need to take place so that solutions identified can be put into place. They may include meetings, trainings, setting up tests with parameters for test and control, setting a regroup time, just to name a few. The list should include the ACTION STEP, WHO is accountable, and what date the task is expected to be completed by. The dates may be moving targets and if something needs to change be sure to update the group. Thinking in terms of a Gantt Chart format - others may need to know that the dates have moved due to ... so that any dependencies can be adjusted accordingly. Set a time and date for a quick regroup to make sure that the project is still on task, and if anything new has come up. Revisit prior steps as needed.
Regroup for validation. Go over the test results as to what was observed. Did the tasks get completed, and did the data indicate your steps provided favorable results? Were you able to see the "light on off" when testing your solution(s)? If process A was changed did the independent variable (test) show desired results compared to the dependent variable (control)? If you add and take away the new process - does the data support that?
As you identify working solutions it is important to start he standardization process. To change a process it is not always just as easy as "go do it." People like to know the why of the what... they want to know the reasons for the change and the importance of the newly developed strategy defined by your team. I believe it was Covey which stated that it takes 21 days to make a habit and you are dealing, most likely, with a culture that will need to be aware and adopt the new process which will eventually lead to ownership.
Implementation. It is important that during the standardization process all the operators have input do the creation of the living document. Some documents are called standardized work, OIF's, job aids, work instructions, just to name a few. During this time train the operators, and allow multiple sessions for everyone to cover the new materials. A recent white paper study SIStem shown that it takes 6+ times of repetition and failure for the process to be adopted successfully by 90%+ of the people.
Create a status check. This is the MOST IMPORTANT step of any of the project steps. For your problem to be sustained and adopted then follow up events to evaluate the status need to take place. This is both for the operators to provide any feedback for suggestions and to ensure that the root cause was really identified, solution implemented, and sustained. One of the best ways to validate a process is to audit. Audits can come in the shape of a form, verbal and physical walk through, and examination of recent history data. I would propose that the group plans on auditing the process at 30 days, 60 days, 90 days and then on some form of longer interval. Reminders can come from systems (if you have something in place for tasks - possibly the same a many mechanics use for timely mechanical checks or PM's). This could be as simple as an Outlook calendar reminder.
Report out of event. Once you have completed this event, determined solutions, and have observed success, a report out of the event should take place. Invite the department managers, supervisors, other management, some team mates (as applicable) and walk through the process of how you identified the problem - determined the gap and put steps in place to close the gap. Report out events are important for several reasons. It is good to show that the money tied into the resources for the test were valuable, allows other departments to consider learning from your events, as well as an opportunity to show professional growth.
Learnigs. Lastly, I wanted to take a moment to share a few things that I have noticed over time, in no particular order.
- If you give people the chance to be quiet while working in a group that is less than engaged, they will be. Call people out for idea suggestions to create or sustain momentum. Many "piggyback" ideas come from other ideas and could be lost if not captured in the group setting.
- A couple smaller meetings to gather the group while going over the problem solving steps is often better than one larger meeting. People will tend to get distracted with longer meetings, as most are busy outside of the current tasks you share for the project. In addition, many of the steps could require "homework" and the group will come to a stalemate without the information to proceed.
- Take Maxwell's advice - it is ok to fail as long as you are "failing forward." During the exercise it is OK to have to take steps backwards and rethink the strategy. If it was an easy problem to fix - you would not be enlisting a team for hours in a formal event setting. Be sure to document any learning that take place for history purposes. They can be put into an appendix and do not have to be shared publicly but will be accessible if the event needs to be revisiting down the road.
- The PDCA cycle is a process where we plan for an activity to take place, perform against the activity, check the results and act or refine based on them. The CHECK and ACT (or Status check, above) allows you to continually verify the root cause was identified and sustained.
In conclusion, I could go over this topic for hours. It is important to understand that the tools used are simply that: tools. The real work comes from the dynamics of the team to define and act. We are simply trying to close the gap for to achieve a desired state. If you have any further questions or need help walking through a process please feel free to reach out to me. You can post in the comments below, or visit the contact link within the blog.
To download the Template that I have assembled: ProblemSolvingTemplate
Best Wishes,
WordPress.com
No comments:
Post a Comment