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