Sunday, November 25, 2018

New Book Part 1

In this series of blog posts, I will be discussing my newest book, The Focus and Leverage Improvement Book - Locating and Eliminating the Constraining Factor of Your Lean Six Sigma Initiative.

Book Overview

In 2010, Bruce Nelson and I began writing a blog under the name of Focus and Leverage, and since then we have posted well over four hundred blog posts on a variety of different subjects. The response to our posts has been overwhelming. The metric we used to track the receptivity of our posts
was the number of page views by week. The number of views started at around one hundred per week, but then it started increasing exponentially until it reached well over three hundred thousand per week. We were both amazed and flabbergasted at the level of response we were getting to our
posts. Several of our more avid readers recommended that we take what we had written in our blog posts and create a book, summarizing our posts. We thought long and hard about this suggestion and have decided to press forward and have this idea come to fruition.  This book captures some of the most popular posts that Bruce and I have written and posted.

You will notice that I use the term “we” to explain the concepts presented throughout this book, even though I am the only author listed. It’s because Bruce has elected not to be a co-author this time, due to time constraints.  But even though he’s not listed as a co-author, his writings cover much of this book and make it much more interesting and informative. Much of what we have written in our posts has to do with creating a forum of sorts. That forum is one on continuous improvement methodologies, principles and best practices. After all, continuous improvement has been the hallmark of both our entire careers, and those who know us well know that we love helping others with their efforts.

The layout of this book is a series of our most popular blog posts, which were combined to form the chapters in this book. Unlike many books, one chapter does not necessarily build on the previous one. For example, one of the most popular posts has been our method for teaching people the basics of the Theory of Constraints. We will be discussing our first experiences with TOC, and in so doing, we think you will see why we have embraced it so much. Another topic of discussion will be on our integrated Theory of Constraints, Lean and Six Sigma. We have christened this approach the Ultimate Improvement Cycle, which is also known by the abbreviation TLS. Because these two subjects are similar in nature, they have been linked into the same chapter.

We have also written about problems and what we believe is the best approach for solving them. We have introduced various problem-solving tools and techniques we have used throughout our careers, including tools like Pareto Charts, Causal Chains, Cause and Effect Diagrams, Why-Why Diagrams and a host of other tools we have used in our careers to solve both simple and complex problems. This chapter will also include a session on paths of variation, which you might find to be an interesting read.

In addition to these time-tested problem-solving tools and techniques, we have also presented the TOC problem-solving toolset, known as the Logical Thinking Processes (LTPs). These tools were introduced by Dr. Eliyahu Goldratt and have been somewhat modified over the years. We have presented the LTPs by use of a case study on how to use TOC Thinking Processes. Bruce has earned the title of a certified Jonah’s Jonah, which means he can teach and certify others. And as you will see, he knows and understands the LTPs as well as anyone I know.

Closely related to the LTPs is a technique known as the Goal Tree, which, if followed to its logical conclusion, will teach you how to assess your company and in a single day will help your company create a strategic improvement plan. Often, we have seen students come away from a training session on the LTPs not knowing how to use them. For these people, the Goal Tree has proven its worth many times over.

We will also be writing about two distinctly different methods to manage projects, namely the Critical Path Method (CPM) and Critical Chain Project Management (CCPM). In this chapter, we discuss project management failure modes, project management negative behaviors that must be overcome, and how best to track projects. We will demonstrate why CCPM is the project management method of choice and how, by using CCPM, your projects can be finished on time, on scope and on budget over 95 percent of the time.

We will also introduce you to the TOC Parts Replenishment Model and will compare it to the traditional Min/Max system. We will demonstrate how, by using the TOC Parts Replenishment Model, you will be able to reduce your facility’s parts inventory levels by 40 percent to 50 percent or
more, while reducing your stock-outs to nearly zero.

In my next post, I will continue the summary of this new book.
Bob Sproull

Friday, August 10, 2018

My New Book Part 11



Review

