Introduction

In the rapidly changing business environment, nothing is as constant as change itself. Any business that fails to change whether it be in terms of its strategy, products and services or fails to respond to the external environment – the market, regulations etc. is soon left behind and perishes in no time. This is enough motivation to have a Change Management process at the centre of the business – this process is owned by the Change Manager.

Businesses and IT are linked closely. That is why ITIL® defines the Change Manager role and the Change Management process around him.

Change Manager roles may not exist in isolation. With IT rapidly moving into a DevOps model, the Change manager role has been blended in with other roles, and a lot of tools are available to make the change management process stronger. This means that a lot more roles in the organization need to be knowledgeable about change management, and not just the manager. In an Agile world, change is welcome (refer to the Agile Manifesto), however, the principles of change management are still intact.

The Q&A in the next section should be understood in the context of the change manager role and not in the context of an individual. With the increasing importance of organizations being able to adapt to change, these questions are significant across the board – developers, scrum master, product owner, project managers, and portfolio OWNERS; and not just change managers. The questions focus on ITIL, so, are specific to the IT industry. Managing business changes is out-of-scope.

There is limited understanding of the change management process, as what we SEE on the ground (in most cases) is always an ‘adapted’ version, that suits the business model. This leads us to comparing processes followed ‘here’ versus those followed ‘there’. Through the Q&A in the next section, I have tried to bring up the often missed out fine print in an ITIL context.

1. What is your understanding of the Change Management process?

Organizations establish a Change Management process to be able to manage the situations that their businesses face – this could be competing products or solutions, changes in regulations e.g. safety standards and laws, changing demographics, consumer preferences, attempting to enter new markets or exit existing markets, changing technology and so on. The list can be enormous. 

Any of the situations presented above could pose significant risks to the business objectives – that could be making profits, increasing market share and revenues or even serving a market segment. No business owner would want any disruption to meeting any of the objectives above. Even if a disruption is inevitable, they would want to minimise the impact, so that it remains transparent to the consumers of the products or services and they keep getting the same quality or service levels. 

Therefore, it is essential for the businesses to put in place a mechanism to manage whatever is not in its control and at the same time be able to fulfil its business objectives, nevertheless. This mechanism is Change Management.

In ITIL, Change Management is a Service Transition process because it bridges the transition between the old and the new. The old is the baseline and the new is the modified services or added services. 

2. What are the steps in the Change Management process?3. What are the major responsibilities of a Change Manager?

The role of the Change Manager is key in the Change Management process. All RFCs should be directed, in the first place, to the Change Manager. He will then review the RFC documentation and check that all the needed information is present. If not, he needs to get back to the requestor to seek more information. He may also consult with the CAB members or any other member in the organization who can provide more information.

Once the change is recorded, the Change Manager is accountable for prioritizing it in line with the business goals and categorizing it appropriately. The categorization helps in the selection of the CAB (or the ECAB) members, and then he chairs the CAB (or ECAB) meetings. During the CAB meeting, he will seek the advice of the members of the advisory committee to be able to assess, authorize and schedule the changes.

When the change is being worked on, the Change Manager helps in removing impediments, especially when these are related to the impact or newly identified stakeholders.

Finally, once the change is implemented, he will evaluate that the business objectives have been met and the Return-on-Investment (ROI) has been achieved. He shall be analysing the change trends – like success rate, earned value, incident metrics etc. and regularly reports these and the progress of all the changes to the management.

In the capacity of the Change Management Process Owner, he should retrospectively monitor the effectiveness of the process and plan to introduce improvements whenever necessary.

4. How is the life of a Change Manager – easy or hard?

A Change Manager is one of the central roles in the IT landscape. He must make a fine balance between stability of a running system and introducing changes to it for improvement, FIXING broken stuff etc.

The most important factor is the knowledge of the change manager – functional, system and operational. Knowledge is acquired through experience and self-education.

A Change Manager also must balance the needs and risks to the various stakeholders who are impacted by the change. He needs to ensure the converse as well – those that should not be impacted must be left alone. Different stakeholders will have different interests in the implementation (or the non-implementation) of the change. Sometimes these interests may go beyond the business and technical realms.

