Hello, all:

Hope everybody is doing well. Here is chapter 1 of my book-in-progress on problem solving: Selecting the Right Problem. [Yes, I know I should have posted this before chapter 2, which is already posted.] I would love to hear your feedback and criticism.

Craig

Hello, all:

Hope everybody is doing well. Here is chapter 1 of my book-in-progress on problem solving: Selecting the Right Problem. [Yes, I know I should have posted this before chapter 2, which is already posted.] I would love to hear your feedback and criticism.

Craig

Craig,

Thank you for posting Chapter 1 from your new book. :agree1:

What caught my immediate attention is your "LITE" approach. So glad you addressed this method! :applause: I have Clients that throw an 8-D at everything that's nonconforming; even a missing signature. They do not understand that there are different approaches for dealing with "light" infractions.

Keep up the great work.

Great reading, easy to understand and (hopefully :frust:) implement.

Stijloor.

Jan,

Thanks for taking a look at the article, my friend. You're right: problem solving is never one-size-fits-all. The full blown process is often necessary, but sometimes it's just a matter of fixing the problem and keeping a record.

Hope you've had a nice weekend. It's been a lazy Sunday in Kennesaw. For my Father-Daughter time today we went to an old graveyard!

Craig

Craig,

Buddy, as usual, some excellent work. May I offer the following?

Page 7, Death or serious injury, focuses on death or injuries internal to the organization. I suggest that you include design flaws that could cause death or injury to the users of the product, and those in the area of use. Those can be expensive, to say the least.

Page 10, I would add "downgraded production". This may or may not be scrap, but there is a cost. Not that we have any at my company, but it has been known to happen at others. Making high profit product A, only to have to sell it as "Brand X", certainly has a cost.

Craig, you have a knack for making the world of quality make sense to outsiders, while reminding those of us in the quality world what a cool set of tools we have. Thanks for your great work, and thanks for sharing!

Your fellow Georgian,

Keep Rocking

Craig H.

Craig,

Excellent suggestions, my friend. I'm going to add these points immediately to the respective sections. Thanks for taking a look with your sharp eye and keen insights.

Hey, if you have any problem solving 'war stories' from your years of quality and management, I'd love to include them in the book as sidebars. You'd be credited, of course. This will add some color and validity to the subject matter. I bet you've been pressed into problem solving service a time or two (or two thousand).

If you're ever up around Atlanta, let me know.

The Other Craig

Craig:

It's a wonderful gift you possess...the ability to take that which sees many of us struggling to communicate to the average person, and turn it into something so simple. Is there a book on brain surgery or rocket science in your near future? :cool:

One thing to consider is the target audience. Presuming that the readers will have some combination of technical, professional and executive backgrounds, I would suggest that you write in a format that is easy-to-read (for them).

An example of this would be on Page 2, where you have the summary table after all the explanations. People in the expected target audience like to see the summary first...then the details. Our brains keep things in point form and as we read on, we can mentally check things off (i.e., an internal "aha, got it, makes sense).

At the same time, an initial table or summation is that way of grabbing the readers' interest. S/He reads the table and is left wanting to know more.

A summary at the end of the chapter is a great idea, but throughout the chapter, I personally believe that those mini-summaries are better before providing the details.

One type of problem source that is, in my experience, an area where there have been countless benefits to applying our problem-solving methodologies, is production process issues (e.g., unscheduled downtime, maintenance delays, utlization, etc.). These are areas where we could see trends and we left scratching our heads trying to figure out what to do. Every month, we would hear excuses and see finger-pointing. Applying problem-solving tools to this, including using data analysis - which you do discuss - has helped us immensely!

What I basically noticed was that the problem sources were typically at the beginning of the overall process (e.g., supplier issues) or towards the end (e.g., customer complaints, nonconforming product, etc.). What about capturing those intermediate processes...production?

Without belittling the system-side of things, applying problem solving tools in production also made things more "real" for our employees. I wasn't coming to them with problems...they were finding them on their own. It was also an opportunity to communicate the tools to all employees at all levels. Typically, issues like audit findings and customer complaints stay at the supervisor/manager level and up. Problem Solving is no longer "What they do in that office up there."

One could argue that the problem source "Data Analysis" addresses this. In my opinion, it does not. It addresses all problem sources as it the means by which we review the sources to determine if there is a problem.

Roxane,

I must give you credit for inspiring the section on 'Problem Solving LITE.' The notion of explicitly addressing this came directly from you. Thank you!

Your idea of including production problems in the section on problem sources is right on the mark. Somehow, I just missed that one. As you said, it's the middle of the supply chain--the true heart of the organization--and most employees understand this more than anything else. I'll certainly cook up a few paragraphs on this. Thanks for the suggestion. You're an absolute charm.

Now, as for the summary ~before~ the section it applies to. I'm having a hard time wrapping my brain around this one. I write the way I talk and think, and this is a bit of a twist. It's a good suggestion and I'll see what I can do.

Thanks for looking at the chapter and providing such good guidance. I really appreciate it.

Warm regards from Kennesaw,
Craig

Another one of your spectacular books under development.

Coury,


You are too kind, my friend! Thank you.

Craig