ITIL Change Management – Some Basics

If we are searching for a concise definition of ‘change’ – in conformity with the ITIL Change Management principles- then here it is. It means addition, modification or removal – which can be termed as de-registration -of an authorized ( or base-lined), planned and supported configuration item/service or service component and associated elements or documents. The circumstances often can be confusing in identifying ‘change’. Requests for password reset, new access, server installation, rebooting a server, new hire setup may not be termed as ‘change’ per se, but they may generate change-management activities. Many IT organizations often get caught up in bureaucratic frenzy that they get programmed to label any service request as change. One just needs to bear in mind, just because it needs approval, tracking and documentation, it is simply not a change. Just because it needs approval, tracking and documentation doesn’t mean it is a change. Similarly, requests for administration are not requests for change. The IT organizations need to be aware and cognizant of these factors to successfully drive the change management process within the boundary of the definition.

The major object or the entity that instantiates a change, is the Request -for-Change (RFC). What is a change request? It is a formal communication seeking an addition, modification or removal (deregistration) to base-lined Configuration Item(s). We should not follow a straight jacket approach in defining change and we might need multiple templates to capture different types and flavors of change. A change request should be exhaustively descriptive of the change details, its purpose, risks and impacts on other CIs and at the level of the organization at large, the implementation plan, the back-out plan if it fails, post-implementation review plans.

Next, the important question is how do we categorize the change requests. The guideline is to categorize them, broadly speaking, based on business impact and complexity. We know that in the simple scheme of categorization, we have three categories – Standard, Normal and Emergency Changes.

The ITIL describes a Standard Change as “…a change to the infrastructure that follows an established path, is relatively common, and is the accepted solution to a specific requirement or set of requirements.” The standard changes, which are pre-authorized, can be implemented under established procedure, in other words, a standard operating procedure(SOP). Its risk and impact profiles are low and known. It should have a tested set of Release-to-Production document templates – build and test plans or scripts, support plans, implementation plans and back-out plans. CAB can pre-authorize the standard changes based on risk and impact and CAB can also delegate responsibility for accountability of delivery of the change to the change owner.

What is a ‘Normal’ change? The ITIL version 3 has introduced this concept. It follows the full-blown ITIL Change Management process- assessment, authorization, CAB approval, scheduling before implementation. Based on the scope, complexity and impact, a normal change can be further categorized as minor, major and significant ones.

An ITIL emergency change is the highest priority change that can be defined in an organization. Emergency changes are defined as changes that need to be evaluated, assessed and either rejected or approved in a short space of time. In other words, emergency Change is reserved for changes intended to repair an error in an IT service that is negatively impacting the business to a high degree. Simply defining a change as an emergency does not automatically entail the change should be implemented. The Emergency Change Advisory Board (ECAB) will assess the change and provide advice to the delegated person responsible for approving or rejecting emergency changes.

In the context of ITIL, ‘change priority’ needs to be properly computed before scheduling the requests. The formula for determining Change Priorities is: Priority = Business Impact + Urgency. Truly speaking, determination of ‘priority’ is not purely a matter of quantitative computation, because impact and urgency are not numeric entities. But at least we can arrive at some ordinal ranking of the priorities.