Change Management
The RFC process, change advisory boards, and the discipline that prevents Friday night outages.
Overview
Change management done well prevents incidents. Change management done poorly creates them, or creates a process people bypass entirely. Answer the five questions below with the operational and governance depth of someone who runs or is audited on a change management process.
Read before you answer
IT change management is the process by which modifications to IT systems, infrastructure, applications, and services are requested, evaluated, approved, implemented, and reviewed in a controlled manner. The objective is to minimise the risk that changes introduce incidents — service disruptions, security vulnerabilities, or compliance failures — while enabling the organisation to move at the pace the business requires. ITIL 4 uses the term "change enablement" deliberately: the goal is not to prevent change but to ensure changes are made safely. The tension between control and velocity is the central challenge of change management, and the design of the change process determines whether it serves this goal or becomes a bureaucratic obstacle that people route around.
The core artefact of change management is the Request for Change (RFC). A well-structured RFC captures: what is being changed and why (business justification), what systems and services are affected, the technical implementation plan, the rollback plan if the change fails, the testing evidence that the change has been validated in a non-production environment, the change window (when the change will be implemented), and the post-implementation review plan. Change Advisory Boards (CABs) review RFCs for significant or high-risk changes before approval. The CAB typically includes representatives from IT operations, security, application owners, and business stakeholders — ensuring that the risk of a proposed change is evaluated by people who understand its potential impact across the organisation. Standard changes — pre-approved, low-risk, frequently repeated changes with a well-established procedure — do not require CAB review, which is how organisations maintain velocity for routine work.
Emergency changes are the highest-risk category because they must bypass the normal approval process by necessity. A critical security patch, a production outage fix, or a regulatory deadline may require implementing a change without the time for standard CAB review. The emergency change process must define: who can authorise an emergency change, what documentation is required (even if completed retrospectively), how the change is communicated to affected stakeholders, and how it is reviewed after the fact to ensure it was genuinely necessary and correctly implemented. Organisations that treat emergency changes as a convenient workaround for poor planning — using them to avoid the RFC process — will see their change-related incident rate climb. Emergency changes should be tracked and their frequency reviewed: a high emergency change rate is a governance signal that either the standard process is too slow or planning discipline is insufficient.