More Compendium history (part 8): Continued Evolution

This is the last of a series.

Back to Part 7

Time moved on. By 2001, the original team of Compendium practitioners and developers at what was now Verizon had mostly moved on to new responsibilities or left. Various mergers and reorganizations left the effort without executive sponsorship. 

We were able to license the software development to KMi, where Simon Buckingham Shum was successful in continuing the development, funding a full-time programmer, Michelle Bachler, who significantly expanded the tool’s capabilities over the next several years. We continued to find new applications and approaches to complement the existing ones, and formed an international group of interested people called the Compendium Institute, holding annual workshops and creating a website and discussion group (numbering 1,267 members at the time of this writing).

In 2003, Verizon granted permission for the Open University to distribute the software, and eventually the program code, freely. As the number of downloads grew (more than 50,000 by November 2008), new applications for Compendium were developed by others outside the core group, with exciting work being done in public policy exploration, e-Government, e-Learning, and many other areas. 

Within the core group itself, innovation and exploration continued, reaching into areas such as collaborative e-Science combining software-based input with on-the-fly group mapping, personnel rescue support, mapping the Iraq debate, and many other areas. Compendium has taken its place among the leading knowledge cartography approaches. The Compendium community, approach, and software continue to grow and evolve in ways both satisfying and, often, surprising to its originators.

Research and development continue on many fronts and in many places, with universities and individuals around the world making contributions. In 2003, I turned my own attention to a set of research questions that felt key to understanding the practice dimensions and, eventually, to finding better ways to support the training of new practitioners. I'm interested in the ways people find to shape Compendium maps into expressive artifacts, to craft expressive hypermedia knowledge maps on the fly, with groups of people, inviting their engagement, reaching into analysis, modeling, dialogue mapping, creative exploration, and rationale capture as necessary and appropriate. That work is the chief subject of this blog.

More Compendium history (part 7): Difficulties in Diffusing the Practices

This is part 7 of a series.

Back to Part 6

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

More Compendium history (part 6): Creativity Takes Center Stage

This is part 6 in a series

Back to Part 5

As we were puzzling about this paradox of having a powerful, successful, flexible technique that we could not convince many others to take on for themselves, a further major influence came into the picture. In 1998 and 1999 we began several collaborations with outside groups. 

One of these was with the New Lenses on Learning research group at the Center for Creative Leadership (CCL), connected by one of our executive internal clients who also served on an advisory board at CCL. This group, particularly our primary contacts Chuck Palus and David Horth, shared a similar interest in “putting something in the middle,” using image-rich visual artifacts in group dialogues to foster creative thinking and exploration of complex challenges.

Their use of manual and paper techniques and ours of software-based issue maps seemed more complementary than opposed, and we began looking at ways to combine our approaches. An early development was adding the capability to display digital photos and images to Compendium, so that the evocative images in CCL’s Visual Explorer toolkit (then existing only on paper) could be loaded into our software and manipulated, adding to the discussion, model, rationale, and issue maps we were already working with. We experimented with different ways to use our combined approaches in the experiential workshops that CCL conducted in different organizations.

The other chief collaboration that began at that time was with Simon Buckingham Shum of the Knowledge Media Institute at the Open University in the UK. Simon’s long background and deep research interest in IBIS, QOC, and related tools and approaches led to a highly generative research collaboration, both exploring the approaches we had developed to date and expanding them in new directions. 

Taken together, the KMi and CCL collaborations held out the promise of integrating creative exploration, issue mapping, model-based design, rationale capture, and meeting facilitation together in one tool. We generated many research papers and formed collaborations that continue to this day. The potential seemed (and still seems) enormous.

Next: Difficulties in Diffusing the Practices

More Compendium history (part 5): Developing the Software

This is part 5 of a series.

Back to Part 4

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. 

Despite the limitations, though, we were able to support some very large projects with the existing software coupled with the Conversational Modeling approach. These included both small group and multi-team analysis and design projects. A few small software development teams that we were members of used the approach to manage their work over longer periods. One of these, that built a forecasting tool, used the approach to manage all of its work over a couple of years, growing a large repository of models and issue tracking with both clients and developers, capturing a great deal of rationale along the way.

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.

These helper tools only took us so far, though, and required a lot of manual intervention on the part of the user. In 1998 we decided to begin developing our own software tool that would combine QuestMap’s capabilities with the features and enhancements we wanted. The early software design, taking advantage of then-new Java, envisioned a fully-featured mapping tool combined with over-the-internet groupware capabilities.

Around the same time we dropped the “Conversational Modeling” name (which we liked, but few others did) in favor of the friendlier term “Compendium.” This became the name of both our approach in general and the software in particular. We had toyed with a variety of other names, most of which were even more turgid and obscure than Conversational Modeling. While laboring one day at the aforementioned dining room table, I asked my non-technical wife Debbie what she would call a method that let you create collections of ideas related together. She suggested "Compendium", and it stuck.

Next: Creativity Takes Center Stage

More Compendium history (part 4): Conversational Modeling Takes Hold

This is part 4 of a series.

Back to Part 3

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.

I wrote a long technical memo that spelled out the various techniques in detail, which I later summarized in a paper for a 1996 hypertext workshop, which even later became a journal article. This was the first public exposure for the approach.

