run-change-enablement

name	run-change-enablement
description	Classify a change (standard/normal/emergency), assess its risk, and route it — pre-authorizing repeatable changes and reserving the CAB for genuine risk. Reach for this on any 'does this need approval / a CAB?' question.

Skill: Run change enablement

Maximize successful changes while controlling risk — not slow every change to a crawl (§2 #2).

Step 1 — Classify the change type

• Standard — low-risk, repeatable, well-understood → pre-authorized via a model, no CAB.
• Normal — needs assessment; higher-risk ones go to the CAB.
• Emergency — urgent (e.g. fixing a major incident) → expedited path (ECAB), with retrospective review.

Traverse the change-type tree in ../../knowledge/itsm-decision-trees.md.

Step 2 — Assess risk

Impact × likelihood × reversibility. A reversible, low-blast change needs little ceremony; an irreversible, high-blast one needs more. Set the approval level to match the risk, not to a fixed gate.

Step 3 — Pre-authorize the repeatable

If this change recurs and is low-risk, build a standard-change model so it ships without a CAB meeting (§2 #3). This is the main lever for de-bottlenecking change.

Step 4 — Build the RFC (normal change)

Document the change, risk, rollback, and schedule in the change-request-rfc. Take genuinely novel/higher-risk normal changes to the CAB.

Step 5 — Coordinate the release

Coordinate scope, timing, and rollback; hand the deployment automation to devops-cicd. A failed change that causes an outage routes to the incident-and-problem-manager.