page 495 lh - Matt Taylor Notebook
Boulder Series |
| When
crisis hits a segment of our society, it has many
mechanisms in place to respond to it. What is
unfortunate, however, is that these are too often
incremental actions, and parts focused that tend
to
fix rather than recreate. |
| A
process and tool kit in not available that facilitates
a large social system, such as a town or region,
to move significantly beyond the
conditions and intrinsic model that has just been so clearly proven
to be vulnerable by the crisis. The HABIT is such that people
just build back the same design-strategy - only “stronger.” |
| And,
once the “crises” is “solved,” rarely
is the original systemic problem generality understood and the system as-a-system improved.
Rarely, are new design strategies passed on to
other areas of the world with the same intrinsic
design vulnerabilities. This is not learning.
And, even more rarely, is the memory [link] built
in a way that the social system can appropriately anticipate similar
kinds of failures in the future. Failures they
are. This is not, as so often broadcasts portray,
a situation of victims - it is more often than
not the result of systematic ignorance, denial
and poor design. Often, short term focused entrenched interests prevent the emergence of better solutions. |
|
 |
page
495 lh
Matt
Taylor Notebook
Boulder
Series
| RDS Central
tracking trends, watching the news for problem
areas and directing RDS deployments in responses
to requests. In time, a KnowledgeBase is
assimilated that supports a degree of Anticipatory
Design so that potential problems can be
identified in advance. |
|
|
| A Newspaper story, in 1982,
about an entire town poisoned by Dioxin triggered
the RDS concept. The town, clearly, had no
way to deal with the crisis - no way to even think
about it. There was, of course a variety of Federal
and State aid programs, as well as, insurance - but
nothing that dealt with the problem itself.
In a way, a town destroyed by something like this
or by a hurricane IS a tragedy - it is also
an opportunity to preconceive a town - as a
whole - and to build a better one. A chanch that anyone
rarely gets. Towns and cities evolve - this is, in
some ways, a goodness. In other ways, it denies a
certain level of thought and design. A crisis can
be an opportunity to think about issues that were
never considered in the first place. It is certainly
the opportunity to avoid intrinsic design flaws that
were just so graphically revealed by whatever crises
“happened.” Guess what, conventional housing
does not work on a barrier island where hurricanes
are prevalent. Build this way, in a location such
as this, and you are taking a calculated risk - it
is a form of gambling. Statistics rule. |
| What
is put back (if it is) should be not only
be respectful of the past but should also be a quantum
improvement for the future with the lessons learned,
from the crises incorporated into the new design, as well as a refreshed embedded vision of a better future than was realized before. |
| The
idea of the RDS is to deploy a capacity
to facilitate a far better design process than
happens in the political vacuum that is too often
the afterbirth of a crisis. To provide a neutral,
creative place where a community can deal
with crisis and recreate itself. To do this
without any up front costs or obligations on the
part of the community. And, then, after
recovery, incorporate the community - as part of
a ValueWeb system - going forward that returns
the favor in an appropriate way, at the the appropriate
time - a gift economy. Increasing returns. |
|
 |
page
499
Matt Taylor Notebook
Boulder Series
| The RDS deployed.
In the center an area for large group dialog
and design. Around the parameter, areas
for breakout teams, information display,
work product production and a crisis center
to coordinate the deployment of needed
resources. The RDS will run 24/7 until
the crises is resolved. |
|
|
| We
live in a human society addicted to over specialization
and linearity. In cases like a broad scale disaster,
the “problems” are solved - the fix is
made - separate from the vision of what
the community wants to and can become. When
not in a crises, few communities can muster the
focus to reshape - in a conscious way - what they
are. The paradox is that crises provides the energy
to act but usually responds with target fixation
on a set of narrow problem parameters that do not
contain sufficient information for generating a
sustainable solution. Society keeps on fixing the
past while haphazardly evolving toward an unknown,
randomly determined, future - design by default. |
| It
is only by fusing the energy of the crisis
with a transformational vision that the curve
of change can be “jumped” to the next
level. Managing the crisis, learning from the
past, and recreating the future has to be seen
as one exercise. It is this way that all
that matters can become the basis for
a truly human and sustainable solution. |
| For
this to happen, all vantage points have to be
honored but none can dominate. Special
interest politics cannot be allowed to define
the solution set - the scope of the outcome.
Sufficient intelligence and alternative models
have to be brought into the process. Ignorance
and dogma is always part of crises. If this ignorance
and dogma prevents alternatives having voice in
the new design, another version of what
failed before is all that can happen. |
| The RDS has
to be a working environment that incorporates
what was working in the community, prior to the
crises, with what was missing and made the vulnerability
in the first place. Disaster is looked upon as
random - as something that happens - with the
population as “victims.” Well, build
a conventional city on the seashore in a hurricane
area and what happens is predictable. If there
be victims it is the result of self-delusion
and bad design - the hurricane is not the cause.
The same goes for mixing dioxin with oil to keep
dust down on dirt roads - which is how the town
in the newspaper article was destroyed. |
|
 |