One of our early successes was working with a cross-functional team from Human Resources that needed to come up with a toll-free hotline for employees to use to access HR resources. We were not only able to use Conversational Modeling to help the group build collaborative representations of the different departments and functions that needed to be incorporated in the “Helpline”, simultaneously recording and working through issues and arguments in the shared display, but we were also surprised to find (based on their comments) that members of the group seemed to be listening to each other, and learning about each other’s work and concerns, with more attentiveness and concern than they had been able to do before. We began to think that perhaps this approach could not only be used for “rational” activities like modeling and analysis, but for group development and mutual learning as well.

After some time and more successes, we went “public” and began offering this approach and toolset as an internal (to NYNEX) consulting service. We also offered the approach free to educational and other external groups. 

Ultimately we conducted hundreds of sessions in dozens of project settings, small and large, over the next several years. We developed training classes (some of that work lives on in these training materials) to spread the competencies we’d developed more broadly within the company, training several dozen people in a number of two-day workshops.

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. 

The many attendees of our training workshops, despite their initial enthusiasm, fell prey to the same pattern we’d seen in the beginning. They’d try the approach in a meeting or two, fall behind or otherwise get stuck, and give up. This experience seemed to be in accord with many of the reports in the 1996 Moran and Carroll book as well as other early work in hypertext and design rationale approaches, which emphasized the cognitive overhead involved in creating representations of design rationale. Many of these researchers seemed to despair that the difficulties could be overcome.

Next: Developing the Software

More Compendium history (part 3): Combining Modeling with IBIS

This is part 3 of  a series. 

Back to Part 2

At the same time as our experiments with CM/1 were occurring, another thread in the lab was concerned with developing a model-based approach to system and business process design, influenced by traditional systems analysis methods a la Yourdon, the European knowledge modeling methodology called CommonKADS, and other approaches such as Soft Systems Methodology. 

As with the explorations of CM/1, there was a good deal of ferment about this as we looked for ways to reap the benefits of such structured approaches while contending with the cognitive overhead of having to work with such frameworks. At the same time, we were limited by the lack of availability of good software tools for such modeling, especially in the area of CommonKADS for which no tools yet existed. 

Coming out of this mix of influences, we’d developed a hybrid modeling framework called World Modeling which prescribed relationships between current state and future state, “implementation” and “essential” (abstract), and other sorts of models. We were quite excited about its potential to organize the work of the project teams we were engaged with, if only we could find a good tool.

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. 

Beyond providing a way of mapping and managing IBIS, CM/1 had some very powerful hypertext features, including the ability to copy nodes from one map and paste them in another such that a true “transclusion” was made – the same object appearing in multiple places, changes made in one place would appear immediately in all the views that object appeared in, and you could right-click on the node to see a clickable list of all the “containing views” for that node. 

This was a key requirement for World Modeling. We needed to be able to show, for example, how a piece of data used in one business process was used in another, without losing the connection or identity of that piece of data. At the same time, we could get the benefit of IBIS argumentation and design rationale capture within the same tool – attaching rationale to model elements as we went, recording debates about how models should be constructed, and the like. 

We came up with ways to tag nodes with searchable annotations (e.g., identifying nodes as “tasks”, “problems”, “resources” and the like), and used CM/1’s export/import capability to build templates of questions corresponding to different model types (e.g. organization models, process models, object models, etc.). It started to look like the good tool was within our grasp.

Next: Conversational Modeling takes hold

More Compendium history (part 2): Early Days

This is part 2 of a series.

Back to Part 1

Over the next few weeks in early 1992, a small coterie of lab members tried to build out discussions and plans within CM/1, mostly working individually to build on others’ contributions in collective maps. Somehow, however, these never seemed to amount to what we expected. Some maps withered with few contributions, while others got very large very quickly, so large that it was difficult to find where to read or contribute. In some cases, long chains of “yes it is”-, “no it isn’t”-style pros and cons emerged as individuals argued back and forth. Few, if any, left-hand moves or coherent arguments or rationale emerged in these collaborative, networked maps.

On the other hand, several of us started to use the software in small group sessions, usually in the context of small software or process redesign projects. These were more successful, especially when the groups paid close attention to what was being put on the screen. When the group worked together to ensure that each node and link were carefully crafted, matching the intended types (e.g. that a Question node really represented a single question and did not bundle in answers and arguments, and was not phrased in such a way as to only allow yes or no answers, etc.), the results were more generative and beneficial.

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.

However, several of us still believed that there was great potential there, if we could only find the right way to apply the approach. We continued to experiment in small groups and individually, recording discussions in meetings, occasionally trying our hand at live facilitation and collaborative capture of design rationale.

Next: Combining Models with IBIS

More Compendium history (part 1)

I've talked about Compendium's early days in some previous posts, such as this. This summer I wrote a longer treatment for a workshop, so I thought I'd serialize it in some posts here. This is part 1.

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

Malcolm Gladwell's Late Bloomers

This article gives hope to those of us well past the prodigy stage. Gladwell writes about Cézanne, Ben Fountain, Mark Twain, Robert Frost, William Carlos Williams, Wallace Stevens, Alfred Hitchcock, and others, all who did much of their best work when they were past 50 years old.

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).