The 7 Habits of Highly Effective Change Managers

Change managers wear a number of different hats in ensuring that changes to the corporate IT estate are applied in a speedy, yet controlled, manner. ITIL IT service management best practice outlines how change management should work, but what are the key things an effective change manager should be doing?

Change management is the IT service management (ITSM) process, or capability, which ensures that anything being transitioned into the production environment is done so efficiently and safely – making change managers the facilitators of change and, when necessary, the gatekeepers of the production environment. They ultimately play an important role in managing risk and keeping the business operational.

I recently blogged on The 7 Habits of Highly Effective Incident Managers, so I thought I’d follow up on the same for change managers.

Here are my seven top tips for running your change process effectively or, as I like to think of them, seven habits of highly effective (and awesome) change managers – covering everything from setting change policy to running your change advisory board (CAB) like a boss.

Tip 1: Create a Change Policy

Create a policy to support your change process and procedures early on so that everyone knows what’s required from them. Importantly, when writing your policy, keep your customers in mind. In particular, don’t try to cover everything in red tape, otherwise people will quickly find ways to circumvent your process.

Your change management policy is your statement of intent, your list of dos and don’ts. Make sure that it’s clear, concise, and is aligned with existing company standards. Also ensure that there’s some flexibility built into your ways of working, such that you can respond to less common business needs as, and when, they arise.

Believe me, no matter the type of organization you work for, there will always be times when something will need to be fixed in the middle of the night or there needs to be an urgent update to your website. And while it’s important that change requests are raised in enough time to be reviewed and authorized, exceptions will undoubtedly pop up – so plan for them now when you’re not under pressure.

You might call this the emergency, or expedited, change process; and it will be used – hopefully minimally – when:

• Something’s broken and causing a major incident
• Something’s about to be broken and you need to prevent a major incident
• There are major commercial reasons, maybe in response to a move by a competitor
• There’s major risk to compliance that need addressing

You get the picture.

Tip 2: Get to Know Your Environment

You don’t need to be a technical expert to be a change manager but you do need to have a good understanding of your IT estate so that you can make the right decisions as, and when, they’re needed.

This is something that comes with time, but if you have a service catalog, configuration management database (CMDB), or configuration management system (CMS), then use them to see the proverbial forest for the trees, i.e. to see the affected services, and the business impact, not just the affected technology. Or, at the very least, to know that restarting the entire financial system the day before year end is a very bad idea indeed.

Tip 3: Make It Easy to Raise Changes

If it takes 15 minutes of mindless data submission to raise a change, then some people will avoid engaging with the change process (or at least find ways of putting changes in under the radar). So, make it as easy as possible to raise changes.

Use standard, preapproved, changes wherever possible. Start by sitting down with support teams to template the most common types of planned works.

Tip 4: Set the Right CAB Agenda

Ensure that your CAB has a Terms of Reference document so that everyone knows what they’re doing and why. For each CAB meeting, send out the agenda – including the changes to be discussed, the change schedule (CS), and details of any changes that caused incidents. And do so way in advance of the CAB meeting so that it prompts people to prepare. 

An example CAB agenda might look something like:

• Review of implemented changes
• Incidents caused by change
• Retrospective approval of any emergency changes
• Forward schedule of change
• Candidates for templates/standard changes
• Improvements – using continual service improvement (CSI)
• Lessons learned
• Good news stories
• Any pending change freeze activities/restrictions

And remember that service delivery teams, senior management, and project managers need time to read and consider the changes as well as to identify any potential issues or questions.

Tip 5: Don’t Just Administer the CAB, Own It

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 reporting period, reviews previous change activity, and looks at CSI. So obviously, ensuring that it runs effectively is key.

Use automation and standard changes to make sure that only the high impact, complex changes are discussed at the CAB – so you don’t spend 45 minutes talking about making a single network port live. And ask “the awkward questions” so that people really have to think about what’s about to be implemented – like these for example:

• Pre-change testing – how do we know this change will go as planned?
• Deployment plan – does it make sense? If other teams are involved, are they aware and do we have contact details for them? Are there any areas of concern where we might need check-point calls or additional support to mitigate risk?
• Post-implementation checks – how do we ensure that everything is as it should be now that the change is live?
• What’s the remediation plan? Do we fix-on-fail or rollback?
• What is the impact to other environments including disaster recovery?

Tip 6: Don’t Forget Project Management

Ask to attend the weekly project meeting (if your organization has one) so that you can get a heads-up of anything that could potentially impact your change schedule.

There’s nothing more frustrating than being told that a major code release needs to be deployed at 4:50 PM on a Friday evening when it had been planned for months in advance but no one had thought to tell IT. By aligning to your project and program teams you’ll get a preview of the coming attractions and you can plan them around your change schedule.

Tip 7: Tell People (About Forthcoming Change)

Make sure that the right people are aware of planned change:

• Is the service desk aware?
• Do notifications need to be sent out to customers?
• Is some other business approval needed?

Issue a CS after each CAB meeting so that everyone knows what’s happening and that there are no surprises.

So that’s my seven tips for highly effective change managers. What tips would you add? Please let me know in the comments section below.