Beyond Mind Mapping

Response to Peter Abrahams' "four generations" article

Peter Abrahams of IT-Director.com recently posted an article, also commented upon by Chuck Frey, arguing that collaborative mind mapping software represents a fourth generation of evolution of mind mapping technology. I don't agree with this interpretation, and here's why.

The first generation, pen and paper (or whiteboard), is still the preferred medium for many occasions, so is not outdated or superseded by electronic versions.

The second generation is electronic implementation of mind maps with computer software. This is worthy of being regarded as a different generation, because it builds on the concepts of the first, but adds fundamental capabilities that did not exist in the first. Specifically, the ability to expand and collapse information allowed us to deal with ten, twenty or a hundred times more information than could be sensibly managed in a physical form. This meant that mind map visualisations could be used in previously inaccessible or impractical areas, and allowed mind maps to become serious knowledge management tools. All the other features of electronic mind mapping, such as attaching files and links, or real-time collaboration, do not change this basic premise. We could (and still do) collaborate in real time with first generation technology; you don't need the Internet for that. Agreed, you can now collaborate at a distance, but this is a convenience, not a fourth generation. I think that Peter's third and fourth generations of mind mapping software are enhancements to the second, and not new generations.

So what will the third generation look like? I hope it will be an "unbundling" of mind mapping technology, and an escape from the silos of information that dedicated "mind mapping" tools are creating. The feature sets of many mind mapping tools are overloaded with import and export capabilities, which itself tells a story. They expend just as much effort trying to integrate with "normal" technology as they do on exploiting the fundamental power of visualisation. You could say they have a stereotypical English persona: "Sorry, I'm a mind map. Sorry." I look forward to the day when electronic mind mapping stops apologising, ceases to be a parallel universe, and is just one of the choices we have to access and manage information in a variety of activities. Mind Mapping software clients are to mind mapping what e-mail clients are to everyday work; I don't want all my e-mails grouped together inside an e-mail application, I want them embedded in whatever project or piece of work they relate to, in whatever visual format that may take. I want to be able to have an e-mail conversation from within a mind map, without going through technological hoops trying to get two separate applications to liase with each other. I want to be able to click the "mind map view" tab in Google, Word or PowerPoint. While we have standalone mind mapping applications, this will not happen.

Mind mapping technology is the third generation, not more sophisticated mind mapping applications. I hope!

Spiral Presentation Maps and Virtual Donuts

Software mind maps are frequently used and abused as a presentation tool, as a refreshing alternative to endless bullet points. Done well, they can make complex concepts much clearer. Done badly, they can alienate even the friendliest of audiences.

A key advantage of software mind maps over other presentation tools is what happens below the waterline of your presentation iceberg. 90% of the value of a presentation is created in the preparation. The 10% that the audience sees is merely the final flourish. If there is little or nothing below the waterline, your iceberg will capsize at the slightest push. PowerPoint® hardly helps at all when it comes to building foundations, as most of the features are aimed at the part the audience sees. Software mind maps offer fewer visual tricks, but are much more helpful in structuring and developing your presentation, because you can visualise and verify the relationships between the concepts that you want to communicate. A presentation prepared from a mind map is likely to be far better thought out than one prepared straight to bullet points.

There are a "few rules of thumb" that help with most business presentations:

• Use an inductive rather than a deductive approach; tell your audience what your conclusion is, then justify it, instead of presenting a trail of clues followed by a big surprise
• Tell them what you are going to tell them, then tell them, then tell them what you have told them
• Most presentations overrun, so use a strategy that ensures you get your key points across even if you get cut short
• Aim your presentation at the right audience, so that the call to action is compatible with their remit
• Leave them wanting to know slightly more, rather than worn down by exhaustive detail.

Most of the map-based presentations I have seen have started on a step-by-step walk through the topics of a map, drilling straight down to the first great-great-grandchild of the first main topic and crawling onwards from there. This usually cancels out the benefits of tree structures as a way to encapsulate big ideas first, then break them down into more detail only later when the audience is warmed up and receptive.

There is no single template for a map-based presentation that would work in all cases, but there are some principles that will help many:

