Hello!

I'm working on a book on Problem Solving. Each chapter will represent a different step in the method that I use and teach. Chapter 2, Defining the Problem, is attached for your review. I would love to hear what you think about this.

This project has me very inspired, because problem solving is truly universal...it's not something that only quality practitioners should be concerned with. Hopefully I can live up to challenge of producing something that everybody can use.

Craig

Hello!
Hopefully I can live up to challenge of producing something that everybody can use.

Craig
:applause:
As i expected your work again is very readable but still full of information. Not hard to read for those new on the subject but still very informative for those who are not really new.

I have 1 input on the part of defining a problem:
Based from experience it sometimes help to define first what is Normal, and use as a benchmark against the current situation. After it was decided that the current situation is really a problem/symptom of a problem(based on why it matters..) it maybe easier to define the problem itself.

Hope that's a good input :)

>>rey

Craig:

A very good read, written in such a way that one does not require a Ph.D or a genius-level IQ to comprehend the message. It has the ability to be understood by people from all levels and walks of life, which is always a good sign of an effective communicator! :D

A few items did, however, catch my attention...

This was, perhaps, a deliberate attempt to re-inforce the message. "Defining the Problem Statement" and "Observe the Problem Yourself" repeat each other with the former providing a more detailed explanation of the questions presented. If this to emphasize the questions, it might be more effective to short list them in the first section and then go into greater detail (lure the reader into asking him/herself how to answer the questions and then provide the guidance).

In the section "Methods for Defining the Problem", the introduction paragraph states "...data gathered, processes observed, people interviewed... and yet the sections afterward are not in the same order. As above, it is good to see the short list and then the detail. However, as an analytical reader, I find it easier to mentally check-off my questions if the guidance is presented in the same order as the short list. The sections afterward are Processes, People, Data.

You also discuss photographing the situation. Does this fall under the Data Gathered section or is it a fourth means of defining the problem? It is difficult to tell with the formatting of the font for the subsections. Differing font applications will assist in the reading flow.

Again in "Methods for Defining the Problem", the short list indicates "data gathered", but the section that follows is "Data Analysis." Gathering and Analyzing are two separate steps in the process of solving a problem (in my opinion).

I look forward to seeing the other chapters. Perhaps you could list the steps in your problem solving process? I will say that my own approach differs slightly. In adopting the PDCA approach to solving a problem, I use a 8-step approach where Problem Identification and Observation are the first 2 steps (i.e., not combined into one as I read in your chapter).

All in all, though, it was a good read in a clear and simply language that introduces the reader to the beginning of how to solve a problem and I look forward to reading more!

Hello!

I'm working on a book on Problem Solving. Each chapter will represent a different step in the method that I use and teach. Chapter 2, Defining the Problem, is attached for your review. I would love to hear what you think about this.

This project has me very inspired, because problem solving is truly universal...it's not something that only quality practitioners should be concerned with. Hopefully I can live up to challenge of producing something that everybody can use.

Craig

Thanks for sharing--very well done, as usual. One thing that often gets overlooked in problem solving (and identification) is requirements that cause problems. We see examples of the phenomenon in the Cove on a regular basis, especially with regard to MSA. Customers who don't understand their own requirements but are obstinately rigid in enforcing them anyway cause untold amounts of fear, loathing and waste.

A good question to ask in this regard is "What gets worse?" In the squirrels-in-the-attic example in the sample chapter, the noise causes fear and annoyance. In the case of a nonconforming part shipped to a customer, there is loss of revenue and other undesireable results. But in the case of a GR&R result that is beyond an arbitrary limit and has no effect on production of conforming product, nothing necessarily gets worse if the requirement is disregarded. The problem iscaused bytherequirement.

Rey,

That's very good input. Thanks a lot. I had a similar intent with the "Why does it matter?" step, but you described it much clearer. I'll see how I can weave this into the narrative. Also, my step 3 of my problem solving method (Defining the current process) will go into what is 'normal' in terms of the process steps. Great advice.

Roxane,

Thank you, madam. You made a bunch of good points, and I've already made a bunch of tweaks and changes based on it. The chapter (as posted) has a bit of a 'stream of consciousness' clunkiness to it that needs to be ironed out. Your ideas got my thoughts better organized. Here's the process on which the book will be based:


