A Beginner's Guide to ITIL Change Types

Manage change or be a victim of it. Using Information Technology Infrastructure Library (ITIL) change management protocols will minimize the risk of IT service interruptions at your small business.

Updated June 26, 2020

Large and small organizations implementing Information Technology Infrastructure Library (ITIL) principles often struggle with change management and how different change types affect IT processes.

We'll show you how to overcome that struggle as we go over the three ITIL change types below and the benefits of using them for your change management protocols.

Overview: What are the ITIL change types?

ITIL change management's goal is to minimize risks associated with the addition, removal, or modification of infrastructure, processes, software, hardware, or documents that could affect IT services.

Change, which the change-advisory board (CAB) and change manager oversee, is divided into three categories:

  • Normal: A change initiated as a request for change (RFC) service request and not categorized as standard or emergency
  • Standard: A preauthorized, low-risk change that follows established change protocols
  • Emergency: A change that must be expedited

ITIL change types are part of the larger ITIL framework. ITIL began in the 1980s as an ad hoc collection of IT service management (ITSM) best practices and checklists. It's evolved into a holistic approach to integrate all IT activities with overall business processes and objectives.

Not all help and service desk applications have ITIL-aligned change management functionality. The distinction between having or lacking this capability is an important consideration when choosing IT management software.

ITIL change types

ITIL change management procedures minimize risk. Every action taken within your IT department affects operations across your small business, and change management models produce intended positive results instead of unintended negative consequences.

1. Normal

Stakeholders, such as employees or external service users, initiate a normal change via a request for change (RFC) submitted through the IT help or service desk. Normal changes encompass all changes that are not emergency changes.

Each will be an expedited, or standard change, which are low-level enough that CAB evaluation is not required.

Categories of normal changes include:

  • Applications
  • Documentation
  • Hardware
  • Networks
  • Operational environment
  • Software

The normal change process has six steps:

  1. RFC submitted: A stakeholder submits an RFC service request.
  2. RFC review: The change manager evaluates the RFC; if the change is validated, the change manager identifies its technical requirements and assembles necessary documentation.
  3. CAB evaluation: The CAB evaluates the RFC, based on a cost-benefit analysis.
  4. RFC approval: If the CAB approves the RFC, any remaining approvals within the organization such as senior management or the business office are obtained.
  5. Coordinate change: Upon approval of the RFC, the change manager works with IT staff to schedule, build, and implement the change.
  6. Post-implementation review (PIR): If the RFC release is not successful, the change manager rolls back the release. After successful implementation, the change manager confirms the change achieved its objectives and closes the case.
A flowchart illustrates the six steps in the RFC process.

The RFC workflow process standardizes the evaluation and implementation of service requests.

Normal changes also encompass minor changes, non-trivial changes with low risk and low impact, and major changes, high risk and high impact changes, that without proper planning could interrupt live operational environments.

2. Standard

Standard changes use documented procedures previously reviewed by the CAB and approved by the change manager. Standard changes include service requests such as setting up a computer for a new employee or hardware life cycle activities like the replacement of a printer.

Performing standard changes provides multiple benefits:

  • Formalize routine activities: Establish a standard operating procedure (SOP) for every IT activity to ensure consistency.
  • Define change: Designate clear distinctions between standard and normal changes.
  • Gather ITSM feedback: Build better relationships between IT personnel and other company departments, employees, and external stakeholders.

Standard changes aren't as time sensitive as emergency changes and don't have as many steps as normal changes. They do codify IT department processes and help indicate the level of integration with the rest of your business.

3. Emergency

Even though emergency changes are expedited, they still follow a defined process similar to normal changes but with a few key differences:

  • Triggering event: Instead of an RFC service request initiating the change process, a major unplanned incident occurs or a critical event is about to happen, which results in the creation of an emergency change (EC) request.
  • Emergency change-advisory board (ECAB): Instead of using the CAB, the ECAB, a subset CAB group, approves or disapproves the EC, based on risk minimization and analysis.
  • PIR: Following successful implementation, the change manager requests that the EC be reclassified as a standard or normal change.

Using the emergency change process in response to an unexpected situation is critical because implementing an off-the-cuff solution with no oversight can cause more problems than it solves. Each step must be documented; email and/or verbal communications are not sufficient.

Uses of ITIL change management for small businesses

Using a formal change management process is important for all businesses to minimize risk. Change management is like insurance: Don't wait until you need it to get it because by then it's too late.

While emergency changes are reactive and standard and normal changes are more proactive, the change management process better prepares your IT department to provide a high level of uninterrupted service.

Normal change use case: Request for a new service

The RFC below is for a new feature to allow users to geo-tag themselves. Key information includes:

  • Change request description
  • Cost-benefit analysis
  • Risk analysis
  • Time frame for implementation
This sample RFC includes different types of information the CAB and change manager require to approve or deny the change request.

This RFC includes succinct, relevant information that makes the case for the proposed change.

Using a preformatted RFC template ensures the CAB and change manager have all the necessary information to evaluate the proposed change. All normal changes, either minor or major, have a level of risk and potential impact on service operations and require thoughtful consideration.

Standard change use case: Decommission a server

The standard change below is to decommission a server as part of the hardware life cycle. Key information includes:

  • Standard change description
  • Implementation plan
  • Test plan
  • Backout plan
An online standard change form to decommission a server is displayed.

Standard changes do not require an RFC but still require documentation to record the actions taken.

Standard changes do not require CAB evaluation because their processes were already approved. These changes still require, however, approval from the department head or change manager.

Emergency change use case: Install a software hotfix

Emergency changes address time-sensitive issues such as zero-day exploits, newly identified security flaws, or Distributed Denial of Service (DDoS) attacks. The EC below is for a software hotfix, and its information includes:

  • Change plan
  • Rollback plan
  • Test plan
The EC request for this hotfix includes the change, rollback, and test plans.

A software hotfix's installation must be expedited to prevent service interruptions or data intrusions.

Time is of the essence when making an EC, whether it addresses an existing major incident or prevents an impending one. This increases the importance of documenting every step taken to complete the EC. That information informs your PIR and contributes to refining EC protocols ahead of future incidents.

Manage change within your small business

Change management is a key part of the ITIL foundation to integrate your IT department's activities with the rest of your business. Develop and implement your change management processes now to avoid needless service interruptions, extra expenses, and decreased customer satisfaction.

LOTS TO CONSIDER, LET US HELP

Get The Blueprint’s latest recommendations by signing up to our free newsletter.

The Motley Fool has a Disclosure Policy. The Author and/or The Motley Fool may have an interest in companies mentioned.