Visualising the Network of Services

The first practice of Kanban is to Visualise. We also have our Service Delivery Principles that state that “Your organisation is a network of interdependent services…”. For many years in a number of different organisations, I’ve been trying to understand and navigate this “network of services”. I’ve found it very useful to combine these aspects of Kanban so that I can, as a coach / consultant, understand problems in the organisation so that I can help target improvements. In this post, I’ll explore more about how I would go about doing this. In future blog posts, I’ll look to provide more details about who the audience would be for this and more detail about why you’d do it from those different perspectives and look into other aspects of using this to improve the network.

As an external consultant, I often have a limited amount of time in which I would like to make the most impact as possible on an organisation given my brief and scope. After years of helping organisations, I’ve found that where the pain is experienced in service delivery, is often not where the source of the pain has been generated. Often it may be upstream of where I’m first told to look, or it could be where I’m told to look is generating pain further downstream. As I navigated more complex organisations, it has become important to be able to map out the network of services to deal with the key problems involved. Indeed, the Service Delivery principles encourages us to optimise the network and to do so “seeing” the network can be critical.

At first, at a lower maturity level, I start looking at which teams / group are doing what kind of work. At this point, I really haven’t identified the services involved. It’s often easier to ask for this kind of information because most organisations at a lower maturity level are really thinking about organisational structure and teams rather than services.

As you can see, this kind of interaction is a little simplistic – you can see some connections and some interaction which gives you clarity on information flow. When you compare this with a more mature network service example, you can see just how different the two are. Note that in this example, there are more services and groups involved – this often occurs as you lean more about the organisation. I’ve overlaid team names on the key services so you can get an understanding of how the above has translated below.

I then started to work with more complex examples and larger organisations – 2000K+ people. I began to draw out the network at a more portfolio scale and came to examples such as this:

There are multiple service areas / portfolios in this diagram – usually each area might have between 4 and 12 teams providing services for the themselves and other groups – except for areas A and B, who only provide demand for other teams (they haven’t got a delivery capacity per se). All of the other service areas create demand for the capacity that they have in their own area (as signified by the line connecting a Service Area to itself). We can also see Service Areas M and N who don’t have dependencies on the other groups (at least at this stage) as denoted by their lack of connectivity to the rest of the network. You can also see where there are deeper and shallower connections here denoted by the thickness of the line – the thicker the line the more requests between the areas.

You can start to get a better understanding of potential bottlenecks, increasing / decreasing demand plus a number of other insights in your organisation. Further details will be expanded upon in future blog posts.

Depending on the nature of the problems in your organisation, you might want to visualise different aspects of the network. Some examples of things that you might want to visualise on you network include:

  • Nodes
    • Sources of demand
    • Different capabilities / services
    • Capacity of a node
    • Speed of a node
    • Throughput of a node
    • Reliability / Predictability of a node
  • Links between nodes
    • Relationship between demand and capability
    • Number of requests
    • Types of Requests
    • Classes of Service
    • Order of workflow steps
    • Requests servicing upstream or downstream

As you can see just from the visuals above you can start to make insights based on what you’re seeing. Seeing problems is the first step to remedying them and making improvements, so when you’re dealing with problems at scale this can be inherently valuable. In future posts we’ll examine who can use this and what they can use it for in more detail.