Building Capabilities

If you’ve been following our series, you’ll know that we believe that whether you’re restructuring an existing business or building a new one, the base unit of building a service aligned business is a capability. We’ve explored elsewhere the different types of capabilities (Case Managed and Core Standardised), how to structure services and the practicalities of building services. This article is concerned with the practicalities of building a capability.

As a reminder, a capability is the base unit of the purpose of an organisation, something the organisation does to fulfil its customer proposition. There are levels of capability, from top level capabilities such as “payments” or “customer relationship management”, to much more granular capabilities like “instant payments”, “customer onboarding” and beyond.

Capabilities are organisationally agnostic and don’t describe how an organisation is structured to achieve them, although they include the processes, services, technology, skills, roles, team makeup, etc that are required to deliver them. Capabilities can underpin a microservices technical architecture, and are particularly useful in ecosystem organisations, as well as reducing friction in more traditional organisations. Types of capability are covered in our article Case Managed and Core Standardised Capabilities.

We’ve covered elsewhere the rationale for developing capabilities, so we’ll dive straight into the practicalities.

Prerequisites

We’ll assume that your organisation has accepted that it wants to become a capability based organisation (purpose and vision), but even so, changing from a traditional hierarchical model to a capability-based model is a significant organisational and cultural shift, so in addition to the will to achieve a capability model, you’ll need strong top-down management support for the process of building capabilities (sponsorship). Building capabilities, like any change activity, takes skills, structure and investment of time and money (resources).

Common mistakes are simply to declare you’re a capability based organisation (nothing happens), to appoint capability leads and tell them to get on with it, or to give them very minimal support; just like any other kind of organisational change, this is risking failure as the skills to deliver change are very different to those which lead to managerial appointments in most traditionally built organisation. In addition, building an organisationally agnostic capability can be very hard for someone on the “inside” – and in most cases, a senior person in the legacy organisation is the best or most natural fit to carry the capability forward, having both knowledge of the capability and the influence to make things happen. So this is almost always the right way to approach it (there are exceptions, for example when building a new capability or if there’s significant political friction, in which case appointing a neutral external may be better).

Another prerequisite is skills. You’ll need business architects and facilitators who’ve done this sort of thing before, sometimes as part of a project or as part of an internal service. Capabilities, like organisations and services, are composed of a range of elements, and to get from current state to future state requires change in most areas, for most types of organisation. The more traditional the organisation, the greater the level of change, so more support will be required where, for example, metrics are short-term and cost-focused, and individuals are rewarded for the size of the team they command. Organisations with flatter, more informal structures see fewer barriers, but they can struggle with aspects of governance and accountability.

An important prerequisite is also timing, which relates closely to the purpose and vision. Typically, service organisations such as banks need to reach a tipping point where it becomes obvious to senior management and at least a significant minority of middle managers that change is needed, before progressing with such a radical change is possible. For flatter, more fluid organisations, the tipping point is usually more to do with scale; typically they’ve grown from startup to a medium size and are starting to feel a lack of structure and accountability impeding their ability to support customers effectively. Either way, a radical change of organisational alignment requires some sort of burning platform, combined with the management drive, otherwise passive resistance will kill the initiative.

Finally, change agents and cheerleaders are critical. There will be some people in your organisation who can already see the need for radical change, and on becoming engaged, they will do your groundwork by selling the vision in their teams, in the canteen and in their customer engagements. It’s very easy to identify these people; post something about changing to the model on the intranet and they’re the one giving you three cheers in the comments section. Capture them and use them, they’ll be thrilled to be involved and their enthusiasm will be infectious to the teams where they work. They don’t even have to understand what a capability is; give them a three para introduction and they’ll be with you.

Opposition to change

You need to accept that not everyone will buy in or get it. There will be people in your organisation who don’t see the need for change, or who for personal reasons are actively resisting change. In some cases the resistance is because they’re close to retirement, and early retirement is a positive outcome for these individuals, but in other cases the opposition may be based on empire, status, or simply fear of the unknown. Support can go a long way with these people but it’s important to decide, and stick to, where to draw the line, to avoid their influence becoming a serious roadblock to change. NB giving a capability lead or facilitator job to one of the resistors may work, but it’s a very high-risk strategy because of the ease with which they can implement passive aggressive strategies of negative progress.

