Posts Tagged ‘dialog mapping’

Book review: The Heretic’s Guide to Best Practices

January 23, 2012 5 comments

The Heretic’s Guide to Best Practices: The Reality of Managing Complex Problems in Organisations, by Paul Culmsee and Kailash Awati, examines how groups of people can work to define a complex problem and to identify possible solutions. The book is divided into three sections: the first part argues why “best practices” often fail in the face of wicked problems; the second examines how people can work together (with a focus on dialog mapping, issue-based information systems (IBIS), and Compendium), and the third provides case studies illustrating successes and lessons learned from the authors’ work experiences. I found the middle section to be the most interesting and enlightening: it included motivation and history behind dialog mapping, with lots of illustrative examples and key citations balanced by alternative approaches. Much of the book centered around Compendium use and examples, the free IBIS-based dialog mapping tool I discussed in a previous post. In case you worry that the authors don’t eat their own dog food, a great many of the figures were generated by Compendium—reflecting intermediate steps of how a manager can address wicked problems using the tool.

The book represents an interesting pairing of authors. Paul Culmsee is a consultant who probably knows more about dialog mapping and Compendium than anyone (except maybe Jeff Conklin of gIBIS fame, who wrote a glowing foreword to the book with high praise for Culmsee). Kailash Awati is an information systems manager, with a couple of Ph.D. degrees and experience at several levels in academia. Both Culmsee and Awati blog prolifically, and many of their blog posts fed nicely into this book (a trick I’m using to prepare my book). People familiar with their styles will find their key writing styles featuring irreverent humor, pop-culture references, and in-depth examples prevalent in this book. (At times, though, I feel their pop-culture irreverence would be better if rooted in fact; e.g., the real Clippy story is interesting and perhaps relevant, and people and stories behind the development are still out there.)

There were a few major weaknesses of the book (though in the spirit of “wicked-ness”, many of these drawbacks to me may be neutral (or advantages!) to you, so take them as such). The index is very weak (less than 3 pages for a book approaching 400 pages). I’d love to look up what they have to say about strong reciprocity, or whose views of claims they discuss, or their view of McCall’s PHI approach to wicked problems, or their thoughts on positions in IBIS, or numerous other topics—but such a short index just doesn’t provide adequate support for a lot of important queries. In addition, I often find that books suffer from a certain myopia when it comes to the authors’ favored approaches, though there’s somewhat less fan-dom in this book than is seen in many books of this type. They certainly show a favoritism to IBIS and Compendium, but it’s the authors’ prerogative in writing a book to choose approaches to focus on and how much to talk about the weaknesses of a favored approach. More generally, they took the “depth over breadth” approach in this book, with heavy details about a few approaches rather than touching on a more inclusive set. It’s great to see examples, but not at the exclusion of alternatives. Somewhat telling, the references list contains only 122 references—there’s no mention of the work of Schön, Toulmin, McCall, Moran, Carroll, or others who have had important (nay, foundational) things to say about the topics in this book.

So who should get this book? The book targets technology managers who are looking for a way to address complex problems, and plenty of software professionals (e.g., ones who want to “deprogram” their managers) could benefit from it as well. Certainly anyone who uses Compendium or, more generally, embraces IBIS as a design approach or wicked problems as a problem classification should read it. If you like Jeff Conklin’s book, then (dare I say it?) I bet you will like this one even more. To grossly oversimplify, this is like Conklin’s book but moreso: more motivation and framing of the problem type, lots more examples, 5 years more of experiences and Compendium advances, more history of where these ideas came from, and more positive and negative examples of Compendium’s utility. If that sounds appealing, you should get a copy of this book.


Compendium review

October 7, 2011 8 comments

Compendium is a hypermedia mapping tool created by a consortium of universities and research labs in Europe and the US. It is rooted in Rittel’s wicked problem conceptualization and IBIS approach to design and design rationale capture, building on combined efforts of Al Selvin, Simon Buckingham Shum, Jeff Conklin, and many others. Compendium allows designers to create a node-link graph of interrelated concepts, including questions, ideas, pros and cons, references, and decisions. It’s similar to a lot of the mind map tools that are out there, though its scientific basis makes it

I downloaded Compendium (version 2.0b1) and used it as part of a personal brainstorming session. I wanted to exercise the things that could be done with Compendium, then share my results with a remote group of colleagues–as seems to be the great strength of Compendium. Specifically, I wanted to explore how an app or set of apps on mobile interfaces can be used to encourage physical activity among K-12 students (mainly middle schoolers)–assuming each has a phone with the apps installed. We’ve come up with a small handful of games and activities ourselves, and we’ve been inspired by the process and products from the SICS-Microsoft “Inspirational Bits” effort. What we need is ideas, and that why I turned to Compendium.

