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