A change request: what, why, what could go wrong, and how to put it back

A change is anything that alters a system other people depend on. A change request writes down what will change and why, who it affects and what could go wrong, how it will be undone if it goes wrong, when it will happen, and who approved it. Then it is done in the window, verified, and closed.

Hone is a place to practise a career, one idea a day. This is one of its lessons, written out in full and free to read without an account.

What it is for

A firewall rule is 'tidied up' on a Tuesday afternoon with no ticket. The finance system stops talking to the bank at 15:00, on the day the payroll run goes out. Nobody knows what changed, because nothing was written down, and the person who did it is at lunch. A change request would have been ten minutes on Monday and a rollback plan on Tuesday.

How to think about it

Write what and why in two sentences. List who is affected and what breaks if it goes wrong; that is the risk. Write the rollback plan before you ask for approval, because 'how do we put it back' is the first question anyone asks. Get approval from whoever owns the risk. Pick a window when the fewest people are affected, tell them, do it, verify with a real task, and close the request with what actually happened.

Worked example

Change: replace the floor 2 switch. Why: two failed ports, and a third dropping

What and why, in two sentences.

Affected: 40 users on floor 2, the floor's printer, for about 30 min. Risk: config not copied correctly; VLANs wrong

Who, how long, and what could go wrong, named.

Rollback: old switch stays racked and powered; move the cables back, 10 min

How to put it back, written before anybody approves.

Approved by the network manager; window Thursday 07:00 to 07:30; floor told by email Tuesday; done 07:04 to 07:26; verified: two users sign in and print

Approved, scheduled, announced, done inside the window, and verified by real tasks.

Your turn

Write the name of the plan that says how the change is undone if it goes wrong.

Before approval, write the  plan

The trap

Skipping the request because the change is small. The size of a change is not how long it takes; it is how many people notice if it goes wrong. A one-line firewall rule can stop a company.

Practise a change request on HoneA question on it now, a coding challenge where there is one, and it is remembered for review. Free, no email needed.