“Assumption is the mother of all f**k ups”

Send to Kindle

My business partner, Chris Tomich, is the John Deacon of Seven Sigma.

In case you do not know who John Deacon is, he is the bass player from Queen who usually said very little publicly and didn’t write that many songs (and by songs I mean blog posts). But when Deacon finally did getting around to writing a song, they tended to be big – think Another One Bites the Dust, I Want To Break Free and Your My Best Friend.

Chris is like that, which is a pity for the SharePoint community because he outstanding SharePoint architect, software engineer and one of the best Dialogue Mappers on the planet. If he had the time to write on his learning and insight, the community would have a very valuable resource. So this is why I am pleased that he has started writing what will be a series of articles on how he utilises Dialogue Mapping in practice, which is guaranteed to be much less verbose than my own hyperbole but probably much more useful to many readers. The title of my post here is a direct quote from his first article, so do yourself a favour and have a read it if you want a different perspective on sense-making.

The article is called From Analyst to Sense-maker and can be found here:


thanks for reading


Paul Culmsee



p.s Now all I need to do is get my other Business Partner, mild mannered intellectual juggernaut known as Peter (Yoda) Chow to start writing Smile

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

New videos: Demonstrating the value of Dialogue Mapping

Send to Kindle


In December I recorded a podcast with Nick Martin over at workshopbank.com. This was a fun interview for two reasons. Nick is a really smart guy and great to talk to, and it was Friday afternoon, close to Christmas and I was drinking a beer Smile

In any event, these two videos present an overview of what Dialogue Mapping is all about, some of the case studies where I have used it, and a demonstration of its utility. You will learn:

  • What Dialogue Mapping is and what it can do for you and your stakeholders
  • Learn when to use Dialogue Mapping and when not to
  • Learn how there is no setup or training that the participants have to go through when they’re in a Dialogue Mapping session
  • Learn how all participants feel like they’re being heard when being Dialogue Mapped
  • Hear an great case study when I used Dialogue Mapping for the first time…
  • Hear how as a mapper, you don’t need to be an expert in the subject being discussed
  • Glean a few insights about the Heretics guide to best practices book

To view the interview and demonstration, head on over to workshopbank.com


thanks for reading

Paul Culmsee


 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

Confessions of a (post) SharePoint architect: Do not penalise people for learning

This entry is part 3 of 10 in the series confessions
Send to Kindle

Hi all and welcome to another small piece of my SharePoint architect manifesto. In the previous post I introduced you to the notion of f-laws, which were first coined in a book co-authored by Russell Ackoff. In the process of developing a SharePoint governance and information architecture class, I was inspired to use the idea of an f-law because they appealed to my contrarian sense of humour and also contained some interesting nuggets of wisdom. I ended up coming up with a heap of f-Laws for SharePoint, and plan to write an article to cover each one.

In the last post, we learnt that f-Law 1 was all about the contention that the more you try and define what governance is, the less anyone will actually understand it. If you never read the first SharePoint Governance f-law then I suggest you do so, because these articles do tend to build on the foundation set from the previous. On that note, the focus of todays f-law extends on one that Ackoff himself came up with. All I am doing it putting a SharePoint bent on it…

F-Law 2: There is no point in asking users, who don’t know what they want, to say what they want.

This f-law comes with an additional corollary: There is even less point in thinking that you already know what they want! (IT departments – I am looking at you here!)

The definitive way to explain this f-law is to leverage the work of one of my mentors – Jeff Conklin. In 2007 I read a paper of his that literally changed my career. It was titled “Wicked problems and social complexity” and despite me reading many papers since, to this day it is one of the best introductions to complex problem solving you could ever read.

In this paper, Jeff talks about the fact that many prevailing methodologies suggest that the best way to work on a problem is to follow an orderly and linear “top-down” process, working from the problem to the solution. You begin by understanding the problem, including gathering and analysing “requirements” from customers or users. Once you have the problem specified and the requirements analysed, you are ready to formulate a solution and eventually implement that solution. This is illustrated by the red line in the figure below.


Now many project managers, cheque signers and just about every program management office I have ever worked with try to operate this way because it promises order, certainty and control. This is understandable when ones performance is being judged on getting stuff done to an agreed time and cost. It is also understandable if you are a manager and will get your ass kicked if you blow your budget. There is only one teeny issue. For some scenarios, it simply does not work.

In Conklin’s paper, he detailed a 1980’s case study at the Microelectronics and Computer Technology Corporation (MCC) that looked into how people solve problems. A number of designers participated in an experiment where they were give a one page problem statement – not too different to many SharePoint business cases I have seen. Participants in the experiment had to design an elevator control system for an office building. Despite participants being experienced and expert integrated-circuit designers, none had ever worked on elevator systems before. Each participant was asked to think out loud while they worked on the problem. The sessions were videotaped and analysed in detail.

Below is what really happened. Check out the green line…


Clearly, the subjects in the elevator experiment did not follow a linear approach. They would start by trying to understand the problem, but they would immediately jump into formulating potential solutions. Then they would jump back up to refining their understanding of the problem. Rather than being orderly and staged like the red line, the line plotting the course of their thinking looked more like a seismograph for an earthquake. Now if you are looking at the green line and thinking “my god I better put a stop to that sort of shenanigans,” consider what Conklin had to say about it in his paper:

These designers are not being irrational. They are not poorly trained or inexperienced. Their thought process was something like: “Let’s see, idle elevators should return to the first floor, but then, you only need one elevator on the first floor, so the others could move to an even distribution among the floors. But the elevators need to be vacuumed regularly. I suppose we could add a switch that brought idle elevators down to the first floor. But then what happens in an emergency?” In other words, what is driving the flow of thought is some marvellous internal drive to make the most headway possible, regardless of where the headway happens, by making opportunity-driven leaps in the focus of attention. It is precisely because these expert designers are being creative and because they are learning rapidly that the trace of their thinking pattern is full of unpredictable leaps.

When I am speaking at conferences I like to mess with project managers in particular (who doesn’t eh?), because they are an easy target and already an insecure lot to begin with. I will ask the audience if anybody has an industry certification, such as a PMP or Prince II. Several hands usually go up. I then point to the phases of the above diagram and ask them if – when they were studying hard to obtain their certification – they actually followed the discrete phases that everybody else is supposed to follow. No single person has ever suggested that they did, instead all acknowledging that their process of learning looked more like the green line. I then point out that I’ve always found this perversely funny that people follow the green line to learn a process that tries to insist that everybody else must follow the red line. Ironic huh?

Knowing vs. learning problems

It should be stated at this point that you can use the red-line approach for certain types of problems so I am not outright dismissing it. In fact, within SharePoint projects there are indeed elements that can work quite well this way. The green line on the other hand, represents a phenomenon that Conklin called “Opportunity driven problem solving” and is the de-facto way we work on problems that are new or novel. For example, if you have ever experienced an “aha” moment, it was probably a leap of cognition that followed the jagged green line up or down, where you suddenly saw the problem in a different light. (Shhhh… don’t let your project manager know because you will have to fill in a form of some description!)

In these types of problems, we do not start by gathering and analysing data about the problem because the problem itself is moving target and varies depending on different stakeholders and their world views. Thus, there is no pure and concrete understanding of “the problem” because it is still forming as you think about solutions. In short, the jagged green line is a picture of learning. Quoting again from Conklin:

The more novel the problem, the more the problem solving process involves learning about the problem domain. In this sense the waterfall is a picture of already knowing – you already know about the problem and its domain, you know about the right process and tools to solve it, and you know what a solution will look like. As much as we might wish it were otherwise, most projects in the knowledge economy operate much more in the realm of learning than already knowing. You still have experts, but it’s no longer possible for them to guide the project down the linear waterfall process. In the current business environment, problem solving and learning are tightly intertwined, and the flow of this learning process is opportunity-driven

I believe that many innovations stem from the opportunity driven, creative leap of faith of the green line. On that note, I’d say that one of the greatest opportunity driven learners had to be Einstein. An article by Mort Orman suggests that Einstein was intrigued by “holes” in prevailing theories and enjoyed posing “mind riddles” to himself, just to see if present theories could satisfactorily explain them. Unlike many others who might have given up when they got stuck, Einstein was persistent and kept at it for 10 years before he came up that little formula everyone knows. After explaining this story at conferences, I sometimes ask people “Do you think Einstein used waterfall when he came up with relativity?” No one has said yes yet…



