Dependency Mapping

Recently, I published an article where I discussed the concept of dependency as a proxy for complexity. I also tried to show that complexity is the biggest aspect to consider when attempting to improve the flow of value. This is all part of a concept I call Dependency Mapping.

Following publication of the article, I had a few people who read it on LinkedIn reach out for some advice on actually doing it in their place of work. In this article I will dig deeper into the process by which we can start to map out dependencies. With the map completed, we can then work to remove them.

Dependency maps are going to be messy as they try and convey a huge amount of information. We’ll aim small, and then offer some suggestions for improvement from there.

Prepare for the workshop

First things first, we’re going to need a few things for a successful workshop. Mostly, this will be people. You can either map a sub-section of your system, or the entirety. I’ve done both, and this choice is largely down to scale and availability. Ideally, try and get as much of the system represented as possible. I’ve run this as a full day for 60 before and that was fine. If you are missing key roles, functions, or divisions, then you’re map will be incomplete.

Don’t invite entire teams, but make sure the people involved can answer questions like:

• “For this piece of upcoming work, which of the the other teams will you need to go and request time from?”

• “Who else do you need in order to complete this?”

• “If I locked you and your team in a room, who else would I need to add so that you can get this completed and with a customer?”

You will also need some materials:

• A large room with plenty of wall and table space

• Plenty of large flip chart paper or magic whiteboard

• Pens, stickies, tape, etc. Everything to be creative.

Starting the Workshop

Whatever your chosen workshop or training approach, make sure you do one thing. At the start of the session, get each represented group to write their group identifier on a sticky and add it somewhere where everyone can see it. We’ll use this as inspiration later. By group identifier, I mean team name or function. Something unique to them.

Dependency Mapping

So now we can start the actual Dependency Mapping. The general idea is that we want to build up a network map of all dependencies. Hopefully, we’ll end up with something that looks like the following. This graphic is just the output of some random nodes and relationships, but it gets the picture across. We’ll want to know how interlaced the different aspects of our system are.

Here is my favoured guidance in building this out:

Think of the work

Get each group to go and think of their work. Think of all the projects they completed in the previous 3 months. Think of what’s next on the horizon. Think of all the work they’ve been happy with, or disappointed with.

The intent is build a repository of known work that can be used in the map. Get everyone to write each item on a sticky and pop them on their canvas of choice.

Time this activity, then get everyone to share their work with the wider group.

Identify the Dependencies

With this complete, you should now start to identify where the dependencies are. We chose to create a list of known work as a platform to help the teams think through cases where they have needed external expertise.

Get the teams to work through each piece of work and build a list of dependencies using the group names from the wall. If any team thinks of a dependency not captured on the wall, then feel free to add it.

For each dependency, ask the teams to draw lines from the pieces of work to the dependency. This will inevitably get messy, but don’t try and control it. Let people draw it out however works for them, we just want the final output.

Iterate

One of the biggest benefits to getting everyone together is that the groups can interact. At the request of senior leaders, I’ve previously this piecemeal over days or weeks, and it never works as well. We end up missing too many aspects.

Get each group to share their maps with the wider room. We are hoping for conflict. It is almost certain that people will not have been able to think of everything, so getting everyone else involved is our chance to plug those gaps.

As each group progresses, encourage the room to collaborate on fleshing out the map. I’ve never gone through this process and not had dozens of comments along the lines of “How are you going to deploy that without a firewall change, Jim?”.

Cleaning up the maps

You are going to need to do some serious analysis on these maps, so give everyone some time to go and redraw their maps.

If you want to, there is an excellent piece of information that you can gather from these draft maps. Previously, I have added a second tier to the maps in the form of the work items, and then linked dependencies beneath those. This gives the added benefit of being able to highlight upcoming work that is most at risk. We used this in a large financial organisation to show that their mission critical B2B project was almost certainly not going to complete as expected.

Everyone should now have a list of their known dependencies. Time to pull it together.

Building the completed map

I’ll leave this up to you, but you now need to get all of those individual maps merged into a cohesive graphic. A graphic that you can understand, and digitise in the comfort of your office.

Personally, I would recommend building off the wall nodes that you gathered at the very start. Remember those stickies with the name of each group? Work through each one and get them to list their dependencies, drawing appropriate lines as you go.

Finishing Up

You should now have a rather large, and completely unwieldy, dependency map for the system under scrutiny. The next step is to digitise and analyse. No doubt you’ll be able to come up with a decent strategy just by looking at it, but in the next post I’ll share some step by step guidance as to how you can go about learning and planning from what you’ve gathered.

Think about what you have in your hands, it’s essentially a network map of the system. This map is telling you where the problems are. When you have a hand-off or a delay, you introduce waste and complexity. It is this effect that is slowing your rate of delivery and reducing quality. Increasing dependencies will decrease ownership. The more functionally aligned your system is, the greater chance of teams resorting to isolationism. Who is thinking of overall quality if the work is passing through multiple teams on its journey?

The tactic is to cut these links by evolving towards strategically aligned teams that are able to fully execute on a complete value stream. But we need to be careful not to disrupt the rest of the system through our activities. Removing an external link will also kill an internal one, leaving an orphaned dependency.

In the next post I’ll walk you through how to go about capitalising on the wealth of knowledge you now have in your hands.

Alternate Ideas

Extra data

Here are some additional pieces of information you can capture at this stage. It will make the analysis more complicated, but will provide you with greater insight.

• The name of the dependency

• Classification, such as Process, Tool, or Person

• The relative size or frequency

• Impact of removing the link

Extra layers

Here’s an example of a dependency map that was built with the additional lens of complete and upcoming projects. Earlier I mentioned that you could keep the initial version and build off it to add another dimension

• Blue – Team

• Teal – External Teams

• Orange Clouds – Projects

• Red Lines – Directional dependencies

• Purple – Common services within the organisation

Note that lines come out of the teams directly when all of their work requires the use of that dependency.

I work at DevOpsGroup, helping our clients solve complex problems relating to Agile, Lean, culture, organisational design and data-driven business.