REPLY Getting a Good Problem Statement (SD6603)

[SDMAIL Ralf Lippold]

Posted by  Ralf Lippold <ralf_lippold at web.de>

Hello,

Jean-Jacques makes a really good point as it is essential to get down to the 
same level concerning the problem articulation with your client (this could 
be your boss, another department's boss, plant manager, etc.).

At 7:56 Uhr -0400 09.09.2007, SDMAIL Jean-Jacques LaublÈ wrote:
> You used solutions meaning I suppose that there are many level of
> definitions.
> For me the first level of definition should not include anything about the
> solution because the problem exists independently of the solution and that there are
> many solutions to the same problem depending on the time resources that
> exist and that you will decide to use.
> ....

As long as this is not leveled out there will be no solution that can be 
followed through (even though something has been decided on - this will be 
most probable not sustainable).

Just the other day I have had a discussion with a friend on the effects of 
improvement workshops on the workforce.

The intention to do a workshop differed quite a lot:

ME: due to problems being transparent in current processes there is a workshop 
done in order to improve the quality (or other goals, such as time saving, 
safety improvement) of work,

HIM: to save the necessary communication efforts of multiple one-hour-long 
meetings a longer workshop is conducted.

It became quite obvious that the underlying assumptions (Why do we do anything 
at all?) was not expressed on the same level on both of us.

This leveling seems to be THE challenge: to speak one language concerning the 
problem statement!

Only after this is settled one can talk about possible solutions that can heal 
the problem.

> ....
> The cost of the overall operation must be considered too, especially if
> there is a failure.

This is for most people quite difficult to see as they are stuck in there 
functional silos;-(. So there we should find ways on how to open the doors out 
and into the silos elsewhere in the company (or organization in general). 
Cross functional workshops/meetings can be one way to start with.

> ...
> To my opinion if these questions are well addressed, 80% of the problem is
> solved.

I can follow that from my own experience. It is always a relief asking people 
directly on the shop floor who are involved in the questioned process instead 
of discussing in a remote meeting with people higher up in the hierarchy.  On 
the other hand there are other dynamics coming into play when this kind of 
communication happens or is forced to happen.

> But I think that too properly define the first level of definition, should
> take at least half of the total effort in time and effort allocated to the
> resolution of the problem and it is because it is not done this way that SD
> is not well appreciated.
>
> I could give you examples as you asked, but to my opinion the best thing
> would be to work on concrete subjects like the one I exposed 'modeling the SD growth' although I
> think that it would be difficult because of the lack of data.

>From my own experience -due to attending John's workshop on Business Dynamics 
last June- there is no real need for data as the process of connecting the 
different views is worthwhile starting the "expirement" and building the 
causal loop connections around the "SD growth". The problem that occurs on 
that point is how to provide an easy way to communicate this process without 
sending emails back and forth?

Jim, and others have already given some great ideas on collaboration tools (in 
order to obtain a "Learning Virtual SD Society"). Myself I have used a 
mentioned tool (Bascamp) to organize and discuss around a workshop on "lean 
thinking" (has lots in common with system dynamics and learning organizations).

> There should exist a public place like this forum where organisations,
> business (of course after a selection to be defined) could expose a problem
> that would be openly solved and criticized (or not solved) so as to make visible the
> concrete process of SD modelling.

As one faces in the real world of organizations nobody is really happy to lay 
open his/her pressing problems in the company.

So why not covering pressing problem that concern all of us and where have 
some own experience?

Fields -that come to my mind- could be:

- Growth of SD -especially for practical use
- Difficulty of change programs and how to overcome them
- Effects of cutting service level (train connections, air traffic, etc.)
- Establishing a Learning Organization
- Lean Thinking - how to start off

I guess everyone of us has some personal experience in -the described and other- 
practical fields where SD could be great help.

> ...
> I do not say it is easy to do, but one can start with something less
> ambitious.


That is right:-)

Ed  Roberts already mentioned that one should start with SD on the "big 
problems".


Regards

Ralf 
Posted by  Ralf Lippold <ralf_lippold at web.de>
posting date  Sun, 9 Sep 2007 18:47:19 +0200