The pattern of behaviour between the red and green lines represents the difference between a knowing problem and a learning problem. With a knowing problem, the problem is clear to all participants and even though it might require specialist expertise to solve, many of the variables are well understood. But for a problem that is novel or requires learning from participants Conklin’s case study illustrates that:

  1. People will examine potential solutions just to explain the problem.
  2. Each instance of examining the solution will impact the understanding of the problem.

Given that SharePoint is almost always starts out as a learning problem for the majority of participants, I do not see the point in trying to fight that green line. Instead, it is critical that you work with it rather than against it. The difficulty people have with this is that to do so conflicts with that promise of certainty, order and control that the red appears to offer. Why? Well among other things, you have to:

  1. Expect fluid requirements and scope changes
  2. Involve stakeholders from the start (they have to live with the result and their up-take is presumably a key KPI)
  3. Expect resistance and pullback from stakeholders (because people attribute more to what they perceive to lose compared to what they might gain)

Above all, you have to avoid penalising people for their learning. If you put barriers in front of people who are trying to improve their understanding of a multi-faceted problem they will eventually disengage from you. If you want to guarantee this sort of disengagement, go right on ahead and solve some problem before your stakeholders even realise there is a problem. Then when they do realise, smack them with the metaphorical baseball bat known as the scope variation form. One of two of those babies and those annoying stakeholders are guaranteed to go away. A pity your solution will go away with them but hey, it was in scope right?


I deal with this core issue of not penalising learning in a number of ways… some of which I have outlined in blog posts and many that I will cover in detail as we progress in this series and examine more f-laws. If you simply can’t wait for me and want “the answer” then I have news for you. If it were that easy there would be a “best practice” for it and someone would have created a certification by now!

So instead I will give you a couple of KPI’s to work to.

  • KPI 1: You get to a stage where your clients questions are “informed”. It is pretty easy to tell as a SharePoint professional where your stakeholders are at in their understanding of SharePoint. Over time there is a certain level of maturity in the questions asked of you and the way they are asked. This reflects both stakeholder learning as well as your ability to teach. If you get to this stage, you have increased your chances of SharePoint success significantly, which leads onto the next KPI…
  • KPI 2: You get to the stage where your clients are asking you well informed questions that you don’t know the answer to. Trust me that they will not mind that you don’t because their awareness of the product will no longer be naively simplistic anyways. You will also have developed a great collaborative partnership by then too. Also don’t forget my quote from Horst Rittel in the midwives post. There is a symmetry of ignorance with complex problems. The knowledge required to solve a complex problem never resides with a single person.

This leads me onto the final KPI:

  • KPI 3: Your clients should start telling you stuff about SharePoint that they have done that you have never done before or didn’t know you could do. In short, they will start teaching you stuff.

If you can create those conditions, be happy that they don’t need you that much anymore.



Thanks for reading


Paul Culmsee



 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

Why can’t people find stuff on the intranet?–Final summary

Send to Kindle


Those of you who get an RSS feed of this blog might have noticed it was busy over last week. This is because I pushed out 4 blog posts that showed my analysis using IBIS of a detailed linear discussion on LinkedIn. To save people getting lost in the analysis, I thought I’d quickly post a bit of an executive summary from the exercise.

To set context, Issue Mapping is a technique of visually capturing rationale. It is graphically represented using a simple, but powerful, visual structure called IBIS (Issue Based Information System). IBIS allows all elements and rationale of a conversation to be captured in a manner that can be easily reflected upon. Unlike prose, which is linear, the advantage of visually representing argument structure is it helps people to form a better mental model of the nature of a problem or issue. Even better, when captured this way, makes it significantly easier to identify emergent themes or key aspects to an issue.

You can find out all about IBIS and Dialogue Mapping in my new book, at the Cognexus site or the other articles on my blog.

The challenge…

On the Intranet Professionals group on LinkedIn recently, the following question was asked:

What are the main three reasons users cannot find the content they were looking for on intranet?

In all, there were more than 60 responses from various people with some really valuable input. I decided that it might be an interesting experiment to capture this discussion using the IBIS notion to see if it makes it easier for people to understand the depth of the issue/discussion and reach a synthesis of root causes.

I wrote 4 posts, each building on the last, until I had covered the full conversation. For each post, I supplied an analysis of how I created the IBIS map and then exported the maps themselves. You can follow those below:

Part 1 analysis: http://www.cleverworkarounds.com/2012/01/15/why-cant-users-find-stuff-on-the-intranet-in-ibis-synthesispart-1/
Part 2 analysis: http://www.cleverworkarounds.com/2012/01/15/why-cant-users-find-stuff-on-the-intranet-an-ibis-synthesispart-2/
Part 3 analysis: http://www.cleverworkarounds.com/2012/01/16/why-cant-users-find-stuff-on-the-intranet-an-ibis-synthesispart-3/
Part 4 analysis: http://www.cleverworkarounds.com/2012/01/16/why-cant-users-find-stuff-on-the-intranet-an-ibis-synthesispart-4/

Final map: http://www.cleverworkarounds.com/maps/findstuffpart4/Linkedin_Discussion__192168031326631637693.html

For what its worth, the summary of themes from the discussion was that there were 5 main reasons for users not finding what they are looking for on the intranet.

  1. Poor information architecture
  2. Issues with the content itself
  3. People and change aspects
  4. Inadequate governance
  5. Lack of user-centred design

Within these areas or “meta-themes” there were varied sub issues. These are captured in the table below.

Poor information architecture Issues with content People and change aspects Inadequate governance Lack of user-centred design
Vocabulary and labelling issues

· Inconsistent vocabulary and acronyms

· Not using the vocabulary of users

· Documents have no naming convention

Poor navigation

Lack of metadata

· Tagging does not come naturally to employees

Poor structure of data

· Organisation structure focus instead of user task focussed

· The intranet’s lazy over-reliance on search

Old content not deleted

Too much information of little value

Duplicate or “near duplicate” content

Information does not exist or an unrecognisable form

People with different backgrounds, language, education and bias’ all creating content

Too much “hard drive” thinking

People not knowing what they want

Lack of motivation for contributors to make information easier to use

Google inspired inflated expectations on search functionality on intranet

Adopting social media from a hype driven motivation

Lack of governance/training around metadata and tagging

Not regularly reviewing search analytics

Poor and/or low cost search engine is deployed

Search engine is not set up properly or used to full potential

Lack of “before the fact” coordination with business communications and training

Comms and intranet don’t listen and learn from all levels of the business.

Ambiguous, under-resourced or misplaced Intranet ownership

The wrong content is being managed

There are easier alternatives available

Content is structured according to the view of the owners rather than the audience

Not accounting for two types of visitors… task-driven and browse-based

No social aspects to search

Not making the search box available enough

A failure to offer an entry level view

Not accounting for people who do not know what they are looking for versus those who do

Not soliciting feedback from a user on a failed search about what was being looked for

So now you have seen the final output, be sure to visit the maps and analysis and read about the journey on how this table emerged. One thing is for sure, it sure took me a hell of a lot longer to write about it than to actually do it!

Thanks for reading

Paul Culmsee



 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

The end of a journey… my book is now out!

Send to Kindle

About bloody time eh?

The Heretics Guide to Best Practices is now available through Amazon, Barnes and Noble and iUniverse.



In Paul and Kailash I have found kindred spirits who understand how messed up most organizations are, and how urgent it is that organizations discover what Buddhists call ‘expedient means’—not more ‘best practices’ or better change management for the enterprise, but transparent methods and theories that are simple to learn and apply, and that foster organizational intelligence as a natural expression of individual intelligence. This book is a bold step forward on that path, and it has the wonderful quality, like a walk at dawn through a beautiful park, of presenting profound insights with humor, precision, and clarity.”

Jeff Conklin, Director, Cognexus Institute


Hugely enjoyable, deeply reflective, and intensely practical. This book is about weaving human artistry and improvisation, with appropriate methods and technologies, in order to pool collective intelligence and wisdom under pressure.”