In my last post, we continued our discussion on what I believe are the 4 best tools for problem solving.  I discussed the Pareto Chart and presented a simple example of how to construct one.  In today’s post we will look at the third tool, the Causal Chain.  Much of what I have discussed in this series, is taken from my newest book, A Guide for Problem Solving, Prevention and Making Effective Decisions - Roadmaps for Today and Tomorrow.



The Causal Chain

The final tool we will be discussing in this series of posts is the causal chain. When problems occur, we know that a chain of events has taken place to alter the performance of the process. We aren’t always certain as to what happened, so we need some kind of tool or technique that will help us develop a theory as to what did happen. One of the most effective tools available for accomplishing this is the causal chain. Causal chains are step-wise evolutions of problem causes. Each step in the causal chain represents an object in either a normal or abnormal state. The object is placed on the line to the far right of the chain, with the state it is in listed directly beneath it.

So, in the figure above, the object in distress is the press and its state is that it has stopped. Although we might use a cause-and-effect diagram to list the variety of reasons why the press stopped, it does not explain the causal mechanism that actually caused it.


In the figure above we see that a press has stopped and we ask the question why. The press stopped because the motor stopped. Why did the motor stop? Because the current has stopped flowing. We continue asking why until we reach the end of our chain, and find that the press stopped, because the motor stopped, because the current stopped, because the pressure switch opened, because the air pressure was too low, because the air compressor failed, because the oil level was too low, because of a gasket that failed. We have now developed a potential theory as to why the press stopped, and along the way we have identified objects or items (e.g., current, oil level) that we can test to prove or disprove our theory. Each step is the cause of the next step and the effect of the preceding step. That is, the information on the step to the left is always the cause of the information on the step to the right.

What if we have more than one potential cause? How do we handle that situation? The answer is simple. We just create additional, individual chains like the one in the figure above and place them along the y-axis as in the figure below. This is an actual example from a team that was working on a core machine that was malfunctioning. Here the team brainstormed and came up with four different chains. Each individual chain is, in reality, a brief theory to prove or disprove, as to how the core machine was malfunctioning.

Ultimately, the team either eliminated the chain as a potential cause through testing or developed action items for each of the potential root causes. At the end of the day, the team performed all of the actions in the gray shaded boxes, and the problem was not only solved, but it was improved from its previous state.

Remember, the primary purpose of a causal chain is to develop a stepwise chain of events that explains why a particular performance shortfall exists. Once this is complete, hypotheses or theories can be formulated as to why a problem exists. Causal chains are, in my opinion, one of the simplest and effective, yet most underutilized tools available for a team to use.

In my next post, we’ll start a new blog post series on a different topic.  As always, if you have any questions for me, just send me an email and I’ll answer it.
Bob Sproull

Sunday, July 29, 2018

My New Book Part 10


Review

In my last post, we continued our discussion on what I believe are the 4 best tools for problem solving.  I discussed the Pareto Chart and presented a simple example of how to construct one.  In today’s post we will look the third tool, the Cause and Effect Diagram.
The 4 Best Tools for Problem Solving (con’t)
The Cause and Effect Diagram
While the run chart answers the questions of if and when a change has occurred and the Pareto chart is more of a comparative tool, the Cause and Effect Diagram is a tool that helps identify, organize, and display possible causes of a specific problem.  The Cause and Effect Diagram, or Fishbone Diagram (because its structure resembles the bones of a fish) is one of the most popular tools ever developed.  It was created and developed by Dr. Kaoru Ishikawa, a noted Japanese consultant, and are also referred to as Ishikawa diagrams in his honor. It graphically illustrates the relationship between a given outcome (the effect) and all the factors that might influence the outcome (the causes).  The structure of the diagram helps the team think in a very systematic way as they look for potential causes of the problem they are trying to solve. Let’s look at a simple example.




 The construction of a cause and effect diagram starts by identifying and defining the outcome or effect being studied (i.e. problem description) and placing it to the far right side of a straight line.  We then establish main causal categories such as man, method, machine and materials and place them at the end of diagonal lines drawn from the central spine of the fish as is illustrated in the figure above.