The Change Manager must continuously ask the question – “What if …?” This is not an easy question for the one who needs to answer. When the stakes are high, such questions may not just be unwelcome, but may cause a change of direction if there is no good answer. Imagine a critical change not being implemented because one of the impacted stakeholders hasn’t prepared a ‘rollback plan’.

The job of a Change Manager is tough – one not for the faint-hearted.

5. What exactly is a ‘rollback plan’? Why do we need it?

All changes made to the baseline code and configuration pass through stringent quality gates. Such changes may have been made based on the impact analysis done in as a part of the change management process. However, as one of the US Presidents mentioned in the 1950s – ‘Plans are useless, but planning is everything’, it is quite possible that the reality after the change is implemented turns out to be something very different from what was envisaged earlier. The question is – have we planned for this ‘possible different reality’? Enter the ‘rollback plan’.

The terminology is self-explanatory. Every change that needs to be implemented must have a rollback plan, i.e. what are the steps that need to be followed if the changes cannot be implemented as planned, or the system becomes unstable post-implementation. The changes would need to be backed out with a sequence of activities, that would have people responsible for carrying them out. The rigor is the same as when implementing the change – the only difference is the intention – you are taking the system back to the baseline. Because you are backing out from an implemented change, this is also called the ‘backout plan’.

Some rollbacks may need to happen as an emergency, e.g. implementation of a new FIREWALL hardware results in cutting off the system from the supplier network, stalling the supply chain. Such a rollback may need to be handled via the ECAB.

Remember – for every implementation plan there needs to be a ‘backout plan’.

6. What is a CAB? What does it do?

The ‘CAB’ is an acronym for the ‘Change Advisory Board’. Many people think that it is ‘Change Approval Board’ – that is not right. It comprises of many members and the membership will typically be defined in the Change Management Policy. Since the CAB is an advisory board, the main purpose of having this organization is to get the right advice on matters related to changes – so membership must be chosen wisely as per the priorities of the organization. The chosen members must also be knowledgeable in their respective areas, so that accurate inputs can be provided in the form of the right advice.

The Change Manager chairs the CAB meetings and is obviously a permanent member of the CAB. Also mandatory is the Configuration and Release Manager. Other members may include – Service Desk Manager, Operations Manager, Applications Manager, Information Security officer, Incident Manager. In real life, most of these roles will participate in the CAB meetings like permanent and may only excuse themselves if there is no agenda pertaining to their role. However, such a situation is unlikely. Sometimes specific support analysts having deep knowledge on a particular topic, incident or functionality may participate upon invitation – with the sole purpose of providing the right advice.

The CAB is concerned only with changes, so most of the discussions may be around future changes – i.e. the Requests-for-Change (RFCs), what risks may be introduced as a result of these RFCs and also prioritizing these. Other topics may also include the past changes that are implemented, rolled back or cancelled. If any implemented change causes the system to be unstable and results in incidents, then these incidents also need to be discussed in the CAB.

7. Your colleague tells you that a change manager is the ‘change agent’ of the organisation. What would be your reaction? 

The Change Manager may be a ‘change agent’ of the organization, but that is not his primary job.

The Change Manager is responsible for authorizing and approving changes with advice from the Change Advisory Board (CAB). The Change Manager is the sole authority who can put his stamp of approval for a change to be implemented (or not to be implemented). Because of this responsibility, he will chair the CAB meetings.

Making the decision about a change to be implemented is not trivial, therefore, the person must be knowledgeable about the system, architecture landscape and the stakeholders. That is a broad spectrum. This also means that this person can also actually be a change agent for the organization. Help is at hand, in the form if the Change Advisory Board – which advises the Change Manager in matters related to changes.

The Change Manager is also the process owner for the Change Management process. Since processes may need to change themselves, the Change Manager must continuously validate the efficiency and the effectiveness of the steps in the change process. E.g. for standard changes, he may want to create a Standard Operating Procedure so that this stands pre-approved and the cycle time for change implementation reduces as the CAB is no longer required.

While changes may lead to disruption, the objective of the Change Manager is to minimise the disruption – through the effective use of process, expertise and tools. He should be approving only changes that are beneficial to the organisation and aligned to the business goals and the objectives.

