IT Service Management and ITIL define processes for information technology professionals to follow in order to deliver the best value for their customers. The processes defined are agnostic to whether the clients are internal or external. Some in the industry think of AV and IT as separate, however we are very similar and in many organizations, one and the same. To that end, we should continue to learn from our IT counterparts where appropriate. One of the processes that I believe holds a lot of value for our industry is the change management processes.

AV systems today are completely interconnected. They can connect people from meeting rooms to boardrooms to offices and even to their homes. We also know that many of our AV systems are software-intensive and networked. When you make a change in one place, are you thinking about and aware of what is being affected in another? Change management processes help you with this. These are processes that allow you to meetneeds that are changing, while also creating stability in those services and the others that may be dependent on it. As organizations begin to employ support contracts with integrators, basic change management practices can help the firm and the client set expectations.

The process defines three types of change: standard, normal and emergency. These can easily be defined in terms of our industry. There is also a simple set of activities in the process. These steps are: create request for change (RFC), submit RFC, review RFC, review risks and impacts, authorize RFC, communicate changes, coordinate the change, review outcomes of change and close the RFC. These steps define themselves by their title and organizations can choose to use or not, depending on the change and on the organizations needs. The steps are reviewed and approved by a pre-defined group, called the Change Advisory Board (CAB).

Let’s first look at the type of changes. A standard change is a type of change that is pre-approved and does not need authorization from the change advisory doard. Again, this is customized, so your organization decides what a standard change is. This could be considered anything from maintaining equipment to changing equipment out for like equipment. Changing a lamp in a projector, or replacing a damaged display, likely does not need to go through a CAB. Next is an emergency change. An emergency change is one that needs immediate action in order to keep or restore the normal operation of the service. Often, emergency changes are pre-approved or a minimal CAB is formed to make emergency decisions. An example of this is a device that has failed and needs to be replaced or a server that has crashed and needs to be restored. The emergency CAB in these cases may consist only of AV technicians and networking technicians who can schedule a time to do the work together. A normal change is one that is neither a standard change, nor an emergency change. This would be the case of making a decision to upgrade software or change programming in a system or making major changes to the equipment in the system. These are the specific types of changes that take planning and consideration and do require the steps defined above.

An integrator can use this framework to help build a support contract with their customers. They can provide examples of who, in other businesses they work with, is on the CAB. They can offer suggestions on what is a standard change versus a normal change. Doing so will also help the contractor make sure they are supporting their client’s entire organization and protect their reputation. Let’s say a client is prepared for a significant software upgrade for a service. By having a pre-agreed upon change management process, the firm can ask to see that the appropriate requests have been made and that the approvals have been given. This forces the internal communication to happen. The firm does not start a process and later get questions from others in the client’s business about why it is happening. It also forces the firm to show that they are prepared. For example, in the risks and impacts steps of the process the firm would have to show the client they have plans for a failed upgrade (backups).

Sometimes organizations, or more specifically people in the organization, push back on processes like this by saying that the processes “don’t know our unique circumstances” or “don’t understand how we do business.” The more you learn about ITIL or service management, you’ll begin to understand that they do not suggest a rigid process. Rather they define some basic principles and allow each organization to develop the specifics around those principles. The processes should be as simple as possible, while still satisfying the needs of the organization. The people involved should be those who can authorize changes, depending on the level of risk to those changes. Most of all, these processes force us to take steps we know we should be taking, but too often don’t feel like we have the time to do. Working with a team who helps this happens brings value to support services from firms.