We’ve found that strong resistors can be converted and, when they embrace the change, can become some of the biggest advocates and drivers in moving it forward. However, where there is persistent resistance and an inability to move forward, rational arguments can’t win and people who genuinely don’t want to embrace the new approach may need to be found other things to do. The best approach is to gracefully support them by finding them roles in other organisations more aligned to their belief system, but whatever happens you need to accept that keeping them in your organisation will not only hamper your ability to change, but impede your ability to run the organisation in its new form.

Moving the needle: identifying capability owners

Every capability needs two or more leads, one who is responsible for the direction of the capability and probably also the lead link (communicating to the rest of the organisation) and another who is responsible for prioritising work within the capability. The prioritisation role may also be combined with the skills development role, where the capability is a core standard capability and relies on internal skills development. Unless the organisation is quite small, it’s a good idea to separate these roles as the owner role is strategic, whereas the prioritisation and skills development role is operational. In smaller organisations, or if you’re very lucky to have leaders with the right breadth of skills, it may be possible to give both roles to the same individual, but we caution against this.

The first role you need to appoint is a capability owner. Identifying a capability owner also involves explaining to, and reaching agreement with that capability owner, what a capability is and what’s encapsulated in her capability. The usual challenges for managers to understand in traditional organisations are:

The capability does not own all the resources who perform that capability, but is accountable to the services for the delivery of that capability
The people who perform the capability will sit in multiple teams (unless core standardised)
The capability involves different areas of the organisation, some of which will stay functionally aligned in different areas of the organisation
The capability and configurations of the capability support services and outcomes, so while the capability allocates resources, the services are likely to decide what the people actually do
The capability is managed via metrics, rules and governance rather than hierarchy and management

So it’s important for all capability owners to be engaged in the process of understanding what a capability is and how they should govern it, before agreeing to accept the role. This can usually be managed by a series of dialogues and some case studies of organisations which have gone through this transformation successfully.

This can also be a discovery process; there may be many potential capability owners for any given capability in your organisation, especially if it’s currently quite fragmented. Discussing these considerations with senior stakeholders and potential capability owners will probably help you to identify the right person to take on the role, if it’s not clear from the outset. Broadly speaking, the right person to own the capability should be the person who’s got the most skin in the game for the capability to succeed, but that’s not necessarily the person with the biggest team involved in delivering that capability today. For example, a customer facing capability is likely to have a very heavy reliance on operations and reporting, but the natural owner is not in the operations or reporting space.

Define the capability’s purpose

Defining what your capability is for is the most important activity in the development of a capability, so ensure you allocate sufficient skills and time to this. You will need a business architect and representatives of the services that consume the capability, as well as someone who understands what it does. As with services, it’s best to define a vision of the end state before going into the detail of what happens today. This is because as you learn more about the details, your perception of what the capability does is likely to be influenced by what happens today, much of which may not actually support the desired outcome. There are various standard models that can be used to support this exercise but what your capability delivers to your organisation will be determined by the goals and values of the organisation, so be cautious with cut and paste capabilities, unless you’re doing something very standardised such as data centre provisioning.

As you define the purpose, also clarify the scope of the capability, both what’s in and what’s out of scope, so the boundaries can be identified. Scope definition can be tricky when you have a lot of instances of the same capability already within your organisation, because they’re likely to all be performing slightly different functions with slightly different purposes, so as you define the scope try to align as closely as possible to the purpose rather than taking too much of the as-is, or trying to please everybody. As you are moving towards a single definition of the purpose of that capability in your organisation, it’s likely that many of the activities that are done today within equivalent functions aren’t actually supporting the capability, so it’s inevitable that there will be a certain level of pain. Some good questions to ask are:

Is this scope necessary to deliver the purpose of the capability?
Is this scope actually necessary to delivering some other capability?
Is this scope core to delivering the purpose of the capability as we have defined it, or do we do this out of habit – the three habit reasons being:
Someone told us to do it (but I don’t know why we do it)
We’ve always done it (but I don’t know why we do it)
It’s in the process manual (but I don’t know why we do it)

These questions will help you to validate that the scope of the capability is aligned to delivering the business outcomes that make up the purpose of the capability. When you have agreed this, document it carefully and continue to refer to this as you progress with building the capability. We prefer to baseline the capability purpose at this point, and manage any changes under rigorous change control, to avoid scope drift as you progress. The biggest enemy to your future delivery is the current state, and maintaining rigour around the scope helps you to continue asking these questions as you get more involved in the detail.

Determine the services that will be delivered by the capability

