Capability Modeling Guidelines | How to Structure a Capability Map
Designing Capabilities Around Activities or Objects
As mentioned in the previous section, capabilities should always be designed around “what belongs together and is distinctive from other capabilities.” While this may sound obvious in theory, designing for togetherness is challenging in the reality of complex enterprises. Among the thousands of processes that occur in an enterprise every day, which ones are similar enough to be grouped within the same capability?
The best way to identify processes (and their required people and assets) that belong together is to look for specialisations - where do we need similar, special skills? Where do we need similar, special assets (like machines, applications, raw material, buildings)? Once you have identified these specialisations, you need to ask questions such as: “Is building railway assets so similar to maintaining railway assets that we should put it in the same (level 2) capability?”, “Is building a track similar to building a station?”
Depending on the answers we have two options:
1.) Grouping by Activity
Planning railway assets differs significantly from building and maintaining them. However, building and maintaining all types of railway assets may be “similar enough” to categorise under a single capability group. In this case, we group by activity: “Railway Asset Management” with lower-level [[capabilities: “Plan Railway Assets” and “Build and Maintain Railway Assets”.
2.) Grouping by Object
Building and maintaining tracks is very different from building and maintaining stations. These capabilities require different engineering skills, processes, and machines. Therefore, we group “Build & Maintain Railway Assets” into lower-level capabilities: “Build & Maintain Railway Tracks” and “Build & Maintain Stations”.
Practical Tips
Co-design what “belongs together”.
Choosing whether to group processes and their required people and assets by similar activities or similar objects is a design decision — a conscious choice with trade-offs. There are always alternatives, and each choice comes with its own opportunities and constraints. Experiment with different approaches to help both you and your intended audience see and agree on the implications of each option.
Break down into typical Sub-Capabilities.
Break down higher-level Capabilities either into typical sub-activities, such as Plan, Build, Run, Deliver, and Maintain or into sub-types of objects, e.g. “Railway Asset” → “Tracks”, “Stations”, “Powerlines”, “Powerplants”.
Make the criteria for “belong together” clear for all co-creators.
It can be challenging to agree with the many co-creators on how to recognise the criterion “belongs together” and on the hierarchy of capabilities. Defining a set of clear criteria makes it easier to agree. Those criteria can then be defined as enterprise-wide principles for future change initiatives.
Example: Intersection Railways
The following example illustrates how grouping the elements of capabilities always requires intentional design decisions between “grouping by similar activities” and “grouping by similar objects”:
