Change Request Template

WHEN TO USE IT For changes to shared systems where the people affected are not the people making the change — enterprise IT, network, shared platform, database. Routine application deploys through a tested pipeline should NOT use this; making them do so is the single most reliable way to get a change process routed around. Tier it. A password policy change and a core routing change do not need the same scrutiny, and pretending they do trains everyone to treat the form as paperwork. HOW TO USE IT The requester fills it in; a reviewer who is not the requester approves it. The reviewer's job is to find the missing back-out and the unlisted dependency, not to re-derive the work. Approval should take minutes for a tier-3 change and a conversation for a tier-1. Record the outcome afterwards. A change process with no record of what actually happened cannot tell you your change failure rate, which is the only number that justifies the process existing. THE TEMPLATE # Change request: <title> Tier: 1 (high blast radius) | 2 | 3 (routine) Requester: <name> Reviewer: <name> Window: <when> ## What is changing Precise description. For configuration, the exact before and after. ## Why now What breaks or fails to improve if this waits. ## Who is affected Systems, teams and users. Name the ones who do not know yet. ## Back-out plan The exact steps to reverse this, and how long they take. If the change can remove your own access to the target, say how you get back in. ## Verification How you will know it worked — the specific check, not "monitor". Include the end-to-end check, not only the component's own status. ## Dependencies and sequencing What must happen before and after, and anything that must NOT run concurrently. ## Risk if it goes wrong Realistic worst case, and who needs to be available. ## Outcome (filled in after) Succeeded | backed out | partial. What actually happened. ADAPTING IT In smaller organisations, tier 3 can be a single line in a channel with the back-out named — keep the discipline, drop the document. In regulated settings add the approval record and evidence retention. The back-out and verification fields are the two that must never be optional at any tier. Everything else can be scaled down. See /releaseops for the release side and /itops for the enterprise-change process this fits into.