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.

 

The Secret of Change Management

The secret is there isn’t one secret.

There is no single aspect of Change Management that makes it successful. There is no right or wrong way design your Change Management process.

I have worked with two dozen customers on Change Management, and I have found few consistent threads. Every organization is different.

It’s important that:

  • You have a process
  • You define changes (more on this later)
  • You review and improve the process periodically

You also need to define “change” in a way that is appropriate to your organization. I once worked for an outsourced data center provider who required a change to access the data center–the one-time access was a Change. This is an extreme example, but it clarifies the point.

A weekly meeting of the  Change Authorization Board is not required. Half the customers I worked with never defined any group that resembles anything like a CAB. It can work well for some organizations, but most organizations are better off without one.

Accountability for implementing unauthorized changes is also important. Most companies build “Unauthorized” or “Out of Process”  Changes into the process. One customer called them “Poorly Planned Changes” and the CIO had to approve them. The rate of such changes dropped significantly.

Otherwise the standard advice applies.

  • Define your KPI’s. Identify your performance metrics.
  • Assign a roles that are appropriate to your organization.
  • Automate approvals and notifications where possible.
  • Use “Standard” (pre-approved) changes in order to reduce the volume of management approvals.

Are Standard Changes “Good”

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.

Exploring the Role of Steering Committees in Realizing Value From Project Management

Abstract: The impact of steering committees on project performance and their role in creating value from project management capabilities is not well understood. A case study analysis was chosen to analyze the configurations and specific functions of project steering committees. A measurement model for steering committee configurations was developed to enable further survey-based studies. One of the major insights resulting from the authors’ interviews with project managers and senior managers was that they perceived the existence of a project steering committee only when the context was defined and clarified. Furthermore, a large variety of committee involvements was identified, concluding that steering committees per se are very rare. On the project level, the cases clearly demonstrate that committees with project steering functions play an important role in the selection, initiation, definition, and control of projects. On the organizational level, they are important to implement and maintain project management standards. Finally, the results clearly indicate that steering committees directly support project success and are instrumental for attaining value from an organization’s investments in its project management system.

Reference: Project Management Journal, Vol. 40, No. 1, 42-54.

Authors: Thomas G. Lechler, Stevens Institute of Technology; Martin Cohen, Stevens Institute of Technology

Link: http://www3.interscience.wiley.com/journal/122217097/abstract

Comments: My first reaction was: I wonder what relevance this research has to Change Advisory Boards in a Change Management process. However, beyond the superficiality they are not very similar. Projects, and hence project steering committees, are more strategic. Project steering committees consist mostly of executive management; the CAB may consist of representatives of management, users, partners, and vendors among others.

What surprised me the most of the research is how little research has been performed this area. Lechler and Cohen sought to address the questions of project steering committees: 1) what are the various configurations and responsibilities, 2) which project decisions are made, 3) how are they organizations, and 4) do they increase project management value? In order to do this they examined four companies in depth, as part of a larger PMI-sponsored study.

They found wide variety in steering committee composition, which is consistent with my observations of CABs in organizations implementing Change Management. In general they found steering committees are perceived to improve project management performance with minimal detrimental elements, such as political infighting or delayed decision-making. I wonder what would have resulted from the study of project-oriented organizations that lack the element of a structured steering committee–would they perceive lack of a steering committee hinders project management success?

What is the dividing line between a Project and a Change?

When is a Change really a Project? ITIL simply says the following are not changes:

  • Changes with significantly wider impacts than service changes, e.g. departmental organization, policies and business operations – these changes would produce RFCs to generate consequential service changes
  • Changes at an operational level such as repair to printers or other routine service components.

It isn’t clear to me that the natural agency—PMI—offers any clear guidance. PMBOK defines a project as a temporary endeavor undertaken to create a unique product, service, or result. Temporary endeavor implies a definite beginning and end.  Unfortunately, this definition is not inconsistent with a Change.

PMBOK offers little guidance about how big or how little a project needs to be in order to become a “Project” except to say the PMO exists to support project managers including developing a methodology, best practices, and standards. I would say a project is a “Project” when the benefits of managing it as a “Project” outweigh the overheads of the PM method. Hence the answer is organizationally dependent. If the organization’s PM methods are non-existent, then you can call anything a “Project” and send it off the secretary masquerading as a PM.

If the PMO’s PM method is detailed and rigorous, then projects would be greater than 80 hours at a minimum. However, in order to avoid the tendency of middle managers to “break up” projects in order to avoid PMO oversight, PMO’s will generally make the PM method scalable, requiring less overhead and oversight for smaller projects and more for larger projects.

In general time alone is a poor indicator for defining the boundaries of a project. A PMO should also look at factors such as strategic alignment, whether the Change supports or endangers the company’s strategy, and the project’s risk profile. Riskier projects should be overseen by the PMO in order to ensure the risk profile is in line with its support of the strategy.

In most organizations the PMO is more strategic and is independent of the IT operational processes. The Change Manager may hear about projects a few days before they are expected to go live (as a Change). In other words, the Project usually precedes the Change, not the other way.