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.
Jim Hines [mailto:jim@ventanasys
Newbie
Posts: 1
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement

Post by Jim Hines [mailto:jim@ventanasys »

Posted by Jim Hines [mailto:jim@ventanasystems.com]

Jean-Jacques Laublé writes

>> I prefer plain text [to express the problem definition]

No doubt an undiagnosed dyslexia is to blame, but I'm anti-text when it comes to problem statements.

After a few years teaching an SD Applications course, I dropped the step of writing a text problem statement (a step that had come immediately after getting reference modes) and ultimately banned text problem statements altogether. The reason: text statements seemed to prevent students from describing problems dynamically. In contrast, students could be positively eloquent when simply speaking spontaneously about the reference modes.

Prior to teaching that course, my consulting experience had made me suspicious of text problem statements. The sheer time that a group of managers could spend word-smithing a problem statement amazed me. If we already had reference modes, the time was wasted; worse, if we **didn't** already have reference modes, creating a text-based definition seemed to get us started down the wrong path. The only saving grace: Word-smithing is sufficiently slow that we didn't get very far down the wrong path.

Note: I am anti-text, but proudly pro-Laublé.

Jim Hines
jim@ventanasystems.com
Posted by Jim Hines [mailto:jim@ventanasystems.com] ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌPosted by Jim Hines [mailto:jim@ventanasystems.com] _______________________________________________
Ralf Lippold <ralf_lippold@we
Member
Posts: 30
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement

Post by Ralf Lippold <ralf_lippold@we »

Posted by Ralf Lippold <ralf_lippold@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@web.de>
posting date Sun, 9 Sep 2007 18:47:19 +0200
_______________________________________________
George Richardson <gpr@albany
Member
Posts: 20
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement

Post by George Richardson <gpr@albany »

Posted by George Richardson <gpr@albany.edu>

On Sep 8, 2007, at 7:10 AM, SDMAIL Jim Hines wrote:
> You're right that defining a problem in terms of reference modes
> pre-supposes that people have already decided to use SD.


I don't think that's quite right. It presupposes that you want to address a dynamic problem, and to define to the problem dynamically, that is, in terms of graphs over time, but that does not mean that you are constrained from that point on to use the rest of the system dynamics approach. I would think there could be any one of several follow-ons to starting by defining the problem dynamically, including micro-simulation (agent-based modeling).

We have seen several settings in which just asking a client group to draw graphs over time of the issues that concern them helps the group with their problem(s), usually beacuse they had not previous taken a look at the problem specifically over time.

I'd definitely agree with Jim, if I understand him rightly, that asking folks to draw graphs over time of what they're interested in is absolutely essential for getting a good problem statement to approach the problems using system dynamics tools. But I also tend to think its a good idea not matter what approach the group ends up using. Thinking dynamically draws us naturally into putting events in a context that moves over time, and that's smart thinking whether one tries to see those dynamics in stock-and-flow / feedback terms or not.

..George
Posted by George Richardson <gpr@albany.edu> posting date Sun, 9 Sep 2007 10:54:16 -0400 _______________________________________________
""Ken Lloyd"" <kalloyd@wattsy
Junior Member
Posts: 5
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement

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

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

Jim,

May I offer a sample problem statement, one which is currently in a Challenge competition.

Problem Statement:

To develop a framework for a flexible architecture that enables an intelligent, small business enterprise in accomplishing its objectives within the marketplace of values and ideas. The architecture describes the structure of a system whose behavior exhibits intelligence, by which we mean the ability to anticipate, adapt and respond to conditions represented in an environmental context. These conditions may not be known or understood by the enterprise a priori, and they will change over time in ways over which the enterprise has no direct control (although the enterprise does influence the environment in the actions and reactions it may take).

The enterprise ... is one in which the market and competitive conditions are well documented and understood. This enterprise represents a small, independently owned business classified by NAICS ..., that has competitors ranging from small to very large.

Deliverables:

Given (you provide the enterprise description, financial, human and capital resources, the objectives, and the NAICS classification of a real system under investigation)

Describe the architecture (structure and behavior) that can survive, and thrive in a randomly (stochastically) selected set of market, competition, collaboration and regulatory conditions for that NAICS over a period of 36 months.

Achievement:

Measurement upon a rubric based upon Maslow's Hierarchy.


Posted by ""Ken Lloyd"" <kalloyd@wattsys.com> posting date Sat, 8 Sep 2007 11:49:18 -0600 _______________________________________________
""Saeed, Khalid"" <saeed@wpi.
Junior Member
Posts: 4
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement

Post by ""Saeed, Khalid"" <saeed@wpi. »

Posted by ""Saeed, Khalid"" <saeed@wpi.edu>

Jim makes a good point. Defining a problem as a reference mode allows one to develop at least a preliminary mental model subsuming the phase relationships between the various trends in the fabric we call a reference mode. Several years ago, I was assigned a small project by the UN- Economic and Social Commission for Asia and Pacific to create projections for trend in resources and environment for the region. Given that the numerical data was fragmented and incomplete and could never support any statistical projections, I was forced to think of these trends as reference mode, which was well received by the client even without mentioning a model.
I later attempted to document the process I used in the following article:

Saeed, K. 2003. Articulating developmental problems for policy intervention:
A system dynamics modeling approach. Simulation and Gaming. 34(3): 409-436

Of course, as a system dynamicist, I had to develop a model, not as a part of my assignment, but to personally conclude the project. This model was written up in the following article:

Saeed, K. 2003. Land Use and Food Security — The Green Revolution and Beyond. In A. Najam (Ed). Environment, Development and Human Security, Perspectives from South Asia. Lanham, MD: University Press of America.

I’ll be happy to supply reprints if you write to me at saeed@wpi.edu

Khalid

Khalid Saeed, PhD
Professor of Economics and System Dynamics Social Science and Policy Studies Department WPI, Worcester, MA 01609 Posted by ""Saeed, Khalid"" <saeed@wpi.edu> posting date Sat, 8 Sep 2007 11:23:10 -0400 _______________________________________________
Jean-Jacques Laublé <jean-jac
Senior Member
Posts: 61
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement

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

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

Jim

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.

I do not pretend that one cannot step back having studied a first level of definition and began to apply the solution. This is why there is a sort of chicken egg process here.

The first level of definition includes the critical questions that make a project fail or succeed :the level of the nuisance of the problem and if it is continuous or discreet.
By continuous I mean that the nuisance can be reduced more or less and discreet if there are only two solutions (on can imagine more than two
solutions) for example: the problem is solved or not solved.

The range of time left to solve the nuisance and the minimum reduction of the nuisance needed.

The level of risk the client accepts to solve the problem.

Example: if the client is a multinational company and the problem is in one of its branch of small importance, he may accept a high expectation characterized by a very high profit and a smaller probability of success, while a company owned by a family who earns its life from it, will prefer a smaller expectation characterized by a lower profit and a higher probability of success and low probability of failure and overall cost.

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

These are fundamental questions that have nothing to do with the solution.

These points will automatically have an influence on for instance the boundaries of the model, the horizon, the quantity and precision of the date needed etc.

But these questions must come first.

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

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.

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.

The people involved in the process and how other people could ask questions or even have an influence on the process should be well defined.
This would give another credibility than text books examples.
I do not say it is easy to do, but one can start with something less ambitious.
Regards.
Jean-Jacques Laublé
Posted by Jean-Jacques Laublé <jean-jacques.lauble@wanadoo.fr> posting date Sun, 9 Sep 2007 13:06:42 +0200 _______________________________________________
nickols@att.net <nickols@att.
Junior Member
Posts: 5
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement

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

Posted by nickols@att.net <nickols@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@att.net (nickols@att.net) posting date Sat, 08 Sep 2007 13:30:06 +0000 _______________________________________________
""Jim Hines"" <Jim@ventanasys
Junior Member
Posts: 12
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement

Post by ""Jim Hines"" <Jim@ventanasys »

Posted by ""Jim Hines"" <jim@ventanasystems.com>

Jean-Jacques,

You're right that defining a problem in terms of reference modes pre-supposes that people have already decided to use SD. But in the absence of that decision, it's unlikely that you'll get a problem statement that subsequently will be very useful to an SD approach. Part of the SD process is problem definition.

My guess is that problem definitions usually do presuppose some approach to problem solution. I think that's why supposedly neutral problem statements often seem to me to be heading down a wrong (or at least non-SD) path. For example, a client will say ""the problem is that we don't have enough salespeople"", when the real problem is that sales are declining. Or they'll say ""the problem is that the right data isn't available to the top people"", when the real problem is that their business is oscillatory. Or, they'll say ""we're creating a new business flow for our call centers and want to check for hidden gotcha's"" when the real problem is that their quality has mysteriously declined.

In practice it seems that a manager starts with some poorly articulated problem and uses that to decide on a poorly articulated problem-solving approach. Then, the hint of the problem solving approach lets the manager get a bit more precise on the problem statement, which lets her get clearer on the solution approach, etc. I'd speculate that human thought processes actually **require** a problem statement to develop in tandem with a solution approach. You can't have one without the other.

Jean-Jacque, you're probably sadly shaking your head and thinking I simply need to see a **real** problem statement of the kind you mean. I agree.
Would it be possible to post an example of one?

Jim Hines
Posted by ""Jim Hines"" <jim@ventanasystems.com> posting date Fri, 7 Sep 2007 09:42:54 -0500 _______________________________________________
""Alan McLucas"" <a.mclucas@a
Junior Member
Posts: 10
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement

Post by ""Alan McLucas"" <a.mclucas@a »

Posted by ""Alan McLucas"" <A.McLucas@adfa.edu.au>

This is an interesting thread and one which deserves closer attention. My comments are intended to add a few ideas that have either been touched upon lightly or, in a small number of instances, missed. I seek your indulgence.

In developing a good problem statement we need to understand what the problem is. Understanding the problem is often the biggest challenge:
the closer we can get to understanding the problem the close we get to ""solving"" it. I reluctantly use the word ""solve"": complex problems rarely get solved!

In developing our understanding of the problem we have to make certain judgments about who to include and who to exclude from having an input.
This input spans early conceptualisation through to development of the problem statement(s) and through to the development of strategies we might wish to implement. But who are the stakeholders or decision makers and how should they be involved? Clearly those excluded cannot influence the analytical processes or development of models (conceptual or otherwise and in what ever form they take) from which strategies might be derived. Unfortunately, those we choose to exclude might well be adversely affected by the strategies decision makers subsequently implement.

Engaging them effectively requires us to speak their language and be able to communicate effectively about the problem situation. This is not always as simple as it might first appear, and there are many opportunities for miscommunication and misinterpretation. Further the mindset we bring to the discussion may not enhance the communication:
not everybody speaks in terms of feedback, reference modes, rates of change and etc.

Those having an opportunity to contribute to the analysis should be engaged to the extent that they are best able to provide insights into the particular problem situation. To identify those who hold these insights might involve initially expanding the definition of the boundary to sweep in diverse perspectives then progressively contracting the boundary. It is important to note here that once we build any form of quantitative model we are invariably representing only ONE perspective of a given problem situation. We should be very cautious about proceeding quickly, or directly, to a single perspective of a problem situation to the exclusion of all others.

We need a variety of methods and methodologies to help us engage and communicate effectively with those who find themselves in a problem situation. Here I differentiate a methodology as having strong theoretical and philosophical underpinnings, whilst a method involves a series of steps sometimes taken iteratively (but not having the same theoretical basis). A methodology might include several methods. Also, choice of methodologies should be informed by potentially diverse preferences those with a stake in the problem have for processing information and problem conceptualization.

The system dynamics way of thinking is certainly powerful in certain situations, but it is not universally applicable. Further, in system dynamics, we often conceptualize using ""systems"" constructs which do not align with the notion of ""systems"" as they appear in other disciplines, such as, in systems engineering. We need to recognise that. Systems constructs we often create can be abstract and/or highly aggregated in our models, and as such do not represent real-world systems in a strict functional sense. Despite this, those constructs can be valuable in informing our understandings of structural feedback dynamics, for example.
Just because we are fascinated by the insights they enable does not mean that those confronting a problem situation will feel the same way.

We use system dynamics modelling to analyse systemic problems: we do not model systems. This, in itself, is a boundary issue. Boundary issues cannot be separated from considerations of interfaces: not all problems are the product of only endogenous factors.

We should consciously seek to balance the extent to which our models are abstractions of the real world with the need, explained by Jay W.
Forrester, that all SD models we build must not only replicate real world behaviour but must be founded in real-world cause-and-effect relationships.
This raises a question about the relationship between potentially abstract systems constructs, often necessarily including intangibles and soft variables, and the extent to which they are sufficient, necessary and legitimate representations of the real world. Here I deliberately avoid use of the term ""valid"", because we cannot fully validate SD models (and that is another issue).

A good problem statement for SD analysis purposes is not the same as a requirements statement in systems engineering or an objective function in an operational analysis problem. For example, once having created a systems engineering requirement statement we set out to define tests (applied
subsequently) to validate the physical solution we hope to create.

To enhance our ability to create good problem statements (see Midgley (2000) Systemic Intervention), we need to reflect on:
a. the boundary which we define to test the extent of the systemic problem
and, in the process, making judgements about who to include and exclude;
b. judgments about theories and methods that are most appropriate for the
purposes of the analysis (not exclusively focusing on SD); and
c. a clear understanding of action that needs to be taken to create sustained
improvement.

Whilst SD is powerful in helping us to understand how to create strategies for creating the last of these, that is, sustained improvement, no strategy will work if its implementation is not supported by those likely to be impacted by such implementation.


All of these issues influence what good problem statements might look like and who we might go about formulating good problem statements.

There is one other consideration, and in my view the most important: any problem statement we create is a transient object. Once we have developed it, it is outdated. Arguably, the most important outcome is a certain level of understanding that comes from the journey of creating it.

Regards,
Alan

Dr Alan McLucas
School of Information Technology and Electrical Engineering, UNSW@ADFA, Australian Defence Force Academy, AUSTRALIA Posted by ""Alan McLucas"" <A.McLucas@adfa.edu.au> posting date Tue, 11 Sep 2007 10:59:37 +1000 _______________________________________________
Jean-Jacques Laublé <jean-jac
Senior Member
Posts: 61
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement

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

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

Hi everybody

On Sep 8, 2007, at 7:10 AM, SDMAIL Jim Hines wrote:
>> You're right that defining a problem in terms of reference modes
>> pre-supposes that people have already decided to use SD.

I never wrote this in any of my e-mails.
I wrote that defining the problem statement using a CLD was already supposing a solution, but not reference modes that show its dynamic.

May be I did not make myself understood, but any information, data about the problem can and must be joined with the text explanation; whatever form it has and reference modes are exceptionally clear and do not presuppose any solution.

One can eventually add a causal loop diagram if the objective is to give information only and does not already prepares the solution as it usually does.

Alan Graham wrote:

<It turns out there's some more direct empirical support for non-speedy <rates of change leading to evolutionary progress.
<Scott Rockart's work on magazine strategy demonstrates statistically <that the more successful magazines didn't vary from their strategy <(balance of content vs advertising, advertising rates, etc.) very much, <whereas less successful magazines did.

Is the success coming from the non-speedy rates of change or the opposite?
It may be the opposite because successful magazines will just keep their strategy and unsuccessful will try to change it.
But it can still be the non-speedy rate of change that is the cause of success because slow changes may be easier to implement than big ones.
Regards.
Jean-Jacques Laublé Eurli Allocar.
Posted by Jean-Jacques Laublé <jean-jacques.lauble@wanadoo.fr> posting date Mon, 10 Sep 2007 19:30:29 +0200 _______________________________________________
""Kim Warren"" <Kim@strategyd
Member
Posts: 36
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement

Post by ""Kim Warren"" <Kim@strategyd »

Posted by ""Kim Warren"" <Kim@strategydynamics.com>

Seems to me that SD offers a particular kind of solution to a particular kind of problem, but one that is near-universal - something is changing over time in a way we would prefer to be different from what is actually occurring. This may seem a trivial distinction to our community, but problems seem more often to be stated as ""the current *situation* is not what we want, and we want its
*state* to be different"", [e.g. return on investment is only 5% and we need it to be 8%]. We in SD would worry that this risks creating a better-before-worse outcome [e.g. hitting 8% next quarter, but damaging future profitability].

If so, the reference mode is absolutely critical to SD's contribution. If the owner of the problem [or opportunity] cannot with our help state the problem in this form, then I don't see how an SD process is going to make meaningful progress. I also don't see how it is possible to trace out the likely causality in the situation without linking it back to this performance-over-time of the reference factor, e.g. X is falling at this rate, because Y is rising at that rate, in spite of Z changing like this, which is happening because W is .......
Otherwise, discussion of causality disconnected from the reference mode risks being little more than idle speculation.

The only complication I can see is that there may be more than one element to the dynamic specification of the problem, e.g. ""sales are falling *and* we are spending more on marketing"". But since these multiple elements are part of the same overall system, they should come together in any decent SD architecture depicting that situation.

None of this need assume that people have already decided to use SD, merely that the performance-over-time nature of the problem means that only SD will be suited to addressing it. We do not need to be defensive against the accusation of hitting every problem 'nail' with the SD 'hammer' [assuming we know when to defer to another appropriate time-based tool, such as discrete- event or agent-based]. The really dangerous hammer that is used to hit every problem as if it is a nail is the spreadsheet!

Kim Warren
Posted by ""Kim Warren"" <Kim@strategydynamics.com> posting date Tue, 11 Sep 2007 19:12:15 +0100 _______________________________________________
""Jim Hines"" <Jim@ventanasys
Junior Member
Posts: 12
Joined: Fri Mar 29, 2002 3:39 am

QUERY Getting a Good Problem Statement

Post by ""Jim Hines"" <Jim@ventanasys »

Posted by ""Jim Hines"" <jim@ventanasystems.com>

George's posting concerning how constraining a reference mode is, is quite right. My only nit would be that I'd define the term ""system dynamics"" more expansively than he implies. So, at least some of what he is terming not-SD, I would put in the SD column.

I think of system dynamics as being concerned with how structure produces behavior. Historically the field has concentrated mostly on feedback structure and integration as dynamics-producing structures. But there are potentially some dynamics that are produced by structures better modeled in
ways other than stocks and flows and/or which doesn't involve feedback.

The work on organizational evolution (which is on my mind because of the other discussion thread going on) is one example where a group of SDers used agent based techniques as part of the arsenal to investigate how a particular class of structures generates a particular class of behavior (evolutionary behavior).

Jim
Posted by ""Jim Hines"" <jim@ventanasystems.com> posting date Tue, 11 Sep 2007 14:33:55 -0500 _______________________________________________
Locked