page
495
Matt Taylor Notebook
Boulder Series
| At
the end of a deployment a NavCenter
is built to continue the work of rebuilding
the community. It will be staffed by local
people who “stepped up” to
knowledge work during the crises. A measure
of success
of the deployment will be the NavCenter
becoming an active, neutral place for community
design. |
|
|
| To
accomplish it’s mission, a RDS deployment
has to be of several weeks duration. And even
when the crises is over, and a new path designed,
there will remain many months, if not years,
of implementation. For this reason, the RDS will
leave a permanent Center behind to be operated
by the community. The task: continue stewarding
the rebirth process, be an active member of the RDS ValueWeb,
and build an anticipatory capability (Weak signal
Research). |
| It
is through this network of RDS Centers that
the general Knowledge Base is built and, in time,
this anticipatory capability accomplished. General
patterns will emerge that will prove useful in
dealing with crises, anticipating them and avoiding
them. What is learned will be documented and published.
This is how science works. This will be accomplished
on a grassroots level not by organizational and
governmental bureaucracies. |
| Each
local Center will develop and maintain a “Master
Plan” [link] that
facilitates the THERE to HERE process
of making real the community’s best vision
of itself. |
| Societies
and modern civilizations are complex and cannot
ever be completely understood. This does not
mean that better - much better - design cannot
be brought to bear in their creation and recreation.
There is a limit to growth that the architecture
of our present society can sustain. The architecture
of complexity is not yet in existence. However,
we can do better than we are doing now.
Natural adaptation is an important design principal;
design on the scale and scope that I am talking
about must not be interpreted to mean as top
down, rationalist arrogance. I am talking about
employing a better strategy of design-process and
incorporating the many many modes that are necessary
for robust design to happen. |
| The
history of the DesignShop process, over the last
20 years, and its success with complex systems
like the 777 engine development and the F15 reconfiguration,
demonstrates that complex, cross community, controversial
and multidisciplinary problems can be successfully
solved with the right kind of process and leadership.
The RDS, today, will employ a Patchworks
Design [link] architecture. |
|
RDS History
updated October 23, 2004 |
| There
has never been a RDS deployment for the
purpose of facilitating a community in crisis as
proposed in the original concept. There has been
dozens of deployments, globally, for corporations
employing
the DesignShop
process
on issues relating to their business. The FAA RDS,
in October 1983, was the first deployment and this
was focused on internal FAA issues. We later,
in 1984, did a DesignShop at Acacia dealing with
the consequences of the strike and the subsequent
system delays caused by the introduction to the
hub-and-spoke system. It was not until 1995, however,
that RDS deployments
became common.
They continue
with increasing
frequency
to this day. MG Taylor does several a year and Cap
Gemini, operating with a MG Taylor license, has
three RDS Units which they employ
routinely. Still, all of these remain focused on
normal business
issues.
TomorrowMakers has done a couple of very
small scale deployments in support of community
and local government collaboration [link].
All these RDS units have
been portable
systems derived from our standard AI NavCenter
components and not designed, from the beginning,
for deployment purposes. Although they work well
enough,
they lack the full environmental effect (notable
Armature [link]) and the ease of reuse that a mature
system will require. |
| MG
Taylor has been asked to prepare an RDS that
can be used at the the 2005 World Economic Forum
Annual Meeting at Davos. While this is
not a community in crises, the purpose of this
deployment will
be
to assist the Forum in providing far more interactive
and collaborative sessions then has been their
norm and to address systemic issues
of
global
concern. This use certainly falls into the ANTICIPATORY
DESIGN [link] aspect
of the RDS mission.
We have also been asked to supply this RDS for
a Club of Madrid meeting that will take
place early in 05 [link].
These deployments, and other indicators [link],
give argument that the original RDS concept
may be coming to term. It is also notable that
the RDS being prepared for the
WEF and Madrid will be the first that begins to
approach the level of functionality of the beginning
concept. We will not have the time nor the financial
resources to manufacture a system totally from
scratch. We will be adding Armature elements and
other crating and organizational features that
have been long needed. |
| The
original concept of the RDS was
documented in my Boulder Notebooks as described
above. The FAA RDS deployment
is profiled below and was documented in these same
Notebooks. In 1995 we created a RDS Proposal and
this was updated (version 1.5) in September 1988
[link].
The WEF deploymnet planning is documented in this
web site [link] and
in my post 9-11 Series Notebooks [link]. |
| A
through study of all these sources is
useful for a full understanding of the RDS concept,
its 20
year plus history and for conceiving the full potential
of this idea and the various forms it can take
and uses to which it can be put. |
|
 |
