REPLY Getting a Good Problem Statement (SD6552)

SDMAIL Ralf Lippold ralf_lippold at web.de
Mon Sep 3 07:26:55 CDT 2007


Posted by  Ralf Lippold <ralf_lippold at web.de>

It seems to be that Jean-Jacques has started an interesting and 
challenging question on getting a good problem statement in order 
to work out a sustainable solution.

> Posted by  Jean-Jacques Laublé <jean-jacques.lauble at wanadoo.fr>
> ...
> And to do that one must get closer to the customer problem, preferably
> written in plain English, which eases the communication and that is to my
> opinion the best tool to express anything. Just try to translate a
> Shakespeare drama into a CLD!


Being "part of the problem" (e.g. colleague who as a systems thinking view and 
a feeling what different underlying currents make it up to the "big problem") 
makes things even more difficult. From my experience at the Business Dynamics 
Workshop in June at MIT it is especially challenging to find the "right key"  
to open the door to the mental models managers have in their minds on how/why 
the existing system is "responsible" for the problems.

As the proverb "A prophet has no honour in his own country." says it is difficult 
to act from within the system, even though this guy knows what is going on in the 
system. What are the leverage points to change that common situation (can be 
found in almost every situation!)?

In my own experience one really has to have a problem that "really matters" 
before the change can get to move (by that time the system is perhaps already 
short of resources to solve the case). Even

> I tried to use cognitive mapping techniques like Decision Explorer but
> I prefer a good text explanation.


A plain text explanation in connection with the instant building of a CLD can 
be the "eye opener". As long as people in the meeting are not familiar with 
the causal loop concept it makes things really difficult and challenging. Who 
has done already in the past experiences of this and would like to share those?

> So the question is what should be done in that first step to make the
> translation easier to the second step and the next ones?
>
> To resume what kind of style, presentation, order, way to verify the
> completeness, coherence, etc... is to be respected?


A good way to start with is to involve people who know the processes as they 
actually do them (shopfloor colleagues, people doing the process and experience 
the problems on hand themselves). In a lean surrounding you would say, "Go to 
the GEMBA! and see for yourself". It seems that Toyota in a way is already using 
the SD approach even though you will not find the connection in any book or article.

> Another question near the problem of the customer too. I ask this question
> to modellers with a lot of experience. When a problem is exposed one can
> opt for two solutions. Of course one can opt for an intermediate solution,
> but I expose these two because they are extreme.  The first one is to find
> right away an optimised solution that solves definitely the problem at hand,
> trying to model the reality concerned. The second one is to start from a
> solution already existing and try to improve it step by step, looking more
> at past experiences and building on future experiences to be done, to solve
> the problem. Knowing that people will say that it depends on the type of
> problem, the question is: In general, is the solution nearer to the first
> extreme or to the second one.


Jean-Jacques, I would say the later is the more sustainable solution as it uses 
experiences from the past and that could work as a boundary object on which everybody 
could hang on because it is common knowledge what has been done already. Jumping to 
a completely new solution always arises restistance amongst the involved people and 
in the end -when this solution doesn't work- it is always "the other one"  (the 
modeler, consultant) who is responsible for it. There will be less focus on the 
process and the system in total.

Best regards

Ralf
-- 
Posted by  Ralf Lippold <ralf_lippold at web.de>
posting date  Sun, 2 Sep 2007 13:24:08 +0200


More information about the SDMail mailing list