Last time, we published part one of our change management tips blog, which looked at how to make your change request forms easy to use, how to make your initial change sanity check count, and how to supercharge your change advisory board (CAB). In part two, i.e. this blog, we look at how to successfully manage change build and test, implementation, and change reviews. Offering tips across each.
Before we get started - if you'd like to access all of our change management tips in one place, please download our complimentary White Paper. This features all ten tips covered as part of our two-part blog series, plus a little extra.
How to Manage Change Build and Test Better
One of the biggest factors in increasing the probability of a change being deployed successfully is ensuring that the appropriate levels of testing are carried out – to make sure the expected outcomes match reality.
Testing the change also gives you the opportunity to work out any issues with the deployment procedures you’ve created. And one of the first things to look at, while also making life easier for change testing, is the development of standard build and test methods. And if you can use automation, fantastic! It saves time, duplication, reduces the likelihood of human error, and the economies of scale can be impressive.
If automation isn’t an option, ensure that your build and test methods are documented and templated where possible. Have a list of standard tests and checks to follow, so that even if you can’t remove the potential for error completely, you can ensure that the testing is being carried out consistently and that nothing is missed.
Also ensure that your build and test environments are fit for purpose – does the environment match the type of testing to be carried out?
Implementation Tips
After all the pre-work, the end is finally in sight. The change has been raised, sanity checked, reviewed, authorized, and tested. Now it’s time for go-live. But before we all sit back and relax, we need to survive the implementation stage.
Great communication is the key to a successful deployment. So, ensure that if downtime is involved, business approval has been obtained, a communications plan is in place, and the appropriate service level agreements (SLAs) have been relaxed.
Also, make sure that the agreed implementation plan is followed – yes, I need to state this – and that everyone involved has the contact details (and back up contact details) for the other invested parties. There’s nothing worse than being involved in a change in the middle of the night that’s overrunning because you can’t track down the person who’s deploying the code, bouncing the server, or rerouting network traffic.
Plus, once the change has been made, make sure the post-implementation checks are carried out – is everything as it should be and are there no adverse effects? If the change has not been successful, then the remediation plan discussed and agreed at CAB must be followed.
Make Your Reviews Count
We’ve done the change and everything has gone to plan, or at the very least nothing is on fire. The final step is to carry out a change review to look at both what went well and what can be improved on for next time.
Let’s start with the positives. If the change went well, then that’s great. Look at what was done and who was involved so all the great work can be captured for next time, perhaps in the form of change models or standard changes.
Now for the not-so-great side of change reviews. If things went badly, for example if the change broke something, caused an incident, exceeded the implementation window, or had unforeseen effects, a review must be carried out to understand what happened, the root cause, any remedial actions and finally, any actions to prevent recurrence.
If the change has caused incidents, then you’ll be involved with both the incident and problem management processes. You’ll be providing information to incident management about the nature of the change and exactly what was done during the fix efforts and, later on, you’ll be looking at lessons learned with problem management in an effort to prevent recurrence. Above all, you want your lessons learned to be captured, discussed, and acted on. And a great way to make sure this happens is to have a regular CAB agenda item for lessons learned and continual service improvement (CSI).
When reviewing changes, don’t forget to look at things from a business perspective. Speak to your customers and ask them if they feel the expected results were delivered and that the promised benefits have actually materialized. The next step is to look at the technical benefits, for example, are we in line with the current recommended levels of patching, has performance been improved, or do we have more resilience?
The final stage of the review step is to close the loop. Make sure that your infrastructure and IT service records – a configuration management database (CMDB) or similar – are updated such that what we have captured in our documentation matches what we have in our environment. If the change was to fix a problem record, then work with problem management to ensure that the issue has been resolved and with the service desk to let everyone else – including those affected – know.
So, there you have it, our top tips for change management across two blogs. Hopefully they will help you to reap the potential benefits of effective change management – with change risk effectively managed, change delays and failures reduced, and change-related incidents and problems minimized.
Is there anything you would add? Please let us know in the comments.