page
564
Matt Taylor Notebook
Boulder Series
| Notebook
sketches of materials for a FAA RDS deployment
- the first test of the idea. This page
show the Radiant Wall at the end of the
event with all of the documentation components
that were shipped with the system. This
page later because the basis for our first
Manual. |
|
|
| We
had a colleague who was an internal OD facilitator
for the FAA. He had the task of facilitating
a senior management group in an management retreat.
He had little money, less time and no mandate
to bring in someone from the outside. Yet, he
wanted to give these managers a true DesignShop
experience. These circumstances lead to our first
one-time License, RDS kit, and method
transfer “workshop.” John
had a general background in what we did and good
skills in facilitation and organizational development
consulting. He was part of a network that we
had some relationship with through the work we
had done, earlier in the year, with the Army.
Our task was to compress the DesignShop experience
into it’s most minimal form without compromising
it or increasing the risk of failure. We had
little time ourselves because we were preparing
for our move to Washington DC and work with Acacia.
We had three days with John, and then once he
and the kit left our facility in Boulder, it
was all totally out of our hands. The documentation,
from my Notebook, contains the basic theory and
practice of the DesignShop process, the design
of his DesignShop experience, as well as, the “parts
list” of the RDS kit. |
As such, it became the most
compact description of our work to that date and
the basis for our first manual which was produced
in 1985. It also illustrates my personal documentation
method. These pages were distributed, in real time,
to five of our active clients. |
| Page
564 is an
illustration of the WorkWall, AndMap, Task
Map, storage and retrieval system we shipped.
It diagrams the flow of information during
the process and shows what content should be
where on the WorkWall at the end of the event.
Thus, it illustrates the technical process,
the tools and the “End State” of
the work. |
|
 |
page
565
Matt Taylor Notebook
Boulder Series
| The
AndMap process and symbols for capturing
the strategy work produced
by the FAA Management Team.
The AndMap is a language developed
for this propose. Like all languages is has
its own grammar and rules, that once learned,
allows common understanding of complex
issues. |
|
|
| Page
565 outlines
the basic grammar of the AndMap map which was
one of the major products of the exercise.
The Strategy of the management team was to
to be captured here with the Tactical work,
by detailing the major projects, illustrated
on the Time and Task Map below it. As 564 shows,
The center section of the WorkWall - at the
end of the process - would display strategy in
the form of a flow chart supported by tactics in
the form of a color coded project map. Both
the AndMap and the Time and Task Map systems
were and are proprietary methods of our enterprises
supported by an array of physical, process
and computing tools. In the three days that
John was with us in Boulder, we gave him a
through grounding in how an AndMap diagram
is constructed as a language and as a group
process. The object of the tools was to provide
the participants with a concrete representation
of the strategy and tactics in a form that
is communicable to others and bridges effectively
to the implementation work that follows the
retreat. This work, in our terms, was the THERE of
their work - and, of the DesignShop process
itself. |
| On
the scale of their work, it provided the FAA
an artifact to work back from as they developed
their implementation steps. On the scale of the
DesignShop event, this “End State” provided
the goal for the experience. The design of the
event, then, became an exercise in “getting HERE from THERE -
what experiences and work did the participants
require to be at this state in the end. This
was what CS Forester taught me one delightful
day in 1954.[link] |
|
 |
