Change management process flowchart (ITIL)

How it works

1. Rename the lanes to the roles you actually have

   Replace Requester, Change manager, CAB, Implementation team and Service owner with your real functions. Plenty of organisations have one person acting as both change manager and CAB chair, and smaller teams have no separate implementation team at all. Merge those lanes rather than drawing a structure you do not have, and keep it to five lanes or fewer or the chart stops being readable at a glance.

2. Define your three change types at the triage decision

   Write down what qualifies as standard, normal and emergency next to the "Change type?" decision, and set the boundaries by risk and blast radius rather than by effort or ticket size. Keep the pre-authorised standard change list short enough that someone genuinely maintains it, and give each standard change a documented change model it has to follow.

3. Name the change authority, its cadence and its emergency equivalent

   At the CAB review step, record who the approvers are, how often they meet and the cut-off for getting on the agenda. Define the ECAB separately: the person who can authorise an out-of-hours fix is rarely the full board. The rule most teams settle on is authorise verbally within minutes, write the record the same day, review it at the next CAB.

4. Specify what the assessment record must contain

   Turn "Record assessment and rollback plan" into a real checklist: affected services and users, risk rating, dependencies, downtime window, test approach, rollback steps and who executes them. The CAB decision is only as good as this record, and it is the document an auditor will ask for months later.

5. Make the scheduling and clash rules explicit

   State your freeze periods, minimum lead times and who owns the change calendar. The clash check in this chart is deliberately a decision rather than a formality, because most collisions are two teams touching a shared dependency rather than the same system. Decide up front whether a clash means rebooking or escalation.

6. Define success, then publish and version the procedure

   Say what "Change successful?" means for you: which smoke tests, how long the service owner watches, and what triggers the rollback call. Then share the chart where the work happens, next to the change request form or in the runbook, capture approval from the people named in it, and keep the earlier versions so you can show when the procedure changed and why.

Frequently asked questions

Is this IT change management or organisational change management?

IT change management. The two share a name and almost nothing else. This flowchart is the ITIL-style operational process for changes to live services: an RFC is raised, triaged, assessed, authorised, scheduled, implemented, verified and closed. Organisational change management is the people-side discipline for helping staff adopt a new way of working, usually structured around models such as ADKAR or Kotter's eight steps, and it has no CAB, no change calendar and no rollback plan. If you are looking for stakeholder analysis and communications planning, this is the wrong diagram.

What is the difference between a standard, a normal and an emergency change?

A standard change is low risk, performed often and pre-authorised against a documented change model, so it needs no individual approval and goes straight to scheduling. A normal change is anything that has to be assessed and approved on its own merits, which is the path through risk and impact assessment to the CAB. An emergency change is one where waiting for the next CAB would cause more damage than the change itself, so it gets expedited authorisation from an emergency CAB. In this chart all three converge on the same change calendar, implementation and review, because the category changes the approval route, not the record.

Does every change need to go to the CAB?

No, and sending everything there is the fastest way to make people work around the process. The CAB exists to review changes whose risk is not already understood. Once a change type has been performed enough times to have a reliable procedure and a known failure mode, promote it to a standard change with a documented model and take it off the agenda. A CAB that spends its meeting rubber-stamping routine work is not reviewing anything, and the queue it creates pushes genuinely risky changes towards the emergency route.

What should happen when a change fails?

It follows the same path to closure as a successful one. In this chart a failed verification at "Change successful?" triggers the rollback plan in the implementation team lane, and the rolled-back change then goes to post-implementation review and closure exactly like a successful one. Two things make that work in practice: the rollback plan was written and approved before the change ran rather than improvised during the incident, and the review asks whether the change type was right as well as whether the change worked. A second attempt is a new RFC, so the failed attempt keeps its own record.