Maturity Progressions¶
Purpose and Authority¶
This document defines Maturity Progressions as governed Prescribed Patterns for advancing a Capability, Competency, or other explicitly qualified Maturity Subject from one canonical maturity anchor state to the immediately next higher anchor state.
It applies the Maturity Model and is a child of Capability Models.
Supporting guidance is maintained in:
- Reference Progression Model;
- Reference Progression Registry;
- the five canonical Reference Progressions indexed by that registry.
Maturity Progression. A governed, subject-specific, adjacent-level Prescribed Pattern comprising required Practices and Proficiencies, together with necessary enabling conditions, Investments, accountabilities, evidence, and verification criteria, that, when implemented and sufficiently sustained within the stated scope, can be verified as advancing a Maturity Subject from one established Maturity Level to the immediately next higher Maturity Level, and no further.
A Maturity Progression:
- begins from a sufficiently evidenced source Maturity Level;
- targets exactly one immediately adjacent higher Maturity Level;
- identifies the operating changes required to establish the target state;
- prescribes or cites Practices, Proficiencies, Plays, enabling conditions, and evidence;
- preserves the source anchor as the canonical designation until the target anchor is sufficiently evidenced;
- does not independently prove performance, an Effect, or realized value.
Controlled State and Progression Language¶
| Source state | Controlled Progression | Target state |
|---|---|---|
| M0 Conceptualized | Improvising | M1 Improvised |
| M1 Improvised | Normalizing | M2 Normalized |
| M2 Normalized | Rationalizing | M3 Rationalized |
| M3 Rationalized | Optimizing | M4 Optimized |
| M4 Optimized | Harmonizing | M5 Harmonized |
Past-participle terms describe anchor states. Gerund terms describe adjacent transition patterns.
Improvizing and Conceptualizing are prohibited variants for the M0-to-M1 Progression.
Four-Layer Progression Architecture¶
| Layer | Function |
|---|---|
| Canonical Maturity Progression | Defines the universal adjacent-state transition logic. |
| Reference Progression | Provides portable, illustrative, non-exhaustive guidance across Pillars, Effects, Plays, evidence, and risks. |
| Progression Pattern | Defines reusable prescribed logic applicable to one or more Progressions and one or more Maturity Subjects. |
| Progression Application | Applies one or more Progression Patterns to a specific subject, scope, source position, adjacent target, and evidence basis. |
A Reference Progression does not replace a Progression Pattern or Progression Application. A Progression Pattern may relate to several Capabilities, Competencies, Pillars, Effects, and Maturity Progressions.
Adjacent-Level Rule¶
One Maturity Progression advances one level only.
Valid:
M1 Improvised -> M2 Normalized
Valid as a Progression Roadmap containing separately governed Progressions:
M1 Improvised -> M2 Normalized -> M3 Rationalized
Invalid as one Maturity Progression:
M1 Improvised -> M3 Rationalized
Work associated with later maturity states may begin earlier where justified. Early automation, integration, or cross-boundary coordination may be useful. The subject must still satisfy and evidence the intervening anchors before receiving the higher designation.
Maturity Position and Progression Position¶
A decimal Maturity Position represents sufficiently evidenced advancement through the active adjacent Maturity Progression.
[ \text{Maturity Position} = L + P ]
where:
- (L) is the highest sufficiently evidenced Maturity Level;
- (P) is the Progression Position through the immediately next Progression;
- (0.00 \leq P < 1.00).
A Progression Position must be derived from a governed rubric. It may consider:
- applicable Practices established and operating;
- required Proficiencies demonstrated;
- enabling conditions established;
- mandatory gates satisfied;
- evidence produced and validated;
- material exceptions resolved or governed;
- sustainment demonstrated.
Weighting may be used where materiality differs, but it must not average away a mandatory foundational deficiency.
A subject at 2.9 remains M2 Normalized until M3 Rationalized is sufficiently evidenced.
Evidence Sufficiency and Applicability¶
Sufficient evidence does not require every conceivable artifact or indicator. It requires that:
- all applicable mandatory exit criteria are supported;
- material conditional criteria are supported where their conditions apply;
- not-applicable criteria are explicitly justified;
- evidence represents the declared scope rather than isolated favorable examples;
- operating evidence is distinguished from plans, outputs, and assertions;
- residual limitations and uncertainty are explicit;
- the validator has a defensible basis for the designation.
A Progression may be substantially implemented without the target level being designated. The target designation follows sufficient evidence of the operating state, not completion of the change activity.
Illustrative Content Rule¶
Descriptions of typical Practices, Proficiencies, Plays, evidence, enabling conditions, false positives, and transition relationships in this document are illustrative rather than comprehensive.
They do not:
- define a universal checklist;
- supersede a Reference Progression;
- supersede registered Progression Patterns;
- replace subject-specific entry and exit criteria;
- require equal intervention in every Value Realization Pillar;
- prove that cited Effects will occur.
The applicable prescription is established through the relevant Progression Patterns and Progression Application.
Progression Composition¶
Each material Progression Application should identify:
| Element | Required content |
|---|---|
| Progression identity | ID, title, version, owner, and lifecycle status |
| Maturity Subject | Capability, Competency, or explicitly qualified subject |
| Scope and boundary | Organization, function, Product, Platform, geography, Partner ecosystem, or other boundary |
| Source state | Highest sufficiently evidenced Maturity Level and current Maturity Position |
| Target state | Immediately next canonical Maturity Level |
| Value rationale | Why advancement is fit-for-value |
| Effects | Priority, contributing, protected, and adverse or trade-off Effects |
| Pillar relationships | Primary, contributing, affected, evidence-producing, and excluded Pillars |
| Entry criteria | Conditions required before the Progression begins |
| Progression Patterns | Reusable prescribed logic applied to the subject |
| Plays and Efforts | Reusable Plays and other intentional work |
| Required Practices and Proficiencies | Operating requirements to be established or demonstrated |
| Enabling conditions | Players, Partners, Platforms, Products, Projects, information, controls, and decisions |
| Investments | Capital, effort, capacity, time, attention, assets, and other commitments |
| Accountability | Accountable Player or body and material decision rights |
| Evidence plan | Sources, owners, timing, coverage, quality, and validation |
| Exit criteria | Applicable mandatory and conditional criteria for target designation |
| Sustainment period | Period over which the target state must remain operative |
| Validator | Player or body authorized to confirm advancement |
| Confidence and limitations | Residual uncertainty, exclusions, and evidence limitations |
| Regression triggers | Conditions requiring reassessment or downgrade |
Progression Lifecycle¶
A Progression Application may use the following lifecycle statuses:
- proposed;
- qualified;
- approved;
- planned;
- active;
- implementation complete;
- evidence pending;
- verified;
- sustained;
- regressed;
- superseded;
- abandoned.
The subject remains at its last sufficiently evidenced Maturity Level until the next anchor state is verified.
Improvising Progression¶
The Improvising Progression advances M0 Conceptualized toward M1 Improvised by placing the governed concept into actual or sufficiently representative operation and generating enough operating evidence to establish that the subject functions in practice.
Illustrative concerns include bounded operating context, initial accountability, minimum viable Practices and Proficiencies, safe experimentation, evidence capture, exception learning, and value-hypothesis review.
See Improvising Reference Progression.
Normalizing Progression¶
The Normalizing Progression advances M1 Improvised toward M2 Normalized by establishing a common, documented, transferable, consistently applied, and governable operating baseline.
Illustrative concerns include controlled terminology, standard Practices, required Proficiencies, exception governance, knowledge transfer, baseline evidence, and alignment between documented and actual operation.
See Normalizing Reference Progression.
Rationalizing Progression¶
The Rationalizing Progression advances M2 Normalized toward M3 Rationalized by simplifying and aligning the normalized subject and removing, consolidating, reconciling, or justifying material duplication, conflict, redundancy, and disproportionate complexity.
Illustrative concerns include variant inventory, authoritative sources, semantic and control reconciliation, dependency mapping, consolidation, retirement, retained-variation rationale, and validation of the surviving model.
See Rationalizing Reference Progression.
Optimizing Progression¶
The Optimizing Progression advances M3 Rationalized toward M4 Optimized by establishing systematic, evidence-based improvement against explicit and balanced value, performance, quality, capacity, cost, risk, continuity, and resilience objectives.
Illustrative concerns include reliable baselines, feedback loops, root-cause analysis, controlled experimentation, stable-work automation, capacity and Investment allocation, Effect trade-offs, persistence, and net-value validation.
See Optimizing Reference Progression.
Harmonizing Progression¶
The Harmonizing Progression advances M4 Optimized toward M5 Harmonized by establishing compatible, coordinated, and adaptive operation across material organizational and system boundaries while preserving justified local variation and autonomy.
Illustrative concerns include dependency mapping, semantic reconciliation, decision-right alignment, interoperability, coordinated Investments, end-to-end measures, local-versus-system trade-offs, continuity, and state-of-the-art renewal.
See Harmonizing Reference Progression.
M5 Sustainment and Renewal¶
M5 is the highest canonical anchor, but it is not permanent or terminal.
Harmonized subjects require continuing dependency discovery, evidence renewal, state-of-the-art review, Partner and ecosystem adaptation, continuity testing, fit-for-value reassessment, and controlled decoupling where integration no longer creates net value.
There is no canonical M6. Further advancement is expressed through renewal, recalibration, a changed scope, or future canonical revision.
Progression Roadmaps¶
A Progression Roadmap coordinates two or more adjacent Progressions and related Projects, Initiatives, Plays, and Efforts over time.
The roadmap must preserve the separate source level, target level, exit criteria, evidence, and validation of each Progression. It must not represent a multi-level sequence as one undifferentiated transition.
Relationship to Pillars, Effects, Efforts, and Plays¶
Maturity Progressions may relate to all six Value Realization Pillars using primary, contributing, affected, evidence-producing, and excluded roles.
An Effect is a canonical outcome class. A Priority is the contextual designation of an Effect as a scope-defining intended outcome. Citing an Effect does not prove it occurred.
An Effort is bounded intentional work. A Play is a reusable prescribed Effort. A Playbook is a governed composition of Plays and supporting guidance used to pursue one or more Effects.
A Progression may cite Plays and coordinate Efforts, but it remains distinct from a Play, Playbook, Project, Initiative, Practice, or Effect.
Relationship to Projects and Initiatives¶
Projects and Initiatives may implement some or all of a Progression Application. They may establish Practices, develop Proficiencies, deploy Platforms, create Products, change governance, or produce evidence.
Project completion does not prove maturity advancement. A Progression may require several Projects or may occur through continuing operational improvement without one discrete Project.
Relationship to Performance and Value¶
A Maturity Progression changes an operating condition. It does not independently establish that the condition creates net value.
Every material Progression Application should state:
- the value rationale;
- expected Effects;
- Investments and lifecycle burden;
- Performance Measures;
- evidence required to test value contribution;
- risks of under-maturing and over-maturing;
- fit-for-value target rationale.
A Progression should be stopped, changed, deferred, or reversed where evidence indicates that expected value does not justify the Investment or sustainment burden.
Regression and Reassessment¶
A subject may regress because established conditions deteriorate or because relevant market, professional, regulatory, customer, operating, economic, or state-of-the-art expectations advance.
Regression may reduce the decimal Maturity Position, return the subject to a lower anchor, invalidate the assessment basis, or require revised Progression Patterns and exit criteria.
Regression must be evidenced, explained, and versioned. It must not be used to manufacture artificial demand for change.
Progression Application Metadata¶
progression_application:
id: ""
name: ""
version: ""
status: "proposed"
subject:
name: ""
type: "Capability | Competency | Qualified Other"
scope: ""
system_boundary: ""
source_maturity:
level: ""
position: null
evidence_reference: ""
target_maturity:
level: ""
value_rationale: ""
domain_relationships:
primary: []
contributing: []
affected: []
evidence_producing: []
excluded: []
effects:
priorities: []
contributors: []
protected: []
adverse_or_tradeoff: []
progression_patterns: []
plays: []
other_efforts: []
required_practices: []
required_proficiencies: []
enabling_conditions: []
investments: []
accountable_player: ""
decision_rights: []
performance_measures: []
evidence_plan: []
exit_criteria:
mandatory: []
conditional: []
sustainment_period: ""
validator: ""
confidence: ""
limitations: []
regression_triggers: []
Prohibited Interpretations¶
Do not:
- use Conceptualizing or Improvizing for the M0-to-M1 Progression;
- treat a Progression as a Maturity Level;
- use one Progression to skip an intervening anchor;
- treat illustrative reference content as a comprehensive checklist;
- force a Progression Pattern into one Capability or one transition only;
- treat Project, task, documentation, training, Play, or implementation completion as maturity verification;
- average away an unmet mandatory exit criterion;
- use not-applicable designations without rationale;
- treat a Progression or cited Effect as proof of realized value;
- assume maximum maturity is the appropriate target.
Governance¶
Changes to controlled progression names, adjacent relationships, the four-layer architecture, decimal-position rules, ontology relationships, or verification principles require canonical governance.
Progression Patterns and Applications may be adapted within these rules, provided their source and target levels, evidence basis, value rationale, applicability decisions, and limitations remain explicit.