ITSM 101: Change Management Tips (Part 1)

Most if not all of us know that the change management process ensures that risks are effectively managed with changes reviewed, approved, and scheduled in a sensible way; that regulatory requirements are met; and lessons learned are captured. So why are so many of us struggling to get the basics of change management right?

 

Change management sits in the service transition stage of the service lifecycle along with the other key IT service management (ITSM) players: release, knowledge, and configuration management

Thus, when describing the change process, the people involved – from change managers to change advisory board (CAB) members – are the guardians or protectors of our live production environment and business operations.

Ultimately, change management in place to protect everyone, in this case by ensuring all changes are sanity checked, tested, reviewed, authorized, communicated, and scheduled at a sensible time. With the key areas to focus on being:

• Creating the change
• Reviewing and evaluating the change
• Change assessment
• Authorizing change build and testing
• Coordinating change build and testing
• Authorizing change deployment
• Coordinating change deployment
• Review and closure

Much of how to do this is included in ITSM best practice documentation such as ITIL. So, this blog, and part two, drop into the detail to offer tips that help you at a more granular level. Here we start here with the following three pieces of advice:

• Make your change form easy to use
• Make your initial sanity check count
• Supercharge your CAB

Make your change form easy to use

One of the golden rules of ITSM is to always try to make it easy for people to use your process. If raising a request for change (RFC) is a 45-minute saga of multiple forms, menus, free-text fields, and radio buttons then – newsflash – people will try to avoid it by either not engaging with the process (hello raft of unauthorized changes) or by using the standard-change process (a quick route for pre-authorized low-risk changes) inappropriately.

So, make your RFC form as easy as possible to use such that RFCs can be quickly raised in an accurate, consistent way.

Although less isn’t necessarily more, as it’s important to have the right information in change requests for review and approval purposes. Here, those involved need to have all the facts required to make the right decision for your end users/customers and business. Things you should consider having in your change form include information related to the following:

• Title/Description/Reason
• Service(s) affected
• Whether the configuration management database (CMDB) – if you have one – needs to be updated afterwards
• Information security considerations to be taken into account
• Known risks
• Implementation windows
• Implementation teams
• Pre-implementation testing
• Implementation plan
• Post-implementation verification checks
• Rollback plans
• The impact on other environments
• Whether the change needs be replicated to your disaster recovery (DR) environment

If all of this is required, make it easy for the information to be submitted.

Make your initial sanity check count

The review and evaluation of a change request should be the initial check carried out by the change manager to ensure that the change is reasonable and has all the required information filled in. There’s nothing worse than attending a CAB meeting only to find that half the change requests on the agenda either have missing information or haven’t been raised correctly. So, putting the work in early will pay off later.

Things to bear in mind when assessing a change include the benefits, hopefully putting the needs of the business first and foremost. As you can have all the technical benefits in the world but you’ll need to be able to articulate them in business language such that the change can be reviewed and communicated effectively.

Then there are the risks associated with the change. We recommend that you ask as many possible “downside” questions as possible up front so that, in the event of a change going terribly wrong, you can be confident that everything possible was done to mitigate risks and protect service during the change process.

Things to consider when carrying out a risk analysis include:

• Number of people affected
• Whether the change need to be done out of hours

• Financial, regulatory, and reputational aspects
• The effect on performance – is there any potential loss of productivity or hit on performance?
• Availability – is there any potential down time?
• Seasonal considerations, for example is the work being carried out too close to a business critical time?

Also, make sure you have clear assessment criteria for the management of changes. Examples include:

• Pre-implementation testing – how do we know this change will go smoothly? What tests are planned so that the best possible outcome can be achieved?
• Implementation plan – does it make sense, do we have the right people involved, if other teams are needed to support the change are they aware and do we have contact details for them? Are there any areas where we might need to checkpoint calls or additional support to reduce the risk?
• Communications – will there be any downtime? Do we have a way of letting the business know? Do we know who we should be telling?
• Back out plan – what happens if something goes wrong during deployment? Do we fix on fail or roll back? Are the change implementers empowered to make a decision or is escalation needed?
• Post-implementation verification – how do we make sure everything is as it should be?
• Impact to other environments – ensure that any pre-production environments will be refreshed in line with production following the change. More importantly, make sure that if the change is applied to your live environment, it’s also applied to your DR or continuity environment. The last thing you need in the event of a disaster is not being able to fail over because someone forgot this key step in the change process.

Supercharge your CAB

The CAB meeting is one of the most important and useful meetings a service-orientated organization can have. It sets out a view of what’s happening to key services over the next week or month, reviews previous change activity, and looks at continual service improvement (CSI).

So, when setting up your CAB, make sure that you have a clear “terms of reference” statement that gives attendees the right steer on how to prepare, good meeting behaviors, and how to represent changes effectively.

The change manager should also send out the CAB agenda, including the changes to be discussed, the change schedule, and any previous changes that caused incidents well in advance of the CAB meeting.  Why? Those involved need sufficient time to read and consider the changes – which might call in third-party knowledge and opinions – as well as to identify any potential issues or questions.

Of course, not every change has to go to CAB. Just use the CAB for the important stuff – your big, complicated changes that will have a major impact on the business. So, scheduled server reboots or security patching are candidates for a standard-change model. Keep the CAB as focused as possible by enforcing an agenda that only deals with the RFCs that are high risk, major impacting, or have lots of complicated detail. And ensure that the right people turn up and that all areas are represented.

An effective CAB agenda looks something like:

• Review and retrospective approval, where appropriate, of any emergency changes
• Review of implemented changes
• Review of incidents caused by change including any lessons learned
• Review the forward schedule of change
• Review candidates for pre-approved, standard changes
• Improvements and opportunities for CSI

It’s important to keep your CAB pacey, and on schedule, so that it becomes seen as a “must attend” event and a business enabler rather than yet another mandatory meeting to be sat through.

So, that’s our first three areas of change management advice. Please come back soon for part two of the blog where we’ll look at build and test, implementation, and change reviews.

Want to access all of our change management tips in one place? Simply download our complimentary Change Management White Paper below.