• Always use statements and not headings in a presentation map. The topics are your bullet points, and will be the written record of your presentation. Headings alone will be meaningless without the words. Provided you don't make the mistake of simply reading out the map to your snoozing audience, statements give them the chance to scan ahead, which they love to do - so that they get an idea of how the whole thing fits together. Some presenters don't like scanning ahead because they think it distracts attention. If the audience is prone to distraction, they will distract themselves with anything that moves. It's better that they distract themselves with reading your presentation than with what is happening in the corridor.
• Use the structure of the map to address different levels of audience, so that you don't have to reveal more than they really need. Software mind mapping tools will let you show or hide different levels of topics. Provided you use statements instead of headings, this lets you "layer" your presentation very effectively. Think about the map as a set of donut-shaped rings. The ring nearest the centre of the map is for your executive audience, who have short attention spans and grasp big ideas quickly. The next ring is for management, who are going to need a better understanding of the implications in order to deliver it. The outer ring is for the people who actually do the work, who will need real details. The true benefits of the tree structure become evident here, because you can position detail in the context of bigger ideas.
• When presenting, start at the one o'clock main topic and walk through your map in a spiral, addressing the executive level first, then the management level, then the detail if it is appropriate. This takes you on a complete tour of your map in at least three passes, which helps your audience feel comfortable from the outset about the scope of your presentation, and critically, the way it is represented by your map. This might disappoint the few who enjoy suspense and surprises, so it is up to you as a presenter to make it entertaining and engaging in other ways, instead of by playing with the content. That's like playing with food, and you can remember being yelled at for that. If your audience is still with you when you complete your tour through the management level, then they are ready for the detail. If you have already lost their good will, or are running out of time, then more detail would not have helped and could even have set you back.

This template gives you some ideas on structuring the content, and the kinds of information that you might include at the different levels. The numbers on the topics represent the presentation order.

So when using software mind maps to prepare and deliver presentations, use statements, translate different audience levels to layers, and develop a spiral route through your map to keep your audience on track. And don't forget the donuts.

Mindomo raises the bar for mind mapping software

The last couple of months have seen the launch of several new Web-based mind mapping software tools. Chuck Frey predicted that we would see more this year. The recent launch of the beta version of Mindomo from EXswap is a new and welcome addition to the world of mind mapping software, raising the bar significantly for both Web- based and desktop software providers.

Mindomo is a Web-based mind mapping software tool that runs in your browser, with the maps being stored on their server. But what distinguishes Mindomo in this growing field is genuine desktop-quality functionality. Pretty much everything you need from basic desktop software is there - rich formatting, curved lines, images and symbols, relationships, notes fields, task data, drag and drop editing, Web hyperlinks, and import from Mindjet MindManager. Clearly a lot of thought and work has gone into it. But rather magically, you don't need to download or install anything. You only need a Web browser with a Flash player. If you are a corporate user with a locked-down desktop and an active IT police force, this is a highly attractive proposition - especially with the elimination of issues such as upgrades, service packs, multiple location licensing, platform locking, and synchronising files between your desktop and laptop. All these things become history. Most business users these days have a desktop and a laptop, and an increasing number have both Microsoft and Macintosh platforms. I even heard a rumour that Eric Mack was going to get a Mac...

What is scary for desktop software publishers is that straight out of the box, Mindomo is multi-platform and enables collaborative working at no cost. The challenge of persuading your colleagues to purchase and install desktop software so that they can work with you has been eliminated, with few compromises on functionality. No more "read-only" viewers for one-sided collaboration. You can simply create a joint account on Mindomo Free edition and access each other's maps from anywhere. The basic version is free, but there are other (purchasable) editions that provide secure connections or even installation on your own server for security-conscious corporate users. This approach is a critical distinction between "free" and "Open Source"; Mindomo is free to use at one level, but you can migrate to a commercial and contractual relationship where you need to. Open Source will always remain in a grey area for many commercial organisations.

Almost as a by-product, Mindomo creates a visual "Wiki" where users can collaborate on shared maps, and can publish templates and examples for anyone to use. I don't think I am alone in regarding Wikis as full of potential in theory, but rather awkward and to understand and use in practice. On Mindomo, a shared account acts as a Wiki where you can control the membership.

