Is your organization planning to boost its IT service management (ITSM) maturity level by formally entering the world of change management (or change enablement as it’s now called in ITIL 4)? Why formally? All companies deal with change, but not all do so in a consistent and controlled way, i.e. with a formal change management (or change enablement) capability. If you are, where do you start, and how demanding do you need to get with the change management processes (or change enablement practices) that you wish to implement? This blog will attempt to provide some assistance in helping you along with your change management journey.
Why Change Management (or Change Enablement)?
The purpose of change management (and change enablement) is to improve the availability of IT services, especially the services that are critical for the ongoing welfare of the business. And by introducing a formal change management, or change enablement, capability the adverse effect of failed changes – the disruptions to IT services – should be minimized.
Doing nothing is not a viable option, as changes will always need to be made to the IT infrastructure; and thus a capability needs to be put into place to ensure that changes are made by the least disruptive means possible.
What is Change Management?
First off, let’s define what changes and change management are from an ITIL – the ITSM best practice framework – perspective.
The ITIL 4 Foundation book defines the following types of changes:
- “Standard changes. These are low-risk, pre-authorized changes that are well understood and fully documented, and can be implemented without needing additional authorization. They are often initiated as service requests, but may also be operational changes. When the procedure for a standard change is created or modified, there should be a full risk assessment and authorization as for any other change. This risk assessment does not need to be repeated each time the standard change is implemented; it only needs to be done if there is a modification to the way it is carried out.
- Normal changes. These are changes that need to be scheduled, assessed, and authorized following a process. Change models based on the type of change determine the roles for assessment and authorization. Some normal changes are low risk, and the change authority for these is usually someone who can make rapid decisions, often using automation to speed up the change. Other normal changes are very major and the change authority could be as high as the management board (or equivalent). Initiation of a normal change is triggered by the creation of a change request. This may be created manually, but organizations that have an automated pipeline for continuous integration and continuous deployment often automate most steps of the change enablement process.
- Emergency changes. These are changes that must be implemented as soon as possible; for example, to resolve an incident or implement a security patch. Emergency changes are not typically included in a change schedule, and the process for assessment and authorization is expedited to ensure they can be implemented quickly. As far as possible, emergency changes should be subject to the same testing, assessment, and authorization as normal changes, but it may be acceptable to defer some documentation until after the change has been implemented, and sometimes it will be necessary to implement the change with less testing due to time constraints. There may also be a separate change authority for emergency changes, typically including a small number of senior managers who understand the business risks involved.”
This is how the different types of changes are used:
- Standard – this low-risk change is pre-authorized so doesn’t need to go a change advisory board (CAB) meeting for approval. Standard changes are routine things – like maintenance, minor DevOps releases, or weekly server reboots. The activities required to implement the change are well known and proven to work properly.
- Normal – These are changes that are more infrequent, are broader in scope, or are touching a critical piece of infrastructure. These will all need to follow a defined change management/enablement process including approval.
- Emergency – these changes are outside of a normal CAB review process. They may be used for things like a server reboot to clear an issue raised by event management or some sort of error that is affecting a service to a great degree. These do not go through CAB review but should go through a post-mortem review to make certain that the appropriate procedures were followed.
Normal Changes in More Detail
Normal change types are the heart and soul of change management/enablement activity. These types of changes should be far and away the majority of changes that are actively looked at and tracked. The number of the other two types should certainly need the minority of change management/enablement attention – as emergency changes should be minimal and standard changes shouldn’t need to get change approval once classified as a standard change model.
A normal change should go through the following sequence of events:
- Define the change that’s required.
- Approve the effort to develop the change.
- Develop the change – depending on the specific change, this may be code changes, planning software implementation, or development of a solution to a problem, etc.
- Test the change – this includes the back out plan in the unlikely event that the change fails for some reason.
- Propose a scheduled start date/time for the change.
- Review by the CAB – the CAB should evaluate the change request to:
- Make certain that the proposed scheduled start date/time doesn’t adversely impact any other business critical functions or previously scheduled changes.
- Determine if risks inherent in making the change are acceptable.
- Implement on an agreed-upon start date/time within the allotted change time window.
- Document the configuration item (CI) changes made in the configuration management database (CMDB).
- Review the change after completion to make sure it meets the expectations, and that the incidents caused by this change are within acceptable limits.
These steps will need to be tweaked based upon organizational requirements, but they provide the backbone for a change management/enablement process.
Implementing Change Management
Where does one start when looking at change management or change enablement? It can be very daunting at the outset, but these steps should help to get you started:
- Identify people in the organization to be the process owner and change manager.
- Design the change process/practice. Things to think about include:
- Plan how changes will flow through the organization. Many process flow documents already exist that can be downloaded from the Internet. For example, http://wiki.en.it-processmaps.com/index.php/Change_Management
- Determine what changes will be standard changes and will receive pre-approval.
- Decide if there will be an emergency change approval process and how the post–mortem on emergency changes will be handled.
- For failed normal changes, how will they be re-scheduled to assure a successful change?
- Not making the process a burden – if it is, then it won’t be implemented.
- Start small with a particular group or particular type of change to make certain the process is working as desired.
- Determine which change management/enablement key performance indicators (KPIs) are most important to your organization and then how they will be monitored.
- Communicate the process and KPIs highlighted in your ITSM tool throughout the entire organization.
- Monitor the change management process and improve (using continuous improvement) where necessary to maintain and improve operations.
Example KPIs and Metrics for Change
Here are some KPIs for change management/enablement that might be of help – don’t just pick them up and use them, first you’ll need to understand which will help your organization to meet its goals best:
- The number of changes implemented to services which met the customer’s agreed requirements, e.g. across quality/cost/time (expressed as a percentage of all changes).
- Reduction in the number of disruptions to services, defects, and rework caused by inaccurate specification or poor/incomplete impact assessment of changes.
- Reduction in the number of unauthorized changes.
- Reduction in the backlog of changes.
- Reduction in the number and percentage of unplanned changes and emergency fixes.
- Change success rate – the percentage of changes deemed successful at review/number of requests for change (RFCs) approved.
- Reduction in the number of changes where back-out is invoked.
- Reduction in the number of failed changes.
- Average time to implement based on urgency/priority/change type.
- Incidents attributable to changes.
- Percentage accuracy in change estimates
Change is here to stay in both the business and IT worlds. And not only is it here to stay, but the pace of change also continues to accelerate. Every IT department has some form of change management (or change enablement) capability in place but, if yours is informal, your business would greatly benefit from implementing a more formal approach to managing change. It will reduce risk and the unwanted effects of badly implemented change, plus it might also speed things up.
Marc Gourvenec
Marc Gourvenec is the Marketing Director at ServiceAide, with responsibility for digital marketing, marketing programs, and demand generation. Prior to joining ServiceAide, he worked for several IT companies in the networking, security, SaaS, and virtualization environments such as HP, Quest Software, and RSA Security.
Marc is an engineering graduated from ESI School in France.
2 Responses
I don’t agree with how you describe the use of a CAB in managing changes.
Even in ITIL V3 we did not recommend that all normal changes should be reviewed by a CAB. In ITIL 4 there is much more emphasis on the need to delegate change assessment and authorization so that you don’t create a bottleneck in the workflow.
Quite an informative piece on change management… Good Read!