How ITIL Change Management Improves Incident Management

Change Management is usually thought of as a back office function that minimizes the chances of screwing things up while making changes. When done right, it does a lot more. Read how Change Management improves Incident Management.

Added Value of Change Management

Change Management Improves Incident ManagementIn How to Implement Basic ITIL Change Management I talked about the primary role of Change Management – rapid implementation of business-required changes, while minimizing the number and impact of change related Incidents.

Most people get how taking the time to evaluate Changes before implementing will uncover problems before they occur. Heading these off at the pass is job one. (Does anyone ever see a pass these days, or know how to head something off at one?) Avoiding embarrassing mistakes, customer impact, service outage, rework, etc, are all good, but that’s just the beginning – there’s much more.

But Wait! You also Get…

What changed? How often have you heard that when something breaks? If something used to work, and now doesn’t – logic tells you something had to have changed. So, what is it?

The very act of documenting Requests for Change (RFC) and reviewing them at CAB gives you an excellent log of what changed and when. RFC tracking tools (see my RFC Tracking Tool) have field(s) to list Configuration Items. This is where you put things like server name, application, software components, etc, related to the change.

As a member of CAB, Service Desk should insist that RFCs be clear and complete, with an eye to troubleshooting if needed. If it’s not clear, CAB should request better change documentation.

Ridin’ Shotgun

Way back in my days of electronics troubleshooting, we were taught to look at the symptoms, and use our knowledge and experience to first ‘shotgun’ some highly likely causes. If your first shot or two doesn’t fix it, you shift into structured troubleshooting mode – where you Change Management and shotgun troubleshootingsystematically eliminate possible sources until you’ve determined the actual cause.

Structured troubleshooting makes it nearly impossible to miss, because you’ve not left to chance the elimination of possible causes. But it also takes a lot of time. And in Incident Management, time is short because customers are down.

Good what-changed information gives you a head start, and you can save a lot of time getting to the real issue.

Harnessing the Change Schedule

The Change Schedule is a goldmine of information for support staff. Service Desk staff should check the Change Schedule every morning to be familiar with recent changes. Techs should search the Change Schedule as soon as they know what applications and/or systems are involved in an Incident they’re working.

The RFC shows who was involved with a change, so support staff can contact them for more information about the change and the problems they’re seeing.

A Tale of Two Cities

Tale 1:

Let’s say an RFC was submitted, reviewed and approved to update the disk array controller firmware on server abc on Saturday at 9:00AM. The change works as planned.

Let’s then say that at 8:30 on Monday morning, Service Desk gets a call about the iWeird application having problems. The user reports that when they try to update records in iWeird, they get a strange message, and then the browser hangs.

So, the enterprising Support technician looks at the Change Schedule and notices the RFC for the array controller update on abc, which she knows to be the primary server for iWeird.

Rather than start with systematic troubleshooting, she logs onto abc, and looks for any obvious problems. She finds the system log is full of disk write errors starting around 9:18 on Saturday. Related to the change? Highly likely.

The Support tech now has a very likely cause to shotgun, and has saved a lot of time getting there.

Tale 2:

Same change is implemented, but with no change documentation.

This time, when the call comes in, the Support tech has no way of knowing about the system update, and is forced to do a more systematic troubleshooting. Most likely, she’ll start with verifying the client computer – basic connectivity, browser, proxy, etc.

A Stitch in Time (Saves nine?)

This is one of those places where you Go Faster with Good Brakes. Slowing down to properly document and review changes accelerates Time to Value in two great ways:

  • Helps Change Management do a good job evaluating proposed changes, reducing risk, and avoiding unintended business impact
  • Speeds resolution of change-related Incidents, improving customer productivity and satisfaction.

Bonus!

Getting started with ITIL Change Management? Check out How to Implement Basic ITIL Change Management.

By Greg Sanker

Photo Credit
Photo Credit