For each of the main categories, we then identify other, more specific factors that could be the causes of the effect and place them on off-shoot bones from the diagonal lines.  We continue to identify more detailed and more explicit causes and then organize them on bones that come off of the off-shoot bones.
The figure above is a hypothetical cause and effect diagram for a person with diabetes whose blood sugar is out of control.  Four major categories were selected (Food/Nutrition, Medicine, Exercise and Person) and then more specific, potential causes for the out-of-control diabetes were added to each major category.  These more specific secondary causes are seen as the smaller bones on the fish emanating from the major categories at the end of the diagonal lines as we attempt to zero in on our list of potential causes of the problem.  Finally, even more specific causes are added.  For example, under the category Exercise we see that the “level of exercise” is listed with “too low” and “none” completing this series of bones.

In my next post, we complete our discussion on these four important tools by discussing the Causal Chain.  As you go through my postings, if you have any questions for me, send me an email to ras8202@live.com.
Bob Sproull





Tuesday, June 26, 2018

New Book Part 9


Review
In my last post, we began our discussion on what I believe are the 4 best tools for problem solving.  I listed the four best tools as the Run Chart, the Pareto Chart, the Cause and Effect Diagram, and the Causal Chain.  I completed the last post by giving a brief description of the Run Chart and explained the basics of how to create one and how it can be used.  In today’s post we will look at more of these problem solving tools.
The 4 Best Tools for Problem Solving (con’t)
The Pareto Chart
While the run chart answers the questions of if and when a change has occurred, the Pareto chart is more of a comparative tool.  That is, if we suspect differences in performance between things like machines, people, or even days of the week, then we can visualize these differences with a Pareto chart.  The genesis of Pareto charts came from a most unlikely source.  An Italian economist, Vilfredo Pareto, was studying the distribution of wealth in Italy in the 19th century.  When he assembled his data, he discovered that approximately 80 % of the wealth in Italy was controlled by only 20 % of the population.  Later Dr. Joseph Juran, a noted American quality authority, further developed Pareto’s inadvertent discovery and so named this phenomenon the Pareto principle in Pareto’s honor.  Juran found that the Pareto principle applied to many different things like absenteeism, defects, accidents, etc. He found that many things typically align themselves and follow the principle that 80 % of problems are manifested in 20 % of the items with the problem. Let’s look at an example of this tool.

Suppose that a machine is experiencing faults and we have been asked to look into the problem.  We assemble the data and notice that the frequency of the faults is not the same every day. If we were to arrange the data as a Pareto chart, by day of the week, as in Figure 2.4, we see that the chart of this data validates what we believed was true.  The Pareto chart gives a picture of the days of the week and clearly shows us that we have a severe problem with faults on Monday and then the faults gradually decrease as the week progresses until Friday when they cease to exist. By knowing that Monday is the worst day for faults, we can focus our efforts on comparing what is unique or different on Monday compared to the best day of the week, Friday.

Pareto charts are really quite simple to create.  Along the horizontal or x-axis we simply place what we are comparing (e.g. operators, machines, etc.), and then place whatever we are measuring along the vertical or y-axis.  Now what could be more straightforward than that?

In my next post, we continue our discussion on these four important tools.  As you go through my postings, if you have any questions for me, send me an email to ras8202@live.com.
Bob Sproull

Friday, June 1, 2018

New Book Part 8


Review
In my last post, we looked at the 4C’s of problem solving which were contain the problem, find the root cause of the problem, correct the problem, and control the problem.  I explained that if you correctly implement the 4C’s, you will be in control of the problem.   In today’s post, I will talk about what I believe are the four best tools for solving problems.
The 4 Best Tools for Problem Solving
In my travels, one thing that has become very apparent and evident to me is that there are so many people who have no grasp of basic analysis tools and techniques.  One of the prerequisites for solving problems is having at least a basic understanding of which tools to use and when to use them.  It is remarkable to me that even after all of the many initiatives and programs like TQM and Six Sigma, so many people and companies haven’t embraced or begun to understand the basic tools and concepts.

