From: John Conover <john@email.johncon.com>
Subject: Re: Re: Re: Re: BPR-L Intransitives of Determination of Prioriti
Date: Wed, 24 Aug 1994 12:14:06 -0700 (PDT)
netcomsv.netcom.com!WRB-AFRES.AFRES.AF.MIL!Dale=Long%HQ_AFRES_IMX%ROBINS writes:
>
> John,
>
> Ah, you mean common sense uber alles? :)
>
Humor well taken!!!
>
> I'm with you, there. I quite agree that most of the "fad" management
> trends are poorly thought out caricatures of simple caring and common
> sense. I feel for Hammer a bit; he's had to watch every cheap hack and
> snake oil salesman pawn off shoddily constructed wares as "BPR."
>
Yea, of all of the management methodologies, I think BPR is probably
the most suitable, practical, and realistic. It would be too bad if
the snake oil folks bastardize it.
>
> I wage a similar battle here in the Air Force. Even in the military, the
> bureaucratic mind set dominates. (No wars to focus everyone's attention on
> what the military is supposed to do.) Sometimes it seems like people make
> rules and regulations simply to justify their jobs instead of for ensuring
> the "common defence."
>
Good point. I think one of the essential points of BPR is that it is
anti-Napoleonic, IMHO.
>
> And basing selection on "leadership" can be dangerous, particularly if you
> look only at results and not method. An example that occurs all the time
> in the Air Force is the "Great Leader" delusion.
>
> In the Air Force, the main prerequisite to command is making rank. There
> are people who spent their entire careers up to full colonel only dealing
> within a narrowly focused functional community. Suddenly, they are thrust
> into a commander's job.
>
> Now, the military is not a democracy. When the wing commander says "paint
> every building on base dark grey," we paint every building dark grey. And
> try to get our normal duties done. In many cases, the troops involved and
> possibly even flying activities, will suffer some hardship simply for the
> sake of grey buildings.
>
> Most wing commanders, however, are somewhat isolated from this. All they
> see is that the buildings got painted and the planes kept flying. So, they
> arrive at the following illogical progression:
>
> "I told them to do it, and they did it, even though it was
> difficult. I must be a great leader."
>
> I imagine there's a similar effect in the corporate world, where no one
> wants to be the first to admit to the boss that something can't or
> shouldn't be done at a particular time.
>
Yes, I see your point. In your opinion, how wide spread is the "Great
Leader" delusion? Is it an ego trip? Is it a take off on wanting to be
a hero? Most of the people that I have known that I would consider a
great leader, (and there are very few,) never wanted to be a leader.
If you talk to them, their attitude is that fate thrust it on them,
and it came with its pluses and minuses, and you can't give it
back. (A take off on the ancient Sumerian folk tale that the gods
offered us civilization, and once taken, we can not give it back.)
>
> With that in mind, I would add a fourth item to your list of desirable
> traits: An effective communications structure. Something that allows all
> levels of an oragnization to share information freely without regard to
> turf protection or filtering. A truly healthy organization can deal with
> honest self-criticism or alarms.
>
One of my favorite points. I do not think that we use informatics to
its maximum capability. We (at least in business) tend to over
emphasize the value of content data (eg., traditional databases.) I
have been running a lot of ad hoc experiments on using inverted
indexes into an email archive to make kind of a "memo-machine," (eg.,
automate the Napoleonic character of organizations.) Thus, to
oversimplify it, all members of an organization would be set up in an
email asynchronous conference, and all email would be put in an online
archive. The archive can be searched by anyone at anytime for by
boolean phrase searches (eg., context searches.) So someone could pose
a context search, like, get all email that contain stuff about project
xyz, and schedules, and delinquent, ... if one wanted to study why the
project was not going well, etc. Seems to work well if all of the
decision making process was included into the archive. You can look
back and find out why a decision was made, and who made it, and if the
decision process was appropriate, etc. As a matter of fact, this is
what lead me to the intransitives study. One "should" be able to
evaluate how well the decision making process operated (in retrospect)
by subjecting the archive to a independent scrutiny. Unfortunately,
the folks doing the scrutiny are faced with making an intransitive
decisions, so you are kind of chasing your tail, (eg., "in retrospect
this was more important than that," is intransitive.)
BTW, I implemented this system (in hopes) that one could make a
retrospect judgment in who provided the "real" leadership in a
project. There is some improvement, but soon folks learned how to use
the system to their political advantage, and it became a "political
tool," It does have the advantage that it is self documenting, and
therefore the "political agenda" is documented.
The idea for the system came from studying the USSR KGB administration
(I detest the principle of the KGB, but their administration was a
marvel of efficiency, IMHO.) An intelligence document would come in
and copies would be assigned to different relevant files, etc. This
system just automates the process in that you can make relevant files,
dynamically, on demand, eg., all phrases in the system are cross
indexed to all other phrases. The only difference was that in the
paper version of the administration, it would have to be decided which
files were to contain copies before hand-in the mechanized version,
the files were made on an ad hoc basis, dynamically. Something like a
"hypertext" system, only that every word is "linked" to every other
word in the archive, and which links you want is determined by boolean
search criteria.
>
> (Another of my ineluctable analogies: think of how effective the human body
> would be if some bureaucrat in the spine intercepted all the pain messages
> from the left foot because they might make the brain unhappy. The brain
> would never know to tell the hands to take that nail out. This may sound
> far-fetched, but I've seen a lot of organizations that fit this picture.)
>
> Another aspect of healthy communication is that the leader's "vision" is
> generally accepted and understood by the troops. "Defeat the Nazi's" was a
> nice simple concept in WWII. "Get the Iraquis out of Kuwait" was pretty
> effective in Desert Storm.
>
> "Protect Viet Nam, but don't offend anyone while we do it" sent a pretty
> confusing message back in the 60's. When you send someone out to do
> something, be it fight a war or go shopping, it helps to have clearly
> stated and communicated goals.
>
> I'd be very interested in seeing the study you mentioned. Where might I
> obtain a copy? :)
>
It was highly oriented to our industry, and I don't know if any of it
is applicable to your situation, but it was started by Fred Brooks
(creator of the "Mythical Man Month," which is required reading by my
managers,) and has been updated with metrics (which largely support
Brooks' intuition) by Nanus and Farr. If you are interested, go to the
software section of a library or book store and search for authors
Nanus, Farr, Demarco, or Boehm. Software development is an exercise in
coordination and complexity. These folks spent a lot of time, effort,
and resources doing metrics and success/failure studies. Modern
software development methodologies are forever indebted. This is from
by bibtex database.
@book{DeMarco:CSP,
address = "Englewood Cliffs, New Jersey",
author = "Tom DeMarco",
publisher = "Yourdon Press",
title = "Controlling Software Projects",
year = 1982}
@book{Londeix,
address = "Reading, Massachusetts",
author = "Bernard Londeix",
publisher = "Addison-Wesley",
title = "Cost Estimation for Software Development",
year = 1987}
@book{Abdel,
address = "Englewood Cliffs, New Jersey",
author = "Tarek Abdel-Hamid and Stuart E. Madnick",
publisher = "Prentice-Hall",
title = "Software Project Dynamics",
year = 1991}
@book{Humphrey,
address = "Reading, Massachusetts",
author = "Watts S. Humphrey",
publisher = "Addison-Wesley",
title = "Managing the Software Process",
year = 1989}
@book{DeMarco:SSOTASP,
address = "New York, New York",
editor = "Tom DeMarco and Timothy Lister",
publisher = "Dorset House",
title = "Software State-of-the-Art: Selected Papers",
year = 1990}
@book{Brooks,
address = "Reading, Massachusetts",
author = "Frederick P. Brooks",
publisher = "Addison-Wesley",
title = "The Mythical Man-Month",
year = 1982}
John
--
John Conover, john@email.johncon.com, http://www.johncon.com/