Defining the Problem (book chapter)

[ccochran]

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

[reynald]

Originally Posted by ccochran

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

Craig

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

[RCBeyette]

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!

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!

[Jim Wynne]

Originally Posted by ccochran

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.

[ccochran]

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:

1. Evaluating & prioritizing problems: Deciding which of the many problems are worth addressing.
2. Stating the problem: Defing the details of the problem in clear concise language.
3. Defining the current process: What is the process right now? By understanding it, we can begin to see where things are going wrong.
4. Identifying the causes: At each step of the current process, what are the real and potential causes of our problem?
5. Planning and implementing solutions: Plan and take action to remove (or reduce) the biggest causes we identified.
6. Verifying effectiveness: Make sure what we did worked.
7. 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

[harry]

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.

[ccochran]

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

[SteelMaiden]

Craig, excellent as always. thanks for sharing.