In this post we will consider four basic tools that a problem solving team must make use of, if the team is to successfully determine the root cause of the problem they are addressing.  You may be wondering if there are other tools available besides these four and the answer is yes.  But having said this, it is my belief that if you can master and make use of these four simple and uncomplicated tools, you will be able to solve the majority of problems facing you.  So what are these four tools?

The four tools are the Run Chart, the Pareto Chart, the Cause and Effect Diagram, and the Causal Chain.  The run chart will answer the question of when the problem started, when it has occurred since it started, and will then help identify whether or not it is a change or launch-related problem.  The Pareto chart will help the team determine things like where the problem is, which machine is creating the problem and who has the problem.  The Cause and Effect Diagram will facilitate the creation of a list of potential causes, while the Causal Chain will help the team formulate the chain of events that led to the problem (i.e. the hypothesis).  Although there are other tools that can be used by the team, I firmly believe that teams will be much more successful by using just these four simple tools.  Now let’s look at each tool and some examples.

The Run Chart
One of the keys to solving problems is knowing when the problem began and when it has occurred since its inception.  In addition, the team needs to be able to measure the impact of any changes made to the process.  The Run Chart will provide the answer to all of these questions.  The Run Chart or Trend Chart, as it is also termed, is a graphical representation of the problem being tracked as a function of time, with time being any unit like hours, days, etc.  Time is placed along the horizontal axis (x-axis) and whatever you are measuring is placed along the vertical axis (y-axis). Let’s look at an example.

Suppose we suspect that temperature is a key factor in the creation of a defect and we are interested in knowing what happens to the temperature throughout the day.  We measure the temperature each hour and record it as follows:

                        Time                                                               Temperature
                        6:00 am                                                                 60
                        7:00 am                                                                 62
                        8:00 am                                                                 63
                        9:00 am                                                                 65
                      10:00 am                                                                 70
                      11:00 am                                                                 75
                      12:00 pm                                                                 80
                        1:00 pm                                                                 81
                        2:00 pm                                                                 82
                        3:00 pm                                                                 80
                        4:00 pm                                                                 79
                        5:00 pm                                                                 75
                        6:00 pm                                                                 72

Although we are able to view the temperatures as recorded above and see the general trend, it is sometimes difficult to see other subtleties of how the data is trending, so creating a Run Chart facilitates this.  The figure below is the Run Chart created from the data we collected and as you can see, the temperature begins at 60 degrees at 6:00 AM and begins to rise until the maximum value of roughly 82 degrees is reached at 2:00 PM.  If you have suspected that temperature is an important factor in the problem you are attempting to solve, the Run Chart tells you what you need to know in terms of correlating temperature to the defect.

In my next post, we continue our discussion on these four important tools.  As you go through my postings, if you have any questions for me, send me an email to ras8202@live.com.
Bob Sproull


Tuesday, May 22, 2018

New Book Part 7


My new book Part 7
In my last post, we looked a bit deeper into the last type of problems that exists, the hybrid problem.  I explained that when you have an expected level of performance, which has never been achieved and it suddenly worsens, you are in the midst of a hybrid problem.  I also presented something I refer to as the 4C’s of problem solving, Contain, Cause, Correct and Control.  In today’s post I will explain in more detail what these 4C’s are.
The 4 C’s of Problem Solving (con’t)
In my last post, I told you that no matter what type of problem you are faced with, there is usually always pressure and anxiety associated with it.  You have demands placed on you that can be overwhelming at times.  You must take action and implement counter measures, but that doesn’t preclude you from following some sort of logical process.  You must remain calm and composed, and sometimes that is difficult to do in the face of a crisis.  Most of the time the immediate actions you take, after the problem surfaces, are crucial.  It is important to realize that the basic actions we take, in the face of all problems, follow the same logical cycle or sequence of Contain, Cause, Correct and Control.  So let’s look at these 4C’s in more detail.

