ESM Institute
← All free contentChange and Release Management

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.

More on Change and Release Management →