On Sat, 13 May 1995, John R. Snyder wrote:
> Replying to LO1177 (Melvin Dickover)--
> >
> >Another way of looking at "resistance to change" that is very useful to
> >consultants is to translate the phrase into "I'm using an ineffective
> >method". This moves the problem to you from the organization, and
> >motivates you to do something different and better.
>
> Hmmmm. This seems like an improvement over the all-too-common practice of
> blaming the client, but is it the best possible approach? It could also
> motivate the consultant to start beating him/herself up about something
> that is beyond his/her unilateral control. It seems to me that whatever
> is happening is *co-created* by the consultant and the organization and
> that the responsibility is shared. Neither can take unilateral action to
> solve the problem. "Moving the problem to [the consultant]" seems to
> reinforce the illusion that the consultant is there to do something
> heroic, set things straight, give enlightenment, use effective methods on
> people, etc. This attitude may well be at the root of why the project is
> going awry -- the heroic "expert" unilaterally decided what the
> organization needed and the organization happily colluded by giving away
> its responsibility for thinking. In that case, the consultant's simply
> guessing again won't help.
My idea is not to blame consultant rather than client, but to remove the
concept of blame (past oriented) and focus on outcome. I work with the
belief that everyone is doing the best they can, given their resources
and beliefs.
Regardless of why it was decided that a changed system is the desired
outcome, I argue for effective ways of doing it. Your point on chosing the
new outcome is very good. But, when the outcome is not being achieved,
Ithink it is the consultant's responsibility to try something else that
might work. The consultant must adapt, must have more states than the
system being changed to get the outcome (law of requisitc variety). Only
then can the consultant help the client learn.
Mel Dickover (dickover@umd5.umd.edu)