You can’t spell ‘office politics’ without ‘IT’

Despite what some may expect from IT’s expertise, fixing a technical problem is not a cure-all for a political power struggle — yet it doesn’t keep some people from trying. One customer in particular pinned high hopes on my tech fix-it abilities to save him from a sticky situation. I was just thankful I was a contractor and could leave the mess behind and move on.

I did contract work for a variety of software issues, but my specialty was adapting older mainframes to accommodate newer software. Customers’ tech needs often had moved way beyond their budgets for hardware upgrades, so I devised ways to work around some of these limitations, such as using rapid prototyping and incremental development of PC software to adapt the technology of yesteryear to the needs of the moment.

[ Get a $50 American Express gift cheque if we publish your IT story. Send it to offtherecord@infoworld.com. | For your daily dose of workplace shenanigans, follow Off the Record on Twitter. | For a quick, smart take on the news you’ll be talking about, check out InfoWorld TechBrief — subscribe today. ]

One day I got a new assignment. The VP of my company explained that the client had a massive, multisite custom accounting system vital to the organization’s operations that they disbursed checks from every day. The system was in crisis, and they needed help — fast. Any solution must run redundantly, as the flow of money must not stop. The system was no longer manufactured and no longer maintained by its maker, and the antique software had been patched so many times that the patches had patches on the patches.

Cobol crisis

The local Cobol team had sent distress signals to upper management six months before, saying that the system’s limits had been reached and, in some cases, exceeded. But upper management had slept through the warnings, thinking this was a boring maintenance issue. Just to keep the system running, the Cobol team had to provide the data entry teams with workarounds, but which could potentially compromise confidentiality and accuracy. The system needed a complete overhaul. Again and again, upper management had ignored the facts.

Fast-forward six months, and the system was paying the wrong people in some cases, and paying the wrong amounts in others. Upper management had received complaints from company officers. They were finally wide awake.

The Cobol team’s manager, “John,” had contacted us to help find a better workaround that would fix the mess once and for all. My VP wasn’t sure what John wanted was even doable, so he told me to interview John and anyone else who could help, look at the system myself, then report back to him. We’d then determine how to proceed.

I arrived at the site and interviewed John. He was a very personable, likeable guy dressed in the usual power suit. As he talked, I gathered that the crux of the problem was due to a colossal power struggle between himself, who worked at the larger headquarters location, and another manager, “Bill,” who was two time zones away and worked at the location that was the clearinghouse for all the system’s financial transactions.

As the problems had worsened, Bill had seen the writing on the wall and instructed his team to get to work building a new system. John hadn’t grasped the urgency of the situation at first and was far behind, having pushed his team for more and more workarounds.

Only one IT team can prevail

Upper management declared they didn’t care who came up with a fix, they just wanted it done. But John believed that if his team solved the problem first with an even better workaround — a magic bullet that would be cheaper than the other team’s solution — his career would get a boost. There had also been rumors that whichever team did not solve the problem would see layoffs and reduction in budget.

Sadly, as I talked with John, I realized that he did not understand the technology he was managing. He understood the people and seemed to have an excellent grasp on the principles of accounting. But the fundamental principles of system design had never been part of his education, and he never took the time and trouble to learn them from his subordinates. My observations were confirmed when I spoke with John’s staff.

“Maybe you can get through to him,” one member of the Cobol team confided in me. “There isn’t a way to overcome the physical limitations of the system like he’s been pushing us to do. We’ve done what workarounds can be done, as far as anyone on the team has been able to imagine. What do you think? Have we missed something?”

I reviewed the patches and design changes the local Cobol team had made. Their work seemed smart to me and thorough. But looking at the system and its problems, it was obvious that more workarounds were not the answer — despite what John thought. The local team could start working on their own solution to overhaul the system, but John didn’t like that idea. And besides, time was running out.

Around the water coolers, I was confidentially briefed on what they’d heard of the potential capabilities of the new system planned by their adversary two time zones away, which was fairly far advanced by that point. Unless they bungled the execution of the plan, it seemed that it would succeed.

End of the road for workarounds

I couldn’t verify what the other team was doing, of course, but could make observations and recommendations regarding the local team’s options. I wrote a lengthy report on the situation and what I thought could and could not be done about it. My VP and I met, went through the findings with a fine-toothed comb, and both agreed that yet another workaround was not the answer. Buying or a building a new system was the best thing that could be done at that point, which John did not want to do.

The final meeting with John did not go well. He concluded that I was an inept bumbler who had let him down. Per the instructions from my VP, I didn’t argue with him — and left as soon as possible after delivering the bad news.

It’s interesting that the more things change technically, political power struggles remain the same as they ever were. I don’t know what happened with this whole mess. I did feel for the local Cobol team that had the ability to devise their own solution, but were stopped by a boss who couldn’t think beyond one way of doing things. I was glad to get back to tech problems because in many ways, they’re less complicated.

Send your own IT tale of managing IT, personal bloopers, supporting users, or dealing with bureaucratic nonsense to offtherecord@infoworld.com. If we publish it, you’ll receive a $50 American Express gift cheque.

This story, “You can’t spell ‘office politics’ without ‘IT’,” was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.