Contain the Problem – No matter whether the problem is located within your plant or facility, or has already reached your customer, the first action is to always contain or confine the problem.  That is, you must stop the bleeding immediately, and limit its scope.  If the problem is defective product, you must not permit it from entering the value stream of good product.  It is always good practice to physically isolate the problem, if there is product involved.  If the problem involves people, such as a labor unrest, you must defuse it quickly, so it doesn’t grow to unmanageable levels.

Find the Cause of the Problem – Once you have caged and confined the problem, it is imperative that you find the root cause or origin of the problem.  Systematically define and analyze it, and search for the cause or causes.  If it is a quality problem, for example, you must find the source of the problem or change that has occurred.  If it’s a people problem, you must understand what caused the unrest to surface.

Correct the Problem – As soon as the cause of the problem has been determined, you must take swift and pragmatic action to find an effective counter measure and implement it with expediency.  Make certain that you don’t just start making changes without justification or reason.  Often times you will have options with one solution being short term, and the other more long-term.  What you must decide is how urgent the solution must be implemented, and it could be that you find yourself implementing a temporary, short term solution just to get out of the crisis.  It is okay to do this as long as your intention is to implement the longer-term solution later.

Control the Problem – Once the problem has been resolved, always implement some kind of control that will prevent the problem from recurring.  When problems persist, and recur at customer locations, your credibility takes a hit, so avoid this by implementing a control.

Remaining calm in the face of problems is imperative, so if you will just stop and remember these four actions, you can transform a stressful and taxing situation, into one of relative calm and tranquility.  In the face of pressure, clear headed thinking and practical actions are crucial, so simply remember the 4 C’s, Contain, Cause, Correct and Control, and you will be in control of the situation.
In my next post, we will shift gears and talk about what I believe are the four best tools for solving problems. As you go through my postings, if you have any questions for me, send me an email to ras8202@live.com.
Bob Sproull


Thursday, May 17, 2018

Another New Book

Just to let everyone know, I have another book scheduled for release in November of this year.  The new book is entitled, The Focus and Leverage Improvement Book: Locating and Eliminating the Constraining Factor of Your Lean Six Sigma Initiative.  It's a book that is based upon many of my blog posts here and will probably be helpful for anyone trying to improve their systems and processes.  I'll provide updates as we get closer to its release date.
Bob

Tuesday, May 15, 2018

My New Book Part 6

My new book Part 6
In my last post, we looked a bit deeper into two of the three different types of problems that exist as follows: 
  1. Problems that have resulted from a change or adjustment from existing conditions or change-related problems.
  2. Problems that are persistent and have seemingly been around forever and are therefore chronic problems.

In today’s post I will complete the DNA of problems by looking at the final type of problem which I refer to as a hybrid problem.

The DNA of Problems (con’t) 

Hybrid Problems
Now that we understand the differences between a change-related problem and the chronic problem, you might wonder if it's possible to have both types of problems acting together simultaneously?  The answer is an emphatic and categorical yes!  When you have an expected level of performance, which has never been achieved and it suddenly worsens, you are in the midst of a hybrid problem.



Consider the situation in the above figure.  Here we see actual % EBITDA by month, compared to budgeted % EBITDA.  The actual % EBITDA has been below budget by approximately 2.5 % for the first seven months of the year.  In August, the situation worsens, and the gap between expected performance (i.e. % EBITDA) and actual performance grows to about 8 %.  A situation that I’m sure was filled with pressure and negative energy, just became worse.

If you were the owner of these dreadful and deplorable financials, imagine how you would feel and what your actions might be.  You have two competing priorities here.  On the one hand, you must determine what changed to make the already dismal situation deteriorate, while on the other you must close the gap to the budget.  You are in the midst of a hybrid problem, with each part of it competing against the other.  The logical approach would be to return to “ground zero” by finding the change that caused the performance shift, reverse it if possible, and then develop a plan to improve the % EBITDA.

