5 Tips for Supercharging Your Change Management Process

When creating a request for change (RFC), it’s tempting to stick to the bare minimum. After all, most of us have better things to do than populating endless forms with information that nobody really needs to know. I mean what are the chances of the requested change going wrong?

Apparently pretty high it seems, if the oft-quoted incidents-related-to-change numbers are to be believed. So with a high proportion of incidents caused by a change can you really afford to be slapdash when submitting an RFC? So what can you do to make your RFC process, and forms, better? Here are my top tips for supercharging your requests for change.

1. Ensure that All the Required Supporting Players Are On Board

You may have internal and/or external supporting players as part of your RFC process. So it’s essential that they are aware of what, and when, work needs to be done. Sounds like common sense, right? Well yes it is, but you’d be amazed how many times this dependency isn’t taken into consideration. It’s also critical to your change management process that you ensure that such supporting players have the bandwidth to carry out what you’re asking and within the timescale proposed. Just presuming that those required to help with RFCs are just sitting around waiting for you to give them something to do will definitely cause you issues. In order to keep your change process running smoothly, and to keep your colleagues happy and on-side, you’re going to want to have these discussions before you write the request for change, not after it’s been submitted.

2. Ensure that Your RFC Has Sufficient Lead Time

Is there really enough notice to make it work? Ideally your organization will already have a change policy and the RFC notice period will be clearly defined within it. If not, be realistic and ensure that you take all stages and connected changes, including those by supporting players, into account. The last thing you want is to have everybody lined up to do their part only to find out that another change, which is going to take a couple of days, needs to happen first. You won’t be very popular if this happens.

3. Ensure that You Get Your Change Approved by the Right People

Are the right people approving your change, based on the services affected and business impact? Again, I’m hoping that your change policy is in place and that approvers have been properly thought through.  Without it, you’ll struggle to know who these people are and will likely waste time trying to find out. However, it remains vitally important that you gain approval from the people in the business that know the business impact of proposed changes. For instance, proposing shutting down the payroll server on the 25th of the month is a stupid idea.

4. Ensure that All Relevant Parties Are Notified of the Proposed Change

Is there a plan to notify everyone affected of the requested change? The name of the game here is information sharing and making life easier for the service desk. Sticking a message up on an infrequently visited news page on your company intranet is probably not going to cut it. And have you ever spoken to a stakeholder when they’ve called to say that they can’t access a service, watching them turn into a monster after telling them, “But we did inform you Mr. CFO…it was on the intranet”?  Equally important is not bombarding everyone “just to be safe.” Ensure that notifications are targeted and timely, in a medium that will be seen. Don’t know what that medium is? Just ask your stakeholders.

5. Ensure that You Locate All Tickets Related to the Change

Is the proposed change linked to any related incidents, problems, known errors, releases, projects, or other changes? It’s tempting to assume that all related tickets will have already been linked as part of the RFC completion, but the chances are that a quick search will locate at least a few more. Knowing what issues the change will impact will give yourself, change approvers, and the change advisory board (CAB) a more detailed account of risk and urgency together with an additional way to measure success post-change.

Feeling Super(Charged) Yet?

These five tips should take your change process and RFCs from acceptable to trusted, and save RFCs from needing to be passed backwards and forwards for additional information.

Remember that wherever possible you should use standard repeatable changes to save everyone time and effort. However, don’t be tempted to try to hoodwink your colleagues into thinking a change is standard when it’s not. The repercussions can be wide reaching and will reflect badly on not just yourself but your entire department.

So that’s my top tips covered. What tips would you add?

If you would like to hear more about improving your organization’s change practices, then I recommend this change management webinar by ITSM-industry luminary Ivor Macfarlane.