page
566
Matt Taylor Notebook
Boulder Series
| A “classic” 2
day DesignShop event structure designed
for the FAA deployment. The THERE to HERE process
is illustrated with each Module supporting
the work - flow described. This was aligned
with the
Model
of the Creative
Process and related theory outlined on page
568. |
|
|
| In
our tutorial experience with John, this lead naturally
to the basics of the process and a model of the
event itself. The DesignShop event was two days
- a minimum time frame for the work desired and
a huge commitment in the eyes of senior management
at the time. Page 566 diagrams the basic
process going “out” on day one - the SCAN and
getting “back” on day two - the FOCUS and ACT.
Below this diagram a variety of Modules were outlined
that provided the experiences necessary for this
journey. For reasons that are lost in the mists
of time, we now call this a “StrawDog,” These
Modules contain a series of experiences, each with
information provided, that allowed an open-ended
and structured approach to the work. This underlying
structure is based on a model of learning, memory
and creativity that was designed based on a theory
of brain/mind observations of how creative people
work. A theory that had been tested through a number
of prior DesignShop events. 18 years of such testing,
observing, and recreation lead to the knowledge
supporting our Patent application in the late 90s.
This Patent has application, naturally, that goes
far beyond the DesignShop “test-bed” itself. |
| This
level of structure was adequate, given his prior
experience, for John to proceed with the development
and delivery of the event and
to be successful. This became, historically, our
first exercise in transfer. Although it was part
of our mission [link] from the beginning, it
was another 10 years before transfer became the
main focus of MG Taylor’s work. |
|
 |
page
567
Matt Taylor Notebook
Boulder Series
| Parts
list for the FAA RDS deployment.
Each deployment requires a different mix
of parts, components and knowledge-agents
as determined by its circumstance. This
deployment, by modern standards and technology
with five times the people, was relatively
simple. |
|
|
| Certain
aspects of the underlying theory of the DesignShop
process were key to John’s success. These
were selected by considering John’s knowledge
and skill set, the specific challenges presented
by the participants, and considering those unique
aspects of the DesignShop process that would
provide the greatest leverage in the circumstance
of this deployment. It was impossible
to transfer the entire theory and practice so
we focussed on what was necessary to do this
design and employ the specific environment and
tools provided. This is an example of just-in-time
learning an important aspect of the 7 Domains
Model. In regards the tool kit, Page 567 provided
the entire parts list. This was used to assemble
and manufacture the Kit and it was used, with
John’s pre-DesignShop time with us, to closely
link each part of the environment with the specific
processes supporting the event. In this regard,
the diagram on Page 564 can be seen as
a knowledge management algorithm and an early
precursor to the 10 Step Model [link] which was
to emerge in it’s present form in 1987. |
| While
the FAA RDS was in no way near the scale
and scope of a full RDS deployment, I
was very interested at the time in simulating
as much of the experience as possible. This was,
also, the first transfer process of our technology
outside of our own organization. Our agreement
was not to provide a DesignShop or event an RDS Kit.
Our agreement, with the FAA, was to provide a
facilitation work shop for John. The materials
he carried away and the use of the Kit was incidental to
this arrangement. This, of course, circumvented
a great deal of complex procurement issues. This
is also a model that still has utility given
the circumstances of many organizations today. |
|
 |
