An Evolution in Change Management

In an industry predicated on evolution and change, it’s funny just how resistant we can be to managing change. Who has time to change for change, really? However, that’s exactly the challenge placed at the feet of Instructional & Campus Technologies (ICT) at Elon University less than three years ago.

Since that time, ICT experienced a fast-paced evolution in change management. Starting with a big-bang-style partnership that sparked change management in our organization, through a developing period that was reminiscent of the chaotic Wild West, to a mature forward-thinking process, we were faced with a central problem: implementing change management from nothing in a fast-paced, nimble environment while simultaneously achieving buy-in from organizational members responsible for changes, but who were resistant to the idea of changing longstanding methods of work. A solution to this problem was central to our process because, without buy-in, how would the process even work?

Getting Started

Implementing change management in an organization is no easy feat. Ours started with a big bang when ICT and our internal auditor partnered together to examine the process of change management.

Prior to this partnership, ICT worked like other divisions at Elon—we worked quickly to make things happen. If someone wanted a change, they would make the request and work would be started immediately. Most notably, our Application Technologies group gained a reputation for being immediately responsive and nimble in making these changes happen. From a customer service standpoint, the work was amazing. From a data integrity standpoint, this approach left a few things to be desired.

Our partnership with the internal auditor was the catalyst in starting our evolution in change management. ICT always wanted to have better change controls for backups and redundancy, but we never wanted to slow people down from doing their jobs. By coming to an understanding of what the auditor felt should be in place and why gave us the reason to slow down and do our due diligence.

After the need for change management was identified and established as a priority, it wasn’t necessarily easy to get started, especially when it came to broad divisional change. While we had buy-in from leadership, we still needed buy-in from those on the ground floor—the technicians, systems administrators, network engineers, and developers—who would be responsible for filing change requests.

One way we began getting organizational members on board was to start simple. After all, one of the most appealing aspects of ITIL is its “adopt and adapt” nature. It would be impossible to start with a fully functional and realized process. So, we started with small changes.

Change management at Elon began with a fairly simple change request form in SharePoint. The initial form collected information such as who was submitting the change, what was occurring, and when. The change types and change scale were taken as described from ITIL. We did not require change requests to be filed at the start of our adoption. Instead, we appealed to those drawn towards documentation as early adopters of filing requests. Once they began realizing the value of filing change requests, they helped encourage others to participate in documenting changes.

The last component of our genesis with change management was to implement a Change Advisory Board (CAB). Members were selected from every department within the division to provide their insight and concerns for requested changes. While the CAB was used lightly at first, it began to generate more communication across departments than we had seen historically. Having this diverse representation of departments together in one room also allowed us to show the value in the process to key organizational members who carried word back to their colleagues.

Taming the Wild West

There is no underestimating the power of starting small and letting people adapt before introducing new components to a process. After the genesis of change management, our organization found itself in terrain similar to the Wild West. Sure, there was a form to fill out and a governing body in place. But we still faced a mindset of “How can we go about doing what we always have without the change manager knowing?” So we had to consider what we could do with this new information, how to make it relevant to colleagues, and how to continue to improve.

For us, the answer was to continue to find small ways to add onto or improve what we had already put in place. It was important to show colleagues that change management was good for our organization. For example, when the CAB was first created, we relied solely on email communications. To continue to improve, we implemented bi-monthly meetings to review and discuss changes. In turn, these meetings generated conversations that led to small tweaks to our RFC form, such as expected timeframes and specific departments affected by the change. We learned it was important to never start large, otherwise you are setting yourself up for criticism and failure. If we had launched full scale with weekly meetings, full agendas, and a lengthy RFC form, the sheer amount of added work would have made it difficult to get buy-in from the organization at large.

To help mark our progress, we produced a strategy report to highlight to leadership where we had come from and where we needed to go to continuously improve change management. For our organization, it was helpful to have a document highlighting strengths, weaknesses, opportunities, and threats in continuing to develop change management.

