Change Management in 7 Easy Steps

Just about every business has to make IT changes at some point that are going to impact customers. There’s a good way to do it and a bad way to do it. The bad way is to do it whenever you want and put out the fires if/when they happen. If I had a dollar every time something screwy happened in my career because of that, I’d have about forty bucks. So, I’m not a millionaire, but it’s still Not Good.

Here’s my tips for good change management that will get you well on your way.

1. Decide on a suitable maintenance window.**
Will your intended change impact the network or customers in some way—either as a result of the change or in the process of making it? Is it possible that it might? Then choose a time when it will impact the least amount of people. This could be after close of business, overnight, or on the weekend. Consider your customer base and network traffic patterns to make the decision. e.g. You may find that Wednesday nights are most quiet, so all major changes from now on, will be scheduled for between 1am and 4am on a Thursday morning.

2. Choose a date and schedule an appropriate amount of time for this change.**
Make sure there are no conflicts—either with required staff or other scheduled changes. Allow extra time for testing and rolling back on changes that don’t work out.

3. Notify those who will be impacted.
Send your customers an email, provide updates over social media, and have a message on your website a few days in advance of the change that explains the potential for outage, the date and time window, and the expected benefits to the customers.

4. Document the steps for making the change and for rolling back.
If you don’t intend to make the change yourself, provide detailed instructions to the people who will. Ensure there is a clear escalation path should questions or difficulties arise, and provide instructions for testing the change.

5. Test the change to see if it worked or not.

6. If the change window is blown or an unexpected outage is triggered by the change, own it and notify.
Let the customers know through those above-mentioned channels that something went wrong. Notify stakeholders inside the business who Need To Know. Give an explanation about who it affects, what symptoms they’ll be experiencing, and a realistic ETA for the fix, if you can. Be realistic and don’t make promises you can’t keep. Provide regular updates.

7. Review.
Review the change process each time to pick up any issues that came up along the way. Address any procedural or technical problems that occurred and advise stakeholders of changes in process.

** When your change management process has matured, or if your organisation is big enough, this is where a Change Advisory Board (CAB) would come in.

Think this post could help someone? Share it.

  • Pingback: Fresh Links Sundae Food for Thought from Actionable ITSM | Actionable ITSM()

  • Jon Reade

    I’d tactfully suggest another sub-step for internal changes:

    3.1…and negotiate with those affected users if the proposed time is not acceptable
    for a business reason of which you were not aware.

    Although this often doesn’t apply where a generic service is being offered, if a targetted service (eg: server hosting) is provided to an extenal customer, then negotiation should also be a consideration in that scenario. To ignore customers, particularly the external, paying variety, is to risk loosing that customer.

Archives