REPLY "Flawless Consulting" and SD (SD6641)

SDMAIL Bill Harris bill_harris at facilitatedsystems.com
Thu Sep 20 05:43:06 CDT 2007


Posted by  Bill Harris <bill_harris at facilitatedsystems.com>

"SDMAIL Bob Eberlein" <bob at vensim.com> writes:
>> A short comment on this. There is a lot of discussion of data in this
>> thread but as I understand from the original query data was intended to
>> mean all information about the problem domain, the people involved, what
>> is at stake, how information is exchanged and everything else. The 
>> question posed was whether using a style of front end interaction in a
>> project, such as "Flawless Consulting" leads to more effective 
>> engagements. 


Bob,

Thanks; you got it!


>> Actually I don't think the intention was to restrict such methodologies 
>> to the front end and that means there are two different questions to
>> be considered. First, are there methodologies that increase the 
>> effectiveness or efficiency of information gathering? Second are the 
>> methodologies that increase the likelihood of implementation success?
>>
>> In my limited experience the answer to the first question is no. It is


I agree that SD can provide deep information gathering, and so I'd
mostly agree with your answer to the first question.  

The part we may miss from an SD perspective is the emotions people have
wrapped around situations and any power imbalances that may inhibit the
development of sustainable solutions.  It's not that we can't model
emotions or power; we can.  If we can explain the presenting problem
without calling on them, we may apply Occam's razor to eliminate both,
leaving people frustrated and less likely to help with implementation.
That's a call for watchfulness on our part.


>> best not to completely alienate the problem stakeholders, but beyond that
>> the key to getting good information in a timely manner is knowing what to
>> look for and being persistent. I don't know the answer to the second 
>> question. It seems like it should be yes, I want it to be yes, but I have
>> never seen anything that is both methodical and effective. 


We could probably all agree with the first clause of your first
sentence.  :-) 

That second part of your response to the second question is the one I
think I'm most focused on.  Sure, we can produce great insights, but can
we find better ways to have the solution become the clients' when we
walk away?  Does the OD approach offer more ownership because it has
less outside expertise and more client group involvement up front and
all along the way?  

I do wonder if there's another alternative view, but I don't sense it's
one we hold.  That view would be that OD (or perhaps another, often
qualitative, approach such as soft systems) is the overarching approach
to improving organizations including power, structure, emotion,
performance, and the like, while SD is the precision tool that comes in
to make sense of specific issues.  That doesn't feel quite right, for SD
can get pretty overarching itself (World3, anyone?).

Here's a real-life, published example from years ago.  I helped an
organization reduce their overspending by 95%; the insights came from an
SD model ("Pipeline Inventory: The Missing Factor in Organizational
Expense Management," National Productivity Review, Summer 1999).  The
organization's manager had been an engineer active with feedback control
systems; when I showed him a slide of the model (about slide 5 in a deck
of about 20, as I recall), he understood immediately what might be
causing the overspending and said, "Fix it!".  I said I had 15 more
slides to show, but he said he understood already; just go do it.
(Hence my suspicion that it may be easier to persuade managers who were
engineers of the utility of SD.)

  Incidentally, that paper also shows why credit cards may be risky to
  your financial health; the same structure applies.

At his request, I wrote the software to add to the expense management
systems to get the required information, but that was only half the job.
I and an admin assistant who also had had OD / change management
experience developed a plan to involve key people (mostly the other
admin assistants and the finance department representative) in the
implementation that made the result theirs, not mine.  We did a number
of specific, OD-ish things that worked quite well.  After a few hiccups
in the process, we achieved our goal of reducing variance by 95%, making
spending highly controllable (the organization was in an expense cutting
mode), and getting expense management off the table as a management
issue.  It was used continuously and successfully until the organization
was disbanded and its remnants folded into another Division.  (Okay, we
solved the expense management issue, not _all_ the business issues.)

What are the lessons from that?  One might look on it as SD up front
followed up with common sense and human courtesy, but specific OD /
change management approaches were used to design the follow-on part, and
I think those were both key in its success and not an obvious part of
common sense or human courtesy.

So that was a successful SD intervention that followed up with OD.  At
the front, I had all the data I needed given to me in meetings for other
purposes, and I developed the model on my own (I think the manager
regarded the problem as simply a fact of life in that organization at
that time).  I guess I may have answered the question for myself: it
may, at least sometimes, be appropriate to apply OD / change management
at the end of the SD work to increase implementation success.  It may be
that participatory data collection (OD) and model-driven data collection
(SD) are simply two design choices, each leading potentially to somewhat
different results and each being more suited potentially to somewhat
different situations.

I think I'm feeling better; thanks for helping me think through this.
Other ideas (and reactions to my comments here) are more than welcome.  

Thanks,

Bill
- -- 
Bill Harris 
Posted by  Bill Harris <bill_harris at facilitatedsystems.com>
posting date  Wed, 19 Sep 2007 08:26:34 -0700


More information about the SDMail mailing list