Network of Services – understanding demand and capacity

In the previous post Visualising the Network of Services, we explore the idea of visualising a network with a few basic examples. In this post, we’ll explore specifically more details on how and why you would do this for understanding demand and capacity. Following this, I’ll also describe what potential actions you might like to take to balance the overall network.

What’s important to point out at the outset is that there can be many points of supply and demand throughout the network. It’s not necessarily just that a single request maps to a single response – there’s often many interdependencies of services that are built into the network and are necessary to fulfil the ultimate customer need.

An Example Situation

Let’s say we’re looking to add a new feature to an online service for customers:

• Product Managers start exploring potential user needs. They engage others to help them understand the market:
  • The Customer research team – puts together a research activity to understand in more detail what the customer need is and how they’d interact with the existing product to achieve the need
  • The User experience team – start to put together designs of how the application would look based on the customer research
  • The legal team – to review content to ensure that it’s compliant with consumer and other laws
  • The technology teams – for how this might be integrated with the existing technology platforms.

The above is essentially a view of what happens “upstream” as the requests are actually being prepared. Anywhere along this journey, the product team might decide that this is not viable / feasible and discard the idea to come up with something else. Assuming it’s ok, here’s some more examples of other services that might come together:

• Product engages technology to begin building out the capability:
  • Web application teams – To get the functionality working on the web application that’s available to customers
    • HR Team – Noticing that they need some specialisation, the web team look to get a contractor in to help with the efforts of this new feature
    • Operational support teams – for setting up monitoring / alerting for new functionality / apis that have been built
  • Mobile teams – To get the functionality working on the native mobile applications
    • API teams – these are often engaged by either / both of the web mobile teams to build the underlying APIs that both will use
    • Operational support teams – for setting up monitoring / alerting for new functionality / apis that have been built
  • Customer Relationship Management (CRM) teams – there’s often an underlying system of record that will need to be updated with the data that has been submitted by the users
  • Metrics capture – oftentimes the web / mobile applications interact with systems that capture metrics about user interactions for later reporting / analysis by product
  • Data Warehouse teams – for storing data from the underlying systems and providing reports to the product team
• Product engages with additional teams to prepare for launch:
  • Sales: to ensure that sales reps are familiar with the new capability so they can upsell when they talk to their premium clients
  • Marketing: to setup new campaigns about the new functionality to draw in new users and upsell to existing users. Marketing, in turn, needs assistance from others to make this happen
    • Web teams – to make sure the new campaign information is available on the company website
    • Legal – to ensure the content of the campaign is compliant with local laws
  • Customer Service Desk teams: to ensure they’re aware of the new feature and how the new offers will work in relation to it

This is just one example of how something that might seem simple on the face of it, will generate a multitude of service requests that resonate throughout the organisation. This is beyond just technology – if you’re just doing this with technology, you’ll only be getting part of the picture and will be missing key points. I often see this done in just technology teams, but with the example above we can see that this accounts for about one third to one half of the requests above – the bottleneck is not necessarily in technology and seeing these problems across the network will help you understand where your improvement efforts should be.

Network of Services Visualised

In the above example, the originating source of demand is the product management group. I’ve coloured the lines to differentiate the types of request into upstream, build and launch activities to help highlight the different areas for the requests. Not that in the above, some of the requests have generated “child” requests with other services. A good example of this is where the Web Application team need to engage with HR to bring on a specialist. You can see that with this original idea, there are a variety of services that need to be fulfilled to ensure the final outcomes with customers. There may be bottlenecks in any of these points in the system that hold things back.

Other Demand / Capacity Examples

In the example above, we can see for a given time period, how many items were requested and how many items were completed. In some cases there are many more requests coming in than going out. In this circumstance, we see an increase of WiP in the team which will cause lead times to increase and can be a source of unpredictability. In this case we can see the Mobile Application features service being overwhelmed with requests, along with Legal. This may mean we need to look into these areas and better shape demand coming into them to prevent flow problems. Alternatively, this could also be a good indicator that you need to add capacity to those groups.

We can also see that Mobile Application features are getting done when requests come from Technology Architecture with good balance between request and response, but not so much when coming from Product Management directly. There might be a different class of service being used here – perhaps incorrectly. This might warrant further investigation to ensure that the right policies are in place to keep the right balance between sources of demand.

Alternatively, we can see certain groups, like User Experience Design, who finished more than they started. This might be ok because they’re clearing out some old items, but it also might indicate that this group may be seeing a decline in demand and possible starvation. There’s a number of things that you might want to consider in circumstances of starvation including getting folks to help out others to improve flow overall, they may balance it by ensuring there are enough options coming from product to work on. Alternatively, they might generate internal demand to improve their capability with the group / service.

The image above is basically the same, except that we’ve added some colour to it. Black where there’s even flow, green where there’s more completed than requested and red indicating more requested than completed. This makes it a little easier to see whether or not the overall system is balanced – we can see more red than green which is a good indicator that we have an increasing WiP load coming into the system. You might also introduce rules that say if the difference is, say, just one item, show it as black which will allow you to focus on the key bottlenecks a lot faster.

Using this from an overall organisation or portfolio level you can see where things are within balance and outside of good balance tolerances. Having this level of transparency and data helps you deal with actual problems in the system rather than symptoms within a limited field of view. Consequently, your actions to correct these are going to have more impact on the overall outcomes that you can achieve. This will allow you to create better customer outcomes, faster and with less stress on your employees creating the right engagement and focus.

RETURN TO BLOG