Evaluating & prioritizing problems: Deciding which of the many problems are worth addressing.
Stating the problem: Defing the details of the problem in clear concise language.
Defining the current process: What is the process right now? By understanding it, we can begin to see where things are going wrong.
Identifying the causes: At each step of the current process, what are the real and potential causes of our problem?
Planning and implementing solutions: Plan and take action to remove (or reduce) the biggest causes we identified.
Verifying effectiveness: Make sure what we did worked.
Documenting the improvement: Set the new standard for the process so we don't slide backwards.


Thanks so much for your guidance.

Jim:

Yes, that's excellent! I was hoping to insert a sidebar on exactly that issue. Back in my textile days, there were all sorts of rejected product based on strange specifications that didn't seem to have any purpose. Once the customer was educated on their own specifications, the problem often disappeared and everybody was happy. It's funny how the requirement can get people wrapped around the axle sometimes...

Craig

If the gist of this paper could be condensed further, we should consider putting it in the 'FAQ' or 'How to use the forum' section for the benefit of new users.

Many new users do not know how to state their problems and coupled with language issues, we find that there are not many response to their post because no body really understand the post or problems the poster mentioned.

Thanks for another reader-friendly piece of work.

Harry,

Thanks for your feedback, sir. I'll try to trim this down to the essense (just like a real problem statement) and post the condensed version. That's a good idea about making this available.

Craig

Craig, excellent as always. thanks for sharing.

Great info Craig and thanks for sharing.

Early this week, I had to give training on a similar subject and for that training, I had to scratch my head for 2 days before the training day. If I would have got this info earlier, it would have been great. ;)

Anyway, shall consider the contents for refresher training :)

Based from experience it sometimes help to define first what is Normal, and use as a benchmark
>>rey
While you are defining Normal, it often pays to think about what is the Best Normal (Best of the Best) and the Worst Not-Normal (Worst of the Worst). Looking at the extremes often helps to put the problem in perspective.

Excellent information in this short chapter.

One point I wanted to mention - I went to a seminar on this topic (years ago - root cause analysis, etc). If memory serves, we were taught to write problem statements in terms of the procedure that was "violated".

So the problem wouldn't be "Shipped 3 pieces instead of 4" but "The procedure to ensure shipping accurate quantity was not followed" or some such example like that.

Does that still hold true? Should problems be defined in terms of what part of the ISO/Quality system "failed" for lack of a better word?

Excellent information in this short chapter.

One point I wanted to mention - I went to a seminar on this topic (years ago - root cause analysis, etc). If memory serves, we were taught to write problem statements in terms of the procedure that was "violated".

So the problem wouldn't be "Shipped 3 pieces instead of 4" but "The procedure to ensure shipping accurate quantity was not followed" or some such example like that.

Does that still hold true? Should problems be defined in terms of what part of the ISO/Quality system "failed" for lack of a better word?

I'm not going to contradict your training...but....:cool: by saying "The procedure to ensure....was not followed" implies that you've already started root cause analysis in your problem statement.

Problem - Incorrect quantity of pieces shipped

Additional Facts - Intern working in Shipping office. Hand held scanners not working on day of shipment. Overhead Crane in Bay4 was down to 60% utilization.

Why #1 - Customer revised order requiring Shipping to update the order.
Why #2 - Procedure to update order to ensure accurate quantity shipped was not followed.
Why #3 - Interns are not on training matrix and are not trained on procedure to update orders.
Why #4 - blah blah blah
Why #5 - blah blah blah

Root cause analysis could have show that it was an error in the software of the scanners or the method by which the materials are put onto the truck.

Problem identifcation should simply state what the situation is....in my opinion...

I'm not going to contradict your training...but....:cool: by saying "The procedure to ensure....was not followed" implies that you've already started root cause analysis in your problem statement.

Problem - Incorrect quantity of pieces shipped

Additional Facts - Intern working in Shipping office. Hand held scanners not working on day of shipment. Overhead Crane in Bay4 was down to 60% utilization.

Why #1 - Customer revised order requiring Shipping to update the order.
Why #2 - Procedure to update order to ensure accurate quantity shipped was not followed.
Why #3 - Interns are not on training matrix and are not trained on procedure to update orders.
Why #4 - blah blah blah
Why #5 - blah blah blah

Root cause analysis could have show that it was an error in the software of the scanners or the method by which the materials are put onto the truck.

Problem identifcation should simply state what the situation is....in my opinion...

Roxanne,

Absolutely! Excellent points. :agree1:

Jumping to conclusions (possible causes) muddies the problem/nonconformity statement and misdirects the root cause analysis. Regretfully, folks in quality and manufacturing are already pre-programmed to think in this erroneous way. For example, a problem is observed; someone says: "Oh that's because of....."

This is also a problem with FMEA; mixing up failure modes, effects and causes.
A structured/systematic approach is required.

Interesting stuff, and it keeps coming back.

Stijloor.

I'm not going to contradict your training...but....:cool: .

Good point!
And to add, "The procedure to ensure....was not followed" is actually assuming that the procedure itself is correct and has no room for further improvement(Mistake Proofing, etc), which is ussually not the case.

EDIT PART:
I forgot to mention that in a Problem Solving Process it is VERY important to draw the line between FACTS and ASSUMPTIONS. Though im not sure which step should i put it. But it sure is important when defining the problem and proposing for a solution.

What an interesting debate we've spawned. I think Little_Cee has a good point. What LC was saying has perfect validity: for there to be a problem, you need to have a standard or requirement that's been violated. The requirement could, in fact, be contained in a procedure. This is a legitimate part of the problem statement. Actually, the true source of the requirement would probably be the sales order (given the example Little_Cee used). Either way, it's very helpful to say what the requirement is. I don't think we would be assuming a causal relationship, just saying what standard has not been met. We haven't explored WHY the procedure or sales order was not followed, only described the source of the requirement.

In the example Little_Cee started, here's how I believe I would write the problem statement:

What exactly IS the problem? - We shipped 3 units of product XYZ to the ACME Company, instead of 4 units. ACME was forced to stop production because of the shortage.

Who experiences the problem? - The ACME Company receiving department supervisor.

Where does it occur? - The problem was discovered at the ACME receiving dock

When does problem happen? - The problem was discovered at approximately 11 AM on 6-26-08 and 6-29-08, during the time ACME receives truck shipments.

How often does it occur? - This has happened twice. In both cases, we shipped 3 parts instead of 4, as required.

Why does it matter? (i.e., what standards or requirements are violated by the problem?) - Sales orders #18867 and #18854 required 3 units of part XYZ. Also, ACME claims to have lost $30,000 of revenue as a result of stopping production.

After writing the problem statement in a clear and factual manner, then you can proceed to the next step of problem solving...

Craig

Ajit,

I remember one time I taught somebody else's problem solving course. There was just ~1~ slide in the section for Writing the Problem Statement. It said, "What IS." No more detaills. I looked at that slide and said, "Uh, yeah. Just say what the problem IS!" Duh. Until you start peeling these issues back to their cores, it's hard to know what to say sometimes during a course. I always come across good stuff a few days after I teach something, too...

Craig

Thanks for sharing. The attached file is great. However, there are some cases on our part, symptoms are mistaken as a problem. In this regard, some problems were solved immediately without realizing that they are creating a minor fix not thoroughly solving the problem.
Raffy

I sent Craig a PM on this thread as I felt that perhaps the gist of what I wanted to say would take away from the focus of his original intent (i.e., our opinions on the chapter exerpt). The last thing I wanted to do was side-track the thread or turn it into a debate on the process for problem solving. The latter belongs in its own thread in another forum.

Craig, however, said to feel free to include my PM in this thread and I will. If I see that the conversation starts to turn more into a debate on problem solving instead of commenting on the chapter exerpt, we'll need to do some "thread maintenance". :D

*** *** ***

Craig:

Reviewing your sequence of steps in problem solving had me thinking about my own organization's approach to treating failures.

We try to classify a problem into one of two types - abnormal and chronic. While the approaches to resolve the two are similar, chronic problems are treated with a more rigid system.

Abnormal problems are those failures which occur on a daily basis (but not consistently or for the same reason...to our initial perception).

The steps taken to resolve abnormal failures is:

Identify the failure
Eliminate the effects / symptoms of the failure (i.e., correction)
Record all failures
Separate irrelevant failures
Develop and execute action plan - including revision/creation of standards and training
Confirm elimination of the failure's causes
Complete report


In my response to your book exerpt, I realized that my feedback was based more upon our approach to resolve chronic problems. These are problems that recur and will require a systematic and rigourous use of quality tools in a team environment. It also requires that the team actively share the history and solution of problems with others in the organization - this is done through a web-based software where sites can see chronic problems solved by other sites and our company problem solving competitions (our North American competition was in May at Disneyworld and the top 3 teams will compete in our global competition in Brazil in October).

