8 tips for improving visual mapping on IT projects

by | Sep 15, 2016

Get everybody on the same page

Pictures are a great way to bring people together but they can also intimidate and confuse. This post gives you some tips for how to better use visual mapping to improve the chances of success for a project. Perhaps a good start is to consider some principles:

  • keep it lightweight
  • keep it collaborative
  • create a shared understanding

These were introduced by Scott Ambler on the Master Business Analysis Podcast: Episode 084: Agile Modeling. Along with those I’d like to emphasize the importance of iteration as a principle. A great way to get engagement and interaction is to draw something that you half understand and then get assorted stakeholders to chip in, repeating the process with different stakeholders.

These principles are very much in line with what we’re trying to do here with Hubscope.

Tip 1: Use real words that people understand

If we want to keep it collaborative then we need to avoid domain specific language. We need to avoid specialist terminology that confuses and divides. Use common terms that everybody can understand.

For example, in Hubscope we have a very simple data model that both business people and technical people can understand and collaborate with. The data model consists of just seven entities:

  1. Business unit
  2. Person
  3. Requirement
  4. Service
  5. Software
  6. Hardware
  7. Data

Now, whilst it’s possible to argue over what exactly these things mean, everybody has a general understanding and can get using them straight away.

Tip 2: Follow a simple, repeatable process

The big picture of a complete project can be overwhelming, there just seems to be too many moving parts and it’s difficult to know where to start. So, it helps to break it the whole thing into a small number of constituent parts that are simple but then connect to produce a holistic understanding of the whole project. Think of these different parts as jigsaw pieces that fit together when they are assembled in the correct way.

Again it’s useful to remain in the domain of the familiar so we like to use diagrams that people can instantly understand. In Hubscope, we have four overlapping perspectives that combine to visualize the whole project on one page:

  • Perspective 1: Who: This is an Org Chart that can be used to show the key players on the project, what part of the organization they belong to and how they relate
  • Perspective 2: Why: This is a Requirements Tree which shows a hierarchy of requirements along with relationships to stakeholders who own them
  • Perspective 3: How: This is a Services Map which shows an abstracted view of how the requirements will be addressed
  • Perspective 4: What: This is a high level Conceptual Architecture which shows how technology (software, hardware and data) deliver the services
  • Perspective 5: All: This is the summary view which brings all of the other perspectives together on one page

Not only does this provide a simple way to break down the visualization, it also provides a simple methodology for how to create the drawing starting with Who then Why then How then What.

Tip 3: Don’t hide and create, share and co-create

We talked about iteration in the principles and it plays a key part in creating and improving the quality of a diagram.

Often business analysts or solution architects are nervous about creating and presenting a diagram that isn’t correct. They hunker down and try to draw everything by themselves. This is not the way to go. It’s far better to put something out there as an early draft to get the ball rolling, invite feedback and progress towards a more accurate understanding of the project. The important thing is to create something quickly and use it as a vehicle to drive collaboration and engagement for all parts of the technical team and external stakeholders.

Hubscope makes it easy to quickly create diagrams and to change diagrams thanks to its simple interface and intelligent auto-layout functionality. It’s very easy to delete nodes and relationships or edit existing nodes and relationships in the diagram.

The data is actually stored in Excel which means that’s easy to share and update by using Excel too. People are very comfortable with looking at and editing spreadsheets. Often projects use Excel for maintaining inventories of project artifacts. This works well up to a point as some people will not be able to process and understand the information held in the spreadsheet. Visualization makes this a whole bunch easier.

Tip 4: Group the information in useful ways

Grouping is very important in order for us to abstract and identify patterns in the information. We can group information in all sorts of ways, for example, we can group:

  • user stories by the sprint they will be developed in
  • hardware by the environment that it sits in (Production, Development, UAT, etc.)
  • requirements by their relative priority, (Must have, Should Have, Could Have, Won’t Have, etc.)
  • people by their role, and so on.

Hubscope uses tags so that you can group different elements in the diagram in many different ways. Here we can see tag 1 being used to identify which Sprint the requirements will be developed in and the use of the cluster feature along with expand and contract to group requirements together.

Tip 5: Hide the parts that are not important

You don’t need to be able to see all of the information all of the time. Different people will want to work with different parts of the diagram. Filtering out the stuff that they are not interested in is very important.

For example, you may be having a meeting with a business stakeholder to discuss a few things around Sprint 1. To simplify the conversation you could decide to remove requirements for sprint 2, business unit, hardware and data.

Hubscope’s filter function means that this is very easy to do.

Tip 6: Consider the project from the stakeholder’s perspective

When you have conversations with business stakeholders it’s important to use their language and speak to them from their perspective. What does this mean for visualization?

Well, instead of starting with the solution and then building a narrative you have to start with the stakeholder and construct a story that takes them to the solution. So, you start by identifying the stakeholder and showing that you understand their key requirements. Then you show how these requirements are delivered to by specific services. Then you show how these services are implemented by the technical solution.

Hubscope provides different perspectives which allow you to walk through this story as well as a feature which allows you to redraw a particular perspective from the point of view of an individual stakeholder.

Tip 7: Focus on relationships and key dependencies

Spreadsheets are great for considering lists of things. Asset inventories, people who work in a department, the projects being managed by a PMO, etc. What they are not good at is showing relationships between things. Relationships and connections are an important part of how we think and understand the world.

Graphs with nodes and connections between nodes are the best way to visually represent relationships. In the project world of IT, relationships can show things like:

  • who reports to who in the organizational structure
  • who owns a particular requirement
  • what requirements are satisfied by a particular service
  • which services need to be changed if an application is being updated, and so on.

Hubscope has lots of interesting ways of looking at relationships. One thing that you can do is navigate around the graph by starting at one point and then following the connections to see what that thing is connected to. There is also a function that highlights all first order dependencies.

Tip 8: Get started straight away

This may seem like a strange tip to be finishing with but what I often see is that people are reluctant to get started with the drawing. Some people are good at this in terms of sketching diagrams to help with their own thinking but this is not what I’m talking about.

I’m talking about those heroes who stand up at the whiteboard when the scope is unclear, the objectives are unclear and they start drawing to get everybody engaged and to co-create the way forward.

That’s what we’d like you to try with Hubscope. Get started today by clicking the button below and co-create better understanding with your team.

And if you liked this post, please share it with your pals using the buttons on the left …

The Thunderbolt Moment that Led to Hubscope
A simple methodology for visual project mapping