ITIL Change Management

Why the five phases run in this order

Phase 1 answers one question: which kind of change is this? Classify change type (standard/normal/emergency) at +1d is the fork in the road. Standard is pre-approved and never reaches the CAB. Normal walks the full path below. Emergency inverts the order. Classify late and you have spent coordinator time on a change that needed none, or queued something urgent behind a weekly meeting.

Phase 2 ordering is not decorative. You cannot estimate downtime until you know which configuration items the change touches, and you cannot book a window until you know who it hurts. Note the highest-priority subtask in the phase: Document rollback procedure. A CAB cannot responsibly approve a change it has no way to reverse.

Phase 3 puts technical, security and business review before the CAB, not at it. The CAB is a decision forum, not a design review. Bring an unreviewed change and it becomes an architecture debate with the wrong nine people in the room, and the next four changes on the agenda slip a week.

Phase 4 sits three days after approval, not the same afternoon. That gap is the notification period — approval at +9d, user notice at +13d, execution at +14d. Inside the window: backup, execute, verify, smoke test. Phase 5 keeps the record open a week after the change works — 48 hours of monitoring, review, CMDB update, closure. Close before updating the CMDB and the next change assesses its impact against stale data.

Who owns which gate

• Requestor — the business justification, and nothing else. Not the plan, not the risk assessment. That keeps a change from being designed by the person who most wants it shipped.
• Change management (the process function) vs change manager (the person with authority). The template separates them deliberately: validation, classification, agenda, comms and record closure are process work; assigning a coordinator and granting CAB approval are decisions.
• Change coordinator — owns the change. Writes the plan, documents the rollback, presents to the CAB, verifies implementation success.
• Tech lead, security, business owner — three independent sign-offs feeding one decision. Security review is conditional, and what triggers it should be a written rule rather than a judgment call made under deadline.
• Ops team, QA, comms — execute, test, notify. Ops runs the change and QA runs the smoke tests, so whoever did the work is not who declares it good.

Ten roles across 38 issues, each written as a @role token — an unmatched name becomes a template variable you fill once on apply rather than 38 separate assignments, and the [Due + Nd] offsets resolve against the anchor date at the moment the template is applied.

What breaks when you skip a step

• Skip Document rollback procedure and the CAB approves anyway under schedule pressure. The upgrade half-applies at 2am, nobody agrees what the previous state was, and a 90-minute maintenance window becomes a nine-hour incident.
• Skip Identify affected CIs and services and the impact estimate is guesswork. The team you failed to notify is reliably the one that pages you mid-window.
• Skip Confirm implementation resources are available at +13d and you discover at the start of the window that the only person who has run this upgrade before is on leave.
• Skip Create pre-implementation backup and the rollback procedure you documented has nothing to roll back to.
• Skip the post-implementation review and the process never changes. The same class of change fails the same way next quarter and you pay for it twice.

Five people versus fifty

At five people there is no CAB. There are two engineers in a thread. Collapse requestor and coordinator into whoever is doing the work, change manager into the engineering lead, and keep the two things that carry weight: a written rollback, and a second person who says yes before production. That is the control; the rest of Phase 3 is scaffolding for an organisation big enough to need it. The one merge to refuse is requestor and approver — once those are the same person there is no change control, only a changelog.

At fifty the CAB is real and meets weekly, so the +7d to +9d approval span is mostly queue time, not review time. That makes the day-one classification the highest-leverage step in the workflow: it is what keeps routine work out of the queue. File everything as normal and the CAB becomes a rubber stamp, lead time balloons, and engineers route around it through the emergency path — implement, obtain retroactive approval, backfill the Phase 2 documentation. Needing that often means your standard-change catalogue is too small, not that the process is too slow.

Why run it in Jira rather than a spreadsheet

A control review asks three things of a sampled change: was it approved before it shipped, was the approver someone other than the implementer, was there a tested rollback. Record approval, ownership and rollback as issues and that sample set falls out of the work. A spreadsheet gives you an archaeology project instead.