Change management process map
A swimlane map of an IT change from request to post-implementation review, across the requester, the change manager, the CAB, the implementation team and the service owner. The triage phase is the load-bearing part: it is where a change is classified, and the classification decides how much of the rest of the map it has to travel.
Opens a copy in the editor and saves it in this browser. No account, nothing sent anywhere.
What is in this map
20 steps across 5 swimlanes and 6 phases, with 5 decision points.
- Swimlanes (who does the work)
- Requester, Change manager, CAB, Implementation team and Service owner
- Phases (left to right)
- Request, Triage, Assessment and approval, Scheduling, Build and implementation and Review and closure
Why map this process
Every change process has to solve the same tension: enough control that risky changes get reviewed, little enough friction that routine ones do not queue behind them. That is solved by classification, not by rules: standard changes take a short path, normal changes go to the CAB, emergency changes get a compressed route with a retrospective approval. A map is the clearest possible statement of those three paths, and it is why the triage decision sits so early here.
The other reason to draw it is the review at the end. A change process without a post-implementation review is a process that cannot learn, and it is always the phase that gets skipped because by then the change has shipped. Drawing it as part of the same flow, in the service owner's lane, makes it a step with an owner rather than an intention.
Every step in the map
This is the spreadsheet behind the diagram. The numbers in “Goes to” are row numbers, which is exactly what the editor’s “Line to” column holds — so you can read the flow here and retype any part of it.
| # | Step | Shape | Swimlane | Phase | Goes to |
|---|---|---|---|---|---|
| 1 | Raise a request for change | Start | Requester | Request | 2 |
| 2 | Log the *RFC* in the register | Registry | Change manager | Request | 3 |
| 3 | Request complete and in scope? | Decision | Change manager | Request | 5 (Complete), 4 (Incomplete) |
| 4 | Supply the missing detail | Process | Requester | Request | 3 (Resubmit) |
| 5 | Change type? | Decision | Change manager | Triage | 6 (Normal), 11 (Emergency), 12 (Standard) |
| 6 | Assess risk and service impact | Process | Change manager | Assessment and approval | 7 |
| 7 | Record assessment and rollback plan | File | Change manager | Assessment and approval | 8 |
| 8 | CAB reviews the change | Process | CAB | Assessment and approval | 9 |
| 9 | CAB **approves** the change? | Decision | CAB | Assessment and approval | 12 (Approved), 10 (Rejected) |
| 10 | Change rejected and closed | Reject | Requester | Assessment and approval | End |
| 11 | *Emergency* authorisation by ECAB | Approval | CAB | Assessment and approval | 12 |
| 12 | Schedule in the change calendar | Process | Change manager | Scheduling | 13 |
| 13 | Clash with another scheduled change? | Decision | Change manager | Scheduling | 14 (No clash), 12 (Clash) |
| 14 | Build and test the change | Process | Implementation team | Build and implementation | 15 |
| 15 | Implement in the approved window | Process | Implementation team | Build and implementation | 16 |
| 16 | Verify the service after the change | Process | Service owner | Build and implementation | 17 |
| 17 | Change **successful**? | Decision | Service owner | Build and implementation | 19 (Yes), 18 (No) |
| 18 | Execute the **rollback plan** | Compensation | Implementation team | Build and implementation | 19 (Rolled back) |
| 19 | Post-implementation review | Process | Change manager | Review and closure | 20 |
| 20 | Close the change record | End | Change manager | Review and closure | End |
The decision points
Every branch in the map, with the label on each outgoing line. These are the questions the process has to be able to answer.
-
3. Request complete and in scope?
Owned by Change manager · Request
- Complete → step 5
- Incomplete → step 4
-
5. Change type?
Owned by Change manager · Triage
- Normal → step 6
- Emergency → step 11
- Standard → step 12
-
9. CAB **approves** the change?
Owned by CAB · Assessment and approval
- Approved → step 12
- Rejected → step 10
-
13. Clash with another scheduled change?
Owned by Change manager · Scheduling
- No clash → step 14
- Clash → step 12
-
17. Change **successful**?
Owned by Service owner · Build and implementation
- Yes → step 19
- No → step 18
Notes on specific steps
These notes travel with the map. In the editor they live in the Notes column and appear when you open a box.
- 5. Change type?
- Standard changes are **pre-authorised** against a documented change model and go straight to scheduling. Normal changes are assessed and go to the CAB. Emergency changes go to the ECAB. Keep the standard change list short enough that someone maintains it.
- 7. Record assessment and rollback plan
- One record the CAB can read in a minute: affected services and users, risk rating, dependencies, test approach, rollback steps and who executes them.
- 13. Clash with another scheduled change?
- Check the calendar against freeze periods and business events as well as other changes. Most collisions are two teams touching the same dependency, not the same system.
- 19. Post-implementation review
- Review failed and emergency changes at the next CAB too. Record whether the change type was right, not only whether the change worked.
Making it yours
Adapt the triage decision first and everything else follows. List your change categories as branch labels, then check that each branch has a path that reaches implementation: the most common defect in a change map is an emergency branch that skips approval and then has nowhere to record that it happened. Put your change-window rules in the Notes column on the scheduling step.
What to watch out for
- The rollback plan is a step, not an attribute. If it is only a field on a form, the map cannot show that somebody has to review whether it is credible, and reviewing it is the point.
- CAB approval and service-owner acceptance are different approvals. One asks whether the change is safe to make; the other asks whether the service can take the disruption now. Merging them removes the only voice that represents the users.
- An emergency change that never gets retrospectively reviewed is an unrecorded change. Draw the review as the emergency branch's mandatory rejoin point rather than as an optional follow-up.
Frequently asked questions
Does this map follow ITIL exactly?
It follows the ITIL change-enablement shape (request, assess, authorise, implement, review) with the CAB as an explicit lane. It is not a certification artefact, and it deliberately keeps the standard/normal/emergency split visible on the page rather than hiding it in a policy, because that split is what people actually need to know.
How do I map a standard (pre-approved) change?
As a branch off triage that goes straight to scheduling, skipping the assessment and CAB phases entirely. What it must not skip is the record: a standard change that leaves no trace is indistinguishable from an unauthorised one, so the branch should still pass through the logging step.
Where does testing belong?
In the build and implementation phase, in the implementation team's lane, with a decision after it that can send a failed test back to build. Teams that leave testing implicit end up with a map whose implementation step has no failure path, which is the one thing implementation reliably has.
Open the map and start editing
The editor loads this chart with the spreadsheet underneath it. Change a cell and the diagram redraws — no drawing, no signup.