Change Management

Change Management is without doubt one of the core processes in IT Service Management.

Why is Change Management so Important?

As with business change, if you do not manage changes to the IT infrastructure you are surrendering your organisation to an unidentified level of risk, and you will not understand the impact on the organisation if the change were to fail. You may also be in the dark to many internal and external changes, and non IT changes that are going on at the same time which could have an impact on your organisation. There is also a major connection between uncontrolled change and service failure.

Should the Change Management Process be the same for every Organisation?

No. Different organisations have diverse levels of risk tolerance. For example, at one end of the scale, let’s say we have a nuclear power plant, and at the other end of the scale let’s say we have a small dot com company. Which do you think is more risk averse? Of course the former. Just bear in mind that all organisations are likely to lie somewhere on this scale and a change management process will need to be adopted according to the level of risk exposure to the company.

Managing Change

Okay, hopefully we all agree that  there is a real need to manage change effectively, but where do we start and how? Below are some guidelines outlining processes required for effective Change Management which I hope you will find useful. Please note that it may be sensible to consider running this under an official project structure.

Mission Statement

You need to have a goal, a vision, or maybe even a mission statement. For example:  “The efficient and swift management of all changes to IT Services, in order to reduce the effect of change related Incidents upon service quality.”

Scope

You will need to identify the stakeholders, get senior management buy-in, delegate roles and responsibilities and document the scope of the process.

Senior Management Commitment

Buy-in will be needed from everyone that will be involved in this project, and most crucially commitment from senior management will be required to ensure that no one will be allowed to avoid the process. To achieve this you may need a senior champion to provide direction and guidance.

Roles and Responsibilities

There are a number of roles that need to be recognised and assigned. For instance, the Process Owner, the Change Manager, Members of the Change Advisory Board. Also, who will be responsible for managing the change process on a daily basis? And finally, you will need to identify who will be authorised to raise changes?

Process Design

You will need to design the Change Management process. This is extremely important and requires a lot of thought and analysis. A poorly designed Change Management process could potentially cause more harm than no process at all! Basic process templates are available that can be used as a starting point.  However, some considerations that will need to be taken into account are:

• Are you looking to implement Change and Configuration Management simultaneously? If so they will need to be planned in conjunction with each other.
• You will need to consider the interfaces with Incident, Problem, Release and Continuity Management processes and others if they exist.

Your design process should at least include the following steps:

• Initiation and Sponsorship
• Evaluation (Filtering)
• Acceptance & Matching
• Prioritisation, Impact and Urgency Assessment
• Approval and Authority to Proceed
• Design Build and Test
• Approval and Authority to Implement
• Implementation & Operational Review (Back out or remediation as necessary)
• Post Implementation Review and Reporting
• Closure

Designing the Request for Change form (RFC)

You will need to design the Request for Change (RFC) form. Either an electronic or paper based form, with appropriate fields. For example:

• RFC number (plus cross reference to Problem report number, where necessary)
• Name, location and telephone number of person proposing the Change
• Date that the Change was proposed
• Change priority
• 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
• 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. ‘new’, ‘assessed’, ‘rejected’, ‘accepted’, ‘pending’, ‘completed’, ‘closed’

Process Automation

Depending on what tool you have available, you now need to configure the tool to automate the entire process. This will either be an in-house job or we may need assistance from the toolset vendor.

Types of Change

You will need to consider the different types of change as 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

You need to consider how Service Requests will be handled, either via a different process (Request Fulfilment) or via the change process as minor changes. Most organisations will find that they may be limited by the tool being used for the Change Management process.

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 and need 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.

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 good rule of thumb is that if more than 5% of all changes are categorised as emergency, something is not right.

Don’t forget about Metrics

They are very important in charting the progress toward achievement of the stated goals of the process. Also, it is always necessary to consider the urgency of changes in order to determine the order in which they should proceed. This is especially important when only finite resources are available. It also helps to ensure that the business priorities are always being considered in terms of which activities should take place in which timeframe.

Service Management Best Practices

Service Management emphasises consideration of the 3 P’s. These are People, Process and Products. ITIL provides us with the best practice process guidelines, Technology vendors supply us with the products. The final factor, the People, is the most difficult to conquer of the three and most often the one forgotten. To begin with, Service Management must also be considered from the HR perspective. Does the organisation have the right people, with the right skills and knowledge necessary to perform their assigned duties? How are people measured (i.e., speed of delivery vs quality)? What is the reward structure of the organisation like? In other words, what incentives (bonuses, promotions, raises) are created to make the necessary changes in behavior?

This is the most important factor that will have the greatest impact on the success of the program. After all, even the most well intended change programs supported by cutting edge technologies fail when people fail to provide the necessary support.

Other Considerations

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 of implementing change and transformation programs in a multitude of environments, businesses and organisations.