Mind Mapping for ITIL and Support Teams

Mind mapping is one of the quickest ways to make ITIL make sense to a support team. Put the framework in the middle of a page, hang the processes off it, and you can see in five minutes where incident management ends and problem management begins. It’s a split teams blur all the time, and a map clears it up better than another slide deck.

I’ve written before about mind mapping a support problem with a team. This post is about a different job: using a map to understand and teach the way a support operation is organised.

What is mind mapping?

Stated simply, mind mapping uses words and simple pictures tied together to help you generate and keep ideas. You put one word or idea in the centre. Related ideas branch off it, and further ideas branch off those, with the most important closest to the middle. It sounds like a big ask for a few circles and lines, but it works.

The modern form is usually credited to the British author Tony Buzan. Plenty of people had drawn branching diagrams before him, so I’d treat the history as background and not the point. What matters is the shape. A map shows relationships. A list can’t.

Why does mind mapping suit ITIL?

ITIL is a framework made of connected parts, and connections are exactly what a list hides. In the version I wrote about in the difference between incident and problem management, the library was five books: Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement. Newer versions have reorganised the material, but the habit of thinking in stages still helps.

Try it. Write ITIL in the middle. Draw one branch for each stage of the service lifecycle. Under Service Operation, which is where support lives, add the processes your team touches every day: incident management, problem management, request fulfilment, event management and the service desk itself. Then do the part a list can’t do and draw the cross-links. An incident that keeps recurring points to a problem record. A problem fix goes through change. A change that worked becomes part of the knowledge base.

Once the links are on the page, people stop asking “which process is this?” and start asking “what does this feed into?” That’s a better question. If you want the formal definitions behind the framework, the people who now steward ITIL publish them at AXELOS.

How do you map incident and problem management?

These two sit next to each other on the map and get confused constantly, so they deserve a close look.

An incident is a single, unique issue affecting one customer and their service. There can be many similar incidents across many customers, but each one is its own record. A problem is the underlying cause behind one or more of them. The incident gets the customer working again. The problem gets the cause found and fixed so the incidents stop.

On the map, draw an incident branch and a problem branch side by side. Under incident, add the steps in the order a customer feels them: logged, categorised, prioritised, worked, resolved, closed. Under problem, add the steps your team takes after the customer is happy: spot the pattern, find the cause, record the workaround, get the permanent fix through change. Then draw a line from “resolved” on the incident branch to “spot the pattern” on the problem branch.

That one line is the whole point. It’s the same split I describe in what a helpdesk is: one job fixes what already has a known fix, and the other finds the cause. A team that can’t see the line closes tickets forever and never asks why they keep arriving.

Can you map your support structure the same way?

Yes, and it’s one of the better uses. Put “a customer issue arrives” in the centre. Draw one branch for each level it could be handled at: first line, second line, specialist or engineering, and the vendor if you have one. Under each branch, write what that level can resolve on its own and what makes it hand the issue up.

Two things usually show up straight away. First, some branches have a lot under them and some have almost nothing. A first-line branch with five items and a second-line branch with twenty tells you where the work really lands. Second, the handoffs are vague. “Escalate if complex” appears on the map, and nobody can say what complex means.

That’s the cue to turn the map into rules. My posts on the tiered SLA matrix and the escalation matrix show what the finished version looks like once the vague branches have timings and owners attached.

How do you use a map to brainstorm with a team?

It’s an extremely useful tool for brainstorming. Put a mind map on the board and have several people throw ideas at it, linking each one to something already there. It’s more interactive than a list, and it’s easier to take part in. The quiet person adds a branch. The loud one sees their idea sitting next to someone else’s.

A simple picture with all the links to and from the centre also shows relationships you wouldn’t have guessed at, and it shows some extra links that take you in new directions. That’s the value in a support setting: the cause of a recurring problem is often on a branch nobody started with.

Can you use mind maps to train new agents?

It’s worth trying. A new agent has a lot to absorb in the first few weeks: products, tools, queues, escalation paths, tone. Ask them to draw how it fits together, with the customer in the middle, and then walk through it with them. Where the map is thin is where the gaps are. Where it’s wrong, you’ve found a misunderstanding early, before a customer does.

The same exercise works for a team lead learning a new area. Draw it first, then compare it with how the team actually works. The difference between the two drawings is a short list of things to ask about.

Draw it from memory first and only then check it against the documentation. Copying someone else’s map is just reading with extra steps.

Where does the knowledge base fit on the map?

Almost everywhere, which is why it belongs on the map and not in a footnote. Add a branch called “knowledge” and run lines to it from three places. From incident handling, because a good agent checks it before escalating. From problem management, because every workaround you record is a draft article. And from training, because it’s what a new hire will learn from when you’re not in the room.

The map makes the gap obvious. If the lines run in but none run out, you’re writing articles nobody reads. If the lines run out but none run in, you’re sending people to a knowledge base that’s going stale. Either way you can see it in a minute, and you can show it to someone who doesn’t work in support without a long explanation.

What does a map of one incident look like?

Take a made-up example to see how the pieces connect. A customer can’t log in, and three other customers report the same thing within the hour. On the map, the first call is an incident. It sits on the first-line branch, gets categorised and prioritised, and gets a workaround so the customer can work again. When the second and third calls arrive, they join the first.

That’s the moment the line to the problem branch lights up. Someone needs to own the cause, and it won’t be the agent taking the calls. The problem record gets opened, the cause gets found, and the permanent fix goes through change. When it’s live, the knowledge article is updated, the workaround is retired, and the incidents stop. You can trace the whole path with a finger, and a new agent can do the same.

What goes wrong with mind maps?

A few things come up repeatedly.

Writing sentences. Use a word or two per branch. If the branch needs a paragraph, it’s a document and you should write it as one.

Trying to put everything on one map. ITIL is too big for a single page. Draw a top-level map and then a separate map for each process you care about. A crowded map is as hard to read as a long list.

Mixing levels. If “incident management” and “the printer in building two” sit on the same level, the map is lying about how they relate. Keep each ring of branches at one level of detail.

Drawing it once. Processes change, and teams reorganise. Redraw the map after a major incident, after a change in structure, and whenever a new group of agents joins. The second drawing is nearly always better, and the differences between them are worth a conversation.

Which mind mapping tools are worth using?

For a room with a whiteboard, the whiteboard is enough. If you want software:

• Visio, from Microsoft, has a mind mapping module built in.
• MindManager, from Mindjet, is a commercial tool and a powerful one.
• FreeMind is free, intuitive and downloadable. Freeplane, its fork, is the more actively maintained choice.
• bubbl.us runs in a browser, which helps if your company restricts what you can install.

Pick one your team will open twice. A map that’s drawn once and never revisited is a diagram, not a working tool.

If ITIL still feels like a pile of terms, try this before your next training session: draw the framework from memory, then check what you missed. The branches you couldn’t fill in are your agenda.