About 6 years ago, whilst still at my last job, I was feeling pretty disillusioned about the software industry in general. After only having worked as a software engineer for about 5 – 6 years, it felt to me that the entire industry was full of miscommunication. All too often clients didn’t know what they wanted, and software engineers were too self-absorbed to listen (me included).
It was at this time I thought I’d try something new and try to build my own consultancy. In what was a perfectly serendipitous event, Paul Culmsee, an old colleague I worked with at a job 3 years earlier, had also gone out on his own a year earlier. Paul was now looking for a business partner with a software engineering background and I was in desperate need of a mentor (I had only really been in the IT industry for a total of about 8 – 9 years at that point). It was at this point Paul introduced me to the one tool that has pretty much come to shape everything I now do as a consultant, Issue-Base Information System diagrams. Soon after this, Paul and I went to the US to meet and learn with the guru, Jeff Conklin, and everything else, as they say, is history.
It’s the continued use of IBIS, and the further pursuit of mastery in it, that has shaped me from being just an analyst to being a sense-maker.
Issue-Based Information System – The Knowledge Worker’s Swiss Army Knife
Issue-Based Information System (or IBIS, pronounced as i-bis, kind of like iPhone) is a diagramming technique very similar to mind mapping. Paul had found it while researching about wicked problems and had begun to use it to analyse projects he was working on. Because of the simplicity of the IBIS notation and its visual nature, Paul was able to give me a quick rundown of how he had used it for his projects.
I immediately saw the power in helping how I organise vast lists of requirements collected from clients. In these early stages I used IBIS to organise these thoughts but over time I’ve come to realise it is so much more than that, a proverbial “swiss army knife” for any knowledge worker, which I use for –
Quick Sidenote – Software to do IBIS
Clearly if you’re wanting to use IBIS, it’s going to make your life easier if you use a piece of software to create the diagrams. Thankfully, many years ago there was a research project that developed a piece of software precisely for this purpose called Compendium. The research project has since ended but Compendium still exists as a community supported open source application. I won’t go into the software here as I’ll let the project site and community support forums provide more information on it than I could. You’ll find the Compendium software site at http://compendiumng.org/ .
Introduction to IBIS
The true beauty of IBIS (particularly for the mathematically minded such as myself) is that it provides a very simple visual notation upon which any conversation can be represented. Below is a very simple example of the components of an IBIS diagram.
Each individual component of an IBIS diagram is called a “node” and these nodes represent one of four basic conversational building blocks common in everyday language. These being –
- Questions –This is literally a question that has been posed.
- Ideas – This is any kind of statement that has been made in response to a question.
- Pros – This is a supporting argument for an idea.
- Cons – This is an opposing argument for an idea.
Each of these building blocks are then linked together by an arrow to form an IBIS diagram. Below is a meaningful IBIS diagram to give you a better idea of the structure.
To read an IBIS diagram, first you read the left most node and then any nodes that point to it are a ‘result’ of the node to the left. In the example above, the ‘No’ and ‘Yes’ nodes are a result of the posing the question, “Should I get a cat?”. It’s at this point I’ll introduce the first two important rules of IBIS for questions and ideas.
IBIS Rule #1
Questions can result from any node.
IBIS Rule #2
Ideas can only result from questions.
These are the most important rules for IBIS as they underpin the core values that make IBIS an invaluable analysis tool.
Following from the questions and ideas, there are then pros and cons that result from ideas. One important rule for IBIS is that pros and cons can only result from ideas, not questions.
IBIS Rule #3
Pros and Cons can only result from Ideas, they can’t result from Questions.
Using these 4 simple nodes and 3 basic rules, ANY conversation can be visualised. And I truly mean any. Just to name a few things I’ve build IBIS diagrams for –
- Articulating images in language
There is honestly nothing I haven’t come across that could not be visualised using IBIS. Now that is not to say there aren’t other (or even better) visualisation tools to represent information, but IBIS is pretty versatile and to my experience, universal.
Principles of IBIS
Now that you know how to read IBIS, why would you bother to use it? Especially when it’s so simplistic in its nature. This simplicity is the immediate reason I became a massive fan-boy for IBIS. Because it is so simple, it means you aren’t bogged down in trying to understand it. Instead you are now free to use it in any manner to do the really important task – to understand and communicate a problem amongst a diverse group of people.
The beauty of IBIS is that it can show the logical flow and connections of any kind of information. This means that, if done masterfully, you can use IBIS diagrams to explore topics including the assumptions those topics may bring. If there is one thing I’ve learnt being a sense-maker over the last 5 years, it’s that “assumption is the mother of all f**k ups” (a quote eloquently spoken by a former junkie that my colleague Neil Preston used to provide clinical counselling to).
The 3 IBIS rules that were introduced before are also key to improving the exploration of a topic, reducing assumptions, and providing context (a very important concept in removing assumptions). The IBIS Rule #1 is important because it seeks to provide as much exploration on a topic as possible. This helps us to remove assumptions from a discussion and ensures that everyone is actually looking at the topic from the same point of view.
Have you ever had the issue where you were sitting in a meeting and Bob begins talking about a seemingly unrelated issue which leaves the room wondering what the hell Bob’s talking about? IBIS Rule #2 aims to resolve these kind of issues. The truth is we’ve all done what Bob did. We’ve all been guilty of answering a question before people know they’re going to ask it. In IBIS we call it the “hidden question” and we do it more often than not. Bob’s story is a more explicit case but often in books the author will make one statement after another with the assumption that the reader will be asking a certain set of questions. By always seeking to understand the context in which a statement is made, we help to further drive out assumptions.
The following scenario I’ve been in numerous times when there is a group of engineers gathered and a serious dilemma at hand. Someone will ask what appears to be a naïve question and immediately an “alpha developer” will cut them down and go “that’s a stupid question, let’s move on”. IBIS Rule #3 is for such a scenario. When we judge a question, then we limit the conversation. The reality is, if a question truly is stupid, the answers (idea nodes) will be quickly exhausted anyway and we’ll move on. IBIS Rule #3 helps us maintain an openness to the discussion so that exploration is encouraged.
The biggest win from mastering IBIS is that it makes you a “super analyst”. What I mean by this is that you become more than just an analyst. The very definition of an analyst is “a person who conducts the detailed examination of the elements or structure of something”. When you think of it in that way, analysts are pretty useless people. What is the point of understanding something if you don’t go and DO SOMETHING with that knowledge? The better you get with IBIS, the more you will realise it’s more than just an analytical tool, it’s a tool that you can use for synthesis and communication.
Having worked with IBIS over the last 6 years in both passive (visualising books, videos etc.) and live situations (presentations, facilitating meetings etc.), and having recently just completed software to create maps (watch this space), I like to think I’ve become a bit of a master at IBIS. In addition to practicing your IBIS notation at every chance, I’ve come up with the following principles that I think need to be fully understood and acted upon if you hope to become a master with IBIS.
- Improving understanding is tantamount. Everything comes second to this.
- Context is everything. Every idea is answering a question. If the question isn’t at first apparent, find it.
- Assumption is the mortal enemy of Context. The infantry in Context’s army are Questions so find plenty of good quality ones.
- A good question is worth more than the ideas/answers that result from it. A good question can create new opportunities.
- All questions are worth exploring but not all questions are born equal. The depth of exploration will always match its value.
Where to from here?
My recommendation is to start using IBIS to analyse whatever it is you might be wanting to learn in detail. It’s going to take a little while to get really proficient with IBIS. With enough practice you’ll be able to get to the point you’re able to use it like talking your native language (my colleagues and I find ourselves building maps in our minds whilst we listen to conversations now). Stay tuned to my blog as I’ll continue to provide more information on mastering IBIS and different ways in which I’ve used it within our consultancy.