During this time, another extremely helpful piece to the puzzle was to reach out to peer institutions to learn about their change management process and how they worked with members of their own organization to achieve buy-in. The insight gained from these discussions allowed us to anticipate potential pitfalls and prove to our colleagues that we were being thoughtful and deliberate with our implementation.

Once we had a strategy in place and had taken feedback from other organizations into consideration, we were well poised for our next evolution in change management. While none of these occurred all at once, over the course of a year, we continued to develop the change request form (incorporating communication and back-out plans), we created a change calendar via Office 365 (so the service desk could easily see what systems might be down due to changes), we developed a space for change management documentation, and we became more stern when it came to filing change requests. While still not technically required prior to a change, leadership began forcing individuals to file them after the fact for documentation if a change request was not filed prior to the change. 

Changing the Mindset

While it took some time—there were definitely growing pains—the solution of gaining buy-in and implementing change management began to take hold as our process started to mature. Sure, theoretically it all made sense to those in the organization. But, it was still an afterthought. The trick was getting people to think about changes preemptively.

While painful, we had to learn to let failures happen and challenge those involved with the why. Why did this change fail? What could have been done differently? Many times, the answers to those questions centered around receiving feedback or involving other departments.

The Technology Service Desk also played a key role in generating buy-in from other departments. There were instances where changes occurred that did not have an associated change request, and therefore did not go through the CAB. In some of these cases, outages resulted (either the change failed and an outage occurred, or the source of the change required an outage). This in turn increased the volume of calls to the service desk, which increased the number of incident tickets sent to the involved departments.

Those receiving the tickets were not happy and felt that the Technology Service Desk should have known about the changes and resulting outages. A gentle reminder that a change request would have kept the service desk informed (so they could inform our users, rather than open up what were believed to be trouble tickets) was a quick way to ensure those creating changes filled out the proper paperwork. This reminder also led to implementing a small, but important, change of deadlines and processes for emergency and normal changes.

Certainly, different members of the organization took to participating in change management more quickly than others. However, an unnecessary influx in trouble tickets (while problematic) actually helped generate the final level of buy-in organizationally that we needed. Now that we had people on board and familiar with the process, we could leap into the final evolution of change management.

Our final evolution is currently underway. Last year, we transitioned to a new ticketing system that has an ITIL-aligned change management component. Now that the organization is familiar with and comfortable with engaging in change management, we are currently looking at moving change management into our ITSM tool. During this migration, we are evaluating what areas of change management could still be aligned with ITIL, including the types of information collected on change requests, clearer notifications, streamlined approvals, and an official policy regarding change management in our organization. Once the project is complete, we will have a well-oiled and finely tuned method for requesting, tracking, monitoring, and evaluating changes. 

Engaging Stakeholders

In three short years, ICT at Elon University has undergone a vast transformation in how we view and interact with change management. Our biggest problem was getting people on board with the process, which is hard to do with something completely new and strange. But, it’s a problem we’ve solved (for our environment, at least).

Today, buy-in and engagement with change management is on solid footing within each department across our division. It was a long journey, but implementing change management is easiest when you do it one small piece at a time. Another key is capitalizing on ITIL’s prescriptive nature—adopt and adapt processes to your environment where they fit. If they don’t, ditch them. If it makes sense for your culture, integrate away.

Implementing change management is easiest when you do it one small piece at a time.

You must remember to engage with those participating in the process along every step of the way to answer questions and make them feel comfortable. By starting slow and small, you can ease others into a new process. Eventually, they will reach a place where it only makes sense to revise or add something new to the mix. In fact, by keeping constituents constantly informed and letting them know that they have some degree of input, you’ll find them much more willing and eager to participate. The more willing and eager they are, the easier the machine will operate and you will see and experience the returns of getting your organization to change for change.

Ryan Gay is the manager of service management and project lead for Instructional and Campus Technologies at Elon University. When not leading implementation initiatives that generate a campus-wide impact, he focuses on building and improving processes between the service desk and the rest of technology at Elon. Connect with Ryan on LinkedIn.