In the article about using mind mapping software to map out events, a few readers asked if there was a template map available. Here is the template on the Mindomo site. If you create a free Mindomo account, you can edit this map and save your own private copy of it, or publish an amended version for others to access, which is all rather cool.

Edit this map on-line now!

As a beta, there are of course some features still "under development" - but based on the quality of this beta, I don't doubt that EXswap will deliver them.

Mindomo Web site: www.mindomo.com

From Beyond Crayons to Beyond Mind Mapping

Just today, I read yet another conversation in a bulletin board about the merits (or otherwise) of "mind mapping software" versus Buzan's "Mind Mapping®". As always, there were supporters on both "sides", the Mind Mapping® fans preferring the immediacy and creativity of hand-drawn maps to the sterile, slow and technology-dependent world of software. Who could disagree?

To me this seems like unconditionally declaring whether you prefer to walk or drive. If you are going to the local shop for a loaf of bread, walking is the healthy option. If you are visiting somewhere sixty miles away, walking is unlikely to be a serious contender, regardless of your preferences. So some preferences should be conditional to avoid being dogmas.

I prefer to draw Mind Maps® by hand, but I prefer "mind mapping" software if I want to draw something that needs to be shared and frequently updated and revised. Only those who (understandably) mistake mind mapping software as a tool for drawing Mind Maps® might declare an unconditional preference. There are a few software packages that aim to recreate Mind Maps®, but they are outnumbered by tools that simply aim to provide fast and easy graphical organisation of information.

Unfortunately the industry seems to be stuck with the term "mind mapping software" because that is where most of these tools originated from, and there is no other category that is as clearly recognised by the reviewers or potential users. But this does a disservice to both techniques, by

• implying that a Mind Map® is merely a tree,
• implying that a tree-shaped diagram must be a Mind Map®, and
• inviting misleading comparisons between Mind Mapping® and mind mapping software.

For this reason, I am changing the name of my Blog from "Beyond Crayons" to "Beyond Mind Mapping", to make it clearer that the use of mind mapping software is quite distinct from Mind Mapping®. Not better, not worse, but designed to do different things.

A Simple Template for Visualising Events

The idea that a map represents your relationship with a subject (rather than the subject itself) is worth a whole posting by itself, but before sending everyone to sleep with the theory, it might be more useful to first present a practical application. It leads to a clearer variation of the project map template that captures a simpler view of the relationship between an event and its stakeholders.

Many business people are primarily concerned with events that change the status quo. This could be launching a product or service, commissioning a process, solving a problem, delivering a physical event (such as a seminar), or establishing a new behaviour. Learning, information and knowledge all play a role within that context, either before (in skills and training required) or afterwards (in lessons learned and experience gained). The relationship between an individual or team and a finite event includes responsibilities, actions, expectations, outcomes and consequences for the individual or team.

One of the differences between software maps and pencil & paper maps is that the majority of software tools only support horizontal text. Today, many of the software maps that you look at are not truly "radiant" but are horizontally banded and lead the eye left and right -  like scanning the horizon for interesting features rather than looking in the sky or sea. This is a restriction that we can also exploit as a feature. If we also adopt a left-to-right convention, we have a convenient way of visualising concepts that naturally converge to a single critical point before diverging again.

I suspect you're already way ahead of me here. If we make the centre of a map represent an event, then on the left we can write down the converging factors that lead to the event, and on the right we can show the divergent consequences of that event occurring. This gives us a flexible graphic depicting the whole of our relationship with an event:

(Click for larger image)

For example, let's suppose that you are the director of a mail order company, and you are getting feedback from customers receiving parcels that appear to have been delivered by Ace Ventura. Readers in the UK will know which delivery service I mean. So changing your courier is a promising long term solution. The Event template structure helps us to think about and organise our ideas in several areas:

• The "defining moment" at which the changeover can be described as complete - how this point is characterised
• The conditions that describe that point, which are drawn on the left
• The resources and actions that lead to those conditions, also drawn on the left
• The implications that arise from completion, which are drawn on the right. Not all of them need to be positive, provided they are not unanticipated
• How the outcomes contribute to other strategies, also drawn on the right

(Click for a larger image)