8. What is the first step of dealing with a change? Is this mandatory?

A change is usually received in the format of a ‘Request for Change’ (RFC). Whenever an RFC is requested by the business, the first step is to ‘record the change’. This is primarily the job of the ‘initiator’ – the person who is requesting the change. This recording results in a document, that could be on paper, as well as in electronic media or even in an online collaborative tool (e.g. JIRA).

Recording, or documenting the change is an important and mandatory step, as this document is then PASSED onto the Change Management organization. The Change Management organization is headed by the Change Manager, who may request further information on the RFC if the documentation is inadequate, incomplete or ambiguous. If this is back-and-forth communication is done multiple times, it results in a loss of valuable lead time for change implementation – therefore, the documentation must be accurate. There will always be some back-and-forth communication, but the objective of properly recording the change is to minimise these transactions.

The Change Manager is accountable and responsible for reviewing the change record and ensuring that it contains enough information.

9. You are the Change Manager. You return from a 2-week vacation and realise that a few changes have been implemented 'informally'. Things are normal post-implementation. Should you care?

Unfortunately, there is nothing called an ‘informal change management’. Changes, no matter if they are small or large, have less impact or more, must pass through the change management process.

‘Standard’ changes follow time-tested and time-trusted steps and the outcome is known – however this does not mean that the steps are bypassed. It only means that efforts need not be spent for analysis and the approval, as these are pre-approved.

‘Emergency’ changes that require immediate implementation must still pass through the Emergency-CAB (ECAB) – a subset of the CAB. It does not mean that the immediate changes can be implemented ‘at will’ or ‘as per management decision’. These are common excuses.

So, as a Change Manager, once you hear about the above situation, you should be very alarmed and take action to ensure that the change management process is followed in retrospect, and the necessary documentation created for future reference. In the longer term, you should aim to make changes and strengthen the Change Management process in the organization. The situation also indicates there may be a lack of awareness regarding Change Management in the organization, so some trainings may also be useful to educate people regarding this topic and the perils of not following it.

10. As a Change Manager, how will you ensure that the RFC documentation has all the relevant information?

For every change raised, the Change Manager must do a thorough review together with the CAB. During this review he must verify that the RFC documentation provides the following information at a bare minimum:

1. Who RAISED the change? – it must be clear who is raising the change. In an organization, this would be a department or a role. Note that this role may or may not be an ITIL role, it could well be the business, e.g. the Web Marketing department.
2. What is the REASON for raising the change? – almost all changes are raised for a business reason. Obviously, the person who raises the change knows the reason best. Sometimes changes may be raised for fixing earlier failed changes.
3. What is the RETURN required for the change? – after the change is implemented, it must be useful to the business, there must be some benefit coming out of the implementation. E.g. increased revenue, more hits on a webpage, faster checkout times at a retail supermarket or increased stability of a system.
4. What are the RISKS involved in the change? – while implementing changes result is some benefits, there is always a chance that something else will break. Proper impact analysis for the change must be done – a rollback plan must be created, and enough regression testing must be factored in.
5. What RESOURCES are required to deliver the change? – this is about who and what will be required to implement the change. This may include people with the right skills, hardware, software and even facilities. E.g. to deliver a large IT upgrade program, you may need software engineers, devices, servers, licenses and new office space.
6. Who is RESPONSIBLE for the build, test and implementation? – these are the people who would be working to implement the change – typically many of the other ITIL roles will be involved together with the project organization for larger projects. Developers, support analysts, project leads, and managers are included.
7. What is the RELATIONSHIP with other changes? – this is about the cross impact of changes that are work-in-progress. E.g. a change that is about migrating Active Directory services may have an impact on another change related to corporate email software upgrade.

The above are also called the 7 R’s of Change Management.

11. What is the role of the CAB in an emergency change? 

In the context of an emergency change, we have a special CAB – called the Emergency CAB (ECAB). The ECAB membership is a subset of the more general CAB, and depends on the nature and impact of the emergency change. Because we are in a emergency, time is of the essence, and therefore a pre-defined delegation mechanism may have to be followed if certain members are not present. This definition must be included in the Change Management policy of the organization. 

