The concept of capability is often overloaded with additional aspects in capability frameworks. One may wonder if capability has become a wish list for missing business, strategical, operational, and technical talking points? The presence of these infused aspects may, to a degree, explain why there are many variants of capability based analysis’s and planning methods. Some aspects are there explicitly included and described, but many are tacit or implicit. 
A capability can easily become a box, a square or a component (Capability Component).

An example: a capability can and is often thought of as also being a Unit-of-Responsibility. The logics of responsibility, organisational design, and program management is intermixed with the logics of the underlying concept (operational concept, function, or…) and capability management. Mixing aspects give raise to complications.

In this example, the Unit-of-Responsibility is defined by the nature and logic of a responsibility. An organisation (the whole) is divided into spaces of responsibilities that are assigned to someone or a group. Unit-of-Responsibilities are preferable non-overlapping and can be further divided into smaller responsibilities by delegation.

Let’s start by defining Unit:

“An individual thing or person regarded as single and complete but which can also form an individual component of a larger or more complex whole.” [Oxford Dictionary]

What kind of Units are commonly found interweaved with Capability?

The following list is not exhaustive but enough to provide a sense of intermixing complications and possibilities.

  • Unit of Deliberation: Maybe the most important unit. Being able to use capability in discussions as a talking point, topic, component, part, or module is reported across the board as vital and a key reason for using the idea of capability;
  • Unit of Planning: Plans contain distinguishable planning elements and a capability can be one of them. The whole plan and parts must be aligned with each other. The logic of planning is interweaved with the logics of capability (and the the logic of underlying concept);
  • Unit of Measurement: Organisations, projects and their parts are measured and data are kept and integrated in business intelligence systems. A capability is often measured and should be interweaved with data collection regimes and quality systems;
  • Unit of Performance: How well something is constructed or performs is often monitored. A capability is a representation of a performance (how well) of how the source parts lead-to a result. It should be aligned with other performance elements in performance frameworks, including vision, goals, objectives, assessments, evaluations, and rewards;
  • Unit of Purpose: A purpose is the reason for which something is done or created or for which something exists. A capability can be defined as the possibility that a result, fulfilment of a purpose, is achieved by the sources through a lead-to mechanism;
  • Unit of Value Creation: Business and customer values are created by organisational actions and capabilities may be defined to match each individual value creation activity; The value creation logic determines or influences strongly the structure of capabilities.
  • Unit of Function: A business function can be thought of as a process or operation that is performed routinely to carry out a part of the mission of an organization. It is common to define capabilities that depend on functions, The logic of functional deposition determines or influences strongly the structure of capabilities;
  • Unit of Prescription: A prescription is an authoritative recommendation. A capability can be used to prescribe something in the future. It should be intermixed with various governance systems, policies, principles, rules, instructions, strategy elements, guides, and recommendations;
  • Unit of Specification: A Specification describes something that others should realise or implement. A capability can be divided into a Capability Specification (CS) and a Capability Realisation (CR). A CS must be intermixed with other kinds of specifications and their parts;
  • Unit of Configuration: Parts of an organisation, product line, or production may be configured or assembled for a particular market, product or customer. A capability can be divided into two parts, a Capability and a Capability Configuration (CC) where many CC can be configured to realise or implement a single Capability. All CC must be must be intermixed the underlying logics of other kinds of configurations;
  • Unit of Analysis: The competence of retaining customers can be studied by inquiring the Capability related to the marketing concepts of Customer Retention. A capability in an analysis must be aligned with underlying concepts and align well with other analysis concepts;
  • Unit of Change: Changes can be expressed as a transformation, GAP, AsIs vs. ToBe, or simply a ToBe. Capabilities are used to anchor changes and should therefore be aligned with change management and transformation logics;
  • and many more;

All in all, an approach to Capabilities can simultaneously carry with them the logics of many Units (discussion, planning, function, measuring, specification, responsible, monitoring, performance, change,…)

At the end, one can reasonable ask …

  • if the net result is a set of capabilities or a cluster of units? Or both? or something else?
  • what does a capability map adds to someone in their work, in addition to the logics of interweaved units?