Simon Buckingham Shum, Knowledge Media Institute, The Open University, UK.


“This is a terrific piece of work: important, insightful, and very entertaining. Culmsee and Awati have produced a refreshing take on the problems that plague organisations, the problems that plague attempts to fix organisations, and what can be done to make things better. If you’re trying to deal with wicked problems in your organisation, then drop everything and read this book.”

Tim Van Gelder, Principal Consultant, Austhink Consulting


“This book has been a brilliantly fun read. Paul and Kailash interweave forty years of management theory using entertaining and engaging personal stories. These guys know their stuff and demonstrate how it can be used via real world examples. As a long time blogger, lecturer and consultant/practitioner I have always been served well by contrarian approaches, and have sought stories and case studies to understand the reasons why my methods have worked. This book has helped me understand why I have been effective in dealing with complex business problems. Moreover, it has encouraged me to delve into the foundations of various management practices and thus further extend my professional skills.”

Craig Brown, Director, Evaluator

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

More SharePoint Governance, Information Architecture and *Sensemaking* Classes Planned

Send to Kindle

imageHi all

A big chunk of last year had me off under a metaphorical mushroom, putting together several days of courseware on the topic of SharePoint Governance and Information Architecture. My take on these topics are influenced from some odd places, and the course drew on a lot of the non IT work that I do, that involves collaboration on some very complex problems indeed.

In November and December of 2010, we took this “on the road”, so to speak, firstly in Dublin, then London and Sydney. The courses were sold out and feedback was terrific. Here are a few choice quotes (check out the hyperlinks for full reviews)

“Did it meet my expectations? Well I’d have to say that it far exceeded them. There had obviously been a large amount of effort in preparing the courseware and modules. They covered the important missing links currently absent from the Microsoft and traditional training courses” – Wes Hackett.

“I’ve just finished the second day of the SharePoint 2010 Governance and Information Architecture Master Class presented by Paul Culmsee with the support of Andrew Woodward . I can wholeheartedly say it was one of the best courses I’ve attended both in content and presentation style and they deserve a lot of credit for putting together a fantastic course. Paul in particular has put a huge amount of effort into the slidedeck, sample documents and enormous manual (almost 500 pages worth!) let alone all the great additional insight he could provide in person over both days” – Brendan Newell

“Finally …. after 12 years in the IT industry a course which covers some of the fundamental issues governing project success.   This course is a real eye opener and a must for any IT professional involved in project planning and delivery” -  Stephen McWilliams

“I just came back from the best technology training I have had in years: a world-first Microsoft SharePoint Elite Information Architecture course designed and delivered by Paul Culmsee. It has taught me a great deal across ALL facets of the day-to-day work that I do as a SharePoint architect” – Jess Kim

