|
||||
|
Minimum Specifications Paul Plsek & Associates
Establish only those very few requirements
necessary to define something, leaving everything else open to the creative evolution of
the CAS. |
|||
Bibliography |
One of the most remarkable findings about
complex adaptive systems is that simple rules can lead to complex behaviors.
The classic example of this is the "Boids" computer simulation,
developed in 1987 by Craig
Reynolds. The simulation consists of a collection of autonomous agents-the
boids-placed in a environment with obstacles. Each agent follows three
simple rules: (1) maintain a minimum distance from all other boids and
objects, (2) match speed with neighboring boids, and (3) move toward the
center of mass of the boids in your neighborhood. Remarkably, when the
simulation is run, the boids exhibit the very life-like behavior of flying
in flocks around the objects on the screen. They "flock," a
complex behavior pattern, even though there is no rule explicitly telling
them to do so. While this does not prove that real birds use these simple
rules, it does show that simple rules - minimum specifications - can lead
to complex behaviors. These complex behaviors emerge from the interactions
among agents, rather than being imposed upon the CAS by an outside agent. |
|||
|
In contrast, we often
over-specify things when designing or planning new activities in our organizations. This
follows from the paradigm of "organization as a machine." If you are designing a
machine, you had better think of everything, because the machine cannot think for itself.
Of course, in some cases, organizations do act enough like machines to justify selected
use of this metaphor. For example, if I am having my gall bladder removed, I would like
the surgical team to operate like a precision machine; save that emerging, creative
behavior for another time! Maximum specifications and the elimination of variation might
be appropriate in such situations. Most of time, however, organizations are not machines;
they are complex adaptive systems. The key learning from the simulations is that in the
case of a CAS, minimum specifications and purposeful variation are the way to go. |
|||
|
Looking closer at the
Boids, we see some key elements of the aide of Minimum Specifications (i.e., the minimum
specifications for Minimum Specifications):
|
|||
|
A practical approach to
establishing minimum specification would be to begin with a "good enough vision"
of the desired outcome. Then brainstorm a list of rules you might reasonably expect to
lead to that outcome. Follow the rules of brainstorming; no criticism allowed. Now step
back from the list and challenge each proposed rule by asking: "Can we imagine a
situation where we get our desired outcome even though this rule is violated?" If you
can, eliminate the rule. Also cross off rules that are simply minor variations of other
rules. With the list whittled down, go back through each rule again and ask: "If all
the other rules are met, but this one is violated, will we certainly fail to achieve our
desired outcome?" Think of each rule as unnecessarily constraining creativity. If you
can imagine situations where you still get the desired outcome even if that rule is
violated, throw it out, it is not a minimum spec. Continue this process until you have
only a few rules left, and all pass the test above. |
|||
|
Before using this aide: What has
happened in the past when we have tried to use maximum specification and total conformance
in our design and planning efforts? How has this experience contrasted with times when we
have given people few rules and lots of freedom to act? After using this aide: What creative
approaches can we imagine that would still meet our minimum specifications? What can we
now do to tune our organization to the edge of chaos?
An example of establishing minimum specifications
is given in the attachment. Additional examples of how we used "min specs" in
designing this resource kit are given in the introductions to both the Aides and
the Tales of Complexity |
|||
|
|
|||
|
Generating Minimum Specifications for
This Complexity Resource Kit As you will see in the introductions to several
sections in this kit, we used minimum specifications throughout our design work. An
elaboration on one such instance will serve as an illustration of this aide. 1. At the first
meeting of the planning group (Curt Lindberg, Brenda Zimmerman, and Paul Plsek) we
discussed what it was that we were trying to create. After some dialogue, we had a good
enough vision: "A learning experience for innovators and early adopters that equips
them to go out and generate, capture, reflect on, and understand complexity stories."
We also noted that we wanted the learning experience to be "living;" that is, we
hoped that individuals and groups that took part in the experience would be able to go out
and reproduce it with others. 2. We then
brainstormed specifications for this learning experience. Every idea was boarded for
consideration-no judgment at this phase of the effort. 3. After
several minutes of brainstorming we felt that we had exhausted our ideas. We then went
back through the list asking: "Do we really need that spec, can't we still have a
good learning experience without it?" One "rule" that was easily eliminated
was the statement: "Participants should be teams from an organization." We could
easily imagine a good learning experience for an individual. Indeed, our initial learning
group was composed almost entirely of individuals. Several other rules were similarly
eliminated, or were removed as being redundant with other rules. 4. We now had a
list of seven specifications for the learning experience we hoped to create:
5. While this looks like a nice,
logical, short list, we then went back through it one more time to challenge whether it
really was a minimum list. Considering each rule a potentially unnecessary restriction on
our creativity, we took them one at a time and asked: "If all the other rules are
met, but this one is violated, do we really risk not achieving our desired outcome?"
In this process, we eliminated the second item in the
list above, "actions during the experience should be consistent with complexity
theory." On the surface, this seemed an obvious rule. Surely, if we were going to
help others understand complexity, we must model it consistently in our behavior at all
times. But on reflection, we realized that actions that were inconsistent with theory
could actually enhance the learning experience. If participants were really learning, then
they should be able to point out these inconsistencies. The reflection and discussion that
followed could be very rich. Besides, removing this specification takes away the burden on
everyone to always be unnaturally perfect. The six remaining rules are the minimum specifications
for the learning experience that we are designing associated with this Resource Kit. |
|||
Next | Previous | Return to Contents List Copyright © 2001, Paul E. Plsek
& Associates, |