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 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 broadcast portrays, a situation of victims - it is more often than not the result of systematic ignorance, denial and poor design. | |  | 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. Built 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 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. | | 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 original 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: November 9, 2004
• 20000719.122639.mt • 20000720.214517.mt •
• 20000727.203099.mt • 20010908.111190.mt •
• 20041023.345601.mt • 20041109.322387.mt • (note: this document is about 95% finished) Copyright© Matt Taylor, 1982, 1983, 2000, 2001, 2004 IP Statement and Policy | |
|
