Michael McMaster wrote:
> Murray was expressing a concern that they were throwing out structure and
> design in favour of self organisation. We were sharing a distaste for
> that way of speaking.
>
> My own experience is that there are a significant number who are using the
> term "self organising" as a contrast or antidote to structure as we know
> it but who have little or nothing to replace it with. There are also
> numerous executives whom I've talked to that have heard/interpreted self
> organising used in this way.
As usual, Mike is precise and correct. Over the last few years, I've
helped companies of all sizes, design enterprise-wide messaging systems.
It would be fair to say that I've seen more than a few "self-organized"
messaging systems, most of which were a nightmare.
In one instance, the messaging system had over 100,000 users spread across
all 50 states, with a wide variety of connections between each
geographical location. Some of their connections were high-speed WAN
links, such as Frame Relay and others were slow links such as a 14.4 modem
connection. This particular organization started the implementation before
they even began to think about design. Their attitude was, "it'll evolve
over time to fit our needs."
I flew all over the US trying to help them bring order to the chaos they
had created. It took us several months, and cost them over $400,000 -- in
addition to the original implementation costs -- to get their system
running effectively and efficiently.
It occured to me, after this particular event, that what was lacking was a
few good design principles. I began, at that moment, to think about
writing a design methodology for messaging systems, particularly Novell
GroupWise. Over the next few months a colleague and I talked about it,
experimented, and took careful notes as we visited different companies.
Eventually it became clear to us that we could mathematically represent
the basic theory of our design methodology:
d=r(f)
d = decision
r = rules
f = factors
We then listed all the conceivable "decisions" that would need to be made
in designing a messaging system. Out of this came over 25 pages of
decisions (single line spacing, 6 pt font). We then listed all of the
"rules" we had discovered, and had a list nearly as long. Finally, we
tried to list all of the known "factors" that needed to be considered when
designing a messaging system (a task we never completed).
I became clear to us that there was no way we could cover all of the
possible combinations of decisions, rules, and factors, and so we had to
rethink our work. We backed away from our mechanistic approach, and took a
rather philosophical position. What came of this was what we called the
"bottom-up" design methodology (after we had worked through the "top-down"
and "ad-hoc" methodologies, we decided the "bottom-up" was the best
alternative).
This methology took a little over 30 pages to describe, and has proven
remarkably successful. It covers the basic "concepts" of a design
methology, but in no way defines precise "procedures" or "structures." We
leave those to the designers. It also uses a rather systemic approach,
where you work from the whole to the parts instead of the parts to the
whole.
Those who use our design methodology can still create "self-organizing"
messaging systems, but they do it with greater intelligence and success.
I think, perhaps, this is the type of thing Mike is talking about.
-- Ben Compton The Accidental Learning Group Work: (801) 222-6178 Improving Business through Science and Art bcompton@geocities.com http://www.e-ad.com/ben/BEN.HTMLearning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>