The next step is to decide which services will support delivering the scope of the capability. In most cases, there will be a lot of different services and many, if not most of these, will also form part of larger services, for example a service to deliver servers into a data centre will also form part of the overall software delivery service, which in turn is part of delivering a business change. Some services will also call on other capabilities, and these can be black boxed and recorded as dependencies on those capabilities as you progress through the design. Using a co-created Service Design approach (see the separate article on this), start with the biggest services before drilling down into what supports them; this helps to avoid the trap of just capturing everything you do today and assuming it’s supporting the capability.

As you progress with the service design, you’ll identify sub-capabilities and lower level services; depending on your bandwidth you may want to start on the bigger services and sub-capabilities only, and work through the other elements of these before diving into lower level services. Once the key services have been agreed, smaller teams and even individuals can usually do a pretty good job of building the lower level services, with support from the business architect and facilitator.

The Service Design article gives details of working through the Persona/Problem/Customer Journey/Capabilities/Service cycle so we won’t repeat that here, however delivering a capability needs to move beyond service design, as you now need to create the building blocks that will deliver the services.

Structuring the change

Building capabilities is not the same as running a standard change programme, and can’t be done by simply designing a new set of services and processes and telling everyone to get on with it. Capabilities need to be designed by, owned by, and run by the people within the capability, to be successful and self-developing. If you’ve been following the method for service design, you should by now have a strong team of people committed to the change, with a good idea of what the services need to look like, which is a fantastic starting point and includes:

Service descriptions
Sub-capability descriptions (including internal and external to the capability)
Customer journeys
Customer personas and success factors
Key success metrics
Service interactions and probably a few process descriptions

You should also have reached a point where people have started to adopt natural roles including leadership, within the change project. Now’s a good time to formalise those roles, identify any gaps, and think critically about the skills you will need to achieve the change. Most of those skills will, and should sit within the capability itself, and if the team still feels the need for strong external facilitation, it’s a good idea to start building that skillset internally, as it will be needed a lot on the journey forward. Key roles you will need are:

Leadership – this should by now be your capability owner, however it’s fine to delegate leadership of teams building lots of parallel services if your team is large. This role will be leading a wide range of activities so some familiarity with change management is useful, and it may be worth providing some formal training in Agile change.
Planning and prioritisation – it’s unwise to develop over-complex plans because as you deliver the services, they will continue to evolve, however it’s very important to set clear objectives and priorities and to allocate resource time to them, set targets and evaluate success.
Coordination and communication – don’t assume change will just happen! There is effort involved in moving from one state to another and even in agile, team-led projects this takes resources dedicated to producing artefacts, managing communication between teams, reporting upwards and maintaining plans.

As you progress to build the services, it’s also important to consider some key outcomes for any successful capability, as these will impact not just the services, but also how you build the charter and governance for the capability:

Sustainability and continuous improvement: as soon as you implement any new service, it will start to age and depending on the nature of the service and customer, may be out of date very quickly. So you need to build in the ability to critically examine the successful outcomes, learn and adjust as the capability runs. Feedback loops are important, and in addition to feedback, build in flexibility so that it’s possible to change elements of the service without having to go through massive governance. The accountability for these decisions need to be within the capability and not owned elsewhere (see our article on Decision Architecture for more detail on this).
Communication and governance with other capabilities: no capability operates in isolation; both governance and roles need to acknowledge the need to interact with other capabilities and to respond to the changing needs of the organisation in a coordinated fashion. This may also include coordination with capabilities outside of the organisation.
People development and training: it’s important that career paths, with either traditional or emerging structures, are embedded into the capability, and that people have the opportunity to learn and develop. This should be via a mixture of on the job development, formal training and peer learning. This needs to be embedded into roles and team objectives as they are developed.
Communication and documentation approach: organisations of any size, and in particular regulated ones, need to be able to explain what they do both internally and externally. However brick-shaped process control manuals are not only labour intensive, they’re also usually out of date and inaccurate, because of the effort of changing them, while they’re often not closely followed even if they are kept up to date, because of the effort of learning them. Your documentation approach needs to capture enough information to be useful for training and communications purposes, while being fresh and easy to use – we recommend highly visual, online service descriptions with feedback mechanisms, wherever possible.
Visual management for teams on the ground – very much a key to identifying immediate problems and imbalances with the workload, visual management tools can be as simple as different coloured in trays for different levels of urgency, and there’s a huge variety available. These are key to capturing some of the operational metrics for your feedback loops.

Starting out by planning to include these outcomes in your capability build will embed them into the service designs, and lead to a much greater chance of successful delivery.