Although both are serious problems, one is short term and requires immediate attention, while the other is chronic and requires thoughtful and considerate action!  One thing to remember when you are faced with a hybrid problem, is to separate the problem into its constituent parts.  Disconnect the change related problem, from the chronic problem, because the solution to each will be different.
The 4 C’s of Problem Solving
No matter what type of problem you are faced with, there is usually always pressure and anxiety associated with it.  You have demands placed on you that can be overwhelming at times.  You must take action and implement counter measures, but that doesn’t preclude you from following some sort of logical process.  You must remain calm and composed, and sometimes that is difficult to do in the face of a crisis.  Most of the time the immediate actions you take, after the problem surfaces, are crucial.  It is important to realize that the basic actions we take, in the face of all problems, follow the same logical cycle or sequence of Contain, Cause, Correct and Control.

In my next post, we will complete our discussion on the 4 C’s of problem solving.  As you go through my postings, if you have any questions for me, send me an email to ras8202@live.com.

Bob Sproull

Wednesday, May 9, 2018

My New Book Part 5


In my last post, I presented three different types of problems that exist as follows:

  1.       Problems that have resulted from a change or adjustment from existing conditions or change related problems.
  2.       Problems that are persistent and have seemingly been around forever and are therefore chronic problems.
  3.         Problems that are both chronic and change related, or what I call hybrid problems.

I also described the make-up of change-related problems and listed three requirements that must be satisfied in order for a problem to fit into this category of problems.

The DNA of Problems (con’t) 

Chronic Problems
There is another type of problem that is not necessarily the result of a change, but rather a problem that has been around seemingly forever.  Many times, when you ask someone how long this problem has existed, you get a response like “We’ve always had this defect!” or “This machine has never produced what the others have.”  I have named this kind of problem a Chronic Problem, and for those of you that have ever been involved with the Ford’s or GM’s or Chrysler’s of the world, you will recognize it immediately. [1] Kepner and Tregoe refer to this kind of problem as Day-One Problems. 

As the name implies, it’s the kind of problem that has been with us since day one.  Maybe it’s the launch of a new machine that is supposed to be identical to one or more already in place. But, since the start-up, it has never performed quite like the others.  Or maybe the supplier of a raw material has two factories and product received from one factory, has out-performed the other factory from the first delivery of the product.

In this type of problem there is still the expected level of performance (Machine Target) of the new machine, compared with the actual performance of the other machines making the same or similar product.  The deviation is the output between the lower performing machine, and the other two, supposedly identical machines.  The same rules for deciding, whether or not a problem is a problem apply here, as well as the problem-solving tools and techniques.

The major difference between change-related problems and chronic problems is where we focus our efforts.  In change-related problems, we focus most of our efforts on determining what changed to create the new level of performance, and when the change occurred.  But, when we have a situation where the performance of one item has never been what it “should” be, compared to one that performs to expectations, we can assume that one of the conditions necessary to attain the expected level of performance, does not exist and never has.

In this case, we must focus most of our efforts in the area of distinctions, or differences between where or when we have the performance problem compared to where or when we don’t.  That is, there is something distinct or different when comparing the supposedly identical units, processes or materials.  If we are to successfully solve chronic type problems, then we must find the critical differences or distinctions between the two objects, and take actions that are specifically aimed at eliminating or reducing the differences!

In my next post, we will complete our discussion on the DNA of problems by presenting the third type of problem, the hybrid problem.  As you go through my postings, if you have any questions for me, send me an email to ras8202@live.com.

Bob Sproull

[1] Charles Kepner and Benjamin Tregoe, The Rational Manager – A Systematic Approach to Problem Solving and Decision Making, 1965

Friday, May 4, 2018

My New Book Part 4

In my last post, I explained in detail the 10 behaviors that I believe must be the DNA of problem solvers and must exist if problems are to be effectively solved.  In today’s post, I will be presenting the DNA of problems.  Not all problems are created equal and knowing which type of problem you are dealing with is critical to solving the problem.

