Introduction
...
In this example you are measuring how capable the builder is using a number of criteria as listed above, your measurement isn't based upon just the service they offer. So a capability is more than a service or a function!
Use the following statement as a guide to yourthinking your thinking "being able to do building work doesn't make you a competent/capable builder". Most people can run (to some degree), this doesn't make them a competent capable runner, that competency capability only comes from training, eating well and plenty of sleep. In other words there are a number of key characteristics that must be developed in order to enable that capability (see comment 1 below).
The next thing to remember about a capability is that it is more than just in many cases the concept gets aligned against a business function, service or team, but it is none of these things. It is a logical entity with distinct measurable characteristics (as shown above in the building example) that work together to achieve a desired outcome. Typically a capability considers the following (a MOD perspective on the characteristics of a capability TEPIDOIL)
...
Alternatively one could choose to define capability using the architectural unification approach POLDAT
- Process (business processes)
- Organisation (structures)
- Location (Geographical information)
- Data (models, life cycles, security etc)
- Application (software, security, interoperability etc)
- Technology (infrastructure)
Both TEPIDOIL and POLDAT pay no attention to organisation unit boundaries (business unit, sector, service, function etc) but weave a conceptual path through segments of the enterprise, selecting those areas within those segments that, deliver with the characteristics needed by the capabilities required to deliver the outcome.
More often than not, an outcome is delivered through multiple capabilities
...