Standard Normal and Emergency Changes
ESMi Knowledge Team
· 3 min read
In brief
Standard, normal and emergency changes should each carry proportionate controls, evidence and authority, so that change governance is both fast and safe. The type a change is assigned should determine the level of control applied to it.
- Set clear criteria for each change type, and measure whether the correct type is selected.
- Pre-authorise standard changes only once they are proven. In the article's example, a recurring account update becomes standard only after the method, validation and rollback are proven and controlled.
- Assess normal changes by risk, connecting each decision to the consumer outcome so local efficiency does not damage the end-to-end service.
- Use emergency authority with a retrospective review, and track the emergency change rate alongside standard change success. Invite the people who perform and receive the work to test whether the design is usable in practice.
- Avoid three pitfalls: labelling merely urgent work as emergency, allowing standard changes to drift, and forcing trivial changes through heavyweight review. Pilot on one representative case, review correct type selection, and extend only when the approach is credible. Read the measures as a set, because a better headline means little if quality, risk or consumer effort worsens elsewhere.
Continue reading on the Exchange
Join or sign in to read the complete article and explore the full knowledge library.
Founder membership is free for life
More from ESMi Knowledge Team
Available to members.
Related articles
Members
The Purpose of Operational Change Management
Operational change management enables beneficial change while balancing value, risk, readiness, scheduling and service stability.
Members
Making the Change Advisory Board Effective
A CAB should improve risk and scheduling decisions for relevant changes, not act as a universal approval meeting.
Members
Using a Change Schedule to Protect Services
A shared change schedule exposes collisions, resource constraints, business events and cumulative risk before implementation.
Members
Designing an Effective Release Policy
A release policy provides consistent rules for scope, packaging, frequency, evidence, authority, traceability and early-life support.
Members
Release Versus Deployment
Release makes a service or feature available for use; deployment moves components into an environment, and the two moments may differ.
Members
Choosing a Deployment Strategy
Deployment strategy should reflect risk, reversibility, architecture, user impact, support capacity and the evidence needed to proceed.
