Change management can be a complex and risky process that can pose significant business risk if poorly implemented. Learn ten golden rules for creating a solid change management policy.
Change management is a necessarily complex and complicated process that, if properly developed and executed through reliable measures, can be a true boon for any organization and its continuous evolution and growth. Working in technology involves a certain level of irony in the sense that change is inevitable, but if implemented poorly it can pose significant risk to business operations.
SEE: Power Checklist: Troubleshooting Hard Drive Failures (TechRepublic Premium)
Throughout my career, I have found executing change to be one of the most stressful elements of the job. So, I came up with these 10 golden rules to help safely streamline the process for better results.
1. Set maintenance windows for hosts / services / users
It may never be a good time to reboot a particular host, but some times of the day may be better than others. This is never a popular concept among IT professionals, but a server down for a 4am switch is likely to have less impact than one down for 4pm Identify maintenance windows for systems, services to help identify the safest time to perform any work on them, whether or not this work may cause an interruption. Do the same for users to identify the time periods when they are least likely to require access.
2. Establish a list of standard terms and tasks related to implementing changes that will be used in a form that describes the change.
The form should incorporate these terms and tasks, as well as the details related to rules 3 to 8.
- Change Description; what you intend to do. This is the “what”.
- Change justification and priority; the reasoning behind the change and how critical it is to the business. This is the “why”.
- Hosts / services / users affected; what elements or people will be involved. This is the “who” and the “where”
- Maintenance window during which the change will be executed. This is the “when”.
- Implementation plan, technical validation plan and business validation plan. This is the “how”. The implementation plan should outline the change step by step.
- The technical validation plan confirms that the change was successful from a technology perspective (for example, an operating system was updated and is working or a network card was replaced).
- The business validation plan confirms that the change was successful from a business operational perspective (for example, clients can connect to the updated server and process transactions).
- Also include a rollback plan to describe how to reverse the change and change the output terms such as “Implemented successfully”, “Implemented but with issues”, “Implemented but reversed”, and “Not implemented due to issues”.
3. Develop a fluid mindset for preparing and planning for change.
Since every change is different, from small to major impacts, it helps to ask a series of questions to better identify the risk factors for a change and how to minimize potential harm.
- Will there be an outage, and if so, for how long and who will be affected?
- Who needs to be informed or involved with this change? Who should approve it?
- Has the change been properly researched, prepared and tested?
- What’s the best way to do a full post-change validation?
- How can you build change in the best possible way to eliminate failure?
4. Evaluate change to determine worst-case impact
Conduct a risk assessment to identify the worst-case scenario if change causes impact and how you can recover as quickly and efficiently as possible. Include this in the change form.
5. Optimize the ability to make an immediate withdrawal when possible
If problems were found, identify the best way to roll back the derailleur immediately and with the least amount of impact or damage. A good strategy would involve replacing one server with another by shutting down the original server and then turning it back on to restore service if the change was unsuccessful.
SEE: Checklist: how to manage your backups (TechRepublic Premium)
Note that nature cannot reverse some changes. An effort to replace a faulty hard drive in a critical server will not lead to putting the faulty disk back in the server, so set reasonable expectations regarding recovery plans.
6. Set deadlines for all change-related tasks, including the withdrawal plan.
For example, for a four-hour maintenance window, you can schedule two hours for the deployment plan, 30 minutes for the technical validation plan, 30 minutes for the business validation plan, and one hour for the rollback plan. This helps ensure you don’t cross the maintenance window threshold (but be aware of what might happen if you do, just to be safe).
7. Inform all stakeholders and participate in change.
Make sure all staff who will be involved in or affected by the change know the details and ramifications and have no concerns or objections (or if they do, that they are satisfactorily addressed).
8. Go through a thorough approval process.
Approvals should involve senior and executive staff and should be based not only on the authority to issue permission to proceed, but also on technical expertise to confirm that the change steps are sound. Approvals must take into account the risk assessment and priority of the change.
9. Follow the change management process through the approved change form.
Close all tasks as appropriate to mark them as completed or failed.
10. If applicable, reverse failed changes with a review and identification of what went wrong and why
Avoid engaging in blame games unless there has been outright negligence, and address such failures accordingly. Develop a strategy to redo the change successfully.