To explain the need for this delegation with an example – suppose an emergency change needs a new IP to be whitelisted for changes to take effect, but the approver is unavailable, let us say that he is on a plane from Sydney to Dubai (that takes about 15 hours). A wrong approval may mean endangering the security of the infrastructure. To avoid such a situation, a delegate for the approving authority may have been defined, who can make this approval on behalf of the main person. 

Note that not all emergency changes require an ECAB. There may be emergency changes where a ‘temporary’ operating procedure may have been set till a known issue is fixed (which may be underway and will be addressed via CAB). In this case the relevant parties will execute the temporary operating procedure. E.g., the operations team kills a process daemon consuming too much memory. 

To keep the ECAB process lean, some documentation may be done retrospectively.

12. If there are too many emergency CRs coming, what may have possibly gone wrong?

Too many emergency changes may mean that in the recent past, some changes have been implemented without proper impact analysis. This, in turn, could mean there is a shortage of knowledge in the CAB. Either the right people have not been invited, or the Change Manager may not have the right skills.

Sometimes emergency CRs are a result of poorly defined processes – perhaps incidents are being pushed down as changes in the absence of a robust incident management process and without any defined problem management process. It is also possible that the configuration items (hardware, services etc.) are not assigned severities – this is the job of the configuration manager and should ideally be in the Configuration Management Database (CMDB). This lack of definition means that no one understands whether the impacted system is critical and is introducing a change just to mitigate the unknown risk. E.g. malfunction of a service that produces a monthly report may not need to be handled via emergency change process simply because you have enough time to make a permanent fix. Just raise an incident and move on for now.

Emergency changes may also be the result of wrongly prioritizing less important changes and missing on implementing the critical ones.

Emergency changes causes alarm bells and draws much attention, just like a major or a Severity one incident. Therefore, the Change Manager must educate the organization about it and when to invoke this and resist the misuse of this process.

13. How can you judge whether the Change Management process is robust and effective?

A good Change Management process will ensure that the percentage of successful changes are high. A robust process requires rigor, but that should not slow down the speed of implementing the change requests. The throughput of change requests being implemented should be high. E.g. too much of discussion and delays in decision making at the CAB may result in piling up of RFCs waiting to be implemented – this should not happen if a good Change Management process in place. Suitable delegates must be available for situations where time is of the essence, e.g. for ECAB. 

In terms of changes implemented, there should be very few that require any backing out or even remediation. Both processes consume valuable resources and sometimes specialised skills that will be charged at a premium because of the tight situation. Additional incident management capacity will usually be planned and budgeted when critical changes are implemented or a big release happens – however, a good Change Management process will ensure that the incident volumes remain well under control. 

Most importantly, changes should either deliver value by implementing improvements, or by preventing and removing the negative effects of some existing bug. This value can be measured in dollar value – increase of revenues, increasing market size, reducing downtime etc.

14. What is a Remediation Plan?

We discuss about the ‘backout’ or the ‘rollback’ plan in another question. That was about having a step-by-step guidance of how to return the system to its baseline configuration.

Now, consider the situation where an implemented change has caused some records in the database to be corrupted with unescaped special characters. This has been reported as an incident after about ten thousand transactions have already happened. You can roll back the changes, but then some essential desired functionality will be lost, and the already corrupted records still need to be taken care of.

To manage such situations, you will need to have a detailed plan on the adverse effects of each of the impacts. You will need to possibly assign extra temporary incident management capacity, so that a larger volume of incidents may be handled, and the lights remain on. Some scripts may have to be written to rectify the corrupt records directly, and for this you may need someone skilled at scripting. All this and many other things that you would possibly need to ‘douse the fire’ is what is called the remediation plan.

Remediation plans have well-defined triggers that should be agreed at the CAB. Unlike backout or rollback plans, remediation plans are not about returning to the baseline, but about ‘containing’ the damages that occur due to change implementation. There may be situations where backouts are impossible – like automatic installation of faulty security software in a hundred thousand strong software company. The best solution would be to create and push a patch to remediate the faulty installation.