IT Change Management Guide – How to Manage Changes in your IT Operations?
IT change management is one of the most important aspects of your service management and IT operations—so much that it can make or break an IT enterprise. In this blog, let’s go through what changes are, in the context of IT operations, and how to set up an IT change management function and go about managing changes in your IT ecosystem.
Read on.
What is a Change?
The ITIL® definition
ITIL defines a change as “the addition, modification, or removal of anything that could affect IT services. The scope could include changes to all architectures, processes, tools, metrics, and documentation, as well as changes to IT services and other configuration items” 1
What happens in most organizations?
Although ITIL is not prescriptive, it’s worth noting that ITIL’s suggested scope of a change is a far-reaching definition. In most organizations, the scope of changes under the control and management of the ITSM function is much less than stated in ITIL. Most implementations of ITSM restrict the extent of changes to include just the IT services, the applications and infrastructures that underpin them, and the tools used by ITSM. Changes to the architecture tend to be under the management of a separate IT infrastructure function. Changes to documentation and processes changes are often managed under the organization’s quality management system.
“Any addition, modification, or removal is a change to the current status that should be recognized as a change and appropriate management.”
You can learn more about the basics of IT change management in our blog here.
Relationship between Changes and Releases
Some people in ITSM get confused between what is a change and what is a release. ITIL defines a release as “One or more changes to an IT service that are built, tested, and deployed together. A single release may include changes to hardware, software, documentation, processes, and other components”
Hence a release is a collection of one or more changes that are deployed into use at the same time.
To further help understand the differences, consider the process for managing changes, and the process for managing releases and deployments. The IT change management process concerns itself with the approval of changes, whereas the release & deployment management process plans, schedules, and controls the build, test, and deployment of releases. Hence release management is in effect the process that implements approved changes.
For better understanding, you can watch this video.
Examples of changes from inside IT
- Updating server-based application software, firmware, and network routing tables
- Attaching a new PC to the network
- Amending the incident management process
- Downloading a new application onto a smartphone
- Applying a routine anti-virus update
- Changing the structure of the IT organization
- Making a configuration change to the ITSM toolset
- Changing the support hours of the service desk
- Taking services off-line for maintenance
- Updating the version of database software
All of these are changes that should be under the control of the IT change management process.
Examples of changes from outside IT – to aid understanding
Consider changing the design of an aircraft. The change could be as small as changing the length of a screw used to fasten parts together or a more significant change, such as altering the wing’s shape to improve fuel efficiency. In aircraft design, safety is of paramount importance. Clearly, a change as fundamental as altering a wing’s shape would have to be fully evaluated, tested, and approved before implementation. But consider changing the length of a screw. What looks at face value to be a trivial change could, in reality, add significant risks. How can you be sure that the screw will behave under stress in the same way as the previous screw? Both of these examples are changes that require management.
How to set up a successful IT Change Management function?
Draft a Baseline
The first step to setting up an IT change management function is to fully understand how changes are currently managed and who is involved so that you can keep a tab on what works well and make informed decisions on high-priority areas. This can be achieved by taking a baseline, consulting with everyone involved in the lifecycle of managing changes. Once you have the baseline, the expected outcomes from implementing change management must be discussed and agreed upon with stakeholders from the business, IT, development, and ITSM. Once the outcomes have been agreed, the activities to support the necessary changes in attitude, behavior, and culture should start – then continue throughout and beyond the change management implementation.
Skills and Experience
You need to understand what skills and experience individuals require to work in your IT change management function, using the change management roles as the framework. The change administrator role requires good attention to detail and can work with care and accuracy, following a defined process. Keep in mind that the experience of doing this in IT change management, or experience in ITSM in general, isn’t essential, as they will need to follow your processes and policy, not ones they have previously used. The change manager and change owner roles both require skills and experience in persuasion and negotiation. It is also beneficial if they have good knowledge of the business and its objectives. The change manager should have skills in ITSM; the change owner must know about the IT products and services that they will represent.
Find the Best People
Many organizations already have individuals in the business with the required skills and experience to work in an IT change management function. They may already be working in ITSM, or maybe working elsewhere in the organization. Finding people within your company can be a good approach as they are more likely to understand the culture and may have existing relationships with key stakeholders. If you need to look externally for IT change management staff, then a skills framework like SFIA can provide a sound basis for the job specification’s skills section.
Establishing Relationships
Success in IT change management is mostly dependent on building good and trusted relationships between those working in change management, ITSM, the users, and IT. If such relationships are non-existent, you can borrow the techniques from organizational change management. A good approach is to bring together people from all of these areas to design how your IT change management will work. “Tuckman’s Stages of Group Development” provides useful insights into how to create effective teams across organizations.
Choosing the Right Tools
You can establish change management in your organization, just using standard office applications for documentation and spreadsheets. However, this can be inefficient for anything more than low numbers of changes. While custom solutions can be developed using workflow applications, IT change management can benefit from using ITSM tools with inbuilt capabilities and integration with ITSM processes, especially configuration management. For example, Freshservice’s extensive ITIL change management module can support all change-related activities and provide management reporting with no overheads.
Defining the Process
Many tools come with a pre-configured change management process. If you don’t have this, then the processes should be defined using ITIL as a starting point, then tailored to fit your IT operations with input from all stakeholders. It’s a good idea to keep the process as simple as possible to aid understanding and adoption and speed-up implementation.
Incremental Adoption
There are two approaches to implement IT change management: Phased, or big bang. A phased approach is where you start small, learn lessons on the way, and expand the project’s scope incrementally. The big bang approach is where you implement IT change management all in one go for all services, various types of change, and service providers. This is a higher risk and can require much effort to make it work in the early days.
While you are free to choose which approach you take, good IT change management starts with the first step, however small.
A good approach is to select a small scope for your initial implementation where you can make a visible and positive difference. This can be for your overall IT operations management, a particular service, or for all major changes, or for a specific IT function such as application changes. By starting with a small scope, you can test your change management approach and make adjustments more easily. The important thing is to learn from your mistakes and be prepared to modify the change management process, policies, training, and education before incrementally increasing the adoption scope.
In case you’re wondering, here’s a short video on how you can manage your change processes and transitions with the Freshservice change lifecycle feature.
IT Change Management Best Practices
Creating an IT Change Management Policy
All implementations of IT change management require creating a change management policy, setting the rules and framework for how change management will operate and impact your IT operations. The policy should include all IT change management definitions, rules, templates and guidance. This should encompass the different types of change under IT change management, the change management process and all variants, notice periods required for submitting RFCs, the different change authorities used for approving changes, members of the change management CAB, and detailed roles and responsibilities for all activities in end-to-end change management.
Defining Change Authorities
There should be several different change authorities defined in the IT change management policy. Examples of change authorities in IT change management are a change advisory board (CAB), the change manager, and an IT support technician. The concept of change authorities in IT change management helps to avoid the idea that only one person, the ‘change manager,’ is responsible for approving changes. Using different change roles will prevent delays in implementing changes and manage any overloads in the IT operations management process.
Requesting Changes
Every change that is not defined as a standard change should be requested. Standard methods such as using a Request for Change document should be used, as free form requests can be challenging to interpret and assess.
Categorizing Changes
Every change should be categorized to assist with determining the appropriate reviewers and approval process. As a minimum, the categorization should include the type of change (normal, standard, or emergency), urgency, and the type of assets being changed (e.g. application, network, infrastructure)
Reviewing Changes
Other changes apart from standard changes should have at least some level of review. The reviewers must have appropriate skills and experience and sufficient time to inspect and review these changes. The level of review and people involved should depend on the risk, the impact of the change, and the affected services. The aim must be to apply the minimum amount of review necessary to reduce the risk of a failed change to an acceptable level. Having a fixed list of reviewers that review every change is a bad practice. It must be avoided at all costs, as it will add delays and frustrations for the majority of changes, and risk missing important details for key changes due to review overload.
Approving Changes
All changes should be approved by the change authority defined in the IT change management policy for the specific category and type of change. An approach where all changes go to one place, such as the change manager or the CAB, for approval is a bad practice. All approvals must be recorded.
Implementing Changes
Approved changes are then implemented using release & deployment management, keeping the change record updated as the status changes.
Relationship with Project Management
Change management must be embedded in an organization’s project management methodology. It includes ensuring that future changes are communicated to the IT change management function well in advance, which enables an early review of changes to highlight any potential issues. This allows you to manage the changes before they are formally submitted for approval. If not, there is a risk of time delays to the implementation, especially when there is a mismatch between project dates and the change management calendar.
Relationship with Agile Development Practices
Agile development practices can conflict with ITOM change management, mainly when development teams use continuous deployment techniques. Dev teams require rapid and frequent code deployments, which are often at odds with scheduled CAB meetings. In this case, your ITOM change management function should work with the development team to agree which changes are standard changes, with the latter as the change authority. Changes that are expected to come to a CAB for approval must be limited to very high-risk changes, and the CAB must be able to convene at short notice.
Change Management Automation
Using the right ITOM change management solution, you can automate several aspects of change management. They include the following:
- Verifying the completeness of RFCs
- Change classification/categorization
- Routing changes to the correct reviewers
- Reviewing responses
- Providing approvals if there are no objections
- Sending out communications about the change
Automation can significantly speed up the ITOM change management process and free your IT operations staff from routine tasks allowing them to focus on the more complex and risky changes.
Blog cover illustration by Swetha Kanithi
