Skip to content

Capability Models

01.030.031 v20260810.001

Change Log

Purpose and Authority

This document defines how Capabilities are expressed, bounded, related, assessed, and governed as organizational means to create, enable, protect, deliver, govern, or sustain value.

It is the parent document for:

Canonical Definitions

Capability. An organizational ability to reliably produce, enable, govern, protect, or sustain a defined outcome through coordinated Players, Competencies, Practices, Patterns, Platforms, Products, Partners, information, assets, decision rights, and other necessary conditions.

Capability Model. A governed representation of the Capabilities an organization or other accountable system requires, together with their definitions, boundaries, relationships, dependencies, evidence, maturity, ownership, and intended contribution to value.

A Capability Model expresses the means by which value can be created or sustained. It does not establish that those means are present, sufficiently mature, economically justified, effectively used, or producing realized value.

Capability Doctrine

Capabilities Are Logical Expressions of the Means to Create Value

A Capability describes what an accountable system must be able to do, not merely its current organizational structure, process inventory, application estate, Product portfolio, Project list, or workforce composition.

Capability definitions should remain sufficiently stable for planning and comparison while being specific enough to guide evidence, Investment, accountability, maturity assessment, and Progression design.

Capability Does Not Equal Competency

A Competency is a Player-level observable Proficiency. A Capability is an organizational ability produced through coordinated conditions, which may include the Competencies and Proficiencies of several Players.

Strong individual Competencies do not independently establish a mature Capability. A mature Capability does not require every participating Player to possess identical Competencies or Proficiency levels.

Capability Does Not Equal Practice

A Practice is a repeatable discipline, method, policy, process, procedure, protocol, behavior, or proficiency system. Practices contribute to Capabilities, and one Practice may contribute to several Capabilities.

Capability Does Not Equal Platform or Product

A Platform is a shared, reusable, and extensible foundation. A Product is a coherent value-bearing proposition made available for use or consumption.

Platforms and Products may enable, embody, expose, constrain, or evidence Capabilities. Neither Platform availability nor Product delivery independently proves that a Capability exists or is mature.

Capability Does Not Equal Project

A Project, Program, Portfolio, Initiative, or other governed work object may create, change, or retire a Capability. Completion does not prove that the Capability is operating, mature, adopted, effective, or producing realized value.

Capability Model Components

A material Capability Model should identify, where applicable:

  • controlled name and definition;
  • intended outcomes and value rationale;
  • accountable system boundary and level of analysis;
  • owner and outcome accountability;
  • contributing, dependent, and constituent Capabilities;
  • required Players, Competencies, and Proficiencies;
  • contributing Practices, Patterns, Plays, and Playbooks;
  • enabling Platforms and Products;
  • relevant Partners and governed exchange relationships;
  • information, data, assets, controls, and decision rights;
  • current and target Maturity Levels;
  • current Maturity Position and Maturity Profile where used;
  • active Maturity Progression and Progression Application;
  • relevant Reference Progressions and Progression Patterns;
  • Performance Measures and evidence requirements;
  • assumptions, constraints, exclusions, and risks;
  • expected Effects and relationship to realized value.

Capability Boundaries

A Capability definition and assessment must declare the subject, accountable system, scope, time period, operating and market context, level of decomposition, and evidence basis.

The same named Capability may have different maturity, ownership, dependencies, or value contribution in different scopes. A maturity designation without an explicit boundary is incomplete.

Capability Decomposition and Aggregation

Capabilities may be decomposed into constituent Capabilities and aggregated into broader groups or portfolios.

Decomposition should improve decision usefulness. It should not create artificial precision or duplicate the same organizational ability at several levels without explicit parent-child relationships.

An aggregate maturity designation must not be produced by simple averaging where a material constituent is foundational, constraining, or insufficiently evidenced.

Capability Evidence

Capability evidence may include sustained operating outcomes; governed decisions and accountabilities; observed Practice execution; demonstrated Proficiencies; Product and service performance; Platform telemetry; Partner evidence; quality, capacity, continuity, compliance, risk, and economic measures; and evidence of adaptation, improvement, and sustainment.

Documentation, training completion, Project completion, Platform deployment, or management assertion may contribute evidence but do not independently prove Capability existence, maturity, or realized value.

Relationship to the Maturity Model

The Maturity Model defines the canonical continuum:

A Maturity Level is the highest sufficiently evidenced anchor. A decimal Maturity Position represents sufficiently evidenced advancement through the immediately next Maturity Progression while preserving that anchor as the canonical designation.

Relationship to Maturity Progressions

The controlled adjacent Progressions are:

A Maturity Progression is a governed adjacent-level Prescribed Pattern. Its typical content in the canonical and Reference Progression documents is illustrative, not comprehensive.

The actual prescription is established through registered Progression Patterns and a subject-specific Progression Application. A Progression Pattern may apply to several Capabilities, Competencies, Pillars, Effects, and maturity transitions.

Relationship to Efforts, Plays, and Playbooks

An Effort is bounded intentional work. A Play is a reusable prescribed Effort and subtype of Prescribed Pattern. A Playbook is a governed composition of Plays and supporting guidance used to pursue one or more Effects.

A Capability Model may identify relevant Plays and Playbooks, but Capability, Play, Playbook, Practice, Project, Progression, and Effect remain distinct.

Maturity, Performance, and Value

  • Maturity describes the sufficiently evidenced operating condition of the Capability.
  • Performance describes how it performs against defined measures and expectations.
  • Value describes the attributable and consequential outcomes enabled, protected, accelerated, amplified, assured, sustained, or realized through it.

A mature Capability may perform poorly, support the wrong outcome, or produce insufficient value. An Improvised Capability may produce substantial value through exceptional expertise while remaining fragile and difficult to sustain.

Governance

Capability Models must apply the Value Realization Principles, including Evidence Before Assertion, Designation, and Decision; Highest Sufficiently Evidenced State; Proportionate Applicability and Evidence; Cumulative Inheritance; Enabling Condition Does Not Equal Realized Value; Fit-for-Value Over Maximum Sophistication; and Contextual and Revisable Designation.

Changes to Capability, maturity, Progression, Effort, Play, or Playbook semantics require synchronized updates to the Value Realization Semantic Model, taxonomy, controlled vocabulary, registries, and derivative guidance.