QUERY Getting a Good Problem Statement

This forum contains all archives from the SD Mailing list (go to http://www.systemdynamics.org/forum/ for more information). This is here as a read-only resource, please post any SD related questions to the SD Discussion forum.
Jean-Jacques Laublé <jean-jac
Senior Member
Posts: 61
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by Jean-Jacques Laublé <jean-jac »

Posted by Jean-Jacques Laublé <jean-jacques.lauble@wanadoo.fr>

Referencing the ""Information display challenge (SD6520) I do not think that there is much to add to Joel Rahn remark about two
difficulties: first finding the critical information and then displaying it except that it is very annoying that there are two of them, but if we can solve the first difficulty, maybe the second will be straightforward.

But, one of my concern is not about how I represent a CLD.

I use generally a stock and flow diagram with causal tracing and loops but can start with a simple CLD without stocks. But before making a CLD or SFD one must know what to put in it.

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!

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

The point is that the way the problem will be formulated in plain English is critical for the rest of the study, and I should say that once that first step is accomplished, everything else is a simple matter of technique and that the quality of the modelling effort will mainly depend on that first step.

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?

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.

Regards.

Jean-Jacques Laublé Eurli Allocar.
Posted by Jean-Jacques Laublé <jean-jacques.lauble@wanadoo.fr>
posting date Sun, 26 Aug 2007 19:59:59 +0200
_______________________________________________
Bill Braun <bbraun@hlthsys.co
Member
Posts: 43
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by Bill Braun <bbraun@hlthsys.co »

Posted by Bill Braun <bbraun@hlthsys.com>

Jean-Jacques Lauble asks about problem definition and problem statements.

In my experience, people do not always solve the problems they should solve, but the ones they can. I strive to keep their eye on the problems they should solve, and then help them solve the ones they can. Over time, they will change the questions they ask, and the scope of problem definition will broaden/deepen.

Related to that, I opine that problem statements should include three things: (1) reference to the problem symptom (e.g., why is ""X"" behaving as it is), (2) the stakeholders who control resources, and (3) stakeholders who will implement. Over the years I've come up with any number of stunningly brilliant solutions that failed to secure the support of people who control resources and that failed to be embraced by implementers. Group modeling goes a long way to addressing all three criteria.

Finally, resist ""how"" questions. Such questions assume at least two things: (1) there are no more good diverging questions to be asked and we should be focused on solutions, and (2) someone else knows the answer, the only challenge is to find her or him. Recently a colleague was ranting on the failure of people to bring solutions along with problems. I asked him why he expected people to know the solution, especially where he readily admitted the problem was complex. What would happen, I asked, if you responded to people by asking, ""what are the three most important questions we ought to be asking about that problem?"" I think such thinking will lead to robust problem statements.

Bill Braun
Posted by Bill Braun <bbraun@hlthsys.com> posting date Tue, 28 Aug 2007 07:04:04 -0400 _______________________________________________
""Schuette, Wade"" <wschuett@
Junior Member
Posts: 11
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by ""Schuette, Wade"" <wschuett@ »

Posted by ""Schuette, Wade"" <wschuett@jhsph.edu>

I agree with Bill (below) and expand one comment.

I used to run an executive intelligence group at Cornell University that various VP's would come to for answers to questions they had, where the data or proxies for the data were somewhere in some combination of databases we could get to. I was also taking a computer science course in the development of ""natual language query systems.""

I didn't make myself popular when I told the CS people that the best way to ""optimize"" most queries from execs was to throw them away and start
fresh. I can't recall a single instance where the question someone asked
me (""the presenting complaint"") was even close to the answer they actually needed.

One example: I was asked ""How many employees do we have in the Agriculture School?"" I replied with a polite version of ""Help me understand why you want to know that. What issue are you trying to
decide?"" In this case, he was trying to decide whether there would
be sufficient business at lunchtime to build a new cafeteria in that
vicinity. So, yes, he was interested to know that directly across
the street was a building with 200 federal employees in it that wasn't shown on our payroll. And, yes, come to think of it, I guess students
do eat lunch too, don't they! Etc.

The question recommended by my late statistics professor, Jack Kieffer, ( a member of the National Academy of Sciences) was ""What does it cost you to make this decision incorrectly?"" Jack asserted that there was no way to create an appropriate statistic without knowing the client's risk curve - how much did they win if they were right? How much did they lose
if they were wrong? That had to be factored into the analysis. There was,
in his opinion, so such thing as a ""generic"" answer. Statisticians
battle over that, but, as an MBA, I agree with Jack.

In fact, I think that's a big factor in why most academic research is completely ignored by policy makers -- they don't care about ""p-values"", they care about re-election, or power. Of course, the actual agenda may
be hard to extract or a secret.

Regardless, real people will have to take real action and face real consequences if they are right or wrong, based on what you are telling
them, so it seems wise to include that in the analysis. Most adults
can deal with major losses, if they entered into the deal knowing what they actually were risking.

Others, academic purists, may strongly disagree with that, of course - and argue that they are not responsible for the ""misuse"" of their
conclusions. Hmm. US Product Liability law would hold that one is
responsible for ""expectable misuse"" of equipment. So far that hasn't
been applied much to software or analyses, but maybe it should . Again,
opinions will differ. Still, I'd like to know who's staking what on the
answer being ""right"", and what they would define as ""right.""

As to the questions to ask, Bill (below) suggests ""What are the most important questions we should be asking?"" I'd add to that, ""Who actually has first-hand knowledge of the situation that we could talk to?"" weighted by finding the disempowered people low in the power structure and asking them ""What do you think is going on here?"" Their answers will differ markedly from the ""view from the top"", and will bring in unexpected factors that are completely invisible up the chain of command -- some of which will be true show-stoppers.

Earl Brooks, a B-school faculty member at Cornell, used to consult for GM.
They'd bring him in for big bucks to deal with issues they were having.
Earl would arrive a day early, and spend the day buying drinks for employees at the bar nearest the exit, and just ask them to tell him what
was going on at the plant. Then he'd meet with the top guns, stroke
his chin wisely, and come back with suggestions at $50,000 apiece (30 years ago) that management could have gotten themselves for free, if they'd
asked. Usually his suggestions worked and management was delighted and
astounded at his perceptive insight.

Rule of thumb -- in multilevel organizational hierarchies, the critical details at any level are completely lost in the oversimplified graphics and mental model two-levels up or higher. Toyota's ""Lean"" approach suggests ""Genchi Genbutsu"" - or, go down and look for yourself before making pronouncements.

Similarly, I think the critical variables two layers above one and higher in such organizations are also completely unexpected and invisible, or meaningless at lower levels -- it's like our body's cells grasping the
concept ""Accepted by Harvard."" It's literally another world.
Loosely coupled, but different dimensions.

So, by that reasoning, either a ""problem"" is generally multidimensional and multi-level, or it will be perceived as ""different"" problems at
different levels of stakeholders.

So, that suggests again that opinions on the relevant factors should be solicited from as many different levels as possible, because they may be
wildly different. Similarly, there's no reason built into physics that
the benefit of solutions will be some sort of constant at any radius of consideration in space, time, or scale. There are many ways to win the
battle and lose the war. It may be good to check the sensitivity of the
answer to your planning horizon - if the sign changes as you expand your horizon (from good to bad, or vice versa), be very cautious.

Other opinions may vary of course.

Wade Schuette
Ann Arbor, MI
Posted by ""Schuette, Wade"" <wschuett@jhsph.edu> posting date Tue, 28 Aug 2007 12:23:57 -0400 _______________________________________________
Jean-Jacques Laublé <jean-jac
Senior Member
Posts: 61
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by Jean-Jacques Laublé <jean-jac »

Posted by Jean-Jacques Laublé <jean-jacques.lauble@wanadoo.fr>

Hi everybody

Bill Braun writes and I thank him for his answer:

< I strive to keep
<their eye on the problems they should solve,

That seems a very wise methodology that would normally support the second choice I proposed: starting with a small model that is within the understanding of the problem owner and the capacities of the people that implement the solutions, and from a first experience, broaden the scope and adapt the model to it.

It is exactly what I am doing now.

<Related to that, I opine that problem statements should <include three things: (1) reference to the problem symptom

Sounds good too. But is group modelling enough to avoid the risk of loosing the support of people who control the resources or fail to be implemented?

I think that following strictly what is exposed in the first paragraph seems enough as it necessitates group modelling or at least group participation and if the modelling is a step by step process, where people having the understanding and the capacity are taken into consideration, it cannot fail.

It seems to me that the brilliant solutions failed because the conditions exposed in the first paragraph were not met.

Was it the case?

<Finally, resist ""how"" questions. Such questions assume at

I am not sure of having fully understood this.
It should mean that generally people do not have the solution.
But what about people having good ideas but fearing to take action, or not knowing to implement them?
And what about the risk of proposing a solution that has already been tested and that has a great chance to be rejected?
What about learning from the past experiences, even if one has not participated to the experience?

I ask questions, without giving answers.

I know that wanting to understand fully past experiences can be exhausting, and risky because of a potential misunderstanding.

But one can take a middle strategy approach, listening to eventual propositions or experiences and deliberately deciding to ignore them, explaining eventually the reason of this behaviour.

Finally I reformulate the question that was not well explained in my first mail.

Should one thrive for a complete model before trying to apply the policies, the first solution, or should one start with a simple model first that will be eventually easier to understand and to implement, implement it, take actions with the proposed policies, and after having learned from that experience, eventually broaden the scope as you mentioned, and build a second model, with the same scenario than the first step?
If the two options seem possible, what are the reasons to choose between them.
When reading the first paragraph, it is the second solution that should be favored.

This question is important for me, because some authors like Sterman writes about a step by step process, starting relatively quickly with a small quantitative model, like in the Vensim modelling guide but what is really in the steps is not clearly mentioned.

Does one has to use concretely the model after each step, implementing the solution even if it is far from perfect and incomplete, and learn from that experience before going to the next step, or build a model step by step, testing it progressively but waiting until it is finished to implement the policies?

Regards.

Jean-Jacques Laublé Eurli, Allocar
Posted by Jean-Jacques Laublé <jean-jacques.lauble@wanadoo.fr> posting date Tue, 28 Aug 2007 19:12:35 +0200 _______________________________________________
Bill Harris <bill_harris@faci
Senior Member
Posts: 51
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by Bill Harris <bill_harris@faci »

Posted by Bill Harris <bill_harris@facilitatedsystems.com>

""SDMAIL Jean-Jacques Laublé"" <jean-jacques.lauble@wanadoo.fr> writes:
>> Sounds good too. But is group modelling enough to avoid the risk of
>> loosing the support of people who control the resources or fail to be
>> implemented?
>>
>> I think that following strictly what is exposed in the first
>> paragraph seems enough as it necessitates group modelling or at least
>> group participation and if the modelling is a step by step process,
>> where people having the understanding and the capacity are taken into
>> consideration, it cannot fail.


Jean-Jacques,

You probably know it and act as if you do, as well, but there's something implicit in your statements I've quoted above that seem important to highlight. Absent (possibly physical) coercion, we can't guarantee support and implementation. Absent perfect wisdom, we can't guarantee a lack of failure.

All we can really control or change is ourselves. What we can do includes initiating group modeling and other actions which have been shown to improve the odds of support and reviewing past actions for potential causes of a lack of support, but others still have the freedom to do something differently than we would like. (That's not to excuse our responsibility if we purposefully or ignorantly choose ill-advised actions, of course.)

As I noted, I'm sure you recognize that, but I thought it important to make it explicit.

Just a thought. Others?

>> Should one thrive for a complete model before trying to apply the
>> policies, the first solution, or should one start with a simple model
>> first that will be eventually easier to understand and to implement,
>> implement it, take actions with the proposed policies, and after
>> having learned from that experience, eventually broaden the scope as
>> you mentioned, and build a second model, with the same scenario than
>> the first step? If the two options seem possible, what are the
>> reasons to choose between them. When reading the first paragraph, it
>> is the second solution that should be favored.


You ask important questions in your email.


>> This question is important for me, because some authors like Sterman
>> writes about a step by step process, starting relatively quickly with
>> a small quantitative model, like in the Vensim modelling guide but
>> what is really in the steps is not clearly mentioned.


Starting small is often a good heuristic, I think.


>> Does one has to use concretely the model after each step,
>> implementing the solution even if it is far from perfect and
>> incomplete, and learn from that experience before going to the next
>> step, or build a model step by step, testing it progressively but
>> waiting until it is finished to implement the policies?


I think the answer is likely the classic ""It depends."" In some cases, the insights may be clear enough or the risks low enough to implement a solution based on a partial model. It may be that the initial model leads naturally into an action research phase where experimentation in the real world, not on a model, makes the most sense, at least as a next step or perhaps in parallel with more model development. It may even be that an initial SD model suggests a next step which doesn't directly involve SD.

In other cases, it's clear that the initial modeling attempts have only begun to illuminate reasonable answers, and a prudent person will dig deeper using iteratively enhanced models to gain more insights before implementing the policies.

While some of the reasons to select one or the other course can be set down, others are probably mostly part of the tacit knowledge each of us has developed over the years. The goal, I would claim, is actionable, supportable insight, not SD modeling excellence.

Thoughts?

Bill
- --
Bill Harris http://facilitatedsystems.com/weblog/
Facilitated Systems Everett, WA 98208 USA
Posted by Bill Harris <bill_harris@facilitatedsystems.com>
posting date Wed, 29 Aug 2007 08:12:26 -0700 _______________________________________________
""Elise Weaver"" <elise_weave
Newbie
Posts: 1
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by ""Elise Weaver"" <elise_weave »

Posted by ""Elise Weaver"" <elise_weaver@yahoo.com>

George Richardson has suggested starting with a simple and purposefully wrong model, feigning ignorance Columbo-style (1970's American TV reference). The sheer wrongness of the model engages everyone to correct it.

Posted by ""Elise Weaver"" <elise_weaver@yahoo.com> posting date Wed, 29 Aug 2007 09:43:47 -0400 _______________________________________________
Jean-Jacques Laublé <jean-jac
Senior Member
Posts: 61
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by Jean-Jacques Laublé <jean-jac »

Posted by Jean-Jacques Laublé <jean-jacques.lauble@wanadoo.fr>

Hi Bill

About your first e-mail and the difficulty to control how other people decide, it sounds logical.

But I did not make myself well understood and I will try to better explain what I meant.

I think that people have their own logic and when Bill Braun spoke of failure, I think that one must think of the possible reasons and I was suggesting that a step by step implementation could have made eventually things easier to implement and to understand by the people having the power. It was just a suggestion but the reason was eventually different.

>I think the answer is likely the classic ""It depends."" In some cases,
>the insights may be clear enough or the risks low enough to ...
>In other cases, it's clear that the initial modeling attempts have only
>begun to illuminate reasonable answers, and a prudent person will dig

It sounds logical too except that it does not help the novice modeller to choose between the two paths.
At least I think that books on SD should mention the two possibilities and should give some advices about the two options.

It seems to me that the first possibility, implementing and experimenting at each step should be favoured by a novice modeller faced with a difficult problem or if the problem is complex and the implementation of policies is tricky.

As for an experienced modeller who can avoid the phased implementation approach to construct a good model because of his experience, it is not sure that it is always the good solution.
I know well the mentality of business people who are always suspicious about too complicate speculations especially if they are not corroborated by concrete results.

Business people will prefer small but substantial results, obtained in a reasonable time without too much trouble and easily understandable. All these hypotheses are more susceptible to happen in a phased implementation approach if it is possible to do it of course.

Of course group modelling will help, but do the people that have the power have the time to invest into it?

And even if they do it, they may always think that the model is becoming too complex and become doubtful about the results expected.

I am in that case, and even after having spent years now modelling, I completely adopt the full implementation with each step, because I prefer the security of results even if it takes a much longer time.
I believe in evolution and not in revolution.
Regards.
Jean-Jacques Laublé Eurli Allocar.
Posted by Jean-Jacques Laublé <jean-jacques.lauble@wanadoo.fr> posting date Wed, 29 Aug 2007 19:25:44 +0200 _______________________________________________
Bill Braun <bbraun@hlthsys.co
Member
Posts: 43
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by Bill Braun <bbraun@hlthsys.co »

Posted by Bill Braun <bbraun@hlthsys.com>

Jean-Jaque Lauble poses some follow-up questions.

> Sounds good too. But is group modelling enough to avoid the risk of
> loosing the support of people who control the resources or fail to be
> implemented?


Good point; I think group modeling is necessary and may not be sufficient.
There is much good literature on securing champions and sponsors for projects, so I will not expand on that here.

> It seems to me that the brilliant solutions failed because the
> conditions exposed in the first paragraph were not met.
> Was it the case?

Yes, I failed to anticipate how ""downstream"" stakeholders would receive the proposed solutions in the absence of ""upstream"" engagement. This and your first point I think are deeply connected.

> <Finally, resist ""how"" questions. Such questions assume at
>
> I am not sure of having fully understood this.
> It should mean that generally people do not have the solution.

I am drawing a distinction between asking a question as though the answer is not known, and actually not having it. I opine that ""how"" questions are often a dodge for doing better/tougher thinking.

Simple example: How should we design our web site?

If the technical know-how is missing, finding the technical know-how is a good step. If that question takes the place of, ""what questions are at the heart of designing a web site?"" then the ""how?"" question defers deeper questions that if explored could lead to deeper insights. The ""how?"" question expresses the belief that ""what works?"" is the defining question and as such is a driving force in the identity of the manager. So, ""get stuff done"" wins out over, ""who are our stakeholders, and what really matters to them?"".

This is not an invitation to endlessly wander; I am mindful of moving forward.
I cannot help but wonder, with all the effort that has gone into solutions, why in the the nearly 250 years since the beginning of the industrial revolution and the formation of the concept of ""organization"", we don't run our organization better than we do? Seems like enough time to get it right.

Jay asks why we cannot design organizations to fail at roughly the same rate as chemical plants? So, why can't we, with all the attention given to solutions? We've been collecting the answer to ""how"" for years and entire forests have died to put them into print. What would other questions, design to get at what really matters, reveal to us?

Thank you for the questions, Jean-Jaque.

Bill Braun
Posted by Bill Braun <bbraun@hlthsys.com> posting date Wed, 29 Aug 2007 14:43:48 -0400 _______________________________________________
Jean-Jacques Laublé <jean-jac
Senior Member
Posts: 61
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by Jean-Jacques Laublé <jean-jac »

Posted by Jean-Jacques Laublé <jean-jacques.lauble@wanadoo.fr>

Hi every body

As one of the initiator of the thread I will give my opinion about Fred Nickol's definition.

Fred writes:
<From that it follows that having a good problem statement and a matching solution are basic <requirements.

Yes, but what is a good problem statement? Anyhow it is difficult to imagine a good solution to an ill defined problem.
One has to consider what to put in the problem statement and how to formalize it.
I think the same problem can motivate very differently different people, and the motivation should be put in the statement.
For instance somebody more academic may be interested by the inner working of a process while somebody else may be mainly interested by the concrete solving of the problem.
One person maybe interested by a small amelioration, considering having already tried for years without results to solve the problem, while another with less experience may be interested by a much bigger amelioration. I think that these motivations must be included in the definition of the problem.
There can be too different point of views as to the way the solution will be implemented: some may want to wait some time and make one big change once that a really good solution is found, and another one may favour different steps of modification, fearing that a too sudden change may be too difficult to implement. One can imagine a lot of other conditions to the way things will be processed.
For example, one must take into consideration the experience of the problem owners. The way a study is conducted may vary greatly whether the participants (consultant, deciders and implementers) are more or less experimented.
I personally think that all these conditions are in integral part of the problem.

The motivations of all the participants must be compatible and must be closely considered by all the people that can take a decision, mainly the consultant or the power people who can withdraw. The consultant has the same power than the business leaders at least at the beginning, he can withdraw too.

The question I asked is, what do think other modellers with some experience in the field about it?

Another question is how to formalize the definition of the problem.
I prefer plain text because I feel freer with non formal tools at the beginning. But one can imagine other techniques favouring group modelling like cognitive mapping. But the final resume should be to my opinion in plain English once that all the ideas have been gathered.

One other question is how if this solution is adopted, could one organize this text so as to ease the translation into a more formal tool like a CLD or SFD that RESPECTS THE DEFINITION.

For instance if in the definition it is clearly stated that too much bother must be avoided and the validity of the method proven even if the results are weak but real, it may not be necessary to build a full conceptual model that embraces the full problem, and applicability will be preferred to rigorous representation of reality.

<Beyond these basics, there is the matter of adoption or buy-in, that is, of getting all the <stakeholders committed to and supportive of the course of action known as ""the solution.""

Yes and I was asking if when a brilliant solution failed to be implemented like Bill Braun mentioned, it was not because in the definition of the problem was not mentioned the real motivation of the power people, or not mentioned the eventual capability of the people who have to implement the solution.

This problem is not only specific to SD, and I have seen many consultant works failing because the context of the study had not been well estimated.

About the solution, I do not like that term because to my opinion there is not one solution to a problem but many that are all more or less acceptable depending from the point of view.

<Bottom-line, then, the heart of the matter is essentially that of effecting changes that are <effective, efficient, supported and sustained.

Completely right from the point of view of somebody who is interested in changing things, and not merely by intellectual considerations about how reality works.
But other more intellectual motivations may exist too and be completely justified by more long term objectives.

Thanks too Bill Braun for his clarification of thoughts.
Regards.
Jean-Jacques Laublé Eurli Allocar.
Strasbourg France
Posted by Jean-Jacques Laublé <jean-jacques.lauble@wanadoo.fr> posting date Thu, 30 Aug 2007 17:18:55 +0200 _______________________________________________
""David Rees"" <david.rees@hp
Junior Member
Posts: 3
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by ""David Rees"" <david.rees@hp »

Posted by ""David Rees"" <david.rees@hpls.co.nz>

I would also recommend that people explore the systems literature that is specifically about problem structuring. Of special relevance is the work of Werner Ulrich and Gerald Midgley on Boundary Judgements and a book edited by Jonathan Rosenhead all about 'getting good problem statements - ""Rational Analysis for a Problematic World: Problem Structuring Methods for Complexity, Uncertainty and Conflict.

Regards

David
Posted by ""David Rees"" <david.rees@hpls.co.nz> posting date Fri, 31 Aug 2007 08:25:08 +1200 _______________________________________________
nickols@att.net (nickols@att.net
Junior Member
Posts: 2
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by nickols@att.net (nickols@att.net »

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

I've been following this thread because the subject line is of great interest to me. I thought I'd check my grasp of things before posting...

>From what I can tell, the discussion focuses on what I would call
>""solution
implementation."" From that it follows that having a good problem statement and a matching solution are basic requirements. Beyond these basics, there is the matter of adoption or buy-in, that is, of getting all the stakeholders committed to and supportive of the course of action known as ""the solution.""

Bottom-line, then, the heart of the matter is essentially that of effecting changes that are effective, efficient, supported and sustained.

Do I have the gist of the discussion correct?

--
Regards,

Fred Nickols
Managing Principal
Distance Consulting
Posted by nickols@att.net (nickols@att.net) posting date Thu, 30 Aug 2007 13:04:56 +0000 _______________________________________________
<gpr@albany.edu>
Newbie
Posts: 1
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by <gpr@albany.edu> »

Posted by <gpr@albany.edu>

There have been several references in this conversation to beginning group problem discussions with small models that help to focus the group. If the group has asked for system dynamics support, one such beginning are the so-called ""concept"" models that the Albany group has long used to introduce elements of the system dynamics approach and to get a quick start on the group's problem.

A conference paper on Concept Models is available in the ""Papers on Line""
section of my web site, http://www.albany.edu/~gpr/Papers.html.

I should note, however, that in spite of my enthusiasm for concept models, using them to get started with a group doesn't solve all the interesting problems people are rasing in this discussion.

..George
Posted by gpr@albany.edu
posting date Thu, 30 Aug 2007 08:39:36 -0400 (EDT) _______________________________________________
""Mike Fletcher"" <mefletcher
Junior Member
Posts: 5
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by ""Mike Fletcher"" <mefletcher »

Posted by ""Mike Fletcher"" <mefletcher@gmail.com>

As we know, most problem statements are assumption or solution driven or lack proper focus, and far too little time is dedicated to adequate problem definition. It may be human nature to jump immediately into problem solving mode.

To mitigate against these tendencies there are a series of generic problem restatement methods. These are spelled out in ""The Thinker's Toolkit"" by Morgan Jones, and possibly other texts which I'm not aware of.

In summary the techniques are:

Paraphrasing

180 degrees (e.g. ""What is causing X to go up?"" turns into ""What is could cause X to go down?)

Broaden the Focus

Shift the Focus

Ask ""Why?""

If anyone is aware of any other generic frameworks like this that are effective, I'd be interested in hearing about them.


-- ------------------------------------------------------
Michael E. Fletcher
Posted by ""Mike Fletcher"" <mefletcher@gmail.com> posting date Thu, 30 Aug 2007 12:30:53 -0400 _______________________________________________
Richard Stevenson <rstevenson
Member
Posts: 37
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by Richard Stevenson <rstevenson »

Posted by Richard Stevenson <rstevenson@valculus.com>

Elaine Weaver wrote:

> George Richardson has suggested starting with a simple and
> purposefully wrong model, feigning ignorance Columbo-style (1970's
> American TV reference). The sheer wrongness of the model engages
> everyone to correct it.


This is not an alternative to ""a good problem statement"" (Elaine's focus).
It is however, in my experience, the single most important first step in client engagement.

And it opens a door onto system dynamics' darkest and possibly least discussed problem.

The ""client"" organisation usually has (or otherwise has access to) the real knowledge of its problem issues. The SD role is to extract, synthesise, play back and refine that knowledge. In that sense an SD model is never more than the condensed and organised knowledge of the client organisation. A truly competent practitioner knows how to facilitate the extraction and synthesis of that knowledge, at an APPROPRIATE level of detail - in order to develop client confidence in a solution set.

So the competent SD consultant must initially demonstrate comprehension of the issues.

A good (simple) ""straw man"" first model is a great way to start that process. HOWEVER, this can be a challenging task for inexperienced SD practitioners - because the ""straw man"" must be simple and relevant yet demonstrate sufficient ""richness"" to engage the client in the process.

In a sense, this process summarises a paradox and an implicit problem of SD - despite considerable achievements in education and academia, it just cannot make a significant impact in the business world.

As Jay Forrester often says, understanding basic SD structures requires considerable study and experience - and it takes experience and confidence to develop good SIMPLE models. More intellectual and conceptual skills, in most ways, than developing detailed technical models. Essentially, to be a competent SD practitioner you need more, much more, than technical skills. Conceptualisation and communication are the most challenging SD skills.

Yet, almost by definition, conventional consultants cannot afford to develop those skills internally. Business Schools cannot do more than teach the rudiments. Undergraduate SD courses cannot provide adequate ""front line"" consulting experience. Short executive SD programmes are mostly nothing more than an awareness exercise - what can they do on Monday morning?

Hence there is an acute shortage - and seemingly always will be - of competent SD practitioners who can actually ""hack it"" in serious client situations. I see lots of ""modellers"" out there. But sadly, I see very, very few competent, experienced SD practitioners.

Unless the SD world can somehow come up with answers to this issue it will never make a significant impact in business.
Indeed a simple two or three stock model illustrates this problem perfectly! Physician, heal thyself.


Richard Stevenson
Valculus Ltd
Posted by Richard Stevenson <rstevenson@valculus.com> posting date Thu, 30 Aug 2007 17:45:47 +0100 _______________________________________________
""Jack Homer"" <jhomer@comcas
Member
Posts: 21
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by ""Jack Homer"" <jhomer@comcas »

Posted by ""Jack Homer"" <jhomer@comcast.net>

Richard Stevenson writes (SD6544):
""In a sense, this process summarises a paradox and an implicit problem of SD - despite considerable achievements in education and academia, it just cannot make a significant impact in the business world..I see lots of 'modellers' out there. But sadly, I see very, very few competent, experienced SD practitioners.""

Also, this past January, Richard posted ""The Death of System Dynamics?""
(SD6203), where he said:
(1) ""I want to question the entire basis of the System Dynamics Society...
a self-serving and introspective club that resists change and is entirely blind to new opportunities and problems in the real corporate world"";
(2) ""the problem with SD today is its lack of business focus and a complete absence of self-discipline...in thre real, corporate world, SD's impact has been minimal compared to its potential - and far from getting stronger, it is in fact disappearing"";
(3) [the SD forum] is completely random. Who's really in charge?""

Jay Forrester, in this summer's conference speech, ""System Dynamics - the Next 50 Years"", described various laments that have appeared in the listserve discussion, and mentioned ""The Death of System Dynamics?"" one specifically.
He said:
""Those of you who are doing good system dynamics work know that these messages of despair do not represent the field, but they stand on the record and mislead newcomers to the field. Such messages are going unchallenged by those of you who understand that they are not representative of the field.""

Actually, the ""Death of System Dynamics?"" did NOT go unchallenged at the time, and Tom Fiddaman gave an especially forceful and eloquent response with point- by-point commentary. Nonetheless, Jay's general point is worth heeding.

I think it is fine that Richard speaks his mind forthrightfully, but I do think that maybe he is generalizing from his own experience, rather than drawing conclusions from broader evidence of how we as a field are actually doing. From my own decades of experience in the field it seems to me that SD is doing pretty well and is having a significant impact on business and government. Of course, that statement, like Richard's, is not based on a comprehensive review of the facts, but is rather just my own observation. My purpose here is simply to point out for those of you less familiar with system dynamics and its history that Richard's observations are opinions based on his own experience, and should not be taken as more than that. I do not question that they are honest opinions, but I do question their generalizability.

- Jack Homer
Posted by ""Jack Homer"" <jhomer@comcast.net> posting date Fri, 31 Aug 2007 09:08:52 -0400 _______________________________________________
Richard Stevenson <rstevenson
Member
Posts: 37
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by Richard Stevenson <rstevenson »

Posted by Richard Stevenson <rstevenson@valculus.com>

Jack Homer writes:

> I think it is fine that Richard speaks his mind forthrightfully, but
> I do think that maybe he is generalizing from his own experience,
> rather than drawing conclusions from broader evidence of how we as a field are actually doing.

For the record, my occasional comments in this forum (e.g. ""The Death of SD"" etc ) are not driven by criticism of individuals or groupings in the SD fraternity - but rather from my deep commitment to the field and my conviction and considerable frustration that COLLECTIVELY, SD is still selling itself very short.

In particular, ""The Death"" posting was deliberately provocative - and it did generate a degree of discussion, although perhaps not as much as I had hoped - and certainly little from the leaders in our field, which slightly disappointed me.

Of course I agree with Jack that my views are generalised from my own experience (how can they not be?) but I know quite a few people who share them - and my experience is not inconsiderable. The fact is that the SD field is still (a) dominated by academics, (b) weakly represented in business, (c) introspective, (d) extremely poor at communicating. The reasons are systemic (surprise) and simple enough to address from a pure SD perspective. But who is interested and listening? Apparently not the ISDS or the wider SD community.

I refer to Jay's comments at ISDC 2007 (as quoted by Jack - I had not seen them previously, so I assume they are verbatim).

> ""Those of you who are doing good system dynamics work know that these
> messages of despair do not represent the field, but they stand on the
> record and mislead newcomers to the field.""

I regret I was not at ISDC 2007 (personal reasons only) and would have been happy to respond there. But with great respect to Jay, the messages are sincere. They are not ""of despair"", and not intended to ""mislead"". They are intended to be challenged - constructively.

Whether my views are ""representative of the field"" is another matter. I am quite sure they are not representative of the few hundred attendees at ISDC 2007. But that is not the point - the ISDS is still a tiny community and the view from East Coast USA is not necessarily representative of the SD field as a whole, never mind the wider business community.

That, after sixty years, SD is still such a tiny fraternity, is lamentable. For thirty years (or more) I have listened to the
prognosis that SD is growing exponentially - but in fact it is not.
In business it is still hardly known - or maybe even declining.
Indeed, in a number of business schools that I visit, if SD is known at all it is sometimes even regarded as ""yesterday's"" toolset.
A professor at a good UK business school recently commented to me, ""SD? We looked at it a decade ago. Too complicated!""

Strange! Because in the 1990's ""systems thinking"" was first adulated, then criticised as being too abstract and simplistic.
Talk about mixed messages!!

This is clearly not a failure of substance. But it is definitely a failure of communication and organisation. To succeed, SD needs to establish critical mass. Instead it remains a ""cottage industry""
discipline - scattered thinly in universities and in small consultancies. Small (i.e tiny!) SD consultancies can survive by specialisation - but the larger consultancies have all found it difficult to establish and maintain a strong SD capability - ""too risky"", ""too few saleable days"". I know one - and only one - multinational company that has adopted SD as a key internal competence.

None of this should be a revelation to SD practitioners - the business model is just simple SD, after all.

I understand that those SD practitioners doing good work (and of course there is a growing number) see the world from the rosy perspective of their current positions and the (evidently infinite) opportunities out there. The evidence, however, is that the SD community as a whole has currently neither the capability, nor the capacity, to build critical mass in the business world.

What's the answer? Well I do have my views. But I'll rest my case for the present.

Finally, to return to Jay.

> ""Such messages are going unchallenged by those of you who understand
> that they are not representative of the field.""


Really? Perhaps we could have a proper discussion in this forum that will not be censored by the moderator? Oh - and maybe also some real contributions from those who either regard themselves, or are widely regarded, as leaders in the field?

Come on - let's stop the internal congratulations - and start to think about how we can make a real difference.


Richard Stevenson
Valculus Ltd
UK
Posted by Richard Stevenson <rstevenson@valculus.com> posting date Sat, 1 Sep 2007 19:07:07 +0100 _______________________________________________
""David Rees"" <david.rees@hp
Junior Member
Posts: 3
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by ""David Rees"" <david.rees@hp »

Posted by ""David Rees"" <david.rees@hpls.co.nz>

While concept models are an important part of developing understanding and engagement in the SD process it seems to me that they sit around step 2 or 3. There are many assumptions that go into choosing the concept model and rely on the modeller 'getting it right' in terms of initial understanding.
Systems Thinking in all its guises assumes everything is connected to everything else; we cannot model everything however so we have to make choices - it is these boundary choices, hopefully made with rather than for the client, that is at the core of developing good problem statements. As the work of Midgley and Ulrich highlight, choosing the boundaries determines what's in, what's out, whose viewpoints will be considered and whose will be ignored. Starting with concepts models is fine if the task is to engage someone in SD modelling. However, if that task is to solve a problem, and SD is the tool you are using, the challenge starts earlier.

David
Posted by ""David Rees"" <david.rees@hpls.co.nz> posting date Sun, 2 Sep 2007 10:31:43 +1200 _______________________________________________
Ralf Lippold <ralf_lippold@we
Member
Posts: 30
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by Ralf Lippold <ralf_lippold@we »

Posted by Ralf Lippold <ralf_lippold@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@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@web.de> posting date Sun, 2 Sep 2007 13:24:08 +0200 _______________________________________________
""Ken Lloyd"" <kalloyd@wattsy
Junior Member
Posts: 5
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by ""Ken Lloyd"" <kalloyd@wattsy »

Posted by ""Ken Lloyd"" <kalloyd@wattsys.com>

Hello everyone.

Wonderful discussion. I believe this is my first posting to your group.

David Rees makes some good points. My contribution is a small attempt at refinement on these points. In my work, there is a critical distinction between data and models. Data represents ""known"" values from measurement.
While data is known, it may contain measurement errors and noise. Compare this with models. Models represents a temporal procession of a-priori information believed true, but unknown or uncertain. This at the start, this is based on two (assumed faulty) premises 1) that the data = model + error (d = m + e) and that the data is only a function of the model d = f(m). Since we are certain that models contain modeling errors (referring minimally to Godelian incompleteness or inconsistency), we need to separate measurement errors from modeling errors. After this, the model may be refined and validated.

Using a hybridization of network graphs to represent models, it is possible to create knowledge models. The subtle distinction (critical IMO) is that in dealing with unknowns, even those we believe true, is that we move from the world of trajectories and determinism, to the world of ensembles,
probabilities and distributions.

In reference to Rees statement that everything is connected to everything else, there is a distinction between geodesic connection length (an
enumeration) and the L2 Norm length (a Euclidean distance). The shorter L2 length implying a tighter degree of (possibly non-linear) coupling distance.
Furthermore there exist ""small-world"" network paths that can be leveraged (see Newman, Watts, Barabasi).

Therefore I suggest that the boundary conditions are not monolithic ""in or out"", but result from network graph clustering phenomena related to the previous paragraph. This yields a probabilistic distribution of model ensembles. The only challenge left is to decide which models under investigation are ""most likely"". This is derived from a measurable probability on a distribution of probabilistic models - again, ensembles, not trajectories.

This can be accomplished by relating the distributions of known data, to the distributions of unknown models, through cyclic refinement of Bayesian forward and inverse processes. For those unfamiliar, see J. Scales, ""Geophysical Inverse Theory"" or works by A. Tarantola or P. Mosterman. This yields the likeyhood measurement useful for model ""tolerancing"".

I hope that this makes some sense to those who predominately think in deterministic patterns. I propose this aligns better with statistical mechanics, (graph) thermodynamics, and physics (both classical and quantum).

Ken

=============================
Kenneth A. Lloyd
CEO and Director of Systems Science
Watt Systems Technologies Inc.
Albuquerque, NM USA
Posted by ""Ken Lloyd"" <kalloyd@wattsys.com> posting date Sun, 2 Sep 2007 08:37:41 -0600 _______________________________________________
George Richardson <gpr@albany
Member
Posts: 20
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by George Richardson <gpr@albany »

Posted by George Richardson <gpr@albany.edu>

On Sep 2, 2007, at 7:38 AM, SDMAIL David Rees wrote:

> Posted by ""David Rees"" <david.rees@hpls.co.nz>
>
> While concept models are an important part of developing
> understanding and engagement in the SD process it seems to me that
> they sit around step 2 or 3.

Good point. Lots happens before them, and lots happens after.

> There are many assumptions that go into choosing the concept model and
> rely on the modeller 'getting it right' in terms of initial understanding.

In our experience, if concept models are used to get a conversation started, there is less a need to get the concept model 'right' in terms of substantive content than one might think. Indeed, it is useful that little models used to start conversations with system dynamics tools are seen to be inadequate to represent the issues at hand. Those inadequacies jump start the conversation. Having them 'too right' can actually interfere, as the conference paper I mentioned in the earlier posting discusses in some detail.

> Systems Thinking in all its guises assumes everything is connected to
> everything else; we cannot model everything however so we have to make
> choices - it is these boundary choices, hopefully made with rather
> than for the client, that is at the core of developing good problem
> statements. As the work of Midgley and Ulrich highlight, choosing the
> boundaries determines what's in, what's out, whose viewpoints will be
> considered and whose will be ignored.

All good work with groups has to consider boundary issues, stakeholders, power/interest considerations, and careful group problem identification.
Our use of concept models doesn't help with any of that.

We think the rich problem structuring literature in soft OR, largely emanating from the UK, is extremely helpful. We are particularly influenced by the work of Eden and Ackermann in these matters.

> Starting with concepts models is fine if the task is to engage someone
> in SD modelling. However, if that task is to solve a problem, and SD
> is the tool you are using, the challenge starts earlier.

The only way we use concept models is to start conversations aimed at using system dynamics mapping and modeling to help a group that has asked for our help. That usually means they know we tend to approach problems dynamically with the help of feedback thought and formal models. I doubt system dynamics concept models would be useful in any other context.

And it's worth pointing out that lots of folks handle the process problems we're trying to solve with concept models in entirely different ways. These little models, carefully crafted, work for us, but others may have better ways. The goal is helping to get a group started talking about their problem in ways that facilitate the modeling process while at the same time honoring all the intricacies of group process and problem-solving. The more documented experiments the better.

..George
Posted by George Richardson <gpr@albany.edu> posting date Mon, 3 Sep 2007 09:05:53 -0400 _______________________________________________
""Jack Ring"" <jring@amug.org
Junior Member
Posts: 3
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by ""Jack Ring"" <jring@amug.org »

Posted by ""Jack Ring"" <jring@amug.org>

Regarding Jean-Jacques' query (SD6528) ---

One proven way to arrive at a good problem statement is to engage the stakeholders in co-authoring a Concept of Operations that describes how stakeholdes will use the envisioned remedy or solution or therapy or system (but avoids nominating the content/structure of such system) and in co-authoring the companion Measures of Effectiveness and Standards of Acceptance that stakeholders will apply to any proferred remedy/solution/ therapy/system. Guidance for creating a ConOps can be provided to those interested.

Depending on a) the extent, variety, and ambiguity of the problematic situation and b) the extent, variety (diversity), and ambiguity (who's in charge, here) of the stakeholders the task of preparing a ConOps may take a nywhere from five minutes to 100 days (but no longer) and the resulting artifact may range from a simple chart to a multipage simulation. Authoring a ConOps starts with modeling the problematic situaiton (as Jay has reminded us many times SD should be used for descriptive modeling) and ends with concensus that a sufficient basis exists for articulating the 12 or so Measures of Effectiveness.

Likely you will find that at least three ""languages"" are needed, a) conversational or narrative or natural, b) graphical, and c) mathematical.

cheers,
Jack Ring
Posted by ""Jack Ring"" <jring@amug.org>
posting date Mon, 3 Sep 2007 08:15:35 -0700 _______________________________________________
""Ken Lloyd"" <kalloyd@wattsy
Junior Member
Posts: 5
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by ""Ken Lloyd"" <kalloyd@wattsy »

Posted by ""Ken Lloyd"" <kalloyd@wattsys.com>

Bill,

In the history detailed by the following discussion, you seem to be describing problematic attractors without addressing them. See my intervening comments.


>> Posted by Bill Braun <bbraun@hlthsys.com>
>>
>> Jean-Jaque Lauble poses some follow-up questions.
>>
>>> > Sounds good too. But is group modeling enough to avoid the risk of
>>> > loosing the support of people who control the resources or fail to
>>> > be implemented?


Is the situation (left undescribed) the fact that people who control the resources were not included in the model context? More specifically, when you refer to group modeling - what stakeholders constituted the group?
Was the intelligence of the modeler(s) substituted for the intelligence of the group (and what stakeholders made up the group)?

>>
>> Good point; I think group modeling is necessary and may not be
>> sufficient.
>> There is much good literature on securing champions and sponsors for
>> projects, so I will not expand on that here.
>>
>
>>> > It seems to me that the brilliant solutions failed because the
>>> > conditions exposed in the first paragraph were not met.
>>> > Was it the case?


In order to validate separation of the intelligence of the modeler from the group intelligence in the problem statement (which I contend is a model set, in that it represents a probabilistic structure representing a-priori information and knowledge that is believed true, but uncertain, therefore unknown. Thus, the only way to refine the superposition of probabilities in the problem set is to simulate the models from two weak AI directions. One is evolution from a primitive state. The second is the level of success of the model in a more sophisticated trained state.


>> Yes, I failed to anticipate how ""downstream"" stakeholders would
>> receive the proposed solutions in the absence of ""upstream""
>> engagement. This and your first point I think are deeply connected.
>>
>
>>> > <Finally, resist ""how"" questions. Such questions assume at
>>> >
>>> > I am not sure of having fully understood this.
>>> > It should mean that generally people do not have the solution.


Is this a result of a modeling error, a conceptual error (inadequacy of understanding the temporal domain), or an error in the modeling tool, being unable to represent the ensembles during dynamic progression? Or did it stem from sensitivity to the initial condition of a measurement error?

>> I am drawing a distinction between asking a question as though the
>> answer is not known, and actually not having it. I opine that ""how""
>> questions are often a dodge for doing better/tougher thinking.


I'm not sure I understand the above statement. My interpretation is that the prior statement represents a question model (a question whose presumed answers are believed to be true, but uncertain) compared to the latter (a question of unknown probability or possibility). The former can be tested to its level of uncertainty, the latter (computationally much more complex) to random variables (equiprobable microcanonical ensembles). Or did you mean another.

>> Simple example: How should we design our web site?


In the mereological relationship between strategies and tactics, how can you tell if the technical know-how is missing without a distribution of strategic scenarios? How can strategic scenarios be developed without modeling the dynamic context of the questions from ontology of the stakeholder group?

Here, I suppose the unstated answer often is ""I'll take a SWAG, based upon my experience"", hence the intelligence in the modeling ""expert"" is substituted (magically) for the intelligence of the stakeholder group.


>> If the technical know-how is missing, finding the technical know-how
>> is a good step. If that question takes the place of, ""what questions
>> are at the heart of designing a web site?""
>> then the ""how?"" question defers deeper questions that if explored
>> could lead to deeper insights. The ""how?"" question expresses the
>> belief that ""what works?"" is the defining question and as such is a
>> driving force in the identity of the manager. So, ""get stuff done""
>> wins out over, ""who are our stakeholders, and what really matters to
>> them?"".
>>
>> This is not an invitation to endlessly wander; I am mindful of moving
>> forward.
>> I cannot help but wonder, with all the effort that has gone into
>> solutions, why in the nearly 250 years since the beginning of the
>> industrial revolution and the formation of the concept of
>> ""organization"", we don't run our organization better than we do?
>> Seems like enough time to get it right.


Sounds like stochastic evolution rather than survival of the fittest to me.


>> Jay asks why we cannot design organizations to fail at
>> roughly the same rate as chemical plants? So, why can't we,
>> with all the attention given to solutions? We've been
>> collecting the answer to ""how"" for years and entire forests
>> have died to put them into print. What would other questions,
>> design to get at what really matters, reveal to us?
>>
>> Thank you for the questions, Jean-Jaque.


Bill, and thanks to you for your insight. This is important stuff!

Posted by ""Ken Lloyd"" <kalloyd@wattsys.com>
posting date Tue, 4 Sep 2007 09:03:12 -0600
_______________________________________________
""Ken Lloyd"" <kalloyd@wattsy
Junior Member
Posts: 5
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement (SD6528)

Post by ""Ken Lloyd"" <kalloyd@wattsy »

Posted by ""Ken Lloyd"" <kalloyd@wattsys.com>

Jack,

What if the problem in the problem statement is an ill-posed problem? Here, I use ill-posed in the mathematical sense, meaning that at the time the problem statement is created, it is not ""known"" whether a, or any, solution to the problem exists; whether the solution is unique; or whether the solution model continuously relates to data measurements.

This is the curse and error of determinism to the solution of dynamic problems, which says: If we are smart, and work hard, we will find the ONE TRUE RIGHT answer to our problem. It doesn't work that way.

This is my concern with many academics and esp. mathematicians. They have taught their students how to arrive at answers to which they already know an answer exists, and may even know that answer. Thus, the problem statement is at equilibrium - there is no ""Arrow of Time"" (AOT) and the problem is reversible, meaning that if you played the solution functor backward (in time), you would arrive at the problem statement. It has to be this way, because the problem statement was created before the time the exam was taken. But this doesn't often happen in real dynamical systems. The problems are NOT at equilibrium, either internally, or with their temporal, environmental contexts, and the solutions are ensembles not trajectories.
AOT means the path back is not the path you took, and probably does not exist at all any more. For example, one cannot un-bomb a building and un-kill 3 people.

Then what of the offered heuristics? Wasn't it Jack Ring that once offered ""Experience is a bad teacher, because it gives the exam first and the lesson later?""

I also believe that to state Forrester champions only descriptive modeling as incomplete. However, I also believe that control theory, while very illuminating is also incomplete because of directionality (from both AOT and ensembles [or vector fields & bundles]) and that SD is more complex than merely circular feedback with bias. This is the reason I champion formalizing non-equilibrium dynamics as the paradigm for understanding system dynamics. It is conceptually reachable and now computationally feasible to couple modeling with probabilistically superposed simulation in an evolutionary context, with emergence.

My apologies to William of Occam. I tried, but it didn't work.

=============================
Kenneth A. Lloyd
CEO and Director of Systems Science
Watt Systems Technologies Inc.
Albuquerque, NM USA
Posted by ""Ken Lloyd"" <kalloyd@wattsys.com> posting date Tue, 4 Sep 2007 16:53:20 -0600 _______________________________________________
Jean-Jacques Laublé <jean-jac
Senior Member
Posts: 61
Joined: Fri Mar 29, 2002 3:39 am

Post by Jean-Jacques Laublé <jean-jac »

Posted by Jean-Jacques Laublé <jean-jacques.lauble@wanadoo.fr>

Hi Jim

Thank you for your point of view.

I have often noticed that when people in this forum and elsewhere express different opinions, it is often because they just do not talk about the same thing.

It is to my opinion the case with Bob Eberlein and Richard Stevenson in one of the present thread. They are to my opinion both right from their different point of views.

One typical case is the controversy some six years ago between Coyle and Homer, Oliva about quantitative and qualitative modelling where I think that both parties were right because they were not considering the same problem.

It seems to me that it is the same case here .
When I say that I prefer plain text, I should have mentioned what was the utility of that text and generally speaking, what is a problem definition for me.

For me a problem definition is independent from any method, paradigm, methodology etc.
It explains just what the problem is about, and does not suppose that there is dynamic involved, that the problem to be solved needs simulation or optimization or anything else.

It explains the context of the problem too, the intellectual, financial, time capacity, the past experiences and everything that everybody needs to consider and in particular the different solutions (because there can be many of them) that the problem owner would be satisfied with.

To my opinion, the problem definition as you expose it, supposes that one has already made the choice of the method and that there are sufficient inertial and feedback problems that justify the application of SD, and that the client has the necessary intellectual, financial and time resources and that the stake of the problem matches the effort needed to solve it with SD and that there is no other method more appropriate to the context exposed.

For instance lots of business problems are solved by experiment, just because there is not a lot of inertia and the results of the policies can be seen relatively quickly and permit to avoid simulations more useful when it takes years to see the effect of decisions.

Deciding between the two methods is not easy as sometimes, there is not a so long time inertia and both methods can be considered.

One of the reasons for the slow acceptance of SD by the business word is that the total conditions of the problem are not well considered.

The business word is more results and time oriented than the public sector for example who can afford the risk of starting a study even if the outcome are not evident for the simple reason that whatever the outcome it will be still present after 10 years, unlike the business that can disappear in the meantime.
I hope that I have made myself better understood.
Regards.
Jean-Jacques Laublé Eurli Allocar

Strasbourg France.
Posted by Jean-Jacques Laublé <jean-jacques.lauble@wanadoo.fr> posting date Wed, 5 Sep 2007 13:14:06 +0200 _______________________________________________
""Jim Thompson"" <james.thomp
Member
Posts: 21
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement

Post by ""Jim Thompson"" <james.thomp »

Posted by ""Jim Thompson"" <james.thompson@strath.ac.uk>

If clients knew how to solve the problem at hand, they would hardly be inclined to engage a consultant in the first place. During a system dynamics consulting engagement, clients learn to solve problems with system dynamics.

Engagement circumstances-such as how involved an individual client becomes in the formulation, testing and analysis of a model constructed by the consultant-contribute to how and what the client learns.

If we consultants treat each client the same during the engagement-for example, by facilitating group sessions ""from the front of the classroom""-we risk not being able to see each participant as a learner with needs different from the other learners.

Perhaps it is not feasible to assess the learning needs and styles of every participant in a group problem-solving session. But it may help to have some background information-for example, knowing how relevant the engagement is to the participant's principal occupation. With that bit of information, the consultant can begin to develop an approach that builds on what the each participant knows.

Jim Thompson
Posted by ""Jim Thompson"" <james.thompson@strath.ac.uk> posting date Wed, 5 Sep 2007 10:31:22 -0400 _______________________________________________
Locked