This article will give a brief introduction to the Change Management process used by IT when we make changes to our systems.
There is more than one type of Change Management used in IT, Project Managers talk about Change Management as a process of managing changes to what a project will deliver.
ITIL Change Management is about managing the changes we make to our systems, this could include:-
Change Management is one of a number of processes that are described in the the IT Infrastructure Library (ITIL), this describes best practices for delivering IT services.
Change Management is a process which allows IT to make changes to our systems, whilst managing the risk and impact to the services IT provide.
Changes are logged by IT Technical staff, sometimes with assistance of Project Managers who will have a clearer view of the business benefit of the change. Requests made by customers may end up being logged as changes in order to deliver what IT has been asked, customers are not expected however to log the change (although may have input into the business justification and timing of the change.)
There are three types of Changes.
The Change Advisory Board (CAB) meet Friday morning to review any normal changes which have been classified as Significant or Major. These are changes which pose a high risk and/or impact to services. CAB members receive details of the changes to be discussed in advance, this allows them to clarify any details with those proposing the change.
As well as reviewing Significant and Major changes, CAB will also review any changes which are related to services or technologies that are in "Heightened Awareness." A technology or service can be placed into Heightened Awareness when there has been a Major incident relating to the technology/service and IT want to have extra scrutiny on any changes which could cause further disruption to service.
For Changes to appear at the meeting on Friday, they need to be logged in our IT Service Management tool (ServiceNow) by close of play Monday in order to be quality checked in advance of being sent to CAB Members.
IT uses ServiceNow to record changes. ServiceNow is also the tool we use to manage Incidents and Service Requests that customers raise with IT.
There are a number of fields that need to be completed within the Change Request, the main ones are briefly outlined below.
A full description of the change, written in such a way that those who need to approve the change taking place can understand it.
In the description you should include important details such as:-
The justification for carrying out the change, from a business perspective. May also include the consequences of not carrying out the change.
|Planned start/end date
The start and the end should reflect the total amount of time that is required to start, implement and, if required, complete the back out of the change.
It should include enough time to reasonably monitor and test the success of the change.
The times should be set so that they offer the maximum availability to the customer or a minimal risk to the service.
The times should NOT be set so that they are at the convenience of IT.
The times should be sufficiently far in the future that a fair and appropriate review is able to be taken in a measured way.
The individual steps involved in carrying out the change. This field is important as it describes the activity involved in making the change itself. This would help others to conduct the change if a member of staff is unavailable.
For larger changes, involving multiple people, record who will carry out each stage of the change and who would be able to step in as a backup.
For changes taking place out of hours, who would be the escalation points?
|Back out plan
Sometimes changes don't go to plan and need to be backed out. This field outlines the steps that need to be taken to reverse a change and restore service.
This field is extremely important! The main aim of Change Management is to manage risk and disruption to the business. As much thought, if not more, needs to be put into how a service would be restored should a change not deploy successfully as goes into the Change Plan.
What will be done to test the change in advance, test the process, test the impact?
What will be done to test the change as it is being deployed to ensure services that should be available are?
What will be done to test the change after it has been deployed to ensure that it has been successful?
Who are our Stakeholders and how will we inform them about the change we are making?
For further details, please contact David Barker, Change Manager.