The July 2024 CrowdStrike incident that caused global computer disruptions reminded the world of how dependent we are on technology and, even more so, the people who manage that technology. While much has been written about testing processes before releasing updates, one key takeaway is the importance of change management in production environments. Although ITIL (Information Technology Infrastructure Library) change management principles are well-known in IT, they’re not as commonly adopted in the AV field. Yet, these principles can provide a structured approach to updates and changes, minimizing disruptions and stabilizing the user experience.

Learning the basics of change management can empower technology managers to better support their users. It starts with implementing proper procedures within your team; it then enables you to integrate effectively with your IT department’s change management processes, reducing unnecessary downtime for your systems. The first point I always make about change management is that having a process is more important than having a fully “ITIL-compliant” process. Many organizations don’t require such a strict approach, and the fear of a rigorous process often discourages people from using change management at all, believing it will slow them down unnecessarily.

However, change must be managed when addressing technical issues that impact multiple users or systems. When discussing change management, I often point out that many people are already following the steps — they just need to formalize and document them.

The first ITIL change management step is Change Identification, where you determine what needs to be done, consider the risks and benefits and prepare a plan to restore systems if something goes wrong. For example, updating firmware across a company’s control systems may be desired for security or new features. You first must document what specific changes in the firmware you interested in and why. Then you should review what other changes and risks would be associated with the upgraded firmware. Next, you should test it on a few systems and ensure it works as expected, and document these tests. Lastly, prepare a rollback plan.

The next step is submitting a Request for Change (RFC). This involves documenting what you’ve planned, which can be done formally through software tools or informally via email. The RFC is then reviewed by a Change Advisory Board (CAB), a group of stakeholders who read your plan, ask questions and approve or deny the change. By involving different departments and IT representatives, you can uncover potential issues and gather vital information— like the availability of critical team members or scheduling around major events — that can help minimize disruption. In the firmware example, perhaps you learn of a significant client who will be visiting and several presentations have been prepared. You may choose to wait until after that client visits to implement the change.

Following these steps leads directly to the next stage: training and knowledge transfer. You’ve already documented the issue, the solution and who was informed beforehand. This provides several benefits, such as a record for troubleshooting future issues or replicating a solution for similar changes. It also gives you a timeline for when a change was made. If you start getting problem calls and reports that “this used to work, but stopped working a week ago” you can directly tie that to your change.

It’s important to note that this process doesn’t have to be overly formal or complex. True, for companies like CrowdStrike, a strict change management system is essential due to the high stakes involved. However, for most of us, a simple approach using emails or shared documents works just fine. Getting started and allowing your process to grow is much better than not using one because you fear it will be too much work. You and your organizations will quickly realize the value of the process.