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.