This also gives us simple way to correlate the consequences listed on the right with the actions and decisions on the left, to ensure that we will deliver on expectations. This is hardly a new idea, but formal statement and verification of requirements is not often used in general business. All we want is a simple visual device that can easily be explained to almost anyone and conveys a real sense of the consequences of decisions and actions.

The beauty of using an expansible tree diagram is that there is a place for all the detail you could ever need, without losing the birds-eye view of the most important factors for discussion and presentation purposes. It creates space for some of the more intangible results of completing a project, especially where they lie outside the direct remit of the project team (i.e. are not actions on the left).

An "event" could be a project outcome, problem situation, hypothetical opportunity, educational achievement or anything that has a sense of completion or a point at which a change occurs. The same basic visualisation can be used to communicate, negotiate and deliver anything from buying a new printer to reorganising a department.

A surprise in Chuck Frey's mapping software survey

Chuck Frey of Innovation Tools has published the results of his mapping software survey, and fascinating reading it is.

There were two things that stood out. First, a sizeable proportion of the respondents reported that they used their mapping software for less than an hour a day. This is significant because it shows that this is the first survey to really reach out beyond the "power users" circle. There has always been doubt that surveys only attract the kind of people who like to do surveys. I think this figure shows that Chuck has gone beyond that into more representative areas.

Second, and something of a surprise to me, was that although the average increase in productivity as a result of using mapping software can be estimated at around 20% from the results, only 1% of users considered that to be a primary benefit of using mapping software. So we acknowledge that it substantially increases our productivity, but we don't regard that as a much of a benefit! But isn't that the core of many marketing strategies in this field? Or marketing strategies in general? Time to stop and think.

Read Chuck's full survey results here.

The Chef, the Soup and the Assistant

Edward de Bono made his name with hot water and jelly (or Jell-O for our American cousins). He wrote an entire book on how our minds and memories respond to stimuli like jelly with hot water poured on it – the development of patterns and channels that get deeper and are reinforced with each use.

If wacky is good, then wackier must be better. As a model of how our brains work, “simmering alphabet soup” scores well on the wackiness scale, and is also validated from the experience of many.

Imagine for a moment a deep pan of Alphabet Soup, simmering gently on the stove, occasionally checked by a distracted chef who has a ton of other things to do. As the soup simmers, letters of the alphabet fleetingly appear on the surface. Often, they cluster together, hinting at words that mean more than the sum of their letters. But unless our chef happens to be looking at the right moment, they are gone as quickly as they came.

Like the monkeys with typewriters, the potential volume of ideas and information in the alphabet soup is immense. The letters that roll to the surface are only a tiny fraction of what lurks in the hidden, murky depths of the pan. Our distracted chef occasionally notices messages in the soup, as if it is trying to tell him something. Sometimes, if he catches it off-guard, the soup whispers fragments about past and future happenings in the kitchen. But if he stops what he is doing and glares at it, demanding a clear answer, the soup stops simmering and the letters sink out of sight. You could forgive him for thinking that his pan of soup has a shy and contradictory personality. Worse, it seems to see and hear everything, and have its own interests.

Our chef has realised that vigorous stirring, turning the heat up or down, cursing loudly or blaming the soup for mistakes always make things worse, not better. But if he lets it speak to him in its own subtle way, the richness and variety of its messages are an inspiring revelation. All he has to do is keep it simmering happily, feed it with new ingredients so that it is never short of working material, and be prepared to listen.

In fact, our chef has now hired an assistant for the simple but crucial task of casually watching the soup for unexpected messages, before they sink again forever. The soup and the assistant are getting on famously, as the soup never cared much for the chef’s stressed-out on-demand approach. They are developing a level of mutual trust that the chef found difficult to achieve by himself. There is more productive teamwork between the chef, the soup and the assistant than there ever was between just the stressed chef and his soup.

To hire your own assistant to watch your alphabet soup for you, go here.

Speak now or forever hold your peace

I'm looking forward to reading the results of Chuck Frey's survey on the use of mapping software. If you haven't taken part yet, please do - especially if you don't usually participate in these things. There is an ever-present risk that more widely held views never get aired, because it's always the usual suspects who speak up first.