It was a bit slow to get started using Compendium–even/especially with the 42-page (!) getting-started manual (though there’s also a 2-page quick reference sheet as well, which was helpful once I had a basic understanding of Compendium). There are the typical “starting-with-a-blank-slate” problems where the initial actions aren’t obvious, full of “aha” moments as I played around with it. The palette of nodes on the left of the screen was helpful–but clicking on them does nothing (aha, you can click-and-drag them onto the screen). I couldn’t quickly figure out how to link elements (aha, it’s not just a click-and-drag motion, that’s for moving nodes, it’s a right-click drag motion for linking). Hitting return when I finish typing a node name pops up a node dialog instead of just naming the node (aha, I can click elsewhere to defer adding node details).

My first pass in using the tool resulted in a single question and around 8-10 ideas that address the question. For better or worse, I then felt compelled to use other nodes–namely, the “pro” and “con” nodes (that are quite similar to the upsides and downsides of claims). I considered using the other nodes, but they didn’t seem as applicable–I didn’t want to “decide” anything, and I didn’t delve deep enough to include any references or videos or web sites. Alternating between ideas and pros/cons worked out well, as thinking about pros/cons typically inspired other ideas, and thinking about new ideas led to new pros and cons. Being a good engineer, I ended up with a four-level tree: a question at the root, four idea categories, a bunch of ideas, and a bunch of pros and cons for each idea.

The layout aspects of Compendium are a major weakness of this tool. There’s an automatic layout feature, but it seems to use a poor layout algorithm…thus there’s no way the Compendium graphical representation could support a large node set (beyond 20-30 nodes) that would emerge from many brainstorming sessions.
For example, my 25-node graph, created in a few hours of thinking about, interconnecting, and evaluating ideas–couldn’t fit on the screen either horizontally or vertically in a readable manner. The zoom isn’t very smart, simply shrinking the nodes and thus losing the context that goes with them (rather than, say, keeping the icons visible and/or 1-2 keywords readable) and it doesn’t seem to be possible to zoom down only a portion of the graph. There are so many great graph layout algorithms, and so many ways to lay out and zoom graphs (e.g., radial, fisheye, hyperbolic), that it feels very limiting not to have them available in this tool.

The computer-supported features of Compendium are what I feel makes it worthwhile. When I “lost” a list that I created, I was able to search for it to locate the node where I stored it. You can limit search just to the visible nodes or extend it to embedded lists, notes, etc. The search also extends to deleted nodes, so as a project ages I could have found ideas from weeks or months before. There seems to be some sort of back/forward buttons and history bar which (I assume) allow you to revert back to previous versions of the page–but I couldn’t get this to work. A well-implemented history feature seems like one of those things that would really be worthwhile; e.g., to view what transpired between the beginning and end of last week’s meeting, or to revert back to the state of inquiry from the start of the meeting. But a well-implemented history also seems hard to implement!

After completing a Compendium graph, I sent it to my six remote colleagues, both in HTML form (which can be viewed by any web browser) and in XML form (which could be loaded if you install Compendium). Two of the colleagues responded back, both of whom seemed to look at the HMTL version but not the XML version. There were positive comments about the ideas that emerged, though little specific. One of the two seemed interested in using it in a design session on her end, so I may update this paragraph with more details (and if there are comments from the other collaborators).

Any sort of design tool has overhead associated with it. At times I suspect a paper version of Compendium might be better, at least from a usability standpoint. When leading a design session, I want to get ideas up there quickly, I want to move them around quickly, I want to stack them and move them around and hand them to breakout groups to flesh out themselves. Those sorts of things seem to go faster with Post-Its than with Compendium. And I don’t think it’s the fault of Compendium–I noticed the same sort of thing with PIC-UP (from our lab) whereby the richer and more communicative interactions occurred with paper versions of cards. Of course, those were short one-off sessions, and I suspect the real value of tools like Compendium lies in its use over long periods of time.

Compendium has been widely used, and there are tons of comments on their web site. Compendium’s heydey seems to be the 2003-2007 time frame, when there was an annual meeting on it, and there were lots of case studies and papers emerging about it. It’s certainly still active–the beta version that I tried was released earlier this year–but much of the web site seems dated, and there’s currently no formal support for the tool (though there’s a somewhat active online forum for reporting bugs). It’s hard to judge how large and active the user community is right now, but historically there’s been a fair amount of use.

So is this a good tool? I think it can be great for the right type of situation–when you want to save and revisit and search a collection of ideas, and when you need some encouragement to balance questions, ideas, pros and cons, and associated rationale. The tool really guides you to do these things, and if you’ve got a task that could benefit from it then it can really be worthwhile. And a final note: Compendium seems to be one of those “all-or-nothing” tools–if you buy into its philosophy, there can be great value…but you have to buy into it. The project leader must decide that Compendium will be used, and the team members must agree to use it during their design. If you’ve just got a small portion of the team using it, then the results won’t be nearly as meaningful. But if everyone is on board, it can be a great repository for design.