Sunday, October 19, 2008
Despite these exciting developments and collaborations, however, we still faced difficulty, and sometimes even active resistance, in attracting new practitioners. This was the case both within what was by now Bell Atlantic as well as within CCL, as well as other organizations. Demand for us to provide Compendium services within Bell Atlantic continued to increase. Indeed, we ultimately hired and trained facilitators from an outside firm to keep up with demand. But the phenomenon of potential internal practitioners trying it once then giving up, or rejecting it outright, did not abate.
Within the IT and client organizations of Bell Atlantic, we heard two main objections. The first came especially from the software engineers and developers who were our main training clientele. Most said that the tool was not a true object modeling, database, or “collaboration” tool. We would be asked, "why would we use Compendium when we can use Lotus Notes, or Visio, or Access, or …". It seemed that by asking technical people to act as facilitators and communicators, we were pushing them beyond their comfort zone. There were one or two of our students who (despite being IT people) were gifted communicators, but they tended to feel that their existing toolkit cared for all their needs, and did not see the need to add Compendium to their quivers.
At the same time, within organizations like CCL which had many talented and capable facilitators, the approach appeared to many as “too technical,” too difficult or foreign, too hyper-rational. People accustomed to free-form discussion capture on flipcharts and whiteboards did not like the idea of constraining their representations to what they thought that Compendium could provide.
For both constituencies, capturing and representing complex issues in the software, in front of a group of people watching one’s every move, choosing node and link types and performing complex operations on the fly, trying to keep up with fast-moving conversation, just seemed too hard for most people to do.
Next and last: Continued Evolution
Next: Difficulties in Diffusing the Practices
We soon began to identify desired enhancements for the software, and tried to work with CMSI to build them in to the tool (by then renamed "QuestMap"). QuestMap offered great speed and capacity for navigating even very large maps, and worked extremely well for managing IBIS (argumentation) nodes and links. We wanted greater ability to access and manage the underlying database as well as to be able to create richer representations, especially to support business process modeling. QuestMap was developed with an encrypted, embedded database that did not allow direct access or manipulation by users, and there was no way to add different kinds of icons or images, or to extend or customize the software in other ways. We also wanted to make greater use of transclusions, which we felt were the true "secret sauce" that allowed the tool to be used for multi-dimensional representations. However, CMSI felt that their core market was in IBIS mapping and did not want to extend the software in those directions.
To work around the limitations and help connect the work we did in QuestMap with material developed in other applications and settings, we developed small “glueware” extensions, particularly in the areas of importing and exporting content from applications like Microsoft Office and Visio. Most of these were written in Microsoft's Visual Basic for Applications, which transformed QuestMap's exported text files into forms that other programs could use, or formatted material from other programs into QuestMap's import file structure. VBA let even someone like me, with elementary (at best) programming skills, create tools that let us produce richer representations than IBIS maps. When we needed to use these on critical projects (such as a large Y2K contingency planning effort that required us to generate data-flow diagrams in Visio based on our Conversational Modeling maps), real developers like Maarten and Bea Zimmermann were able to beef up my dining-room-table attempts considerably.
We (mainly Maarten Sierhuis and me) began experimenting with this approach. With growing excitement, we found that the approach seemed to hold together, and even to scale to be able to handle weeks or months of working with a project team. Working “undercover” mostly at first, we applied the fledgling approach in a variety of contexts. Each time we met enthusiastic reception from the people we were working with, and learned more about the best ways to represent and manage models, project management materials, and discussions without leaving the CM/1 software.
Still, though, we did not see broader take up of this approach, at least in terms of others adopting the approach and becoming practitioners themselves. While client groups were quite happy to have us come in and be the practitioners for them, they did not show much interest in picking up the tools and practices themselves. In some cases we were able to train people who did apply the approach themselves on a single project, but they never used it again once that project was complete.
One day in early 1993, I was sitting in a meeting in Manhattan, listening to a group of people from New York Telephone debating approaches to redesigning their capital investment process. I had developed a good deal of facility with the software by this time and was easily able to keep up with the discussion, recording ideas and representing them in IBIS format as the discussion proceeded. As usual, the conversation was a mixture of ideas for process design, systems changes, resource issues, problems and opportunities, arguments and brainstorms. It suddenly occurred to me that CM/1 itself could be used as the tool for World Modeling.
Fast-forward a few months. Despite the initial excitement, the collaborative networked use of CM/1 had died out. We did not get much take-up of the software in any form beyond a few people who had been at the original workshop. Several other members tried the approach with enthusiasm, especially in group meetings, only to give up quickly as the apparently simple act of capturing discussion in nodes and links proved not to be as easy as it looked. Most times we saw people quickly fall behind, and then give up altogether as the spoken discussion just did not seem to take a form that matched what could be represented in IBIS. Neophyte mappers did not know how to intervene in the conversation so as to try to get careful engagement in the maps.
What later become Compendium, as an approach and as software, dates back to early 1992. I was a member of the Expert Systems Laboratory at NYNEX Science & Technology, the R&D arm of the telephone company in the northeast USA. The lab was interested in approaches like participatory design, ethnography, and group process facilitation for our business process redesign and systems development work. Jim Euchner, our executive director, invited Jeff Conklin and others from Corporate Memory Systems, Inc., (CMSI) to give a workshop for the lab. CMSI were the developers of what was then called CM/1, a commercial IBIS groupware tool that had descended from the pioneering gIBIS work at MCC in the 1980s.
In the two days of the workshop, we used CM/1 to construct argument maps of some of the key issues we were grappling with as an organization, particularly how we could best build on previous work in both software development and business process redesign. There were many perspectives about right ways to go forward, many opinions and disciplines contending with each other, and not a few disagreements.
Working closely with the CMSI team, groups of us in twos and threes worked to build maps that represented the positions we were taking, and then presenting the maps to the larger group. In some cases we experienced breakthroughs between people with apparently opposed positions, as we were able to identify “left-hand moves” – larger questions in which both our positions could appear as possible alternatives to be argued for or against, without needing to crush the opposing position with rhetoric.
We were struck with the power of the approach to open up our dialogue about the issues we were wrestling with. The fact that we were working with a software tool that let us create such representations, that could be revisited at other times, added to, worked on both in individual and in collective sessions over the network, seemed to hold out limitless potential.
We excitedly planned to work intensively “in the tool” over the coming months, developing our skills and exploring issues at the same time. Especially we were intrigued by the promise of escaping the “easel archeology” that plagued the months-long participatory design projects we were facilitating, where project teams had to search through stacks of paper to try to find the key ideas from earlier discussions and meetings. If we could use CM/1 to facilitate, capture, and manage such project team discussions, we could have searchable archives of ideas, proposals, and rationale to draw on without having to cart around, and rummage through, tattered collections of easel sheets. We looked forward to realizing that potential.
Next: Early Days
I will try to keep this in mind as the finish date for my PhD oozes beyond next year's birthday. Some take years of trial and error to get things right (if they ever do).