A few of the questions caught my eye in particular; the applications of mapping software, the time spent using it, and the reasons that the use of mapping software might be held back.

Without trying to misinterpret Chuck's design goals, the list of applications for mapping software will reflect more on the job roles and responsibilities of typical users of mapping software, rather than the capabilites of the tool or even its suitability for that purpose. Incurable mappers will use maps for anything they can, even when it's not entirely appropriate. So this question profiles the users rather than the application areas of the software. To normalise this, you would have to establish whether the user (for example) undertook project planning as part of their job, and if they did, whether they used mapping software to support it.

Regarding the question on time spent per day using mapping software, I impolitely  wondered what the unwritten second half was. "How many hours a day do you utilize mapping software..." "...instead of working?" or "...instead of acting normally?" or "...instead of using the right tool?" I'm not entirely serious, of course. But although the metrics will be very interesting, I think distinguishing work supported by mapping software from other kinds of work focuses on the tool rather than the outcome. It reinforces the misapprehension that using mapping software is an exclusive activity rather than an inclusive one, and that using mapping software is itself an end, not a means to an end.

The question on barriers holding back the adoption of mapping software will be difficult for users to answer. The people who genuinely know the answers to this will not be taking part. Ideally, users should poll their colleagues and submit those answers instead. It is entirely possible that as a dedicated user of mapping software, you are not truly aware of how others feel about it in your organisation. I note that Chuck's list of proposed objections doesn't explicitly include the #1 barrier that was identified in the MindManager Yahoo! Group survey earllier this year, but I guess he is trying not to lead the witness too much - since they're not exactly independent witnesses to start with.

So do take a moment to support Chuck's initiative yourself, and ensure that my input does not skew his results :-)

Turning systems models into projects

A while ago my esteemed friend and colleague Patrick Mayfield wrote about using Systems Thinking to build Outcome Relationship models.

Never being too proud to plagiarise something good, I wondered how Patrick's diagram would work as a Funnel Timeline in a software mind map. Would it be a case of trying to make a different tool do something it's not designed for? Would it genuinely create additional value, or would it be a compromise that required rose-tinted spectacles to see advantages?

Although software maps were never designed to represent systems and networks, they are very good at helping to focus on outcomes and priorities in context. So whether a representation of a system diagram is better or worse when mangled into a tree depends on what you wanted to do with the diagram in the first place. If you wanted to understand the dynamics of a closed system without any particular emphasis on one angle, then a systems diagram is best for this. But if you want to use the systems diagram to deliver change, i.e. if it develops into a project or process, then focusing on outcomes can have distinct benefits.

Without repeating Patrick's arguments for systems thinking and visualisation here, this is his diagram showing how the various factors driving improved teaching in schools inter-relate:

Here is the same information, interpreted as a Funnel Timeline in a MindManager map:

What are the pros and cons of each approach?

It is not a case of one visualisation being "better" than the other, but that each can be applied differently. The system diagram shows an interacting set of entities. The Funnel Timeline shows the relationships in terms of the influences needed to reach a new state, using the systems model to determine the consequences of positive changes. In fact Patrick's diagram is a model of an open system. If it were a closed system in balance, the legends would be "Teacher professionalism" instead of "Increased teacher professionalism", and there would be feedback loops showing the relationship between the level of teaching performance and other conditions such as pay (assuming that the perceived value of the teaching system influences how much money is spent on it).

The systems diagram version has no specific central point that might distract users into seeing it one particular way. There is no real priority built into the spatial position of the elements, although this could be added. The elements have more of a feel of "black boxes" to them. There is no ambiguity about what feeds into what. Bilateral influences are entirely possible, although the nature of the influence between them might need clarification.

The map version requires some conventions to understand the Funnel Timeline technique. In a Funnel Timeline, topics represent outcomes or achievements of a certain status, and sub-topics are the predecessors or preconditions required to achieve that status. This makes the Funnel Timeline version strongly outcome-focused, and much better suited for representing open systems rather than closed ones. You can easily see the actions or achievements in the context of the overall outcome.

