ITIL practitioners commonly assume that standard changes are good, and that a high percentage of standard changes vs. normal changes indicates a mature environment. Is this maturity “good” by definition with respect to Change Management? The answer is mostly yes, but not always.
Let’s look at some ITIL definitions. ITIL defines a change as:
The addition, modification, or removal of authorized, planned, or supported service or service component, and its associated documentation.
This definition in ITIL necessarily broad and not very actionable. Every company must define on their own what is and what is not a change. For example, one customer of mine defined their Change Management scope around the financial system necessary to achieve SOX compliance. They defined specific servers, workstations, and application by name in their Change Management policy. Although their definition was narrower than most companies’, it nevertheless worked for them.
The execution of an individual Change typically contains the following steps (in various orders):
- Recording the Change, along with some basic information about it.
- Reviewing the Change, including filtering out Changes that are useless, ill-conceived, or otherwise inappropriate.
- Assess the Change, including analysis of risk, efforts, resources, and possibly more detailed feasibility analysis.
- Authorize the Change
- Implement the Change
- Review the Change after implementation
The most important differences between normal and standard changes are in the assessment and implementation. ITIL defines a standard change as:
A change to service or infrastructure for which the approach is pre-authorized by Change Management that has an accepted and established procedure to provide a specific change requirement.
This definition is strong but incomplete. Standard changes are typically low risk, low impact, highly repeatable, well-documented, and well-understood. Standard changes are pre-authorized by the change board or relevant authorization parties.
Typically when an organization initiates a formal Change Management process, they will have few or no standard or pre-authorized changes. As they learn and grow, they will s identify some changes that occur frequently and are low risk and low impact, and further authorization of each individual change will burden the change board.
Such changes are candidates to become standard changes. Somebody, typically the person who implements these changes, can raise a change for the purpose of pre-authorizing a specific type of change. If authorized through the Change Management process, a new standard change is born. As a consultant I recommended these standard changes should become quick change templates in the ticketing system.
In general the longer an organization has been doing Change Management, the more standard changes it will have defined, and a higher percentage of all changes will be standard changes. This is a good thing, and in general the process of defining the the implementation plan (or change model) for standard changes helps to build repeatability and organizational learning and maturity.
Is a high percentage of standard changes ever a bad thing? In general no, unless the organization is so focused on measuring percentage of standard changes that technicians stop recording normal changes. This is bad, but rare in practice (at least for this purpose).
Standard changes can be difficult to achieve in organizations that are very dynamic or growing rapidly. In these environments it can be difficult to identify classes of normal changes that are candidates for pre-authorization. Growth consumes cash, and growth consumes resources. Highly dynamic environments may simply not have the people and time required to define standard changes, despite the benefits in more static organizations. Standard changes indicate operational efficiency, and not all organizations define their strategic competitive advantage around operational efficiency.