It's much easier to build a capability model from an example than from scratch. Here's how they're typically structured and how to adapt one to your organisation.
Capability models across very different industries converge on a similar structure, which is why starting from an example works so well. Almost all of them separate three kinds of capability.
Strategic capabilities set direction — strategic planning, portfolio and investment management, risk, compliance, performance management. Core capabilities deliver the value the organisation exists to produce, and are the ones that differ most between industries. Enabling capabilities support everything else — finance, HR, legal, facilities, IT.
The useful consequence: roughly two thirds of any capability model is broadly generic, and the third that is genuinely specific to your industry is where your attention should go. Copying the enabling and strategic layers from a reference model is not laziness; it is the correct allocation of effort.
| Industry | Core capability examples |
|---|---|
| Financial services | Product & proposition, underwriting, credit decisioning, claims or servicing, treasury, regulatory reporting |
| Manufacturing | Product engineering, demand & supply planning, production, quality management, logistics, aftermarket service |
| Retail | Merchandising, assortment planning, pricing, store and channel operations, fulfilment, returns |
| Higher education | Curriculum design, admissions, student lifecycle, research management, alumni and advancement |
| Energy & utilities | Asset management, network operations, field service, metering, trading, customer supply |
Note that even here the second-level breakdown rhymes. Most core capabilities decompose into planning, executing, servicing and measuring — which is a useful prompt when you are stuck on how to break something down.
A typical level-one and level-two extract for a mid-size organisation:
Forty or so capabilities across six domains. That is a workable size — small enough to assess in a fortnight, detailed enough to make duplication visible.
Building from a blank page produces weeks of debate about naming and a model no more useful than the one you would have got by editing an example. Take a reference model and change it.
Three edits do most of the work. Rename anything your organisation would not recognise — if everyone internally says "book management", do not impose "policy administration". Delete capabilities you genuinely do not have rather than leaving them in as aspirational. And split any capability where you know two distinctly different things are happening under one label.
Then test it: take three recent initiatives and map each to the capabilities it touched. An initiative that maps to nothing means something is missing; one that maps to a dozen means your capabilities are too coarse.
Use noun phrases, not verb phrases. "Customer Management" is a capability; "Manage Customers" describes a process. The distinction sounds pedantic and matters in practice, because verb phrasing invites people to decompose into process steps and you end up with a process model wearing a capability label.
Keep granularity even across domains too. A model with fifteen capabilities under Technology and three under Operations tells you who was in the room, not how the business is shaped.
Level one gives you six to eight domains for executive conversation. Level two gives you thirty to sixty capabilities, which is where assessment, application mapping and investment planning all happen. Level three is worth producing only for areas you are actively working on.
Decomposing everything to level three feels productive and is usually avoidance of the harder work. Once you have a model, the next step is to put something on it — see building a capability map and the maturity model.
The Business Capability Assessment Toolkit ships with a 40-capability reference model across six domains — a ready example you can adapt in minutes.
