Dear IT Director,
We upgraded one of our major systems last year. We had some glitches, but overall it went fairly well. Here we are a year later, and people still blame the upgrade when they have problems. Very frustrating!
Upgraded in Upton
Hahaha! HAHAHA! C’mon, laugh with me. LOLOLOL! The only other option is to cry. There are a few things we can do to reduce this problem, but we can’t eliminate this completely because, well, people are people. And, in part, we did this to ourselves. Let me explain.
Major upgrades are traumatic for our user base. No matter how well we think (or can prove) it went, our users saw the upgrade as a significant event. If the upgrade team did their job right, there was a lot of communication and testing before the upgrade. Probably some training as well.
In order to make sure the upgrade was a success, we focus the user’s attention on the upgrade. Is it any wonder the upgrade comes to mind first as the reason for a problem?
There are a couple of things we can do to mitigate this problem.
- Declare the upgrade “complete” to management and major players. With large system upgrades, it is difficult to reach a point where we can state accurately that we solved all problems related to the upgrade. Finance wants us to close out the project. The Team doesn’t want to be on a never-ending project. We likely had special support processes in place which need to revert to normal operations. It doesn’t mean that you ignore problems, it just means the upgrade is no longer the default cause of problems.
- We can use our upgrade team to educate the user base. Often, there are people on the test team with a good understanding of how all the pieces go together and they can help others understand it isn’t the upgrade causing the problem.
- If this is the first time they used the functionality since the upgrade (think rarely performed functions like annual financial tasks), they may actually be right.
- Even when the user incorrectly blames the upgrade, they are still reporting a problem we need to solve. If we can prove it isn’t the upgrade because, for example, a dozen people have been using the functionality for months, it’s useful to explain that. But we still need to solve the problem regardless of the cause.
Of course, the best approach is to move to a more iterative approach to upgrading your major system, but this is difficult to do and very few products support that approach. More frequent, and less stressful, upgrades are still in the future.
Until then, all we can do is laugh. Or cry.
Good Luck Upgraded,
The IT Director