Production changes without surprises: request, approval and window

Seven practices so every change arrives with the same questions answered: risk classification, a standard request, proportional approval, windows, rollback plan and verification.

Production change is the most common cause of incidents nobody saw coming: a “small” tweak on a Friday afternoon, with no way back and without support knowing. Change management isn’t about slowing the team down; it’s about making sure every change arrives with the same questions answered. Here are seven practices that work the same in an in-house IT team and in a firm that runs its clients’ infrastructure.

1. Classify changes by risk, not by size

A framework such as ITIL 4 distinguishes three types: standard (repeatable, low risk and pre-authorized, like creating a user or renewing a certificate), normal (assessed and authorized beforehand) and emergency (to restore a failed service, with fast-track authorization). Define which ones are standard and a large share of the volume stops needing review.

2. Every request answers the same five questions

• What changes, and why?
• Which services and users does it touch?
• What can go wrong, and how will we know?
• How do we roll back, and how long does it take?
• Who performs it and who verifies it?

If the request doesn’t answer them, it isn’t assessed. A short form works better than a meeting.

3. One person approves; the board is for big changes

A change board that reviews every tweak becomes a bottleneck and people learn to go around it. Reserve the board for high-impact changes and let the service owner approve low-risk normal ones. What matters is that it’s written down who authorized and when.

4. Published change windows and freezes

Agree on fixed windows (say, Tuesday and Thursday nights) and freeze calendars: accounting close, a client’s peak season, legal deadlines. A change outside the window is an emergency, and emergencies get reviewed afterwards.

5. A tested rollback plan, not an imagined one

“We’ll go back to the backup” isn’t a plan if nobody has ever restored that backup. For each normal change note the decision point (if it isn’t verified after 30 minutes, roll back) and, when possible, rehearse it in a test environment.

6. Verify and close with evidence

A change doesn’t end when it’s applied but when it’s verified: the requester confirms, the result is recorded and it closes with what actually happened (dates, time, incidents). Failed changes get reviewed without blame: which question in the request would have caught the problem?

7. Track two numbers and review them monthly

The share of changes that cause an incident and the share executed as emergencies. If the second rises, the normal process is too slow; if the first rises, it’s too loose.

How it looks in Iurefficient

Iurefficient is not an infrastructure change-management tool; what it does carry is change control for a project, useful when a change alters what was agreed with a client. In each project’s “Changes” tab a baseline is saved and every change order declares its sale price, its cost and the calendar days it shifts. Whoever holds the authority approves or rejects it, and once approved the budget adjusts by itself.

The screenshot uses demo data. For the operational work of a change —preparation, execution, verification— each step can be tracked as a project task with an owner and a date, and bulk task edits can be undone.

it change management itil operations best practices

← Back to the index