Change Enablement

Change enablement is the practice that decides who may modify production, on what evidence, and with what record. Older documents call it change management; a vendor description of the ITIL framing puts it as “change management—also known as change enablement—is an IT practice designed to minimize disruptions to IT services while making changes to critical systems and services.” The rename matters less than what the practice contains, which is an authorization model rather than a queue.

Two goals sit underneath it and they are worth separating, because they are usually conflated and they pull differently. One is catching mistakes before they reach users. The other is producing an auditable record that changes were authorized — a compliance requirement that exists whether or not it catches anything. A control can satisfy the second and fail the first.

The types exist to route authority, not to file paperwork

The practice recognizes kinds of change with different approval paths, and the categories are the useful part. Described in the same source: “standard changes are low-risk, commonly repeated, and pre-approved,” performed frequently and following “a documented, approved process.” Against that, “normal changes are non-emergency changes that don’t have a defined, pre-approved process” — and within normal changes the path forks by risk, since high-risk ones “may require risk assessment and approval from a change advisory board (CAB)” while low-risk ones “can be approved on a quicker timeline by a designated change authority or via automated checks and peer review.” Emergency changes “arise from an unexpected error or threat and need to be addressed immediately.”

The low-risk clause matters: automated checks and peer review are already an approval path inside the framework. The question is not whether to have a process but which category a reviewed, tested, automatically reversible deploy belongs to.

What happens when external approval is measured

DORA’s change-approval guidance reports worse delivery performance associated with heavyweight external approvals in its research and no evidence that more formal external review was associated with lower change fail rates. It recommends peer review supported by automated checks. These findings support changing routine gates, but do not prove that every independent review lacks safety value.

Evaluate a local review by the risks it identifies, the delay it adds, and subsequent outcomes. A reviewer without relevant context may check form completeness while missing a defect. DORA also gives CABs a strategic role in coordination and business tradeoffs requiring higher-level authority, distinct from reviewing every implementation detail.

What the research points to is review that keeps the second pair of eyes and moves it: “change approvals are best implemented through peer review during the development process, supplemented by automation to detect, prevent, and correct bad changes early in the software delivery life cycle.” Both of the original goals survive. Somebody other than the author looked, and the record exists — it is just emitted by the pipeline instead of typed into a form.

When a standard change is real

Pre-approval applies to a defined procedure and risk envelope. The following implementation checks make that boundary usable; they are practical recommendations rather than an exhaustive ITIL definition.

• Assess the procedure and its allowed inputs, environments, scale, and prerequisites. Assign an owner, review triggers, and authority to suspend or revise the approval after failures or relevant changes. ServiceNow’s template management supports modification and retirement; pre-approval is not permanent regardless of new evidence.
• Check instance eligibility. Artifacts and parameters may differ within approved limits. A schema migration is outside the class only if its assessed scope excludes that migration; a specifically approved migration procedure can itself be repeatable. Route departures to the appropriate authority rather than relying on someone to remember the boundary.
• Capture authorization and execution evidence. Link the approved procedure or decision, its authority and time, the actual artifact, checks, result, and recovery path. Automated records need coverage, retention, access protection, and visible failure handling. A later manual entry can document an earlier valid decision, but neither its timestamp nor an automated receipt alone proves prior authorization.

Emergency change deserves the same skepticism in the other direction, and one thing about it is widely misstated. The category buys a faster authorization route during an incident — a reachable authority, a standing delegation for defined actions, an expedited review — not the absence of one. ServiceNow’s emergency change model pairs an Authorize state with a flow that “requests CAB approval,” the same as its normal model. Acting first and recording afterward is a separate exception an organization grants explicitly, with stated conditions; treating urgency itself as the authorization is how unauthorized change gets a respectable name. The test of whether it is working is not how often it is used but what the retrospective review produces. It can approve every one of them and still be doing its job — what to look for is whether any review changes something afterward: a rollback, a follow-up fix, or a standing rule that turns that class of change into an ordinary one. A path that approves everything and changes nothing is the one worth questioning.

What to measure, and what not to

DORA recommends tracking lead time and change fail rate, with defined events, deployment populations, failure classifications, and windows. Using both does not prevent gaming: work can wait before commit, failures can be reclassified, or extra successful deployments can dilute the failure ratio. Read these measures with approval waiting time, recovery time, and user impact, and investigate changes in how events are counted.

Approval counts and rates describe activity. A high approval rate can coexist with useful pre-submission rework, abandoned proposals, or ineffective review; the rate alone distinguishes none of these. Record what reviewers found and changed. Where an agreed rule can provide equivalent protection, consider automated enforcement with evidence retention, accounting for implementation cost and residual exceptions. Where judgment remains, examine whether it is a new decision or a repeated need that better design could remove.

One failure mode is common enough that the same guidance names it as an anti-pattern: “Responding to problems by adding more process.” A failed change produces a new approval step, and the next one produces another, and each step is individually defensible. Nobody decides to build a slow organization; it accumulates one reasonable addition at a time. The counter-move is to ask, for each proposed step, which specific failure it would have caught and whether a check in the pipeline would catch the same thing without waiting for a meeting.

Finally, note that the separation of duties this practice is often installed to provide is an organizational property, not a tooling one — it is a decision rights question about who may authorize what. A platform will implement either model and report on either. How the change record, the request queue, and reliability objectives fit into one operating model is worked through in The Change That Was Approved After It Shipped.

References

• DORA, Capabilities: Streamlining change approval
• Atlassian, IT Change Management: ITIL Framework and Best Practices
• ServiceNow Product Documentation, Change Management
• ServiceNow SDK, State Model Guide
• ServiceNow — Review a change template
• DORA — Software delivery performance metrics

Vendor guides describe their own implementation of ITIL practices, and product behavior depends on the configured model and release.