How capabilities mapping helped us see the bigger picture

Reading Time: 4 minutes

The problem

We have a transformation programme underway across Scottish Enterprise. It was getting harder to see what needed to be done to deliver the bigger picture – rather than just bits of the jigsaw. In addition, many people were focusing solely on ‘the bit you need to build’, rather than seeing the whole service – end to end, online and offline.

So how do we get that shared understanding?

We have used metro maps previously. They help explain the many ways a customer could access our services. They also help show the degree of similarity at a level that seems to work with senior leaders. We worked it through and brought two individual metro maps into one view.

Our combined metro map

Check out our previous blog post on how we build these maps

This still left us with a gap though. We needed to go down a level.

What we did

Back at the end of 2020, Ruth McArthur one of our service designers and Kerin McEwing one of our business analyst had started looking at ‘capabilities’. This was building on the work Ruth was leading on patterns. Unfortunately, the pressure of the Covid response meant they had to pause their work.

So, it was time to dust it off.

We gathered a small group together, made up of a couple of business analysts, service designers, our UI/UX lead and two product owners from the business. This gave a good spread of voices from all the projects that were delivering the programme. It also kept the group small. It’s a hard one, as everyone wants to be at everything, but that doesn’t make for an effective workshop. We needed to make sure the group between them had enough of the detail for a good conversation.

A service designer drafted a ‘capability map’ in Miro. It brought both projects together and showed the end-to-end service in a visual way that we could all then start to discuss.  For us, a capability meant ‘something that we needed to provide to help a customer achieve something’. So, for example, we needed the capability that allowed customers to enquire, and that could include a general enquiry or a service-specific enquiry.  

Working together

The first step was to work through the end-to-end map as a team. We talked through each project and discussed how similar or different each capability was in the context of that project. We looked at it through the lens of all our disciplines – the process, the business, and the user experience. Colour coding was used to show the 56 capabilities. Of those, 33 were essentially the same, 10 were reasonably similar and 13 were very different. As we chatted, we made Post-it notes of any discussion points we needed to come back to. Miro worked really well for this.

This image is the end to end capability map
End to end capability map

The second step was to go back through the map again, but this time the conversation was around readiness. How ‘ready’ were each of these capabilities for the two main projects. This time we used icons to help show whether work was well underway and on track, underway but more thought needed, or clearly not started yet. This gave us a state of readiness for each project and kicked off discussions which led to additional development estimation.

This image shows a small section of the capability map and highlights areas that are the same, similar or different
An area of focus: same, similar and different capabilities

The results

We now have a capability map that has given us a much clearer picture of the whole service. It has helped bring two project teams together and helped them understand the whole service but at a more detailed level than the metro maps can. We’ve played it back to wider groups involved in the programme and it has led to the formation of a new delivery plan.

It has also helped our stakeholders from the wider business understand how many capabilities are common and therefore how to prioritise their work. As an example, we have a capability for internal staff to make an assessment of an application. Both services require a scoring mechanism and although the relative scoring may be different, the thinking behind how we design and build it should be the same.  

We can research and design a capability once, and only change things such as project-specific language and content. The same applies to the technical build. This shared view ensures that where it makes sense to do so, we build the capability so it can be easily extended.

What we are doing next

It’s been said before, but it’s always worth restating – it’s the activity of mapping that matters most, not the final artefacts you produce.

We will continue to use this as a living, breathing thing. It’s helped us think about how we organise ourselves better to deliver what is a complex change programme. It will also help everyone gather around a longer-term roadmap of capabilities we need as part of an MVP and what will come later.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.