The DNA of Problems  
Not all problems are created equal.  That may seem intuitive or obvious to you, but it really isn’t.  When I say that not all problems are created equal, I’m not referring to the basic problem itself, but rather the framework or structure of the problem.  There are different categories or types of problems and it is enormously important that you recognize and distinguish what type of problem you are working on because the approach to one type of problem may not work for another type.  Problems are divided into three fundamental categories as follows:

  • Problems that have resulted from a change or adjustment from existing conditions or change-related problems.
  • Problems that are persistent and have seemingly been around forever and are therefore chronic problems.
  • Problems that are both chronic and change related, or what I call hybrid problems.
Let’s look at each problem type in a bit more detail.

Change Related Problems
[1] Kepner and Tregoe, in their problem-solving classic, The Rational Manager, characterize problems simply as deviations from expected performance, but let’s look at this more closely.  Kepner and Tregoe tell us that a performance standard is achieved when all of the conditions required for acceptable performance are operating as they should.  This includes everything in our work environment including people, materials, systems, processes, departments, pieces of equipment, basically everything.  Kepner and Tregoe further tell us that “if there is an alteration in one or more of these conditions, that is if some kind of change occurs, then it is possible that performance will alter too.” 

Changes happen every day in our lives, so the question becomes, “When is the deviation that we observe considered to be a problem?”  It has been my experience (and that of Kepner and Tregoe), that in order for a deviation to be considered a problem, one or more of the following requirements must be satisfied:

  • The deviation or performance shift must be recognized and perceived as being negative to the organization.  That is, the deviation must result in a negative effect to things like a loss in throughput, a deterioration of quality, a safety performance issue, etc., that translates directly into something like a missed delivery to a customer, a loss in revenue or margin erosion, a customer complaint, an injury, etc
  • The cause of the performance deviation isn’t known.  That is, the root cause is not immediately established using “normal” problem-solving techniques, which results in an extended period of time at the new negative performance level.  Obviously, if the cause isn’t known, then the solution won’t be known either, so the performance problem lingers.
  • Both the root cause and the solution are known, but the solution can’t be implemented because it either costs too much or takes too long.  As pressure mounts to have the problem fixed more often than not the symptoms get treated and a “quick fix” is implemented.  This in turn, usually prolongs the problem episode, or sets the stage for it to return or actually deteriorate even further.


If the root cause and the solution are known and implementing it doesn’t take too long and/or cost too much, then the deviation is not deemed to be a problem because it simply gets fixed.  In effect, it has no visibility within the organization, at least not in the upper echelon.  But when you add the critical factors of cost, time, lost revenues, etc., deviations will most likely be portrayed and characterized as problems.

In my next post, we will continue our discussion on the DNA of problems.  As you go through my postings, if you have any questions for me, send me an email to ras8202@live.com.

Bob Sproull
[1] Charles Kepner and Benjamin Tregoe, The Rational Manager – A Systematic 
     Approach to Problem Solving and Decision Making, 1965

Sunday, April 29, 2018

My New Book Part 3


My new book Part 3

In my last post, I introduced my Problem-Solving Road Map and then listed ten behaviors and personality traits that I believe are the basic genetic material shared and utilized by effective problem solvers.  The ten behaviors I listed were:

1.         Being Objective
2.         Being Analytical
3.         Being Creative
4.         Having Dedication, Commitment and Perseverance
5.         Being Curious
6.         Having Courage
7.         Having A Sense of Adventure
8.         Being Enthusiastic
9.         Being Patient
10.       Being Vigilant

In today’s post I will describe each of these behaviors in more detail.  It’s important to understand that these behaviors or traits do not have to exist in a single person, but rather the team must exhibit them.  Much of what I am posting is taken from my new book [1] The Problem-Solving, Problem-Prevention, and Decision-Making Guide - Organized and Systematic Roadmaps for Managers.

The DNA of Problem Solvers (con’t)
A problem solver must always be impartial and objective and not have preconceived notions, ideas or biases on what is causing the problem.  Each problem has its own set of conditions or circumstances and most of the time the answer lies in the data and information surrounding these conditions.  Without objectivity, crucial observations might be ignored or missed.  I have witnessed so many times individuals and teams jumping to causes and solutions before even understanding the problem.  Keeping an open mind throughout the process is critical.