page
568
Matt Taylor Notebook
Boulder Series
| “Managing” Inclusion and “Parallel
Processing” Models - key aspects of
the DesignShop process - were part of the
FAA RDS kit. These Models and their
related processes as expressed in work
Modules were selected based on the issues
that John was confronting. |
|
|
| For all these reasons, we
had to be as discrete with what was “in” and “out” of
both the Kit and the “work shop” as possible.
Because it was impossible to manufacture even this
simple level of RDS for one deployment we
took advantage of the Acacia move. We shipped the
Kit to John’s retreat location, he shipped
it to Acacia in Washington DC where it arrived
the day we did and served as our temporary Center
while we were remodeling the 7th floor of the Acacia
building. In all, it was a very satisfying experience.
The following year, we were to do a full DesignShop
process with the FAA, and the airline industry,
aimed at solving the problem of massive delays
- which were the aftermath of the strike and the
invention of the “hub-and-spoke” system.
The lessen learned with this was not lost on us.
John could not “buy” what he wanted which
was a full DesignShop conducted by us in our environment.
We went to our “anticipatory design” (Fuller)
shelf and pulled off the RDS idea and adapted
it to John’s needs. This involved some risk.
However, the risk was minimized by employing “mass
customization” to the solution: a very careful
design and preparation that involved no compromise
but provided just what was actually needed for
the event. We made it work, financially, by piggybacking
on the Acacia requirements for a temporary setup.
This meant we had no capital costs associated with
the FAA part of the deployment. We focussed on
transferring to John the specific information he
needed - nothing more. This lead in time, to one
of the most important and interesting DesignShop
challenges we have ever had, and in the short term,
gave us both RDS and technology transfer
experience. |
| Page
568 covers
three key aspects of the DesignShop theory
I though critical for this employment: the Inclusion
Principle, a concept of Information (thus,
it’s management) and conducting the event
using (massive) Parallel Processing much
as the human mind employs [link] (this
latter is a central aspect of our System and
Method). These three Models combine to make
a powerful insight of the inner workings of
group process. Supported, as it is possible
today with a robust tool kit based on our System
and Method, it is possible to construct a working “group
mind” that actually functions in a coherent
way. It is by exercises such as this, RDS and
the many DesignShops conducted in this period,
that we discovered, tested and prototyped the Method which
took many more years to build into a patenable [link] System of
work. |
|
 |
page
569
Matt Taylor Notebook
Boulder Series
| The
basic philosophy behind the practice and
the idea of a RDS being
an Information Factory served as CONTXT for
the deployment. The role
of feedback was also introduced because,
once understood within the system provided,
this process alone can accomplish event
stability and outcome. |
|
|
| At
the time, we worked with John to understand these
three Models on the level of description and
Modeling Language - this was suffient for his
purpose. The more technical level of the system
was presented as a capture, documentation and
publication process - a level of process nececessary
for supporting the DesignShop participant’s
work. Page 569 further explored this theory
and presented the Notion of a Mangagement Center
being an Information
Factory. [link] Also,
here, the critical role of feedback was intoduced.
Intrisic to all of this, was the idea that creativity
could not be made to happen but that the
right environment can be made to ensure the emergence of
it. This theory, of course, was intimately tied
to the process design as outlined on Page
565. Thus, while highly focussed and targeted,
the entire “system” provided John was
broad in it’s coverage of philosophy, design
strategy, event process and tool kit employment
- a true deployment of a system. |
| Demonstrated
here, is the ability to scale. A system and Method
is not a System and Method if it cannot
transfer and scale. The FAA RDS was an early
test of this ability. |
|
 |
