Basics of Change Management

Change Management is quite popular topic and a really important aspect for any organisation to run their daily operations normally. Its very critical to understand this process as if done properly, it can improve the service availability and reduce any unplanned outages. But if its not understood or not followed properly, it can cause disasters and sometimes reputation loss.

Change is good. Progress comes from change, and organizations change on a daily basis. When it comes to information technology, organizations must take steps to ensure that change achieves business objectives without disrupting operations.

I am not going to discuss typical ITIL change management model which you can find it in ITIL manual guide. Here, I’ll cover change management which is based on ITIL however has been modified and then applied successfully numerous times.

There are 2 concepts in change management:

  • Strategical Change
  • Infrastructure Change or Service Change

In this blog we will discuss Infrastructure or as some call it Service Change. This is the area where most of the IT personnel get involved in their daily work.

Also the process below is a very simple representation of Change Management. It does not include the more thorough concepts like RPN, Governance etc.  This is ideally suited to IT personnel/companies that don’t currently have Change Management process in place or looking to improve. This guide can be used as a starting point to implement or modify your existing CM process.

We are not going to discuss Strategical change here. I’ll cover it separately.

What is Service Change?

Any change which can impact normal services to the end users or customers is a Service Change. It has 3 categories:

1.  Standard

2. Normal

3. Emergency

 

Standard Change: These are very low impact changes and most times are pre-approved in the change management process, sometimes classed as white-listed changes. E.g password changes, changing backup tapes.

Normal Change: Is a change which can cause disruption to the normal services and needs to be managed in a very controlled manner. Hence, all normal changes must go through the Change Management process.

Emergency Change: Is the change which generally happens on the fly in case of an emergency situation like an unplanned outage or system failure etc. These changes then go through the change management process after the services are resumed and then documented accordingly. Most of the time these changes get approved at the Senior Management level (ECAB) as the risks associated are really high.

Request for Change (RFC):

RFC can come from Service Desk, where user or customer has opened up a ticket for an issue which requires changes to the system or when engineer is doing some maintenance work which needs some configuration changes to the baseline of the system or IT Project work. A good RFC document should have the following items:

1. Type of change (Standard, Normal, Emergency)

2. Description of the Change

3. Expected Impact of the Change

4. Change tested in the test environment (yes/no)

5. Risk assessment

6. Rollback plan

7. People involved in the change

8. Scheduled time of the change

9. Business justification/ approval

10. Notification

Once RFC is ready and submitted, it goes through the approval process as shown below:

 

All RFC’s must be approved by a relevant authority. In most cases, it is the Change Advisory Board (CAB).

Change Advisory Board (CAB)

CAB has a representative member from each of the business groups who has the technical, operational and business understanding and can provide meaningful input to the Change Manager to aid him to make the right decision.

I remember when I became a member of CAB and attended my first CAB meeting, few questions came into my mind – what are we going to discuss, what are the questions that can help us assess the request for change properly. I sat there and observed other members in the team, we all went through the RFC together and went through a series of questions.

When I went back to my desk I thought there must be a better way of assess the change for request. So I decided to research on this topic, found some information on the internet but again that wasn’t very clear. I finally found my answer while preparing for my ITIL exam.

During that time I also attended an ITIL seminar where the presenter explained the concept of seven R’s in the Change management process. Lets see what these seven R’s are:

  • Who’s Raised the change?
  • What is the Reason for the change?
  • What is the Return required from the change?
  • What are the Risk involved in the change?
  • What Resources are required to deliver and support the change?
  • Who is Responsible for the build, test and implementation of the change?
  • What is the Relationship between this change and other changes if any?

These questions will definitely help you to assess RFC’s properly.

In a nutshell, Change Management process ensures that organizations follow a standardized process for requesting, reviewing, approving, and implementing changes to information systems.

“Change is Good but it must be controlled”

Hope you find this informative!

2 Replies to “Basics of Change Management”

  1. What impact is automation having on classic change management process ? Are we moving to a state where any change will be “On-Demand” ? Also, how is Cloud impacting the overall change management process… would be good to know about these topics as well…

    1. First of all, thank you for reviewing my blog and posting your questions.
      These are very good questions and I’ll certainly cover them in more detail in my future blog on Change Management. In the recent years, many companies have started to automate their CM process mainly to save time but also to keep track of changes for compliance reasons. Some of the Enterprises (including the Cloud providers) are already integrating their ticketing system with Change Management and automating CM with one click functionality to make it more efficient which makes perfect sense. For e.g. some companies use automation to calculate risks associated with a change. They use equations, algorithms etc. to automatically calculate risks. There are various other examples out there of how companies use automation with their CM process.
      As far as on-demand change is concerned, I personally don’t think that we will be able to go to the state where all changes will be on-demand as some are really high-risk changes but yes, low-risk changes (white-listed) can go in this category.
      Now, how cloud is impacting CM process it’s a vast subject and I will try to cover that in my future blogs.
      I believe automation is the future and CM is no different. At the end of the day, it all comes to cost especially for the SMB’s.

Comments are closed.