Discussion: View Thread

  • 1.  Systematic Problem Solving

    Posted 07-28-1998 15:08
    Date: Mon, 27 Jul 1998 09:22:44 -0500
    From: "John P. Trebnik" <jtrebnik@IQUEST.NET>
    Subject: Re: Systematic problem definition and solving

    John Trebnik writes...

    > I'm wondering what has become of the "old" Kepner-Tregoe approach to
    problem
    >analysis? When I was in the corporate world, we studied, preached, and
    tried
    >to adhere to K-T processes as an aid to developing our critical thinking
    >skills. I know that K-T is probably dated, but my own experience is that
    >managers try to apply systematic processes wherever possible. perhaps
    someone
    >could comment on what has become of the K-T approach, and/or similar
    >methodology?

    So far as I know, the K-T approach is alive and well. The workshop
    promotional materials still come around and the methodology is still as
    situationally sound as ever it was. If the classic K-T approach suffers
    from a flaw, it is that the approach is essentially one of troubleshooting
    or fault isolation. This is a dandy technique when something suddenly goes
    wrong and the aim is to put things back the way they were, however, it is
    much more limited in other circumstances.

    The notions immediately above--and some others--were discussed in an
    article of mine that was published in the January 1996 issue of ASQC's
    Quality Progress magazine. The article was titled, "Yes, It Makes A
    Difference: Choosing the Right Tool for Problem Solving Tasks." A copy can
    be found at my personal web site:

    http://home.att.net/~nickols/articles.htm


    Fred Nickols, Executive Director
    Strategic Planning & Management Services
    Educational Testing Service [09-C]
    Princeton, NJ 08541
    Tel = 609.734.5077 Fax = 609.734.5590
    e-mail = fnickols@ets.org

    Views expressed are the author's, not ETS's.


  • 2.  Systematic Problem Solving

    Posted 08-04-1998 07:30
    The systematic problem solving thread illustrates the diverse views held
    regarding problems and the processes for solving them. I'd like to add to
    and clarify/modify some of what has been posted so far.

    My own view, shaped by the writings of folks like John Dewey, Charles Kepner
    and Benjamin Tregoe, and Messrs. Shaw, Newell and Simon, is that a problem
    exists whenever a requirement for action is coupled with uncertainty
    regarding the action to take. As I once read, "Problem solving is what you
    do when you don't know what to do." Sometimes the requirement for action is
    rooted in a clearly defined gap between "what is" and "what should be." On
    other occasions, the current situation is simply untenable and part of the
    difficulty lies in identifying some new goal state. In all cases, however,
    there is uncertainty regarding action.

    Problem solving, or figuring out what to do, serves functionally to reduce
    uncertainty. It is, therefore, an information-based search activity. The
    search for information can be systematic, haphazard, creative, flexible, or
    rigid. (Insert your own adjectives here.) Uncertainty, of course, attaches
    to people, not situations. The uncertainty to be reduced is that of the
    person(s) with the responsibility for the situation in which action is to be
    taken so as to alter that situation. The reduction of uncertainty is in fact
    a speculative undertaking, that is, we come up with a course of action we
    think or believe will work. There remains the sometimes nasty business of
    actually doing it--in a word: implementation.

    Depending on the scope, scale and complexity of the course of action being
    undertaken, one, a few, dozens, or even hundreds of people must understand
    the course of action. Some so as to have their uncertainty reduced, too, and
    some simply so they can "go along with the program." Hence, the need to have
    buy-in through involvement on the part of some and the need to "sell" to
    others.

    People in organizations do all these things--and more--and they do them
    fairly well. If they were lousy at it, organizations would collapse with
    alarming frequency. People are pretty good problem solvers. But they vary
    widely in their abilities, skills, preferences, mastery of techniques, and so
    on. Some rely heavily on creative approaches, while others favor a more
    systematic approach. Some know to engage the implementers early on and some
    don't. Some know that engaging the implementers is a generally useful thing
    to do but not always necessary--and some don't. Some believe in "root"
    causes and set out to identify them; some don't believe in root causes--or in
    any other instance of cause-and-effect reasoning. On and on the variation
    goes.

    Yet, in the last analysis, solving problems is about changing things, it is
    about intervening. To intervene is to change things purposefully, that is,
    with some goal or outcome in mind. Change in organizations is almost always
    indirect; that is, you don't change it (e.g., profit), you change something
    else (e.g., cost) and it changes as a result. Consequently, if we are to
    intervene successfully, we must be able to say that a given action produces a
    given result and, conversely, that a given result can be produced by some
    range of given actions. Being able to say these things with confidence and
    having our confident statements subsequently borne out by experience, entails
    a knowledge of the structure of the situation in which we are intervening.
    In other words, we must be able to show how intervening over here will
    produce the desired result over there or, conversely, how a given result over
    there can be produced by actions over here.

    Typically, we represent the structure of the situations in which we are
    intervening by way of diagrams (e.g., flowcharts, treecharts, and other
    "structural" drawings). Generally speaking, I find three basic classes of
    diagrams to cover the vast majority of problems encountered in the work
    place. One for people, one for processes, and one for profits. Said a
    little differently, these relate to problems of human behavior and
    performance, functional and organizational performance, and financial as well
    as other measurement-based results. Clearly, the more interesting problems
    found in organizations involve all three classes of problems, intertwined in
    what are known as "messes" (i.e., sets of related but as yet undifferentiated
    problems).

    The one thing I don't believe in is the so-called "wicked problem." All
    problems can be tamed.

    Regards,

    Fred Nickols
    Executive Director
    Strategic Planning & Management Services
    Educational Testing Service
    fnickols@ets.org


  • 3.  Systematic Problem Solving

    Posted 08-07-1998 16:21
    On the importance of problems and their (coarse) levels:
    Level 1: Problem can be solved by known routines, cost of error
    correction can be accommodated without big disruption.
    Level 2: Some ways to solve the problem cluster are known. Wrong
    decisions will severly harm the organization, but not kill it.
    Level 3. Most ways to solve the problems in a cluster need to be
    created. Failure will definitely kill the organization.
    Comment 1: Use a 3 by 3 matrix for above, depth of know-how versus risk.
    This helps management to focus on the dangerous parts of a project,
    evaluating the risk.
    Comment 2: Substitute your system for "organization", the matrix will
    remain.

    As a consequence, the depth of research into the various components of
    a problem cluster follows a similar form of matrix:
    Little effect versus big effect of a decision error and implementation.
    (A non-implemented decision has no effect).
    Research must be done to find the little things that have big impact.
    The previous posting of "system must support process" may be a good
    indicator, why some companies survived a failed process implementation.
    The collectice brain of the system didn't support a non-suitable process.
    (In military this might be mutiny, but military and business are different
    systems.)
    Constructive critizism tends to help finding the traps. Virtual test runs
    within a group may point to shortcomings. Present a planned solution to
    laypeople. If the solution cannot be explained, the laypeople may aks
    the right questions!

    Emil Zahner
    Creativity Guide
    I am still eager to have more comments on the systematic innovation
    pages on my website. It started this subject. So far I got useful comments
    on problem definition. I got comments on the training example, these
    were irrelevant, because the question is not the example (system),
    but the process (how did you find the solution). Process comments, please.
    http://ourworld.compuserve.com/homepages/canmor/pros01.htm example.


  • 4.  Systematic Problem Solving

    Posted 08-19-1998 19:13
    Here I refer to a posting made August 3 by
    <<Date: Tue, 4 Aug 1998 07:29:39 -0400
    From: fred nickols <fnickols@ETS.ORG>


    As I once read, "Problem solving is what you
    do when you don't know what to do." Sometimes the requirement for action
    is
    rooted in a clearly defined gap between "what is" and "what should be."
    >>

    A nice way of saying it. The next step then is to use know-how about
    figuring out what to do. There are hazy ways, fuzzy trials, "first
    (untested for error) idea is best " approaches. These are the ways we
    all do it when we don't want to enter into a learned methodical
    approach. "Learned" is an unfortunate, yet correct term. If we would
    learn _methodical ways_ to solve problems we never solved before
    while still in early years in school, we would format our brain just
    as easy as we can format it for music perception and creation. As we
    are getting older, formatting (creating automatisms) is getting
    harder.

    But we can still use systematic thinking consciously. It is
    unfortunate that thinking behavior as such has no place in learning.
    Sure, we learn formulae, grammar, and other rules to make our grades.
    We do not learn creativity, and the built in creativity in a child is
    soon covered up by rules and recipes.

    Zwicky, the founder of the morphological* approach, explained:
    My teachers always wondered about my way of doing things. I had a
    different approach in researching or doing something. While at
    school, I did not recognize the difference. I only wondered why other
    student had so much difficulty. (Quote from memory, in the sense).
    * The term Morphology was created by Goethe. He used morphological
    thinking to find the link between apes and humans. This previously
    missing link was thought to be proof of no relationship. A powerful
    example how to research, in my view.

    Emil Zahner
    Creativity Guide
    Morphological Institute Canada
    http://ourworld.compuserve.com/homepages/canmor/index19.htm