Change Types

Introduction

Changes to an IT production environment come in a variety of shapes and sizes. Industry practices have converged on types of that have served us well for several years as a starting point for discussion. However, they are insufficient and require further elaboration. Historically, these Change Types are:

  • Standard: a pre-authorized change that is low risk, relatively common, and follows a procedure or work instruction
  • Emergency: A change that must be implemented as soon as possible, for example, to resolve a major Incident or implement a security patch.
  • Normal: Any service change that is not a Standard or Emergency Change.

In this post I elaborate on and refine the above definitions. In addition I propose two new Change Types: Escalated and Latent.

Change Types

In the diagram above we see the emphasis and utility of the Change Types across two axes: the source of the Change (external vs. internal), and the level of risk to the service provider and users of the service. The ultimate source of a change can vary widely. External sources include regulators, vendors, partners, customers, who may request specific functions or who may make changes that affect the service provider. Internal sources include Incidents, component upgrades, and code refactoring. Some where in the middle of these are patches, COTS software upgrades, etc. We would see a similar diagram if we replaced source with urgency.

Assessing the risk of a Change is another discussion. I also ignore the broader definitions of what are Changes. These definitions are organizationally-specific and are the subject of a later post.

Normal Change

Normal is the default mode for Changes. Unless otherwise specified, Changes are Normal.

Normal Change is also the place to start when defining or improving the Change Management process. Other Change types are variations of the Normal Change process.

Emergency Change

Sometimes Incident resolutions requires a Change. This may include restarting a component of a service, applying a patch or update, or modifying configuration files. In order to facilitate prompt resolution of Incidents, we define an Emergency Change process that is faster than that of Normal Changes.

Emergency Changes are created in order to resolve an Incident. The Emergency Change record should be linked to the Incident record. Emergency Changes are distinct from Escalated Changes, which are not created in response to an active Incident.

There is no standard Emergency Change process. The authorization of Emergency Changes will be different in each organization, but it should be faster and simpler than the Normal Change authorization. Emergency Change authorization may require only the approval of the functional supervisor or manager, the service owner, or even a peer review of another team member.

The pool of eligible approvers should be flexible. Emergencies sometimes occur in the middle of the night or on a weekend, when staff availability is limited.

The Emergency Change approvals may also be transmitted verbally. In this case the Emergency Change record may not even exist until after it is approved and implemented. The Change should always be recorded after the fact, typically when the Incident record is updated, and should include who gave the approval. Emergency Changes that are verbally approved may be treated as a Normal Change after the fact, in order to reflect on what occurred, whether the actions were appropriate, and whether any follow up actions are required in order to monitor, modify, or roll back the Emergency Change.

Standard Change

In order to avoid clogging up the Normal Change management queue with high-volume, low-risk, organizations may pre-approve specific classes of Changes that may be implemented, at will, within the constraints specified by the approval. Such Changes are called Standard Changes.

Constraints on Standard Changes may include limitations on the scope of the Change, the specific system services on which the Change may or may not be implemented, or time-based windows for the Changes, to name just a few.

A specific class of a Standard Change should be approved as a Normal Change. Thereafter it may be implemented as required, with only logging of the Change. In the ITSM tool this may be implemented as a “Quick Template” in order to pre-fill much or most of the Change record data.

Organizations may  refer to Standard Changes as Preapproved Changes, in order to eliminate ambiguities between the terms “Standard” and “Normal”.

Escalated Change

A Change that must be approved or implemented outside of the Normal Change process or window, but is not an Emergency Change, is an Escalated Change.

A typical example is an Escalated Change is one that is identified on Thursday and must be implemented the following day, Friday, prior to next CAB meeting.

Escalated Changes can arrive from a variety of sources:

  • External sources such as regulators or auditors,
  • New requirements generated in response to Latent Changes by vendors, customers, or partners,
  • New requirements generated in response to a recently implemented Change,
  • Internal organizational or political changes.

The Escalated Change approval process may be the same as that for an Emergency Change, or it may be a variation of either the Emergency Change or Normal Changes approval process.

Because the preponderance of Escalated Changes frequently reduces the overall efficiency of an organization’s Change and Release Management processes and incur a higher number of Incidents, it is important to track and log them separately from other Change Types. Frequently organizations will do so in order to discourage their excessive or unnecessary use.

Latent Change

Latent Changes are Changes to Services or components that were or will be implemented without any action by the service provider, but which may impact the Services of the provider.

The Latent Change type is growing in importance along with the increased reliance on Software as a Service and managed service providers. These providers may make changes to their applications or infrastructure that affect multiple customers. An individual customer may record such a Change as a Latent Change.

A Latent Change may also result from an automated action, such as a patch applied by an ITAM system, or a server restart initiated by an Event Monitoring system.

Finally, a Latent Change may also be an unauthorized Change detected automatically by an ITAM system or manually by a system administrator.

In all cases the Latent Change is recorded and examined, but is not approved. A Latent Change may result in another Change that will roll back, repair, or replace the Latent Change.

It is important to log Latent Changes because they happen, and because they affect Services.