Change management is one of those things that no one really likes to do. Some companies do as little as possible with change control— they invest just enough into it to check it off of a list and move on.
But if you approach change management the right way, you’ll end up saving yourself a lot of time, and you’ll make life easier on you and on others throughout your organization. In fact, you might be surprised how much just a bit of work on the front end can pay off in the long run while improving safety and security.
Check out the ROI Calculator for TCT Portal
Why Do I Need Change Management?
The whole idea of change management is to control changes that happen within an environment — for example, modifications within your infrastructure, devices, networks, firewalls, other equipment and software. Change can include new implementations, and sundowning.
Whenever you make a change, it’s going to have ripple effects that impact other systems, processes, or assets. You’ll need to anticipate those effects and avoid breaking anything. Change management gives you a structured process for change validation and testing while providing a way to put controls in place to keep everything running smoothly.
Without change control, you run the risk of breaking something — your software product, your network security, your records, your processes — you name it. Fixing what’s broken as a result could push back a release date, force overtime hours, increase tech support needs and vendor costs, or create hours of error resolution work.
Use an Automated Change Management System…
A lot of people get turned off by change control systems because they feel it’s cumbersome. But any good change management system will provide intrinsic benefits that far outweigh the work. Some organizations use a home-grown method that requires a good deal of manual labor, and those really are painful. But there are automated systems that can make the change management process streamlined and easy.
Automated systems help walk you through the workflows to make sure all the right steps are taken. They also provide centralized storage of all the information that surrounds each change. This gives you greater control over the change control process, while providing a central repository of modifications to the environment.
There are a lot of tools out there. Atlassian has a terrific product called Jira, which allows structured control of changes from within the environment. It’s customizable, and they have some great templates you can use to get started.
…But Don’t Use Your Vendors’ System
I’ve seen a lot of organizations rely on their vendors to take care of change control for them. It makes sense at first — you can focus on your core business while letting an expert handle technical issues you don’t fully understand. It’s more convenient, it saves time, and you don’t have to worry about doing it wrong.
The downside, though, is that you become dependent on the vendor’s system. If you ever need to switch vendors, you’re at their mercy to give you an export of your data in a timely manner. If they’re using a proprietary system, the files you receive may be very challenging for you or the new vendor to import.
In the end, it’s always best to keep your change control records under your own control.
Making the Change Request
Change management starts when someone makes a request. The request itself should be made to the change control system (either through ticket entry or email submission). Through the process, it should include several pieces of information:
- Description of exactly what is needed — what needs to be done, and what it needs to accomplish. It’s critical to document everything you want, otherwise the garbage put into the change management system is what you’ll get out of it. The net result is increased risk and decreased customer satisfaction.
- Management approval for the change. Someone needs to sign off on the request so that the change can be controlled and appropriately authorized. You don’t want just anyone to make changes without oversight, as that would be inappropriate. This structure also reduces the unlikely risk of an internal bad actor.
- Appropriate validation and testing. What evidence do you need that the change was successful, and how will it be tested? Was it tested properly? In essence, you want to be sure your changes don’t break anything upstream or downstream and the change is working appropriately.
- Rollback plan. If the worst happens and something goes wrong, what do you need to do to undo it?
Some organizations get hung up on the idea of a rollback plan. For most changes there can be standardized rollback plans, rather than a customized step-by-step instruction. For example, before you make a change to the production web server, make a backup image of it. If something goes wrong, sundown the updated version and reinstate the backup. For other changes, such as data changes made to the database, then you’ll likely need a specific script to roll the change back.
Consider the Ripple Implications
In the early days of your change management program, you’ll learn a lot simply by doing it wrong and making mistakes. It happens to everyone, but the more mistakes you can avoid, the better. Here are a few common errors to watch out for.
Don’t miss the ripple implications of a change. Simply purchasing a new piece of hardware can have impacts in many places that might not be obvious. Be sure to evaluate all the updates that the change will require — for example:
- User documentation, or images in the user guide
- Internal customer support documents
- Network and data flow diagrams
- Inventory
It’s also common to make changes that break something in another part of your organization. That typically comes out of a lack of structure and rigor for testing processes — a lack of validation steps. Many problems pop up when the person who requested the change doesn’t review the changes that are applied. It can lead to downed systems, unexpected errors or issues with the systems, or functionality that doesn’t work as expected. You can end up with buggy software or a lot of rework — and a lot of tickets to clear out.
If you’re dealing with a major change, there are certain functions in the security/compliance arena that need to be triggered. Depending on the nature of the change, you may need to run vulnerability scans, or do some penetration testing.
Take Change Management Seriously
The biggest thing I see in organizations that are starting to take their change control more seriously is that the business executives don’t seem to appreciate the value of a good, solid, rigorous change management system. They view it as overhead, nothing more than cost.
I’ve seen clients using a spreadsheet and pass around documents to each other. Some organizations use email or Slack as their primary conduit for change communication. As a result, their risk was substantially higher, and the potential was much greater for problems and unexpected issues.
These executives looked past the real cost to the organization — the cost of the internal labor and the cost of risk. But when you see change control from an efficiency perspective, you see all of the unnecessary labor costs you eliminate, such as:
- Manually running the change control program
- Fixing downstream errors
- Resolving bugs and customer support tickets
- Delayed product rollouts
- Network troubleshooting
- Disappointed clients and/or board members
- Increased client turnover
- Missing SLAs
Change management keeps your business operations running smoothly, reduces overtime, and lets you keep tech support headcounts lower. The reality is that enlightened executive management should be driving the excellence of a well-oiled change management system.
Time To Make a Change?
TCT has been helping companies navigate the world of security and compliance for a long time. If you’re looking for some directional pointers for your change management system, we’re well-connected to the right people who can help. Let’s talk about your change control or compliance needs.