Based on this and similar feedback, we are going to do it again. Locations confirmed so far are London (#SPIAUK), Sydney (#SPIAAU) and Wellington (#SPIANZ) in February and March 2011 and in the pipeline is The Netherlands (#SPIANL) and at least a couple of US cities!

In addition to the unique content on these classes, I am honoured to announce that I am now authorised to teach the official Cognexus Issue Mapping courseware – the only non Cognexus Dialogue Mapping practitioner authorised to do so. As such, we will be running the inaugural Issue Mapping class in London in late February as well (wohoo!)

So, here are the details for each location:

  • (Register now) February 21, 2011, London   #SPIAUK SharePoint Governance and Information Architecture Master Class (Download Flyer)
  • (Register now) February 23, 2011, London #IBISUK Issue Mapping Master Class (Download Flyer)
  • (Register now) March 10, 2011, Sydney  #SPIAAU SharePoint Governance and Information Architecture Master Class (Download Flyer)
  • (Register now)March 14, 2011, Wellington #SPIANZ SharePoint Governance and Information Architecture Master Class (Download Flyer)
  • (Register soon) May 9, 2011, Utrecht, Netherlands (watch this space)
  • Wondering what to expect in these classes? Read on!

     SharePoint Governance and Information Architecture Master Class. 2 full days of real world, examples knowledge and techniques

    Most people understand that deploying SharePoint is much more than getting it installed. Despite this, current SharePoint governance documentation abounds in service delivery aspects. However, just because your system is rock solid, stable, well documented and governed through good process, there is absolutely no guarantee of success. Similarly, if Information Architecture for SharePoint was as easy as putting together lists, libraries and metadata the right way, then why doesn’t Microsoft publish the obvious best practices?

    In fact, the secret to a successful SharePoint project is an area that the governance documentation barely touches.

    This master class pinpoints the critical success factors for SharePoint governance and Information Architecture and rectifies this blind spot. Paul‘s style takes an ironic and subversive take on how SharePoint governance really works within organisations, while presenting a model and the tools necessary get it right.

    Drawing on inspiration from many diverse sources, disciplines and case studies, Paul has distilled the “what” and “how” of governance down a simple and accessible, yet rigorous and comprehensive set of tools and methods that organisations large and small can utilise to achieve the level of commitment required to see SharePoint become successful.

    Master class aims:

    • Present SharePoint governance and Information Architecture in a new light – focus on the “blind spots” where the current published material is inadequate
    • Cover lessons learned from Paul’s non IT work as a facilitator and sensemaker in complex large scale projects
    • Examine the latest trends in the information landscape for industry and government and review studies that inform governance and Information Architecture efforts
    • Present an alternative approach to business-as-usual SharePoint governance planning that focuses on real collaboration
    • Provide quality information that is rigorous yet accessible, entertaining and interesting

    Master class outcomes:

    • Understand the SharePoint governance lens beyond an IT service delivery focus
    • Develop your ‘wicked problem’ radar and apply appropriate governance practices, tools and techniques accordingly
    • Learn how to align SharePoint projects to broad organisational goals, avoid chasing platitudes and ensure that the problem being solved is the right problem
    • Learn how to account for cognitive bias and utilise tools and techniques that help stakeholders align to a common vision
    • Understand the relationship between governance and assurance, why both are needed and how they affect innovation and user engagement
    • Understand the underlying, often hidden forces of organisational chaos that underpins projects like SharePoint
    • Understand the key challenges and opportunities that SharePoint presents for Information Architecture
    • Learn how to document your information architecture
    • Practical knowledge: Add lots more tools to your governance and IA toolkit!

    Course Structure: The course is split into 7 modules, run across the two days.

    Module 1: SharePoint Governance f-Laws 1-17:

    Module 1 is all about setting context in the form of clearing some misconceptions about the often muddy topic of SharePoint governance. This module sheds some light onto these less visible SharePoint governance factors in the form of Governance f-Laws, which will also help to provide the context for the rest of this course

    • Why users don’t know what they want
    • The danger of platitudes
    • Why IT doesn’t get it
    • The adaptive challenge – how to govern SharePoint for the hidden organisation
    • The true forces of organisational chaos
    • Wicked problems and how to spot them
    • The myth of best practices and how to determine when a “practice” is really best

    Module 2: The Shared Understanding Toolkit – part 1:

    Module 2 pinpoints the SharePoint governance blind spot and introduces the Seven Sigma Shared Understanding Toolkit to counter it. The toolkit is a suite of tools, patterns and practices that can be used to improve SharePoint outcomes. This module builds upon the f-laws of module 1 and specifically examines the “what” and “why” questions of SharePoint Governance. Areas covered include how to identify particular types of problems, how to align the diverse goals of stakeholders, leverage problem structuring methods and constructing a solid business case.

    Module 3: The Shared Understanding Toolkit – part 2:

    Module 3 continues the Seven Sigma Shared Understanding Toolkit, and focuses on the foundation of “what” and “why” by examining the “who” and “how”. Areas covered include aligning stakeholder expectations, priorities and focus areas and building this alignment into a governance structure and written governance plan that actually make sense and that people will read. We round off by examining user engagement/stakeholder communication and training strategy.

    Module 4: Information Architecture trends, lessons learned and key SharePoint challenges

    Module 4 examines the hidden costs of poor information management practices, as well as some of the trends that are impacting on Information Architecture and the strategic direction of Microsoft as it develops the SharePoint road map. We will also examine the results from what other organisations have attempted and their lessons learned. We then distil those lessons learned into some the fundamental tenants of modern information architecture and finish off by examining the key SharePoint challenges from a technical, strategic and organisational viewpoint.

    Module 5: Information organisation and facets of collaboration

    Module 5 dives deeper into the core Information Architecture topics of information structure and organisation. We explore the various facets of enterprise collaboration and identify common Information Architecture mistakes and the strategies to avoid making them.

    Module 6: Information Seeking, Search and metadata.

    Module 6 examines the factors that affect how users seek information and how they manifest in terms of patterns of use. Building upon the facets of collaboration of module 5, we examine several strategies to improving SharePoint search and navigation. We then turn our attention to taxonomy and metadata, and what SharePoint 2010 has to offer in terms of managed metadata

    Module 7: Shared understanding and visual representation – documenting your Information Architecture

    Module 7 returns to the theme of governance in the sense of communicating your information architecture through visual or written form. To achieve shared understanding among participants, we need to document our designs in various forms for various audiences.

    Putting it all together: From vision to execution

    As a take home, we will also supply a USB stick for attendees with a sample performance framework, governance plan, SharePoint ROI calculator (Spreadsheet), sample mind maps of Information Architecture. These tools are the result of years of continual development and refinement “out in the field” and until now have never been released to the public.

    Note: The workshop sessions will be hands on, we provide all of the tools and samples needed but please bring your own laptop.

    Issue Mapping Master Class. Your path towards shared understanding and shared commitment

    “Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them.” Laurence J. Peter

    Presented by: Paul Culmsee

    Courseware by: Cognexus Institute and Seven Sigma

    “Not another $#%@*$ meeting!”

    All of us have felt the frustration of walking from yet another unproductive meeting, wondering where the agenda went. Yet, as problems become more complex, meetings are still the place where critical strategic decisions are made.


    What is Issue Mapping?

    Issue-Based Information Systems (IBIS) is a sense-making framework used to support group discussions to assist all involved to come to a shared understanding. It visually maps participants’ points of views, problems voiced, the rationale and reasons leading up to decision(s). The maps can be easily read and understood by everyone, even by those not part of the discussion group.

    Why Issue Mapping?

    • Maps detailed rationale behind decision-making as well as the decision; maps the thinking process of the group
    • Concentrates on pros and cons to an idea, encourages and explores all views, taking the sting out of differences
    • Represents and clarifies diverse points of views, conflicting interpretations and goals, inconsistent information and other forms of complexity
    • Everyone gets a chance to speak, if they want. People are heard and contributions are acknowledged. Interruptions, repetition and dominance of the loudest decreases
    • Keeps participants on topic because they can visually see the progress of the discussion
    • Keeps everyone’s attention
    • Meeting progress/result can be seen
    • Map helps participants come up with ideas/arguments
    • Visual display of progress to review summary if need so the brain can absorb the bigger picture and appreciate the validity and value of a larger perspective
    • Avoids jumping to easy answers or superficial conclusions
    • Promotes deeper reasoning, rigor and even wisdom
    • Everyone can visually see everything discussed- leaves no room for misunderstandings
    • Documents can easily be attached to map to back up ideas
    • Participants can see effectiveness of mapping and genuine will try to make it more productive

    About Seven Sigma

    Issue Mapping is a life skill that can be applied to many different problem domains and scenarios. Participants will gain proficiency in a craft that can be applied long into the future, to help them and others bring clarity and convergence to the management of complex problems. At Seven Sigma, we practice Issue and Dialogue Mapping routinely and this has brought us many satisfied clients. The Mapping in itself is part of the ‘secret sauce’ that makes Seven Sigma’s reputation renowned.

    Seven Sigma Business Solutions is the only recognised designated partner of Cognexus Institute, founder of the art of Issue Mapping, in the world. We recognise that without reaching shared understanding, you will find yourself at yet another meeting, rehashing the same unresolved problems, listening to the same arguments month after month. Or, if a decision has been made, it has not been followed up to fruition due to lack of commitment/buy-in.

    We are proud to be part of your journey towards shared understanding and shared commitment.

    Master Class aims and outcomes:

    • Be able to create great maps – issue maps that are clear, coherent, and inviting
    • Immediately start using Issue Mapping effectively in your work and life; the class will focus on practical experience and map building
    • Command a rich range of options for publishing and sharing maps
    • Lead with maps: create direction, momentum, and energy with issue maps
    • Quickly and effectively do critical analysis in dynamic situations
    • Organize unstructured information and discover patterns and connections within it
    • Make critical thinking visible for inspection and analysis
    • Recognise early, the symptoms of wicked problems and the forces behind group divergence
    • Recognise the importance of capturing the rationale behind decisions, as well as the decisions themselves
    • Rethink the traditional approach to meetings and decision making
    • Start capturing the rationale leading up to the decisions by using IBIS and Compendium software

    It will also give you a deeper understanding of:

    • The fundamentals of IBIS and Compendium
    • The structural patterns that give clarity and power to issue maps
    • How decision rationale is represented in a map

    This master class will be hands on – please bring your own laptop with Compendium software (freeware) installed.

    Duration: 2 days, with homework after the first day

    Audience: For both IT and non-IT audience; those involved in highly complex projects including leaders, consultants, facilitators, organisational development professionals, change agents, managers and engineers.

    Prerequisite: An open mind geared for shared understanding and shared commitment

     Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

    No Tags

    Send to Kindle

    Dialogue Mapping: The Ying to SharePoint Yang

    Send to Kindle

    I don’t know about you, but as a SharePoint practitioner, I love the fact that I do not do SharePoint full-time anymore. I’d like to take some time to explain why this is the case, and how my non IT work helps me be a better SharePoint practitioner. To do so, I will talk about a recent non IT project I worked on. Who knows? This may give you some insights into how you view and approach collaborative work.

    Western Australia is BIG

    File:Kimberley region of western australia.JPGIn case you don’t know already, I live in Perth, Western Australia. You can see Perth if you squint at the map on your left and look to the south west area.

    Western Australia is a bloody big land area and extremely isolated. One claim to fame about living in Perth is its distinction for being one of the most isolated cities in the world. In fact we has a population density is on par with Mongolia (this is dead-set true – I researched this fact). Of the 2.2 million people that live in the state, 1.8 million live in the Perth metropolitan area and the rest are scattered far and wide. In terms of distribution, there are no other major cities in Western Australia. The next most populated town outside of Perth is Mandurah with some 83,000 people. 

    In the north of Western Australia, these towns are often separated by anywhere from a couple hundred to more than a thousand kilometres. The weather is very hot, the landscape is breathtakingly beautiful and the isolation here is hard to comprehend without visiting. The wealth of Western Australia (“GFC? What GFC?”) comes from the north of this vast state, via huge mineral deposits that China seems happy to buy from us, which in turn keep me and my colleagues busy putting in SharePoint around the place.

    Now if you think Western Australia is big, get this: The Kimberley region of Western Australia (the top section marked in red) is almost as big as the entire country of Germany. For American readers, it alone is three fifths the size of Texas. For all that space, only around 45000-50000 people live there.

    These wide distances create all sorts of challenges. At a most basic level, think about the cost of basic services to such a remote location with such a small population density. Cost of living is high and services like health care are always stretched and people living here have to accept that they will never be able to enjoy the same level of service enjoyed by their city slicker cousins.

    Now that I have painted that picture in your mind, let me intersect that with one of Australia’s biggest wicked problems. The indigenous people’s of Australia have many social and health issues that have had a massive human cost to them. We are talking chronic alcoholism, physical and sexual abuse, depression, suicide and the whole range of mental illnesses. Families and communities tear themselves apart in a seemingly an endless negatively reinforcing cycle. Like many indigenous groups around the world, intervention approaches from earlier periods have had catastrophic long term consequences that were never considered at the time (a classic wicked problem characteristic). When you read the stories about the stolen generations, you cannot help but be deeply moved by the long term effects, the damage done and the sad legacy left behind.

    Continue reading

     Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

    No Tags

    Send to Kindle

    SharePoint, Debategraph and Copenhagen 2009 – Collaboration on a global scale

    Send to Kindle

    Note: For those of you who do not wish to read my usual verbose writing, then skip to the last section where there is a free web part to download and try out.

    Unless you are a complete SharePoint nerd and world events don’t interest you while you spend your hours in a darkened room playing with the SP2010 beta, you would no doubt be aware that one of the most significant collaborative events in the world is currently taking place.

    The United Nations climate change conference in Copenhagen this month is one of the most important world gatherings of our time. You might wonder why, as a SharePoint centric blog, I am writing about this. The simple answer is that this conference in which the world will come together to negotiate and agree on one of the toughest wicked problems of our time. How to tackle international climate change in a coordinated global way. As I write this, things do not seem to be going so well :-(.


    Climate change cuts to the heart of the wellbeing expected by every one of us. Whether you live in an affluent country or a developing nation, the stakes are high and the issues at hand are incredibly complex and tightly intertwined. It might all seem far away and out of sight/out of mind, but it is clear that we will all be affected by the outcomes for better and worse. The spectre of the diminishing window of opportunity to deal with this issue means that an unprecedented scale of international cooperation will be required to produce an outcome that can satisfy all stakeholders in an environmentally, economically and social bottom line.

    Can it be done? For readers who are practitioners of SharePoint solutions, you should have an appreciation of the difficulty that a supposedly “collaborative tool” actually is to improve collaboration. Therefore, I want you to imagine your most difficult, dysfunctional project that you have ever encountered and just try and now multiply it by a million, gazzilion times. If there are ever lessons to be learned about effective collaboration among a large, diverse group on a hugely difficult issue, then surely it is this issue and this event.

    Our contribution

    My colleagues and I became interested in sense-making and collaboration on wicked problems some time back, and through the craft of Dialogue Mapping, we have had the opportunity to help diverse groups successfully work through some very challenging local issues. I need to make it clear that much of what we do in this area is far beyond SharePoint in terms of project difficulty, and in fact we often deal with non IT projects and problems that have significant social complexity.

    Working with people like city planners, organisational psychologists, environmental scientists and community leaders to name a few, has rubbed off on myself and my colleagues. Through the sense-making process that we practice with these groups, we have started to see a glimpse of the world through their eyes. For me in particular, it has challenged my values, social conscience and changed the entire trajectory of where I thought my career would go. I feel that the experience has made me a much better practitioner of collaborative tools like SharePoint and I am a textbook case of the the notion that the key to improving in your own discipline, is to learn from people outside of it.

    We have now become part of a global sense-making community, much like the global SharePoint community in a way. A group of diverse people that come together via common interest. To that end, my colleague at Seven Sigma, Chris Tomich has embarked on a wonderful initiative that I hope you may find of interest. He has enlisted the help of several world renowned sense-makers, such as Jeff Conklin of Cognexus and David Price of Debategraph, and created a site, http://www.copenhagensummitmap.org/, where we will attempt to create a global issue map of the various sessions and talks at the Copenhagen summit. The aim of this exercise is to try and help interested people cut through the fog of issues and understand the points of view of the participants. We are utilising IBIS, the grammar behind dialogue mapping, and the DebateGraph tool for the shared display.


    How you can help

    If you feel that issue mapping is for you, then I encourage you to sign up to Debategraph and help contribute to the Copenhagen debate by mapping the dialogue of the online sessions (which you can view from the site).

    Otherwise, Chris has written a simple, free web part, specifically for Copenhagen which can be downloaded “Mapping tools” section of the Copenhagen site. The idea is that if you or your organisation wish to keep up with the latest information from the conference, then installing this web part onto your site, will allow all of your staff to see the Copenhagen debate unfold live via your SharePoint portal. Given that SharePoint is particularly powerful at surfacing data for business intelligence, think of this web part as a means to display global intelligence (or lack thereof, depending on your political view 🙂 ).

    Installing is the usual process for a SharePoint solution file. Add the solution to central admin, deploy it to your web application of choice and then activate the site collection scoped feature called “Seven Sigma Debategraph Components”. The web part will be then available to add to a page layout or web part page.


    The properties of this web part allow you some fine grained control over how the Debategraph map renders inside SharePoint. The default is to show the Debategraph stream view, which is a twitter style view of the recent updates as shown in the example below.


    Stream view is not the only view available. Detail view is also very useful for rationale that has supplementary information, as shown in the example below.


    By the way, you can use this web part to display any Debategraph debate – not just Copenhagen. The Debategraph map to display is also controlled via the web part properties.

    For information on how to change the default map, then check out this webcast I recorded for the previous version here.

    I hope that some of you find this web part of use and look forward to any feedback.


    Kind regards


    Paul Culmsee


     Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

    No Tags

    Send to Kindle

    The practice of Dialogue Mapping – Part 3

    This entry is part 3 of 4 in the series DM
    Send to Kindle

    Hi there and welcome to part 3 of my series on the practice of Dialogue Mapping in the real-world. To recap, in part 1, I provided a brief overview of Dialogue Mapping and in part 2, I described a common real world usage scenario that we perform fairly often as SharePoint consultants.

    The rest of this series will change tack a little. In this article I am going to describe a very different Dialogue Mapping scenario to you. This was a huge challenge and a large leap from what I described in part 2. There were some wonderful lessons learned from this work which I will cover off here.

    The most “wicked” problems are not technical

    My first Dialogue Mapping gig where I was not a subject matter expert also happened to be a real baptism of fire. Here was a problem that I had no understanding of, no discipline knowledge and no sense of background history of the project, the dynamics of the group, nor any idea of the positions of stakeholders on the problem.

    By this time my IBIS fluency was pretty much down and I felt very confident with the usage of Compendium. I had not yet travelled to the USA yet to train under Jeff Conklin directly, but I carried his book around with me, and had read it many times over. I had performed Dialogue Mapping many times, however until this point all the projects or subjects that I was involved in I knew a lot about. This time I felt very vulnerable. Your domain knowledge is a form of armour, and it was unsettling to know that you’re going in stark naked. I was intimidated, yet excited at the same time.

    So imagine this scenario. There was myself, a facilitator, and *fifteen* strangers sitting across from me. This was double the group numbers of the typical IT scenarios I had previously mapped. I remember emailing Jeff for advice when I heard that there would be so many and I recall him saying that 15 was a lot of people for a newbie. What was I in for! 🙂

    Little did I know at the time that this group had been meeting for quite some time before that, but were really struggling on a complex urban planning issue. When I say complex, I mean complex in a social way, rather than technical. Interestingly, the issue was not a technically complicated issue at all. Anybody could have sat in the room and understood most of the dialogue (not necessarily the full context but you would not be completely blinded by science). What made this particular issue complex was the fact that the group members came from several different organisations, representing some quite diametrically opposing viewpoints. In part 2, I wrote about how it was hard enough just to get one IT department to come to the party and that was just one department of a single organisation – sheesh! If you have complained about organisational silos and think it is hard enough to get some degree of consensus within the realm of one organisation, imagine it when over a dozen representatives from different organisations are involved, organisations that straddle the full spectrum of public and private sectors, as well as the community.

    There were simply so many stakeholders and interconnected issues that it was very hard to not get bogged down into tangents, repetition and frustration. Now, imagine eighteen months of this environment and the stressful social complexity impacts.

    This is a long-term project that I am still involved with, so I will not be taking you through the specific details of this project just yet. Rest assured though, it has been such a great experience that I will write about it in detail in the future. For now, I will focus on lessons learnt so that others aspiring to perform this craft can learn from my own experiences.

    People often tell you the best way to learn is to dive right in, and Dialogue Mapping is no exception. No sooner than I had put up a “what should we do…” type root question, it didn’t take long for debate to get … shall we say … rigorous! So I will go over some of the key lessons that I learnt from this experience thus far.

    Lesson One: Confidence and assertiveness

    The first thing that I had to contend with was not being in control of the conversation to the same extent as before. As previously stated, with SharePoint workshops I tend to direct the flow of the workshop as a mapper and as a subject matter expert. But this scenario was very different. I didn’t know the topic area at all and therefore some of the terms and acronyms made no sense to me. Also being new and unused to the decorum of the group, I erred on what I thought was politeness, rather than annoy the group by being direct and at times, interrupting them.

    This, in my opinion, is a mistake and does a disservice to the other participants. It is also probably the most common thing a newbie mapper will experience when starting out, especially with a new group. As a result, the mapping in this first workshop ebbed and flowed. There were a few times where I was mapping the conversation really well, and the participants really engaged with the argumentation as it unfolded on the screen before them. Participants gestured to the map and asked me to add additional arguments and issues to what had already been built there. I could literally hear some of the initially sceptical, suddenly have that magic moment where they see it working. But at other times, during, say a particularly contentious issue, the conversation would fly at a rapid rate of knots. With so many people in the room, many wanted to have their say on these topics. This led to:

    1. Side conversations started up
    2. Some participants looked away from the map, and started debating directly to each other

    As soon as one of these happened, and especially with the latter, I, as the Mapper, had no hope of following the conversation. As you might expect, I would lose focus and the quality of what was captured suffered (hence lots of idea nodes with no connections to anything). The focussing power of the map would be diminished and the wheels would start to fall off.

    So remember this above all else. No matter what you do, you must be confident and assertive from the very start to keep the group focussed on the map. Don’t be afraid to interrupt someone to clarify a point, or pause them before they go too fast. If someone else starts to interject, interject back and make it clear that you will get to them as soon as you have finished capturing what someone else has said.

    Here is the other critical thing: You must be consistent. It is the first ten to twenty minutes that will set the tone for the rest of the session. This is where people will implicitly learn the decorum of a Dialogue Mapping session and know what to expect. Your actions as a mapper, during this period, is critical to the overall quality of the session. Start it well and it will generally end well.

    Jeff Conklin, of course, offers advice for this in his wonderful book on how to dealing with this. But of course, in the heat of dialogue, all of that advice goes straight out the window as you struggle to keep up with the rapid fire dialogue heading your way. Reading about how one should dialogue map is one thing, doing it is another. This is why I call Dialogue Mapping a craft and leads me to my second lesson learned.

    Lesson Two: Remember that one guitar lesson you had? (Be realistic)

    I think just about everybody at one point has had romantic notions of being a rock guitarist, banging out the blues like Clapton or blistering solos like Kirk Hammett or Brian May. A surprisingly large number of people have actually bought a guitar at some stage in their lives and have tried to live the dream. Most give it up once they find that the gap between their ability to play a G chord and their dream of playing the solo to Hotel California stretches to the moon and back. Inevitably, many guitars ends up collecting dust in the attic, along with the home gym set and many other items that were bought from late night infomercials.

    You will hit this with Dialogue Mapping. Remember that wicked problems breed social complexity. Some problems may have some stakeholders with diametrically opposed views and discussion can be quite heated. The romantic notion of your group suddenly solving their wicked problem from your wonderful dialogue mapping has to be viewed with the reality that you still have to learn the G chord and audience can be fickle.

    Thus, as far as audiences go, don’t go playing a stadium gig until you feel that you can handle sitting in the corner of a local bar or the school disco. In other words, start small and work your way up. A small, successful meeting will help you develop your style, confidence and then empower you to take on larger groups.

    As Ali-G would say, keep it real.

    Lesson Three: Stick to your domain of knowledge (at first)

    This is a logical extension of lesson two, and also a tricky one because it can be just as much of a worst practice as a best one. This I suspect is probably a lesson on where Jeff Conklin or other dialogue mappers may disagree with me. One of the transitions that you have to make as a mapper is to move from what I would call Issue Mapping to real Dialogue Mapping. Just because you are doing mapping in front of a group, doesn’t actually mean you are necessarily “dialogue” mapping. Dialogue Mapping is often called “Issue Mapping with facilitation”, and when you work within your domain of expertise and you are a mapper as well as participant. Therefore you are not an impartial facilitator. This is the situation I described in part 2 and discovered very quickly, that pure dialogue mapping was much harder and mentally tougher.

    But in terms of developing your skills, you will have good results when you are working in an area that you know well. You don’t have to worry about the meaning of acronyms and half of the questions you have likely heard before anyway. Remember though, that in a way it is kind of cheating because you are in effect, using the craft to get people to confront questions that you want answered. But it is an important stepping stone and will help you master lesson 4.

    Lesson Four: IBIS grammar in the reptile brain

    IBIS is the grammar that you use to map discourse. When mapping rapid-fire contributions from a group of people, they do not want to sit and wait for you to mull over whether their statement was an idea followed by a pro or an inferred question with an idea. If you find yourself having to do this, it is like trying to play a song on guitar and having to consciously think about how to play that G chord. Just think about how much you’d enjoy a Metallica concert if James Hetfield stopped every minute or so on a hard bit of a song and said “Wait, wait.. I’ve done this before… ok, hang on…oops, sorry”. This translation needs to burn itself into your reptile brain so that the process is as automatic as possible. To do this, you need to initially not worry about getting up in front of a group. As Conklin suggests in his book, listen to interviews on the radio or take an article, pull out its main points and create an IBIS map for it. There are a zillion ways to do this.

    For all of you SharePoint people, a really excellent, highly relevant way of practice that I use, is to sit in the audience of a presentation at SharePoint Saturday or a conference and issue map the presentation. Below is a sample of some of the sessions where I have done this and the image after that demonstrates how much rationale I captured in the “NZ Web Standards and SharePoint” session.

    image   image

    Another great way to learn is to send one of your maps to an IBIS practitioner and let them pull it to bits. Even those of us who have done this for a while need that constant reinforcement and feedback. Like any grammar, different things can be written in different ways and one person’s IBIS will not always look like someone else’s. (There is another blog post in the works that will show this in a funny way). At various times I have sent maps to Conklin for constructive feedback (and then ducked for cover! – hehe)

    Finally, if you are serious about this and like what you are reading, then do what I did – the 5 week Issue Mapping webinar based workshops that Jeff Conklin runs, or if you are in Australia and want something local, then contact me for a half or full-day in-house Issue Mapping intro workshop. Both will not teach you to dialogue map, but by the end of them you will dream in IBIS 🙂

    Lesson Five: IBIS translation in the reptile brain

    Once the language of IBIS is familiar to you, you can take any argumentation and form a consistent IBIS map. You then have to learn how to listen very carefully because that is half the art. Now you have to take prose and pontification by participants and somehow unpack the points made, articulate them into a summary, and form an IBIS based model in your head, and then commit it to the map.

    This can be hard – very hard, and it is nigh on impossible to do without applying what I told you in lesson one. A dialogue mapper is not superhuman and does not have photographic memory. The skill you are developing here is one where you pick out the IBIS elements of some dialogue quickly, as well as knowing when to interject to make sure you do not miss anything.

    A great example of this working is when someone has stated something, and although I cannot remember all points, I know that there was a question and three ideas offered. I might pause the conversation before it goes too far and say something like “Ah, that was important and I need to get this right. I heard you say three things there. You questioned the idea of X, and you offered an answer with 3 pros. One was Y, and what were the other two again?”

    Conklin explains meeting discourse and question types in his book and the aforementioned workshop in a lot of detail. But once again, to apply it to a real-world situation can only be done by practice (and more practice). The absolute best way to do this is to watch an experienced dialogue mapper perform this and look at how they handle the situation, which brings me onto lesson six.

    Lesson Six: Observe

    One of the most enjoyable training experiences of my career was to travel to the picturesque town of Annapolis and learn dialogue mapping from Jeff Conklin himself. Up until then, I had been practicing the craft, but after those two days, I returned as a much better practitioner.

    The single most important part of the time spent there was when we, the students, dialogue mapped each other as we discussed a real-world issue. We each sat in the hot seat for fifteen minutes or so, trying to map the discussion. We were all being completely evil, deliberately starting side conversations, interrupting and interjecting, playing the role of the dominant type A style participant, jumping all over the place and, overall, just being as difficult as we could.

    Unsurprisingly, we all sucked big time trying to dialogue map this. However, when Conklin took the floor, we then saw how exactly Dialogue Mapping was done and what twenty years of practice does. He effortlessly brushed off our attempts to trip him up by observing all of the lessons that I have thus far described, but also with some subtle tricks that we didn’t even notice until he told us afterwards.

    After Conklin had wiped the floor with us, so to speak, we all got to have another crack at it, with the benefit of observation and hindsight. This time the difference was significant in our performance and the way that we each handled the “mob”.

    Moral? The very best thing you can do is to be involved in a Dialogue Mapping session where it has been done well. Watch carefully what the mapper is doing and how they are conducting themselves and the process.

    Lesson Seven: It will make you tired

    If you think of all the various things that you have to do simultaneously (for examples listening, understanding, mapping, and managing the group) during Dialogue Mapping, it is amazing that anyone with a Y chromosome can manage it, given that men usually cannot multitask at all. (Case in point: If sport is on the radio and my wife is speaking to me, one of them has to be switched off…Sorry honey 🙂 ).

    When you are first learning this craft and you are going to be up in front of a group, plan for only an hour or so. While you have to think quite consciously about things, it will exhaust you even more. Once things become more automatic, you can go for longer. From my own experience, the limit for Dialogue Mapping a big group on a really wicked topic would be about four hours at the absolute maximum. (Usually by then the participants also need to take a break and sleep on it anyway).

    Some sessions can be intense, and you, as a mapper, need to be switched on for that entire time. You are listening carefully to every person speak because you are trying to form it into IBIS. So unlike everybody else who can sit there and look interested, yet be mentally switched off, you have to be interested by definition.

    One thing about this is that, while you are in the zone, you don’t need coffee. When mapping, you have enough endorphins racing around your system to keep quite alert, but as soon as there is a break, you can find that you will feel quite tired at times, and a well timed coffee can be very handy (real coffee, of course – none of that instant junk!)

    The one thing that compensates for what Dialogue Mapping can take out of you mentally, is that exhilarating experience when the group is really getting into the process and the positive feedback that you receive when a really well formed map has been developed.

    Lesson Eight: Learn to love “transclusions” and CTRL+R

    I thought that I would drop in a left-field lesson learned at this point that is still very important.

    Trans-what? Don’t worry – I don’t know why they called it that either. Ted Nelson, who also coined the term “hypertext”, came up with the name but I think the day “transclusion” sprung to mind, he was having an off-day. I asked Conklin what it meant and he said “It’s technically accurate … an "inclusion" of material *across* (‘trans’) several documents”. When I whined about the geekiness of the name he added “There was a time when the word "hypertext" was a wacko term for geeks, you know”. Damn! He’s got me there.

    My explanation that will suffice for now? Transclusions is a fancy way of describing the process of breaking your big map up into smaller, linked up sub-maps. I have also heard it referred to as chunking, and when maps get too big, this is a necessity. (For the hypertext nerds that is somewhat incomplete but suffices for this point).

    The compendium software that I choose to use for this work also has a great feature in it. Your map is re-drawn automatically when you hold down the control key and press R. I am now in the habit that after entering a node or three, I redraw the map via this method to keep it all looking orderly. That way, if there has been a lot of dialogue captured, you do not end up with a messy, cluttered map that participants find hard to follow. Like lesson number three and four, stopping conversation while you refactor a messy map will cost you group momentum so ideally if you have gotten into the Control+R habit, all you have to do is a quick transclusion at an opportune time.

    The best time to perform a map transclusion is when a thread of discussion has been exhausted and the group has moved onto a new idea or area in the map. A trick I learned from Anapolis was to sit up and say something like “Okay, let’s just pause for a minute.” (Holding up my hand), congratulate the group on the quality of what they have captured and then say something like “Let’s just put this stuff into its own pigeonhole, so we can now focus on X idea”.

    Lesson Nine: Nurture the holding environment

    Okay, so if there is to be one big serious lesson learned, it is this one. To make the point, I am going to quote Heifetz and Linsky from their excellent book Leadership on the Line. You can read a PDF press release here, specifically the section entitled “Control the temperature.”

    Changing the status quo generates tension and produces heat by surfacing hidden conflicts and challenging organizational culture. It’s a deep and natural human impulse to seek order and calm, and organizations and communities can tolerate only so much distress before recoiling.

    If you try to stimulate deep change, you have to control the temperature. There are really two tasks involved. The first is to raise the heat enough that people sit up, pay attention, and deal with the real threats and challenges facing them. Without some distress, there is no incentive for them to change anything. The second is to lower the temperature when necessary to reduce a counterproductive level of tension. Any community can only take so much pressure before it becomes either immobilized or spins out of control. The heat must stay within a tolerable range—not so high that people demand it be turned off completely, and not so low that they are lulled into inactivity.

    Heifetz and Linsky talk about maintaining the “the productive range of distress” but I have heard many metaphors like this. Another I like is “creative abrasion”, coined by Leonard and Swap in their excellent book When Sparks Fly . Both are essentially talking about making the whole environment conducive to getting the best out of the participants.

    The key takeaway is this: Each group is different and each situation is different. In the normal discourse of the meeting, there will be times where the group works together in almost perfect unison and times where one wrong word will destroy that balance and require the group to stop, reset things and move forward. This is not about IBIS either. The fact is that over time, a particular pattern will emerge in the decorum of the sessions, where conducting the sessions or approaching the mapping in a particular way, will work consistently well for the group.

    Let me give you a classic example that was absolute genius on the part of my client who did exactly this. Before Dialogue Mapping for a group of concerned residents who were facing the prospect of significant change to the amenity of their homes, a bus was hired and the residents were taken to an area where a similar urban transformation had been made ten years before. We all walked around the area for an hour, soaking in the vibe, learning about the history of the area, how the area was redeveloped and how certain planning challenges were overcome.

    This allowed the participants to get a real sense of the issues they needed to confront, and they felt it with all senses, sight, sound and tactile, rather than some cold, rather detached room with a projected map on the wall. Later, when I dialogue mapped the session after the bus tour, the group did a fantastic job and the quality of the rationale that was captured was much richer and faster, through that sensory immersion that took place before the mapping process began.

    So just remember, Dialogue Mapping is a great holding environment in the sense that Heifetz and Linsky talk about. It is a wonderful “rich container”, as Conklin puts it, for fostering and maintaining creative abrasion. But as the bus ride example shows, there is a lot of things that you can combine with it to enhance the experience further.

    More examples like this will be covered in part 4 of this series.

    Thanks for reading

    Paul Culmsee


     Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

    No Tags

    Send to Kindle

    The practice of Dialogue Mapping – Part 1

    This entry is part 1 of 4 in the series DM
    Send to Kindle


    For those who do not regularly read CleverworkArounds, I have a bit of a split career-personality where half my working life is spent as a SharePoint practitioner and the other half as a sort of facilitator, based around the craft of dialogue mapping. This series of articles will delve a little deeper into dialogue mapping and how I have used it.

    I previously introduced the topic of IBIS and Issue Mapping to a SharePoint audience in the “One best practice” series of posts. That series of posts focussed on the issue mapping side of things because it dissected a debate that had already taken place (Joel’s ‘Just say “no” to site definitions’). While this is an effective demonstration of the way that IBIS can break down a seemingly complex argument into more easily digested chunks, I never really wrote about the craft of dialogue mapping, which is a much more difficult, mentally exhausting, yet ultimately fulfilling practice.

    Now I have to tell you, as an IT consultant who has managed to not get *too* messed-up over the last 20 years, I don’t get too intimidated with IT these days. But first time dialogue mapping for a group of stakeholders on a non IT project, where I had no buy in to that project, and my sole purpose was to craft a good issue map to help them work through their complex issue, I was so nervous that I couldn’t sleep the night before.

    So first up, let’s clear up the terms I using so that we are all on the same page.

    • IBIS: The grammar that is used to create an issue map. When I talk about issues, ideas, pros and cons, I am describing the elements of IBIS grammar. You can read about this elsewhere on my blog, my mentor, Jeff Conklin or the amazing work by Kailash Awati.
    • Issue mapping: The craft of creating an map based on IBIS notation. Some examples are in this article.
    • Dialogue Mapping: The facilitation process where a facilitator works with a group to create an issue map and translate discussion into Issue Maps.

    Why dialogue mapping?

    If you have ever uttered the cliché “They don’t know what they want”, then you have your answer. Many problems are rather difficult to define and pin down because, even to define them, requires you to think about possible solutions to the problem. Based on our experience, values (and DNA), we will form our own interpretations of the problem space and then spend considerable time “fumbling around” when working with the rest of the group to clearly articulate our understanding to others, only to find that our understanding is not universal. Disagreements, therefore, are inevitable and are amplified by the sheer number of stakeholders, the fluidity of the problem space and the constraints around the problem, such as a time deadline. This has a way of making life unpleasant and stressful; a situation nobody particularly enjoys.

    People deal with this in different ways. For many, the natural reflex to this situation is avoidance – to try and return to the “business-as-usual” or status quo that existed before. True believers may don the boxing gloves and spar for a few rounds with other true believers. Some may become the ninja, invisible and striking silently. Either way, this sort of chaos that represents organisational pain is fairly familiar to most.

    Now, there are many methods that you can use to remedy this situation. But for me, there are some key ingredients required for the really effective methods.

    1. The method should not take you too far away from the problem space. So, for example, you are trying to grapple with a difficult organisational problem. You decide to adopt a methodology. Now you are focussing on learning the methodology, obsessing if you are doing it ‘right’ and then still trying to gain a shared understanding of the problem space.
    2. The method should be simple enough that people do not have to be trained just to participate.
    3. The method needs to be inclusive, and all voices (not just the metaphorical boxers) need to be heard
    4. The method should be easy to adapt and grow as understanding of the problem changes over time.
    5. Most importantly of all, the method needs to allow a group to start from what they know now. Half the battle with organisational chaos is the continual “going in circles” pain from feeling that all of the questions need to be answered now and if not, we are doing something wrong.

    One of my clients recently summed it up well when he said to me “In dealing with complexity we persist in creating complex methods and wonder why its still complex.” – I found that very profound, but it might have been the beer I was drinking at the time.

    Anyway, I digress. Below is an IBIS based issue map discussing Frodo’s dilemma. Note that I didn’t need to tell you how to read the map. it is inherently readable due to the symbolism in the nodes. This is the sort of output to expect from a dialogue mapping session in Middle Earth.


    So, how would such a map be produced from a meeting or workshop?

    Ideally the room would be set up as per the illustration below. This image below is from the Cognexus site, the home of Dialogue Mapping. Note how one person is sitting at a laptop, with a projected map behind them, facing the rest of the group. The rest of the group is interacting with the mapper and map, discussing arguments, asking for additions or modifications and building out a chain of logic around the problem space.


    The facilitator is the key here. This person knows the IBIS grammar and is taking the group deliberations and translating it to the issue map in real-time. Using software and a projector, as opposed to flip charts, restructuring or refactoring the map live and on the fly is quick and painless. By using the IBIS grammar, the map is inherently readable and very clear, compared to a normal meeting where there is no tool to provide the sort of “holding environment” to allow people to keep collective focus and explore the different perspectives on the problem space.

    This notion of the holding environment also is critically important. If you are lucky enough to work in a job you love, with a team you love, for a visionary CEO who you admire and respect, then that CEO has created the ultimate holding environment and you should consider yourself very lucky (and your CEO is worth all that money they earn). For the other 99.9% of us, we have to make do with what we have. The point here is that any tool or method you use needs to augment the understanding process, not complicate it. If it is over-complicated it will not improve understanding and the group will fall back to business-as-usual and participants will likely wind up resenting the method.

    Consider dialogue mapping as a holding environment versus traditional meeting decorum. Inevitably, a group will start out with one question, and fairly quickly realise there are underlying or deeper questions that also need to be answered. In a regular meeting governed by a strict agenda and roles (as is recommended by many books and facilitators), problem exploration will be stifled. All too often, changes in understanding of the problem is seen as an unwanted tangent that derails the agenda of the meeting. In other words, the system works against the problem exploration space and that sort of meeting decorum is a poor option for this sort of exploration. Why did we invent such systems to keep meetings on track? Because meetings alone are a crappy container for problem exploration! However with the IBIS grammar and the shared space of the dialogue map, underlying questions can be captured and explored with an organised, evolving point of reference.

    The shared space also has a positive effect on the decorum of exploring prickly issues. The group’s attention is now fixed on an evolving map on the wall. A skilled dialogue mapper can utilise IBIS grammar to take a lot of the heat out of argumentation and the process becomes more about building a chain of logic, than cheap point scoring. Typical meeting tactics like pulling rank or personal attacks thinly veiled as “questions” are easily dealt with by the dialogue mapper and never make it to the map in the form intended. The desire to pull back to business is usual is mitigated by the neutrality of the IBIS language and the improved quality of deliberation.

    Perhaps the most important benefit of all, is the capture of rationale, or organisational memory. For me, this is precisely where my SharePoint world intersects with this craft because IBIS maps have for me been one of the best artefacts I have seen for the capture of implicit or tacit knowledge. These maps ultimately are an extremely rich exploration of a given problem and demonstrate very effectively, the circumstances and understanding of a problem at that point in time. With issue maps, gone are the days of looking at a process, policy or report years later and wondering “what the hell were they thinking?”.


    So finally for part 1, let’s sum up by examining dialogue mapping in relation to my earlier criteria for the really effective methods of collaborating on difficult problems.

    The method should not take you too far away from the problem space. So, for example, you are trying to grapple with a difficult organisational problem, so you decide to adopt a methodology. Now you are focussing on learning the methodology, obsessing if you are doing it ‘right’ and then still trying to gain a shared understanding of the problem space.

    With Dialogue Mapping, only the mapper needs any training. All other participants do not need any previous IBIS or Issue Mapping experience. Participants do not need to wonder if they are doing it right, because just by articulating their opinion on issues, ideas and arguments, they are doing it right.

    The method should be simple enough that people do not have to be trained just to participate.

    Cut and paste my last answer. Aside from the mapper, all other participants do not need any previous IBIS or Issue Mapping experience.

    The method needs to be inclusive, and all voices (not just the metaphorical boxers) need to be heard

    Two things that positively kill meetings is death by repetition and grenade lobbing. Death by repetition is when we tend to find a way to suggest our solution, no matter what question is asked. This behaviour has the opposite effect than intended on other participants. But once an idea is captured, it idea is visible along with all of the other ideas. If the repetition continues, all the dialogue mapper needs to do is ask the person if they have anything more to add to the map for that idea. This is surprisingly effective as the disruptive behaviour becomes very obvious to the serial repeater.

    Grenade lobbing happens when someone challenges the whole context of the conversation in some way. When this is a dialogue mapped meeting or workshop, the map comes into its own. The dialogue mapper will capture the challenge as an issue and restructure the map to accommodate this issue. The previous disruptive power of the grenade lob is significantly mitigated and the map now has richer argumentation.

    The method should be easy to adapt and grow as understanding of the problem changes over time.

    IBIS is founded on the principle that problems and solutions are intertwined closely and that exploration of one will change the other in a cyclical fashion. As discussed, refactoring maps over time is critical to managing a problem that is a moving target. But also being able to save the state of understanding at a given point in time, and then being able to examine the evolution of that understanding and rationale (tacit knowledge) over time is capturing a snapshot of organisational memory. Even better, put that snapshot into SharePoint, classify it with metadata and now your collaborative portal includes findable, organised tacit knowledge!

    Most importantly of all, the method needs to allow a group to start from what they know now.

    The exploration of what we know now actually can offer a lot of clarity and insights when integrated into a coherent map. Instead of a long, laborious meeting where various people have lost the thread of the conversation, we have a point of reference on the wall. Furthermore, in breaking down the arguments into simple to follow IBIS structure, participants are better equipped to make the sort of connections between chains of logic to better understand the frame of reference of the other participants. The map is an output of this collective effort, which is visible and available for others to explore. Rather than starting out by trying to peel the onion of problems understanding in ever widening scope, we simply start. We put up a question on the map and attempt to answer it.


    Hopefully, I have managed to convey a little of what the dialogue mapping experience looks like. In part 2, I will expand upon this topic and discuss my baptism of fire experience with dialogue mapping, the factors that have helped me improve my skills in it, as well as working with the master in action – Jeff Conklin

    Thanks for reading

    Paul Culmsee


     Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

    No Tags

    Send to Kindle