Introduction to Change Management Process Flow
According to ITIL® (IT Infrastructure Library), the driving force in a successful business is to continuously improve. It is not surprising that there is the Continuous Improvement Practise whose purpose is "to align the organisation's practises and services with changing business needs".1 The ITIL definition of change does this through the ongoing identification and improvement of:
- Service components
- Any element involved in the efficient and effective management of products/services
Great organisations live and breathe the Continuous Improvement mantra and how to navigate the complexities of change management challenges. They usually appoint a senior IT person that owns Continuous Improvement for the Practise and the IT organisation (e.g., chief cheerleader and coach), each IT department should assign a Continuous Improvement manager for their department as well, and everyone in IT should enters all their ideas into the Continuous Improvement Register (CIR)2 no matter how bold or small the suggestion.
Continuous Improvement managers regularly review the contents of the CIR, pull the most promising out, and use the Continuous Improvement model to analyze the suggestion. If it is good, Continuous Improvement creates a request for change for the project and sends it to Change Management.
The Purpose of Change Management (Enablement)
The practise name changed when Axelos® Global Best Practise, the owner of ITIL released version 4 in November 2018, where Change Management became Change Enablement. This is quite logical, since the Practise only gives permission to change something in the live environment and does not actually manage changes. However, given that Change Enablement is not yet a common term, we will continue to use Change Management in this whitepaper.
Change Management is the Practise of maximising the number of IT changes by ensuring that risks have been properly assessed, authorising changes to proceed, and managing the Change Schedule".3
When considering Change Management "Best Practises", best practise in the IT world is ITIL. Since its introduction in the late 1980s, ITIL has been the de facto global standard for running it like a business. ITIL is not prescriptive (i.e., it does not say "you must do it this way") but embraces all best practises in all its approaches.
ITIL Change Types & Definitions
- Practise — "A set of organisational resources designed for performing work or accomplishing an objective"4
- Practise Owner — The one person accountable for the Practise.
Change Manager — One of many managers that lead project teams to make IT changes.
Most IT departments have a general high-level role of IT Change Manager responsible for chairing the Change Advisory Board (CAB), they could be in this role permanently or on a rotating basis (it is very stressful).
In a best practise matrix organisation, every IT department (i.e., applications, infrastructure, desktop, etc.) would assign a member of their team the role of department Change Manager. In this role, they would be responsible to:
- Ensure the department's compliance to the Practise standards set by the Change Management Practise Owner.
- Coordinate with Change Managers in other departments.
- Contribute feedback to the Practise Owner in support of Continuous Improvement.
- Ensure proper documentation of change models and make sure everyone on the team follows these procedures. Change Models are documented work instructions on how to conduct a specific type of change with quality and efficiency. For example, how to on-board a new employee, how to install a patch or how to ready a new laptop, etc.
- Encourage the development of Standard Changes (more on types of change later).
- Motivate the department to reduce the frequency of Emergency Changes.
- Practitioner — The person doing the work. A single person usually takes on many roles. For example, they could resolve an incident, or work on Problem Management to find the root cause of an incident and then put on their Change cap to install the change that fixes the problem and the related incident(s).
Simplicity Is the Secret for a Strategic Change Management Practise
First, the Cardinal Rule of Change Management:
Nothing can change in the live IT infrastructure without approval from Change Management.
Why is Change Management policy so strict?
If using a Configuration Management System (CMS), it is only effective if it is 100% always correct all the time:
- Most troubleshooting will look here to see if anything has changed.
- Change Management uses the CMS to determine risks associated with a particular change.
- The CMS is used by all other Practises during the design phase of Change Management.
- Network monitoring tools use the CMS as their baseline. If there are unauthorised changes, alarms will sound.
- Change Management governance keeps a Change Schedule for normal changes to ensure that there are no conflicts, and all changes accounted for.
Figure 1: Example of a Change Schedule
Change Management Process Flow Fundamentals: What To Change, What To Change To, and What Workflow To Cause the Change
Remember that the goal is to maximise the number of successful changes. What follows is a logical, practical best-practise approach to making necessary infrastructure changes easy without any errors (i.e., incidents).
Effective Change Management Starts With a Request for Change (RFC)
A Request for Change, or RFC, is the core of ITIL Change Management policy. It should be:
Easy to create in a digital tracking system:
- An incident Practitioner links an incident that requires a change to a system to resolve the incident to an RFC
- A problem Practitioner links a problem/known error that needs a change to resolve the root cause of the problem to an RFC
A service request Practitioner links the service request to an RFC such as:
- Request for a new laptop
- Onboarding a new employee
- Access to a service (e.g., cloud-based project management system or an accounting system)
- A business executive board request for a modification to the company website starts this with an RFC
- Easy to link to a "reason" digital record
Linked to the service associated with the change (e.g., purchasing application, digital hospital records, etc.):
- The service name from your Service Catalog
- This is all about service delivery, and there should be a service owner for every service. The service owner must know what their service incidents, requests, problems, known errors and changes are if they are to properly manage the service.
- Linked to the Configuration Item (CI) in your Configuration Management System (CMS)
Figure 2: Example of an RFC
The Three RFC Change Types Which Product Maximum Efficiency
The three types of changes are:
Best practise is to create separate authorisation authority and process workflow for each change type.
These are the key to Change Management efficiency. They are:
- Low risk (i.e., do not create incidents)
- Pre-authorised (by the IT Change Manager)
- Well understood (trained people and procedures are in place to continually improve it)
- Fully documented (product/servise, work instructions documented and stored with knowledge management)
- Ones that never causes incidents (if an incident occurs, you lose the Standard Change privilege and you must reapply to the Change Manager)
IT leaders in best-run companies set a lofty goal that 80% of all changes should be Standard Changes. In doing so, they are can save a lot of money for the company and increase customer satisfaction. When we discussed roles a little earlier, we said that each IT department should have at least one person assigned to the role of department Change Manager. In this role, they champion the department to qualify as many changes as possible as Standard. There are several efficiency reasons for this:
- No waiting for the change approval by the Change Advisory Board (CAB)
- Because of detailed documentation (e.g., work instructions) and trained staff, they do not create any incidents, thus reducing the workload
- Increased customer satisfaction because of efficiency and professionalism
- Reduced costs
- To reduce clutter, Standard changes are not entered in the Change Schedule
- A user makes a request to the Service Desk, either directly or via a Service Catalog site.
- The Service Desk creates a predefined Standard Change request, which is pre-authorised, and fulfillment can start right away.
- The work instructions are followed, and the request is completed.
- The customer gets what they want and are happy.
- The Service Desk documents the service request.
- The Service Desk completes the Post Implementation Review (PIR), which is its contribution to Continuous Improvement.
- The Service Desk closes the service request, which automatically closes the Standard Change and updates the Configuration Management System (CMS).
These are changes that need to be implemented now (e.g., to resolve an incident or implement a security patch).
Emergency Changes could be initiated by:
- Monitoring and event management tools
- A user reporting an outage, fire, break-in, etc.
- A vendor reporting a breach or eminent failure
- The national Emergency Alert System (EMS)
- Assessment and authorisation are expedited by the Emergency Change Advisory Board (ECAB). The ECAB is a subset of the CAB.
- IT and business key people start on remediation as quickly as possible. The response should be well documented and practised.
An Emergency Change situation could involve other Practises for their emergency response ability:
- Service Continuity Management
- Problem Management
- Service Configuration Management
- Availability Management
- Capacity and Performance Management
- Security Management
- Emergency Changes never go into the Change Schedule (i.e., because they are not scheduled. It is all hands-on deck immediately.)
- When resolved, the PIR for Continuous Improvement should fully document the root cause, specifically, to find ways to prevent the Emergency Change in the first place (e.g., we did not follow the recommended maintenance schedule, we bought a product prone to failing or we use an unreliable provider, etc.).
The goal with Emergency Changes is to show a steady decrease in them over time.
Normal changes are how we evolve to better meet business demands. The main reason behind organising Change Management around reducing the impact of Standard and Emergency Changes is so we can concentrate on Normal Changes. Normal changes are at the core of IT aligning its service offerings with the needs of the business.
Normal Changes follow the Service Value Chain:
Figure 3: Axelos (ITIL) Service Value Chain
The Service Value Chain5 has been around for years and in many variations. The six stages of the Service Value Chain are:
- Plan: To ensure a shared understanding of the vision. Everything begins and ends with the vision; do not start without it!
- Improve: To ensure Continuous Improvement of products, services and Practises. Improvement suggestions come from everywhere. The Continuous Improvement Register (CIR) stores most improvement ideas. At the end of every project, the project manager conducts a Post Implementation Review (PIR) to gather improvement ideas.
- Engage: To supply a good understanding of stakeholder needs, we ask for all stakeholders to contribute to the best solution.
- Design & transition: To ensure products and services continually meet stakeholder expectations for quality, costs and time to market.
- Obtain / build: To ensure that service components are available when and where they are needed.
- Deliver & support: To ensure that services are delivered and supported according to agreed specifications and stakeholder expectations.
Normal Changes are characterised by:
- Assessment of Normal changes:
The Change Advisory Board (CAB) authorises the change by following standard procedures.
- Evaluating risks primarily using the Configuration Management System (CMS)
- Considering inputs from all other Practises (e.g., Risk Management, Service Financial Management, Portfolio Management, Service Level Management, Business Change Management, etc.; see the Practise Dependency Table at the end of this whitepaper to see how dependent every Practise is on Change Management).
- Group knowledge supplied by the different IT departments.
- The CAB schedules and blocks time in the Change Schedule to avoid conflicts.
- The Project Management Practise drives the project by following best practises such at Lean, DevOps and/or Agile.
The key to changing a good company into a great company is ITIL plus Project Management:
- Project Management with inputs from all other ITIL Practises proactively gathers and evaluates business opportunities and demands and turns them into Value (products and services) using the Service Value Chain.
- Best practice says that this is done through one or more of the Project Management proven approaches such as Lean, DevOps or Agile.
Project Management drives the Service Value Chain with the support of all the other ITIL Practises and IT departments. It truly should be an inclusive endeavor to produce the best solution with the least time to market within projected budget.
Who are Stakeholders?
Stakeholders are any person or organisation that has an interest or involvement in an organisation, product, service, or other entity.6 Examples of these roles are the following:
- Customer (Service Consumer): Defines the requirements for a service and takes responsibility for the [business] outcomes of consumption. (e.g., Business department heads).
- User: The person that uses the service. They want the service to be fit-for-purpose (i.e., it lets them get their job done to meet their manager's expectations).
- Sponsor: This is the person(s) that authorise the budget for service consumption.
- Service Provider: Funding from the consumer; business development (i.e., for our purpose, IT).
- Service Owner: A role that is accountable for the delivery of a service. Best practise says that the service owner should be closest to the service. That means that in most cases, service owners exist within the business, and they have the greatest interest in service delivery and excellence.
As demonstrated above and in the following Practise Dependency Table, all changes lead to Change Management and the Service Value Chain to transform business demand and opportunity to Project Management to deliver products and services resulting in value for the business, and thus Continuous Improvement.
Practise Dependency Table
||Relationship to Change Management
||Availability involvement is critical part of every normal change. Plus, when availability wants changes, they come to Change Management.
|Capacity and Performance Management
||Capacity involvement is critical part of every normal change. Plus, when availability wants changes, they come to Change Management.
||Implement projects to improve all areas of the business.
||Moves approved releases to the live environment, updates the CMS and completes the change project.
||Many incidents require an RFC to fix them.
|Information Security Management
||Implement security patches and related items.
||Stores all knowledge documents, procedures, post implementation reviews, and Service Design Documentations needed by Change.
|Monitoring and Event Management
||Tight integration. Supplies automated feedback if anything changes in the live infrastructure that does not have approval. Also, if there are failures, change can get a "heads up" that Incident Management will soon follow. This is often the first sign for an Emergency Change.
|Operational Change Management
||Many times, just doing the change is not enough. Operational Change works with Change Management to ensure that the people/groups using the change accept and get the most out of the change.
||Ensures that the organisation has the right mix of programmes, project, products, and services to execute the organisation's strategy within its funding and budget. You could say this the ultimate boss for Change.
||Problem finds root causes of incidents but requires an approval to make the change.
||Implement approved ideas that come right from the executive of the business.
||Works closely with Cchange. The purpose is to make new and changed services and features available for use.
||Supplies a strategy and guidelines for evaluating new changes.
|Service Continuity Management
||Will require Change Management to bring services back to operational status after a major failure. Service Continuity also requires Change to add safeguards to services.
||Designs new and changed services and oversees the creation of the Service Design Package (SDP) under the guidance of Change.
||This is usually the first-place change disruptions show up. For the Service Desk to accurately communicate the changes that happen, it should be aware of changes through the Change Schedule.
|Service Financial Management
||Supplies a strategy for Change to calculate the actual cost of bringing changes to market.
|Service Level Management
||Captures daily operational metrics and is often the first to know if IT is missing its agreed goals. When this occurs, it will often result in some changes to align the delivery with what the business wants.
|Service Request Management
||Many requests are standard changes. Therefore, the digital flow should be well tested and perfected.
|Service Validation and Testing
||Does the testing under the direction of Change. When the prescribed (SDP) tests are complete, Change validates prior to any release.
||Helps Change to ensure that changes it approves fits within the guidelines of the corporate strategy.
||Necessary to make changes required by vendors so that their services work more efficiently.
|Workforce and Talent Management
||Aids Change project teams to evaluate how the change affects the organisation's workforce.
The Change Management Practise should not be the bottleneck for Continuous Improvement. Make Change Management efficient with Standard Changes, look everywhere for things to improve, train everyone in Project Management, and keep focused on the vision.
1. ITIL Foundation ITIL 4 Edition, TSO – 2019, p. 80
2. Ibid, p. 82
3. Ibid, p. 118
4. Ibid, p. 191
5. Ibid, p. 56