page
570
Matt Taylor Notebook
Boulder Series
| Distribution
list and Notes to associates and clients
- a standard use of my hand-drawn Notebooks
to this day [link].
This is the practice of reuse of Knowledge
Agents and a process that promotes work
iterations. These pages still have value
and are being
reused
to
this day, 20 years later. |
|
|
| For
us, at the time, the entire investment was four
days of effort plus the necessary logistical
coordination to detour the RDS Kit, on it’s
way to Acacia, to John’s offsight. This
was very effecient and indicated the leverage
that was possible to us by Licencing and transferring
the system to a reliable “Agent.” Page
570 is the distribution of this information
to three active clients, our own staff and our
Archives where it has rested until this web publishing
17 years later. It is our practice then - and
now - to share our work, broadly, on the philosophical,
descriptive levels and “down to” the
broad outline of the Modeling language. The deeper,
systemic materials are transferred to staff and
Network members on a fiduciary basis and to clients
on a need-to-know basis determined by their License
and their demonstrated ability-to-employ the
information. |
| The
goals of this have been consistent: maximize
learning and system development by real-world
tests, bootstrap a capability on a pay-as-you-go
basis until it reaches a demonstrable level of
reliability and transferability. There is a Model
of “Level One” where a critical mass
of key system components is reach that allows
the “system as a system” to function.
We have been able to approach this level, in
structured events, for temporary periods for
years. We are just arriving at the ability to
create and maintain this system in an “open” environment
and stand alone basis independent of the need
of constant regeneration on our part. |
| It
should be clear, of course, that this is an essential
requirement of a true RDS deployment
aimed at the kind of mission described at the
beginning of this document. A “deployment” means
that the “system” is going outside
it’s “natural” (protected) environment
into a “hostile” one - the system has
to be sufficiently robust to sustain itself indefinitely
in these conditions. Transfer is a necessary
ingredient of this. Both RDS deployments
and NavCenter environments will only truly work,
by definition, when they meet this specification.
The only way to accomplish this is by constant
deployment and transfer attempts until all the
factors required are learned, documented and built
into the System and Method. Only then is
it an INVENTION and more than a useful,
case specific, personality-centered craft. |
| The
recent history of the RDS started in 1995.
We were asked by Avis Car Rentals if we could manufacture,
in three weeks time, an environment and set it
up in their Reservation Center in Tulsa for a DesignShop
event. Naturally, we said yes. The deployment was
a great
success
but what followed is remarkable. Virtually all
the rest of the year was made up of deployments.
For one reason or another every client wanted us
to come to them. Literally, we would have gone
bankrupt without the RDS ability. Over 80%
of our Revenues were generated by RDS deployments
in 1995! Today, it is a far lower percentage of
our Revenue base for a variety of reasons, however,
it continues to grow in absolute terms every year.
Even Cap Gemini with 20 ASE environments finds
it necessary and useful to employ their RDS capability
several times a year. |
|
Revisiting
the VISION
updated October 23, 2004 |
| THE Vision,
however, remains nascent. It is time to challenge
this state of affairs. Every “negative” condition
that existed in the mid-70s when we started this
process - in order to alter these circumstances
- still
exists today but at an even greater state of crises.
Our human society still does not know how to deal
with systemic issues and so we continue
to see ourselves as victims when things go “wrong”
rather
than taking the message, from nature or another
part of humanity, as the feedback that it is. We
are running out of time. We continue to try and
manage
a PLANET by
controlling the parts. There is no indication that
this will work yet we plunge on blindly as if working
harder, doing more and shouting louder will fundamentally
change anything. |
| Real
change cannot take place until some part of the
system fails. This failure galvanizes action. It
is not the various crises that we face that is
our problem. Our problem is our refusal to see
them for what they are and to take legitimate action.
The PLACE to start systemic change is
on location where some part of the system has failed.
A catagory 4 hurricane is not a problem it is a
fact of nature. Building the wrong kind of cities
in its probable path is wrong-headed. Rebuilding
along the same vunerable lines (only “stronger”)
is stupid. Diaster can be turned into opportunity
not only for the benefit of the directly affected
comunity but for humankind at large. To do this
a SYSTEM is necessary. |
|
Matt
Taylor
In Flight - Palo Alto to Orlando
July 19, 2000
At
Elsewhere
October 23, 2004
SolutionBox
voice of this document:
INSIGHT • POLICY • PROGRAM
|
|
posted:
April 19, 2000
revised:
October 23, 2004
• 20000719.122639.mt • 20000720.214517.mt •
• 20000727.203099.mt • 20010908.111190.mt •
• 20041023.345601.mt •
(note:
this document is about 95% finished)
Copyright© Matt
Taylor, 1982, 1983, 2000, 2001, 2004
IP
Statement and Policy
|
|
|
