As leaders in the field of technology, most of us regard a technology refresh as a positive thing. Even the most risk-adverse infrastructure managers feel the call of their inner geeks when faced with a slick new piece of technology. For the most part, IT folks like technology for its own sake and see that the constant evolution of features has a positive impact on our daily lives. Our users, on the other hand, become deeply committed to specific versions and features of technology. Sometimes this leads us into overt conflicts with those IT serves. More often, it manifests as a simmering, low-level boiling against the IT department that flares into some of the oddest problems IT departments can encounter.
Real-life upgrade rejection
Take for example one "knock-down" fight I witnessed during a very simple desktop upgrade. The technical writing department for a good-sized manufacturing company agreed to upgrade its five-year-old desktops. In fact, the writers very much looked forward to it. In proper fashion, we sucked up copies of all of their software. Testing commenced at once, identifying a handful of packages that would not run on the new systems. We assigned people to go find new versions of the software, or to find suitable replacements if nothing turned up.
In every case but one we found version upgrades for the department's software. Unfortunately, the company that made their image manipulation software package went out of business six months before the project started. There were no copies of the last version of the software in the channel, and we didn't want to put them into an unsupported situation. So we went out, researched a dozen packages, and presented the best four for consideration.
The tech-writing department exploded. How could we dare touch their imaging package? After weeks of heated arguments, debates, and accusations of everything from insanity to deliberate sabotage they agreed to keep a handful of their old workstations as "imaging systems."
The sources of commitment
Assuming for a moment that the department manager was not lost in a paranoid delusion, what happened? What caused his commitment to just another tool for getting his job done? More generally, what factors should we have considered to detect the problem before it erupted into a spat?
Departments that have jobs other than deploying and managing IT tools rarely care one way or the other about particular software packages. The individual users might have preferences, but the department generally cares only in so far as it can get its job done. So long as the software upgrade is equal or superior in functionality, the IT department can discard the idea that the software itself is a problem.
Rather, the software (and its upgrade) is a token in a larger and more complex game. The client commits himself to getting his work done. When IT interferes with that process, IT becomes not only an impediment but also a scapegoat for other problems in the department. Alternately, there may be budgetary or even practical considerations preventing an upgrade that the department does not want to admit to.
Taken in this light, it’s apparent that organizational commitment stems from several different sources, including:
- Failure to establish a history of positive change: If the IT department has botched upgrades before, then the organization will appear very committed to existing technology. It's not that they care about specific software packages. Rather, they don't want to be taken down for another week or two in the middle of whatever it is they actually do. This turned out to be the problem with the tech-writing department in the above example; the previous IT staff wiped out their ability to work for almost three weeks during a previous installation attempt.
- Embedded tools: What IT sees as a simple upgrade may touch on every aspect of a department's job. A change in software could force the department to go though considerable growing pains, changing procedural documentation, generating new archives of inactive data, and forcing the department to go though more training. These ramifications will not be immediately obvious to the world of IT, since IT rarely deals with its customers day-to-day transactions.
- Internal issues manifesting as IT issues: Since many people have at best a rudimentary understanding of IT, IT often gets the blame for anything that goes wrong. Making a fiery stand against a change pushed down by the "IT office" can often be an misdirection ploy masking budgetary problems, internal departmental politics, or something else. These bits of prestidigitation rarely fool anyone for long.
- Personal power plays: Creating a fuss may actually be connected to something else entirely. In fact, it's a time-honored way to stake out a position that you know you will have to fall back from. But by making the fuss, you create a situation where you can "trade" the position you do not care about for concessions from other managers.
Although IT shouldn't discount the possibility that organizational commitment comes from personal rivalries, that kind of interpersonal analysis requires a very careful reading of the specific organizations involved. It's difficult to form a generic action plan to deal with problems originating in the conflict of two unique personalities.
What can you do about it?
Dismissing these problems as political impediments doesn't help push though deployments. It also doesn't help you in this "new era" of IT where customer satisfaction, limited budgets, and close scrutiny are the norm rather than the exception.
Just shoving the new deployment down the users' throats can work in smaller situations. In the given example, I could have just bulldozed over the users' objections. The tech-writing department was not going to derail the entire project. However, on very large deployments (like ERP solutions) such ham-handed techniques can quickly lead to massive political fallout. If the users fall into the second category, it can also completely shut down their business as they struggle to understand and use the tools IT forces on them.
Expectation management and good questioning skills can get you part of the way towards a solution in cases requiring more delicate techniques. In my real-life example, I should have established up front that one or more software packages might need to change. As soon as I found a non-upgradeable product, I should have reached out to the department's users and managers, both to help with the testing and to find out what the software did for them. Whether I needed the help or not, these actions would have established a context in which the users knew they could work together to solve the problem. Users who work with IT rather than against IT open up a large number of opportunities for success. Once IT understands the larger context, IT can make concessions and help to deflect problems away from our own teams.
However, in the final analysis, nothing really helps when one or more of IT’s counterparts goes into deep Machiavellian mode. At that point, IT becomes engaged in a battle of influence that it may or may not win. The question you must ask yourself at that point is: Do I care enough to fight for this? Often, just backing away once a group starts to make outrageous statements leaves them overextended. Once they calm down the rhetoric, you can work with them to achieve a workable solution for everyone.