Getting started with IT Change Management
I was asked a few weeks ago in a training course, how to get started with IT Change Management. It was a relatively small organisation with 15 IT staff supporting about 600 IT users. So I have knocked up a few pages of notes based on ITIL version 3 Best Practice to address this issue for them. If it is of use then please use it as a start.
Free Service Management Consultancy
Getting started with Change Management
Change Management is undoubtedly one of the core processes in IT Service Management. Why? Because if you do not manage changes to the IT infrastructure you are exposing your organisation to an unknown level of risk, and will not understand the impact on the organisation if the change were to fail. You may well also be unaware of many internal and external changes, and non IT changes that are going on below the radar which could have an impact on your organisation. There is also a significant correlation between uncontrolled change and service failure.
To get a feeling for what could go wrong, imagine yourself blindfolded standing on a tightrope. This is the position you are in without an effective change management process. Try it?stand up and close your eyes. You may have trouble reading the rest of the article blindfolded, but stay with me on this. You do not know how far above the ground you are. Are you a foot above the ground or a hundred feet above the ground? What would happen if you were to fall? You don?t know if there is a safety net and if there is, will it hold your weight? You do not know how long the tightrope is so therefore how long you will be at risk. Also, is there someone else on the tightrope walking towards you? If there is there will be a conflict of interest, as one of you will have to give way. What happens when you get to the end of the tightrope? Is there another tightrope or a ladder down to safety?
Worried? Well you should be, especially if you do not have a good robust change management processes in place.
Does one size fit all? No. Different organisations have different levels of risk tolerance. At one end of the spectrum we have a nuclear power plant, and at the other end, small dot com companies. I?ll let you guess which is more risk averse? All organisations will lie somewhere on this spectrum.
Okay, hopefully I have convinced you that you need to manage change effectively, so where do we start? Below I have provided some guidance which I hope you will find useful, but it may be worthwhile considering running this under a formal project structure.
A clear statement of our goal
We need to have a goal, a vision, maybe even a mission statement. How about this? ?The efficient and prompt handling of all changes to IT Services, in order to minimise the impact of change related Incidents upon service quality.?
Scope
First of all we need to identify the stakeholders, get buy-in and assign roles and responsibilities and document the scope of the process. For example:
? ?Live? applications software
? Hardware
? Communications equipment and software
? System software
? All documentation, processes and procedures associated with the running, supporting and maintenance of the live services.
? People
Getting buy-in
We need to get buy-in from everyone involved, and most importantly commitment from senior management to ensure that no one will be allowed to circumvent the process. To achieve this we often need a senior champion to drive this forward
Roles and responsibilities
There are several roles that need to be identified and assigned. Firstly the process owner, then the Change Manager and who are going to be the members of the Change Advisory Board? Who will manage the process on a day to day basis, and also we need to identify who will be allowed to raise changes?
We need to design the process
This needs to be carefully done, but there are lots of basic process templates available which we can use as a basis. There are some considerations which we need to consider, being:
? Are we looking to implement Change and Configuration Management at the same time? If so they need to be planned together
? We need to consider the interfaces with Incident, Problem, Release and Continuity Management processes and others if they exist.
Our process steps need to include:
? Initiation & Sponsorship
? Filtering
? Acceptance & Matching
? Impact and Urgency Assessment, Prioritisation
? Approval and Authority to Proceed
? Design Build and Test
? Approval and Authority to Implement
? Implementation & Operational Review (Back out or remediation if required)
? Post Implementation Review and Reporting
? Closure
Designing the Request for Change form (RFC)
Either an electronic or paper based form, with appropriate fields. For example:
? RFC number (plus cross reference to Problem report number, where necessary)
? Description and identity of item(s) to be changed (including CI identification(s) if CMDB is in use)
? Reason for Change
? Effect of not implementing the Change
? Version of item to be changed
? Name, location and telephone number of person proposing the Change
? Date that the Change was proposed
? Change priority
? Impact and resource assessment (which may be on separate forms where convenient)
? CAB recommendations where appropriate (which may be held separately, with impact and resource assessments, where convenient)
? Authorisation signature (could be electronic)
? Authorisation date and time
? Scheduled implementation (Release identification and/or date and time)
? Location of Release/implementation plan
? Details of Change builder/implementer
? Back-out plan
? Actual implementation date and time
? Review date
? Review results (including cross-reference to new RFC where necessary)
? Risk assessment and management
? Impact on business continuity and contingency plans
? Status of RFC - i.e. 'logged', 'assessed', 'rejected', 'accepted', 'pending'
We need to automate the process
Depending on what tool we have available, we now need to configure the tool to automate our process. This will either be an in-house job or we may need assistance from the toolset vendor.
Types of Change
We need to consider different types of change. Not all changes are the same. We should have a number of categories of change e.g. Standard, Minor (Operational changes), Significant, Major (Projects), Emergency. Each will have different considerations in terms of level of Impact assessment, timeframes etc
Service Requests
We need to consider how Service Requests will be handled, either via a different process (Request Fulfilment) or via the change process as minor changes. We may be limited by the tool we are using.
Physical CAB or electronic Change Advisory Board (CAB)
The Change Advisory Board has the power of veto over Change Requests (RFCs). It aims to maintain a proper balance between the need for change and the risk of introducing new errors. It must also facilitate the efficient and prompt handling of changes. To make the appropriate response to an RFC entails a considered approach to the assessment of the risk and business continuity, change impact, resource requirements.
A personal check list helps, and could be formalised:
Change management, the CAB, ECAB and other assessors must consider the impact of the change on:
? The Customer?s business
? Infrastructure and the customer?s service, e.g. SLA, capacity and performance, reliability and resilience, continuity plans, security
? Impact on other services, projects and non-IT infrastructures (power and air-con) within the organisation
? The effect of not implementing the change
? The current Forward Schedule of Change (FSC). Is there a conflict with another change
? Resources required to implement the change and ongoing resource requirements resulting from the change
Physical vs Electronic CAB
There are pros and cons for electronic and physical CABS. Physical CABs run once or twice a week needs to be carefully planned and orchestrated, and can take up considerable time. They are an opportunity to fully discuss changes and get immediate feedback. On the other hand electronic CABs are on-going, can be run using voting buttons on Microsoft Outlook and probably don?t require as much planning, but people may not fully read or understand the change.
We need to plan for emergency changes
Emergency changes are inherently more risky and need to be carefully managed. Do not confuse ?late? changes with Emergency changes. A rule of thumb is that if more than 5% of all changes are emergency one, something is wrong.
Creating a Change Diary/Calendar or a Forward Schedule of Change (FSC)
Most tools nowadays will have this facility to either print or access an FSC from a web page. If not it can be easily achieve using a reporting tool such as Crystal Reports or Business Objects. Consider who needs to see future changes and what information they need to see.
Also don?t forget things like:
? How and when we produce Management Information
? Continual improvement. Making it better
? Measuring benefits and improvements made, and don?t forget to tell everyone about the benefits
? Engagement with Business change
? Engaging with Project Management
? 3rd party changes
? Budgets ? who pays for changes and how
? Change models for standard changes
? Selling the benefits of adhering to the Change process
This information is not exhaustive, but should get you going. It is only my opinion, but that is based on industry ?Best Practice? and a lot of experience at the sharp end (how did you think I got this grey hair?)
If you feel that we should add to this material then please let us know. Feedback is always welcome
E: Steve.lawless@purplegriffon.com
W: http://www.purplegriffon.com
T: +44 (0) 1539 736828