Effective Problem Solving - Six Problem Solving Fundamentals

[ccochran]

Hello, everyone:

One of the biggest opportunities I've seen within organizations of all descriptions is to improve the effectiveness of their problem solving. Problems come up, half-hearted attempts are made at dealing with them, and everyone prays that the problem will go away. Of course, the problem comes back, because nobody really understands how to effectively deal with it.

I've assembled a running list of what I feel to be fundamentals of effective problem solving. My thinking is outlined in this article from Quality Digest: Six Problem Solving Fundamentals. I would enjoy hearing what others think on this topic, and of course any feedback on the article would be appreciated.

Thanks,
CC

~~~~~~~~~~~~~~~~~~~~~~~~~~~
Craig Cochran
Center for International Standards & Quality
Georgia Institute of Technology

 

[Craig H.]

Craig:

I really like the down-to-earth approach you take here.

One thing I might add in number 2 is sometimes it helps determine a root cause if we also think about what the problem isn't, as well as what it is. By this, I mean thinking about when a particular problem does happen as well as when it does not. This is, I realize, a picky comment, but I thought it might help in some instances.

Again, I liked the approach, and congratulations on an excellent article.

The other Craig

 

[RosieA]

Hi Craig,
The article is a fine overview of problem solving. I've used and am a proponent of structured problem solving. The big problem with many of the tools is that they don't lend themselves to handling things when there's a big, fat, hairy, crisis.

When there's a crisis, our aim is containment, and because the world is a fickle place sometimes, we never get back to root cause once the customer screaming stops.

Crisis management is not the right approach, but it's the one that most of us are familiar with. Structured problem solving works well when the problem being addressed isn't impacting revenue this month, or doesn't involve a customer with a line down.

The one component you mention that I ALWAYS use, however, is the project management approach. If there aren't minutes, then there's nothing to go on if we do have the time to work on root cause later on. If there aren't action plans, then things get lost in the shuffle and never done.

I once had a CEO who loved a good crisis....made him feel alive and needed. We called it "Mighty Mouse management" you remember..."Here I come to save the day!" This guy scoffed at any attempt I made to use structured problem solving. There was no adrenaline rush. He burned people out pretty fast.

So maybe a good topic for your next article might be: adapting structured problem solving to a 4 alarm crisis: here are tools that work fast under pressure.

Gotta run....got a crisis brewing!

 

[galcantar]

Hi Craig,
The article is a fine overview of problem solving. I've used and am a proponent of structured problem solving. The big problem with many of the tools is that they don't lend themselves to handling things when there's a big, fat, hairy, crisis.

I totally aggre with Rosie.

and when the crisis finishes, everybody forget this issue and runs to "solve" the next...

 

[gpainter]

Too busy putting out fires. Remember what Smokey said, "Only you can prevent(forest) fires!".

 

[Atul Khandekar]

Very good article. Congrats, Craig!

 

[Groo3]

One of the biggest opportunities I've seen within organizations of all descriptions is to improve the effectiveness of their problem solving. Problems come up, half-hearted attempts are made at dealing with them, and everyone prays that the problem will go away. Of course, the problem comes back, because nobody really understands how to effectively deal with it.

I agree with everyone here, nice job on the article...

The hard part, as I see it, is getting people to be consistent in their approach. Sooner or later, a fire is going to have to be put out quickly and people WILL take that shortcut... The next thing you know, they take shortcuts each and every time and pray for the best.

My organization does have a corporate driven quality initiative with continuous improvement at it's core. The training program includes basic problem solving tools and even a set of behavior principles (train annd empower each other to facilitate decision making at the lowest possible level... create a climate of open and honest communication... mutual respect... etc). We even try to recognize achievements via newsletters and the ultimate corporate award (which includes getting treated like royalty for a few days and stock options)... The everyday recognition is where we fall short of expectations. Another shortfall, in some of our problem solving methods, is that we sometimes stop our root-cause investigation once it has been determined that human error was involved. I agree with your article in that human error may not represent the true root cause. Nice job. E

 

[M Greenaway]

Craig

You have broadly outlined the 8D approach, which is a very good model to follow.

I would also add that it is important to distinguish between common causes and special causes, as the type of cause necessitates different actions by different people.

Typically special causes need to be dealt with by stopping, identifying and removing the problem, often best done in consultation with the people doing the work. Common causes are however inherent in the process, and are the contributors to the process capability. The inherent process capability has been created by management, and must be improved by management action, typically requiring process re-design.

Recognition of this fact might stop us constantly blaming operators, with the usual 'additional training' corrective action response, and realisation that the tools, equipment, procedures, training, environment, etc, etc are all contributory to common cause.

 

[ccochran]

Some more thoughts...

Thanks for all the feedback on the article. I agree with everyone’s comments. Rosie’s remarks about needing to take fast action particularly struck me, because this is a fact of life in most business environments. It would be nice if everyone had time to tromp to the conference room for brainstorming and a fishbone diagram, but they’ve already got 100 things to do. The methodology of investigating the root cause still needs to happen, but it needs to happen quickly with no extra bureaucracy.

I’ve developed a quick-and-dirty tool (“Product Failure Analysis Form”) for giving production employees the ability to do some preliminary investigation into the root cause of product failures. The intent is that investigation into causes would start right after the problem is discovered, led by the people most familiar with the issues (i.e., the folks out there producing products). This thing is not rocket science, but it could jump start the problem solving process and compress the time needed to reach valid conclusions. As you can see from the form, the idea is that the completed form would be taken to the morning production meeting for a broader review. Obviously, this tool is generic and would probably need to be customized to fit specific organizations. I’ve attached it at the bottom of this message. Feel free to use or edit it as you see fit.

Groo3’s remarks about recognition are critical. Sincere, simple, and systematic recognition of people and teams will drive effective problem solving. I’ve got something in the hopper right now on that subject that I’m looking forward to sharing with everyone. Mr. Greenaway’s remarks on special versus common cause variation was also key. Unfortunately, that’s not something I addressed at all in the article.

Let me know what you think of the Product Failure Analysis Form. Like I said, it’s not the most sophisticated thing in the world, but something like it could be used almost anywhere. Has anyone utilized anything like this?

Talk to you soon,
Craig

~~~~~~~~~~~~~~~~~~~~~~~~~~~
Craig Cochran
Center for International Standards & Quality
Georgia Institute of Technology

 

[ccochran]

The attachment

And here's the attachment I described in the message above...