As we’ve said before, capabilities cover a wide variety of activities, as outlined in our Capability/Service Operating model and it’s important that all of these are considered when planning each service. Not every service will need all elements, so use this as a checklist for purposes of elimination, however every service will feature a large majority of these elements.

Change approach

We recommend an Agile approach, working with backlogs and sprints. As we mentioned above, this may require some training for your teams but we’ve found it’s most closely aligned with the co-creation, team-based delivery approach that we’ve found to be successful for capability delivery. The main challenge with Agile delivery is that it requires the whole team to have a reasonably good understanding of how to work together, while another challenge is that many teams skip important documentation; with the right training and commitment to deliver effective communications material you can mitigate these risks.

Alternatively, you may choose a more waterfall approach, if your team is dispersed or you have limited ability to co-create, however this approach has several downsides for capability delivery: it’s slower, less likely to get team buy-in, and likely to deliver services that are rigid and unable to evolve. If you choose this approach, it’s very important that your core team is not just taken from the capability team, but that you also have a significant rotation between the “home” capability and the change team, to avoid a “them and us” mentality arising, and to do regular live proving to keep people engaged.

As you deliver (we’re assuming with an Agile or Agile-like approach), there will be frequent deliveries of new services, adjustments to existing services and new roles, processes, etc. On the whole this can be managed organically by releasing new processes, services and roles via standard distribution channels, however there will be points at which you make some fundamental changes, such as a change to team structures, removal of processes and IT systems or introductions of new ones, which will need to be more formally planned and orchestrated. Although we’re advocating Agile as an overall delivery method, it’s perfectly OK to have a formal waterfall plan or two in there if needed, to support these unusual events.

When making changes to services, processes and IT, nearly everything you change (and in particular IT) is likely to impact other parts of the business, many of which are not going through the same change at the same time. Where this happens, identify where your change sits strategically in the IT architecture roadmap for the organisation and, if it’s not aligned to the strategy, you may need either to question your proposed approach, adjust the strategy, or, more likely, both. Engage your sponsor and leadership in driving necessary changes, rather than accepting the status quo, but work collaboratively with the organisation, rather than against it.

If you’re building early capabilities, it’s likely that the change approach you’re taking will be relatively unfamiliar to the organisation, and that may lead to confusion and frustration, particularly with change governance or IT change in your organisation. While it’s important to work within the financial commitments of your organisation, it is also important that your ability to implement change isn’t too significantly hampered by these things. Prioritisation of the IT agenda is a common problem, and if there’s a large queue, as there is in every organisation we’ve worked in, you will need to both release incremental changes, which can be done by changing roles, processes, etc independently of IT systems, while you use your sponsorship to ensure any IT changes are managed within both architectural governance and reasonable timeframes.

We hope it’s clear that keeping the whole capability team engaged and informed throughout is critical, and even more important is to ensure this isn’t something done “to” them, but “by” them. Building skills such as Agile delivery into the core team will help them manage the continuous improvement in live operation, while your early capability deliveries will yield people who can move into other areas of the organisation and support other capability development, having learned through doing.

Declaring victory

Something that’s always been drummed into us as change managers, is “don’t declare victory too early”, and this applies to capabilities as much as to any other type of change. It’s easy to get very excited and enthusiastic about the change you’re going through, especially when you can see the benefits that will emerge, but the rest of the organisation may be experiencing the change very differently, especially if they’re having to make changes to accommodate you. You may be very excited about how effective your kanban boards are for the team, but to the rest of the organisation, until there are tangible results, they may look like an unnecessary and distracting fad.

The good news is that, even if you’ve got a long queue with IT, you will see changes to customer outcomes rapidly as you start to embed the new services. This is another reason to have robust metrics and feedback loops, and as soon as you see results, that’s the time to declare victory!

In addition to providing great service improvements, however, you’ve done a lot more over the course of the capability build and it’s important to recognise this both to your team and to the rest of the organisation, to raise awareness of the benefits:

Ability for teams to self-improve services and processes
Immediate feedback loops (visual management and metrics)
New team skills and skills development plans

Conclusion

In this article, we’ve filled some gaps in the practical considerations for delivering capabilities, not covered by other articles. To get the full picture please follow the links, in particular to the Customer-experience led service design and Case Managed and Core Standardised capabilities, for additional material.

Building capabilities is a change activity which requires effort, skills, commitment and structure. It’s also a community effort for the capability, which will result in the capability emerging as strong and sustainable. Management and leaders need to be committed to involving, engaging and supporting the capability community as the journey progresses, and to celebrate the results when they emerge.