# It Change Management > Classifies, assesses, schedules, and closes IT changes: decides standard vs normal vs emergency, forces a real backout plan and validation test, and runs the post-implementation check. Use when preparing a change request, when a change board needs an assessment, when deciding whether something can go straight to production, or when a change failed and needs review. Trigger on 'raise a change request', 'CAB submission', 'is this a standard change', 'change freeze', 'backout plan', 'emergency change', 'post-implementation review'. Not for the engineering review of the code inside the change — that is engineering-code-review; not for an unplanned outage already in progress, which is incident management, not change. - Skill: `alihusains/it-change-management` (Agent Skill) - Install (CLI): `npx skillmds@latest add alihusains/it-change-management` - Raw SKILL.md: https://api.skillmd.com/api/skills/alihusains/it-change-management/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: alihusains (https://skillmd.com/u/alihusains) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/alihusains/it-change-management --- # IT change management ## Purpose Change control degrades in two opposite directions. It becomes a rubber stamp — a form filled in after the work is scheduled, with "backout: revert the change" written in the box — or it becomes an obstacle that teams route around by declaring everything an emergency. This skill keeps the control proportionate: the assessment depth follows the actual risk, the backout plan has to be executable, and the emergency path exists but is expensive enough not to be the default. ## Prerequisites - **Inputs:** what is changing and on which services; who the affected users are; the proposed window; the implementation steps; the backout plan; the test that proves success; evidence the change worked somewhere that is not production. - **Access:** the change record system, the service/CMDB mapping to identify downstream dependencies, and the current freeze calendar. If there is no evidence the change has been executed in a non-production environment, and it is not a documented standard change, say so and stop. "It worked on my machine" is not pre-production validation. ## Procedure 1. **Classify the change before anything else — the class sets every later step.** | Class | Test | Approval | Notice | | --- | --- | --- | --- | | Standard | Pre-authorised, repeatedly executed, documented procedure, known and tested backout, no service disruption | Pre-approved; log only | None | | Normal | Anything that is not standard and is not responding to an active incident | Assessed and approved before scheduling | Per the notice table below | | Emergency | Required to restore or protect a service now, or to close an actively exploited security hole | Expedited approval from the on-call authority; full record within 24h | Concurrent | A change is not an emergency because it was planned late. If a team's emergency rate is material, that is a planning finding, and it should be reported as one — the fix is upstream, not tighter emergency approval. 2. **Assess risk on two independent axes, then take the higher.** Impact (who and what breaks if this goes wrong) and likelihood (how novel and how complex this is). A trivial-looking change to a system everything depends on is high risk; a complicated change to an isolated internal tool is not. | | Low impact | Medium impact | High impact | | --- | --- | --- | --- | | Routine, done before | Low | Low | Medium | | Modified procedure | Low | Medium | High | | Novel, or touches shared infrastructure | Medium | High | High | | Risk | Approver | Window | Required at approval | | --- | --- | --- | --- | | Low | Team lead | Any | Backout + validation test | | Medium | Service owner | Low-traffic window | Above + notified stakeholders + named implementer and verifier | | High | Change board | Agreed window, outside freeze | Above + rehearsed backout + rollback decision point + standby contacts | 3. **Enumerate downstream dependencies from the service map, not from memory.** List the services that consume the changed component and the ones it consumes. Unlisted dependencies are the usual reason a "no impact" change causes an incident. If the map is not trustworthy, record that as the residual risk rather than pretending the list is complete. 4. **Demand a backout plan that passes three tests.** It is written as steps someone else could execute; it names the point of no return (the step after which backout is no longer possible — schema changes and data migrations almost always have one); and it states how long backout takes. "Revert the deployment" fails all three when the change wrote data. If there is no backout, the plan must instead be a forward-fix plan with a named owner standing by — and the change board must be told which of the two it is. 5. **Define the validation test before the window.** A specific, observable check that distinguishes success from silent failure — a transaction completing end to end, a metric returning to its normal band, a report reconciling. "Users report no problems" is not a test; absence of complaints during a quiet window proves nothing. 6. **Check the freeze calendar and the collision list.** Two low-risk changes to the same service in the same window make both un-diagnosable if either fails. Freeze periods exist because the people who fix things are unavailable — overriding a freeze requires the same authority that set it. 7. **Execute with a named implementer and a separate verifier.** The person who made the change is the worst person to confirm it worked. Record actual start and end times, deviations from the plan, and the validation result with evidence. 8. **Close with an honest outcome code.** Successful; successful with issues; backed out; failed. A change that needed an unplanned follow-up fix within the window is "successful with issues", not "successful" — and if that distinction is not recorded, change failure rate becomes a number that always looks good and tells you nothing. 9. **Run a post-implementation review for every backed-out or failed change, and for every emergency.** Emergencies get reviewed not to punish but to find the planning gap that made the emergency necessary. ## Failure modes this skill exists to prevent - **Retrospective paperwork.** The record is created after implementation to satisfy the audit. Detectable: record creation time after implementation start. - **Standard-change drift.** A change is classed standard because it is frequent, though the procedure has since changed and the backout was never re-tested. Re-validate standard change templates on a fixed cycle. - **Emergency as a bypass.** Track emergency rate per team; a rising rate is a planning problem being expressed as a process problem. - **Backout that has never been executed.** For high-risk changes, the backout is rehearsed in pre-production, or it is not a backout plan — it is a hope. ## Data handling Classification: **Internal**. Change records should describe systems and steps, not carry credentials, connection strings, or personal data — reference the secret store rather than pasting values. If an implementation step requires a credential, the record names where it lives; it never contains it. Flag and stop if a submitted change record contains live secrets, and treat those secrets as exposed and requiring rotation. ## Boundaries - A service is already down and you are restoring it — that is incident management; raise the emergency change record alongside, not instead. - The quality of the code inside the change — `engineering-code-review`. - Bulk permission changes arising from a recertification cycle — the decisions come from `it-access-review`; this skill only schedules and controls the execution window. - A user asking for something to be changed for them personally (a setting, an install, a permission) — `it-service-desk-triage`. ## Hand-offs - **Receives from:** `engineering-decision-record` (accepted decisions requiring a controlled implementation); `engineering-incident-postmortem` (remediation changes); `it-access-review` (bulk revocations). - **Routes to:** `engineering-incident-postmortem` when a failed change caused customer impact; `it-service-desk-triage` for the user communications that accompany a disruptive window.