To me, few things in life are as thrilling as problem solving.
I love that in my job, I apply proven problem-solving formulas to big challenges – all for the sake of continuous improvement. Getting better and better. That’s what Lean and Six Sigma are about, and I find it amazing. Here are some great jumping off points to get a better handle on your problem:
What exactly is the problem?
It’s exciting to jump straight into doing root cause analysis on your problem, but before we get there, there’s a crucial first step: problem definition. What exactly is the problem. Be as precise as you can!
Do you have accurate data?
Before you even a lift a finger or start guessing about root cause or breaking anything down you look at when were your gauges last calibrated. How exactly will you know if the problem is solved? What measurements are you using to gauge the situation? Are your measurement tools accurate? What standard is this measuring to? You check the sources of your data.
Analyze the root causes of the problem.
Where is your problem coming from? It’s important to understand that the source of your problem might not actually be a single source. Perhaps you have a bad part being produced – and the reasons are coming from several directions. Perhaps you have a broad result that’s happening for 3 different reasons. Discern which of the reasons is most important.
- 70% of the time, it’s because of worker error.
- 20% of the time, it’s because of defective machinery.
- 10% of the time, it’s because of faulty materials.
Start with the low-hanging fruit.
Tackle the highest priority reason first, and ask piles of questions to learn as much as you can about the problem:
- what’s the history of this problem?
- who was involved with the problem when it first started happening?
- what does it sound like/smell like/taste like?
- where could this be coming from?
Involving your support team here is huge.
Rally together; brainstorm possible theories. Compile some best guesses – start researching those, checking them out. How can you start testing hypotheses? Get every member of the team involved: “Okay, you’re going to go pull the records from last winter to see if the temperature did have an effect on the functioning of the piece”, or “You’re going to go talk to this person because they were around when we installed it and they would have an idea of whether this was certified to the same calibration as this thing.”
Start Improving.
Now that you’ve isolated the primary source of the problem, and you’ve identified and tested theories, it’s time to implement some changes. Perhaps you’re running some re-training for staff. Maybe you provide them with a new tool. Sometimes it’s a very simple programming change, sometimes it’s a much more complex and layered solution.
Install Controls.
You’ve fixed the problem, it’s time to cross the t’s and dot the i’s, update the procedures. You want to make sure your improvements don’t get undone, so you create systems and processes to keep it working smoothly. In this stage, you’re walking around thinking about how this could possibly undo itself, and doing everything you can to make sure it doesn’t. This could include training your supervisors or leadership staff. Help them understand what the new process is. Again, updating documentation is often really popular in the control phase. And then you’re also sort of preparing all of your closing documentation and getting ready to report out to your leadership team on the results and what’s required now to keep those benefits in place.
Have you worked through a process like this?
What’s worked well for you? Is anything missing here? Leave your responses in the comments. I’ll read and respond.
