Ultimately, everything we do in the IT business is done to support the productivity and success of our users. When we make a change, it inevitably impacts the user experience, and they will have their own thoughts and feelings about whether the change was good or bad. We must carefully consider the people at the end of the keyboard and ensure that their needs and feedback are prioritized in our decision-making processes.
The scientific method used in behavioral psychology seems well suited for change management in an IT environment. It can provide a systematic approach to identify effective strategies for implementing and measuring change. Applying these principles in an adaptive manner can enhance acceptance among users and provide assurance to leadership who may be hesitant to change.
The Four Steps
- Description
- Measurement
- Prediction
- Control
Description
The first step is to clearly describe what behavior you want to change. When we use the word behavior, we almost always mean changing the behavior of the system, not the end-user. This can mean publishing a fix, a security update, a feature update, system hardening, or modifying system protocols to enhance performance.
Your description must be a clear and unbiased observation. State the specific issues and outcomes you aim to achieve with these changes. What is your goal and reason for making a change? The last thing you want to do is make a change for change’s sake.
Measurement
Then you need to measure how it will impact the environment, especially the impact to the user experience. Will there be any down-time? How will it change the user experience? Ensuring minimal disruption while maximizing benefits is crucial. Implementing thorough testing can help identify potential issues beforehand.
Prediction
Third, you must be able to reliably predict that the advantages of a change will exceed the disadvantages. There must be more benefit than harm in a particular change. The prediction must correlate two events are related. For example, when you see sunshine, you put on sunglasses; these two independent events correlate to each other.
Control
Finally, you should only implement the minimum controls necessary to effect the change. I’ve seen too many IT environments that are over-engineered and complicated, which often leads to inefficiencies and mistakes when trying to maintain the environment. Focus on simplicity to ensure effectiveness and ease of management.
Note that controls will often come with side-effects that also must be monitored and managed. For example, a password complexity policy may result in user’s forgetting their passwords more frequently, which may result in more user down-time and increase the number of tickets coming in to your help desk.
Let me provide an example.
Let’s say you receive the following ticket to the help desk. It’s the third time this quarter that someone has complained about the WiFi in the Honolulu HQ.
Subject: WIFI IS BROKEN!!!!!
“The WiFi is absolutely terrible today. I’ve been trying to upload a video for the last hour and nothing is working. It keeps dropping out and I can’t get anything done. This is the third time this week it’s happened and it is making my job impossible. Please FIX THIS NOW. I have a deadline in 20 minutes.”
You have already tried the usual fixes several times in recent weeks. Restarting the user’s computers and restarting the access point fixes the immediate problem, but it seems to only be temporary. After some analysis, you’ve identified what you believe is the root cause and decide to bring the problem to the change management board with a detailed plan to address it.
Change management request.
Bad. “The WiFi has been acting up lately and it’s making everyone frustrated. We need to go in and change some settings on the WiFi controllers to make it better. This should be an easy fix and won’t cause much trouble, but we should probably do it after hours just in case.”
Why this fails:
- Biased Language: Terms like “acting up,” “frustrated,” and “easy fix” are subjective. They don’t describe a technical state; they describe a feeling.
- Lack of Specificity: “Change some settings” tells a technician nothing. Which settings? Which controllers?
- Unpredictable Impact: “Won’t cause much trouble” is not an impact analysis. Does “trouble” mean a 5-second drop or a 2-hour outage?
Good. “The WiFi firmware is two versions behind the current production release. Perform a controlled firmware upgrade on the primary and secondary WiFi Controllers located at the Honolulu HQ. This upgrade is required to address known stability issues in the current version and to implement the latest security patches. During the update process, users may experience a brief interruption in WiFi connectivity (estimated < 60 seconds). No impact is expected for wired connections.”
Why this succeeds:
- Objective Language: It uses technical identifiers of specific targets instead of adjectives.
- Clear Objective: It states exactly why the change is happening (stability and security), and correlates the current user experience to a specific action.
- Predictable: It addresses known deficiencies in the behavior of the current version with a specific time estimate for the interruption (< 60 seconds), allowing the users to prepare.
Clarity is our greatest asset. When we provide predictable, objective, and well-communicated changes, we stop being a source of frustration and start being a foundation of stability for the entire company. This approach fosters trust and and establishes the freedom to operate without constant firefighting.
You gain freedom from the 2:00 AM emergency call, freedom from user friction, and the freedom to focus on high-level strategy instead of reactive chaos. Master the discipline of the process, and you will have the freedom to lead change.
