REPLY Getting a Good Problem Statement (SD6596)

SDMAIL nickols (nickols at att.net) nickols at att.net
Sun Sep 9 06:56:19 CDT 2007


Posted by  nickols at att.net (nickols at att.net)

As Jim Hines just pointed out, people do indeed conflate problems with 
solutions and consultants often add value by helping sort things out 
and clarify matters.  What I haven't read about so far in this thread 
is any kind of explanation of what constitutes a problem.  I've spent a 
lot of time delving into that issue - in the literature and in practice.  
As best I'm able to determine, much of the business world views a 
problem as discrepancy or gap between what is and what should be (thanks 
mainly to the folks at Kepner-Tregoe).  I think that's fine as far as it 
goes but I also think it doesn't go far enough.  For one thing, the 
world is full of gaps between the way things are and the way we'd like 
them to be.  Many, however, aren't serious enough to warrant attention.  
Further, John Dewey long ago pointed out that another important 
ingredient in a problem is a sense of puzzlement or uncertainty.  

To my way of thinking, two elements must be present to say a problem 
exists: First, the situation at hand must be such that it requires 
action (often on the basis of a perceived and unacceptable difference 
between current and required conditions) and second, the action to 
take is not immediately apparent.  Some kind of investigation, 
analysis or diagnosis is required.  As one writer put it, "Problem 
solving is what you do when you don't know what to do."

Where I as a consultant frequently encounter difficulty is that clients 
are convinced that they do know what to do about a given situation - 
without having gotten clear about the gap they're trying to close and 
also with little analysis or identification of the reasons such a gap 
exists.  They leap to action and often to an ineffective one.  Yet, I 
also find that clients are not particularly fond of being disabused of 
their analyses or pet solutions.

Just as important, solutions are often depicted as something that must 
be "found," the result of some kind of search activity.  I don't buy 
that either.  To me, a solution is a course of action that, once carried 
out, leads to the desired or what some call "the solved state."  A course 
of action isn't "found," it's configured - it is something that is 
figured out, not simply picked up and implemented.  And, in those complex 
systems we call organizations, there's many a slip twixt cup and lip when 
it comes to implementation.  A good solution (i.e., an eminently sensible 
course of action) can go awry if not properly carried out.  The tendency 
in such situations is to blame the solution, not its implementation, and 
off everyone goes to find another solution.

Finally, as to the distinction some draw between the "perceived" problem 
(or symptoms) and the so-called "real" problem, I don't buy that either.  
What's going on there is contention between two different views of the 
situation; one person sees problem A and another sees problem B.  Thus, 
a big piece of the up front work regarding problem definition and 
formulation is arriving at some kind of consensus about the problem - 
and that can often be very delicate work.

To recap, for a problem to exist, you have to have a situation that 
someone has determined requires action and there has to be uncertainty 
regarding the action to take.  In the end, the main function of problem 
solving is to reduce uncertainty regarding action.  A solution is a 
course of action that produces the required state of affairs and its 
implementation is every bit as important as its formulation.

That leaves open what is perhaps the most important issue: how does one 
get from a crisp, clear (and presumably correct) statement of the problem 
to an equally crisp, clear (and presumably correct) course of action?  
There is where diagnosis, analysis and investigation come into play and, 
for my money, they should focus on the structure of the situation at hand.  
The problem is embedded in that situation and the task of formulating a 
solution is essentially one of finding one or more elements in that 
structure where action can be taken and the effects of that action lead 
to the solved state, typically as a result of "rippling through" the 
structure so that we act in one place (the points of intervention) so as 
to bring about effects at other places (the points of evaluation).  
There, of course, in my scheme of things, is where systems dynamics comes 
into play.  It's a great way of modeling and gaining insight into what 
happens if...

Finally, I'm no SD practitioner myself but I do like to think I know 
enough to get competent help when it's needed.

--
Regards,

Fred Nickols
Managing Principal
Distance Consulting
Posted by  nickols at att.net (nickols at att.net)
posting date  Sat, 08 Sep 2007 13:30:06 +0000


More information about the SDMail mailing list