Credit: Jutta Kuss
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 firstname.lastname@example.org. | 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.
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.