LEARN. PRACTICE. GROW.Concept and mechanism
Change closure should reflect what was implemented and the observed outcome. Record deviations from the plan, validation, service effects, associated incidents, and residual actions. Update configuration information needed for support and future changes to use actual state. A technically completed implementation can leave reconciliation or follow-up work; keep that ownership visible. Measure the process to understand waiting, evidence quality, and failures without turning approval counts into an isolated target. DORA uses five current delivery and instability metrics applied within an application or service context.
Guided application
In a fictional case, 40 changes were implemented and four required corrective intervention under the adopted failure definition. The rate for that set is 10%, but the period, denominator, and criteria need explanation before comparison. If approvals became faster while failures increased, investigate conditions together. Technical review close to the work, automation, or dependency information may be missing; adding a committee to every change does not automatically address the cause. Choose a bounded improvement, define evidence, and track its effect. After a change-related incident, use concrete actions with owners and verifiable outcomes to reduce recurrence while retaining lessons in the process.
Four failures among 40 changes equal 10% within the stated definition and period.
Common pitfalls
Closed ticket treated as outcome; stale configuration; speed alone; metrics without a denominator; more approvals treated as an automatic solution.
Related topics: Mandate, models, and authorization · Impact, dependencies, and calendar · Evidence, artifacts, and controls
Close with outcome evidence and improve conditions influencing risk.
Reference: DORA software delivery performance metrics · NIST SP 800-128 updated October 2019; DORA five-metric model and change approval guidance; vendor documentation inspected 2026-10-01