A good problem solver must be analytical and systematic in their approach to problems.  One of the keys to solving problems is the art of asking the right questions in a methodical fashion.  As we investigate problems, it is crucial to use a logical approach as we move through the maze of unknown facts and forever present opinions of others.  Asking questions, or should I say the right questions, is imperative if we are to uncover the facts relative to the problem.  Closely related to this is the need for analysis.  Once the information and data surrounding the problem is collected, it must be analyzed in a systematic way.  A good problem solver knows and understands which tools and techniques are available, how to use them, and when to utilize each one.

Solving problems requires imagination, creativity and ingenuity.  Solving problems sometimes requires abstract thinking and necessitates imaginative and inventive actions.  Once you have determined the true root cause (or causes) of the problem, it’s time to be innovative and let your creative juices flow as you develop effective solutions.  The solution to your problem will demand ingenuity and resourcefulness, so you must be inventive.

Solving problems requires dedication, perseverance, and commitment because the answers are sometimes obscure or concealed and, therefore, not always obvious.  One must be determined to find the root cause and committed to using a systematic approach.  A good problem solver doesn’t vacillate as the problem-solving journey unfolds, they stay the course.

A good problem solver has curiosity.  When one is curious, they are interested in understanding why things happen and will probe below the surface of the problem looking for things that may not be obvious or evident above the surface.  Solutions to problems all begin out of curiosity and desire to determine and understand what happened and then understand why.  Until you understand why the problem has emerged, your chances of solving it are pretty much nil. 

It takes courage, daring, and “guts” to be a good problem solver.  Since there is usually always a negative aura or atmosphere surrounding problems, people that are closest to and responsible for the area with the problem, sometimes feel threatened.  Because they are feeling vulnerable and exposed, they generally don’t like to be questioned, but you must have the courage and fortitude to push forward and seek answers.  When you ask someone questions about the problem in their area of responsibility, many time the instinctive reaction is to take a defensive posture.  You are typically perceived as prying and impugning their character.   Of course, this isn’t really the case and if you ask the questions in a positive and non-threatening way, you can ease some of this perception.

Solving problems is a journey and an exploration into what happened, so having a sense of adventure is fundamental to reaching your destination.  I have often wondered how the early explorers, like Columbus or Lewis and Clark, must have felt as they sailed into unknown and uncharted waters or passed through unfamiliar and strange countryside, never knowing what they were going to encounter or be confronted with or even if they would be successful.  The one thing Toyota does better than any company I have ever seen is their mandate and directive to their employees to go visit the source of the problem, so they can see firsthand what is happening.

A good problem solver must demonstrate enthusiasm during the problem-solving journey.  There must be a certain zest, zeal and passion that becomes contagious and infectious to the rest of the team.  By demonstrating and communicating enthusiasm to the team, you are inadvertently motivating and inspiring your team members.  There will be times when the situation may appear hopeless to the team, but your positive outlook and enthusiasm will guide you and your team through the process.

Finding root causes and developing solutions to problems are not always clear-cut, straightforward, or uncomplicated, so a good problem solver must demonstrate patience, persistence, and staying power.  You will at times, be pressured to move faster than you would like to or need to, so you must be compelled to stay the course.  Part of learning to be a good problem solver is learning how to become disciplined and regimented.  If you will take your time and systematically work through problems, your success rate will improve dramatically.  Remember, patience truly is a virtue.

Finally, a good problem solver should be vigilant and always expect the unexpected.  Just when you think you may have exposed the root cause of a problem, or have discovered the causal pathway of the problem, new information or something unanticipated may come out of the blue and catch you off guard if you aren’t alert to this possibility.  So be cautious and attentive that DNA of problems.

As we go through my postings, if you have any questions for me, send me an email to ras8202@live.com.
Bob Sproull

[1] Bob Sproull, The Problem-Solving, Problem-Prevention, and Decision-Making Guide - Organized and Systematic Roadmaps for Managers, CRC Press, 2018 by Taylor and Francis Group, LLC