REPLY Getting a Good Problem Statement (SD6609)

[SDMAIL Alan McLucas]

Posted by  "Alan McLucas" <A.McLucas at 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 at ADFA, Australian Defence Force Academy,
AUSTRALIA
Posted by  "Alan McLucas" <A.McLucas at adfa.edu.au>
posting date  Tue, 11 Sep 2007 10:59:37 +1000