By flattening out a systems network into a tree, you can identify primary themes or groupings, and the relationships between the components in these groups are stronger (by implication) than those drawn "across" the tree. This is much easier to see in the tree format. You can also add more detail to a particular node without disrupting the diagram. This is because in the tree version, we have sacrificed a whole axis to "level of detail". In the systems diagram, we use both axes to draw information. In the tree version, we use one virtual axis for information, and the other for the level of detail of that information. Because of this, you can arrange the tree version to show first and second generation factors; things connected more closely to the final outcome are direct influencing factors, whereas things at a lower level are indirect. Again, this is a bit easier to see in the tree version than in the systems diagram.

Another advantage of the tree layout is that you can easily take it forward as an action plan, as the sequence of changes is identified. Interestingly, one of the analytical questions that Patrick cites is identical to the analysis needed to create Funnel Timelines, viz. "What are the necessary things that must happen or be in place for this to happen?" This question creates a bridge between systems modelling and planning for change, i.e. project planning. With the map version, the sequence of changes is clearly laid out, and even benefits from hierarchy & inheritance - you could make one person responsible for delivering everything below one particular node, for example.

So, are we actually better off, or have we forced a round peg into a square hole? I don't think it's a question of choosing between one and the other - each has its own merits. The systems approach is the foundation for understanding how a closed system stays in balance, i.e. what the balancing forces are. Armed with that knowledge, you can then define the actions necessary to move that balance point. This can be presented as a project plan, even though it is derived from a system diagram. Understanding the systems forces already at play helps to make change more effective.

Putting an edge on your maps - part 2

In the previous post, we looked at how the maps, not the software, are the tool that shapes your business issue. In this post, we will look at what makes a map "sharp" or "blunt".

The key to sharp maps is to store not one, but two kinds of information in the map:

• Information about the subject of the map - the plan, presentation, brainstorm or whatever it is, and
• Information about the process of the map and its current status.

The subject information is a snapshot of the output of the process so far. Software maps are capable of easily mixing both types of information in the same space. Very few other containers are as capable as maps. Compare this to the annotation capability in Word to appreciate what a rich container a software map really is.

Most users never make their process explicit. It's just too trivial to waste effort on. Surely it's obvious what the map is about! The trouble starts when the volume of subject matter starts to eclipse the process. This is when a map goes blunt - it has lost its cutting edge. You are not sure quite where you have got to, or what to do next. Individual users have the luxury of putting the map aside, and the excitement of rediscovering their unfinished symphony eighteen months later. Groups tend to panic a bit and the initial enthusiasm is replaced with hesitation and frowns. Nobody wants to be seen to be giving up.

As an example of process, consider the humble brainstorm. The traditional steps are

1. Define the issue or problem
2. Define the selection criteria
3. Pre-expose the audience 24-48 hours ahead of time
4. Gather ideas without evaluation
5. Group, organise and gather more ideas
6. Eliminate the absurd, gather more ideas
7. Evaluate the remaining ideas consistently against the selection criteria
8. Assign actions

If you dive right in and create a typical "brainstorm map", it is probable that the map only reflects steps 4 and 5. The rest of the process is implicit, or in the facilitator's head, or nowhere at all. But if you allocate a space in the map for communicating the process and tracking its status, then this map can be worked upon repeatedly, and voluminous contents won't overwhelm it. So when you have a flash of inspiration while mowing the grass three months later, you can return to your brainstorm map and understand the implications of injecting a new idea, without undermining the integrity of the map or the thinking that it represents.

Input that is added to a map without consideration for the process weighs it down and makes it go blunt, so that you don't want to work with it any more. To recover a map that has gone blunt and is going nowhere, try the following:

• Make a working space in the map that will hold the step-by-step process of developing this map to achieve an outcome. To do this, you will have to decide on what outcome you want. This may have been one of the missing pieces anway.
• Develop a sequence of gathering, organising, deciding and taking action. This pattern applies to much more than brainstorms.
• Now that you know where you are headed, review the organisation of the map and decide where you are up to in this sequence, and what you need to do to get it back on track. You may find that in some places the map is over-developed and shows premature conclusions. This can make it difficult to cope with information that does not fit with the conclusions.

The ResultsManager Template map is designed to capture information about a project, plus information about the status of the map itself. It also has an "in-box" area where new unsorted ideas can be placed before they are integrated into the existing map.