The steps utilized here are:

Identify the problem
Observation
Analysis
Action Plan development
Action Plan execution
Checking
Standardization
Conclustion - overall results, benefits, lessons learned, recognition, celebration of success


Out of curiousity, does your own approach to solving problems distinguish between daily problems and those which require a more formalized method? If so, do you alter the treatment of these failures based upon their type?

*** *** ***

In addition to my PM, let me briefly expand upon the Conclusion step for resolving chronic problems. It is very important to recognize and celebrate the successes and lessons learned. Our approach for resolving chronic problems typically saves the company a lot of money and requires very little (if any) capital investment.

In fact, at our North American competition, the lowest $ was over $300,000 with the largest being over $4 million. And, of course, we can not put a price on the non-financial problems solved (i.e., safety-based problems).

In actually reviewing my training notes, I found that we were instructed to write up corrective actions against THE SYSTEM - my exact notes read as follows:

It is important to write nonconformities defining the system problem, or the respondent may only address the specific incident

I'm not arguing - I agree with everything that has been said so far and think that the book chapter is excellent.

Little_Cee,

You said a couple of things that really add value. One is that problem are system issues, as opposed to being personal issues. We're trying to improve our processes, methods, and systems, not find culprits and guilty parties. The other angle is taking global action on individual problems. Yes, the problem might have occured right here, but it's probably also occuring elsewhere. Even in these cases, I think it's important to define the specific what, who, when, where, and why it matters aspects of the problem at hand. Good thinking.

Roxane,

You always bring up the angle I forget. Yes, of course there's another variety of problem solving. Kind of like problem solving LITE. These are problems that need to be addressed, but don't require the full rigor of structured problem solving. I think I might mention this in the introduction or the first chapter (on selecting problems), and then have a complete chapter at the end that addresses dealing with what you refer to as 'abnormal' problems. Thanks for the great idea.

Craig

In actually reviewing my training notes, I found that we were instructed to write up corrective actions against THE SYSTEM - my exact notes read as follows:

It is important to write nonconformities defining the system problem, or the respondent may only address the specific incident

I'm not arguing - I agree with everything that has been said so far and think that the book chapter is excellent.

little__cee, The teaching you've received is all right, you write nonconformities against standards and procedures - when you audit. Nonconformance against document is an auditor's problem. But it may be that your problem is not adressed in any document.

--------------

I think the chapter is excellent. Actually, I wrote a guidance to our QS about problem solving just two weeks ago - I reviewed it now in the light of the text
and I greatly appreciate finding these three checklists of "possibly bad problem definition" ("attack" etc, "due to" etc and "always" etc).

Craig, you might want to gather all these as one review phase? As a second thought, I attended a problem solving course somewhere where the 5W and 1H questions were "enhanced" by comparison "where NOT" etc. I know you address that in your part about interview tehniques, but you might include it near the end too?

I am very much looking forward to next chapters.:applause:

It just occurred to me that I proposed a unique root-cause analysis algorithm here a while back. I call it WTHH&W (http://elsmar.com/Forums/showthread.php?p=204191#poststop). The first part (WTTH) is germane to the discussion here. :tg:

RLewing,

Putting all the review items in one place is a very good idea. My mind thinks in little boxes, and I rarely bother to put the boxes in one place. Thanks for the fine idea. I have an IS / IS NOT checklist (which is what I think you made reference to), but I couldn't figure out a smooth way to include it in the chapter. I've attached it, just in case anybody is interested. The IS/ IS NOT checklist is used in the problem solving course I teach. By the way, thanks for your kind feedback.

Jim,

'What the HẼLL happened'... I love that! You developed a simple and catchy method for problem solving. All methods need some sizzle to catch on. That's what has propelled six sigma for so long...

Craig

It just occurred to me that I proposed a unique root-cause analysis algorithm here a while back. I call it WTHH&W (http://elsmar.com/Forums/showthread.php?p=204191#poststop). The first part (WTTH) is germane to the discussion here. :tg:

Jim, have you patented the term - truly a great term. If you do not mind, I shall use it in all my presentations ;)

Quality Digest was desperate and I got lucky...

They printed the article "Defining the Problem" in their Sept 2008 issue:
http://www.qualitydigest.com/magazine/2008/sep/article/defining-problem.html

Craig