Ignoring business needs is a bad IT move

A couple of mergers ago, I worked for a good company that just happened to have IT management that left a lot to be desired.

The company was an small/medium-sized business in travel management, and the IT staff was a combination of analysts, project leads, developers, and IT operations folks. We developed and supported products that were client-focused, but were typically for internal use. Unfortunately, the biggest drawback to the job was jumping through hoops for IT managers who lacked common sense.

[ Have you encountered The technology pro’s six greatest enemies? Send your memorable tale to offtherecord@infoworld.com. If we publish it, we’ll send you a $50 American Express gift cheque. | Get a new tech tale delivered to your inbox every week in InfoWorld’s Off the Record newsletter. ]

The Managers (capitalized to give you an idea of how they viewed themselves) included the CTO and his direct reports, but the poor management philosophies were picked up by some project leads. The Managers were very bureaucratic. They believed that an IT decision should always override a business one — this was actually written in a document I had to sign — and thought productivity could be increased by throwing additional bureaucracy at people.

It’s generally accepted that you should lead people and manage results. The Managers did it backward — they sought to manage people and lead projects and other efforts. They also believed that no development methodology was effective unless it filled a binder at least three inches thick (thicker would be even better).

One example of this mindless bureaucracy: An issue came up that the developer estimated would require a maximum of 40 hours to solve. The estimate was raised to 50 hours to provide a buffer in case of unforeseen complications. The maximum the development manager could approve for a single item was 50 hours. The lead on the effort raised the estimate — on her own — to 55 hours, which, because the estimate was then over 50 hours, meant that it must go through the red-tape equivalent of having the U.S. government manage the planting of a shrub in my backyard before it could be completed.

As the item worked its way up the ranks and accumulated more and more documentation, the developer discovered that the issue was simpler than originally thought and could be solved right away. It took him less than an hour to discover and fix, and it would have taken maybe a couple more hours to document and get into production. Did the developer receive a pat on the back? No — the developer got chastised for beginning work on a project without a completed scope. Yes, they demanded a scope — for something that would take less than 3 hours to complete.

Another example of the “IT over the business” and the “process over functionality” mentality happened later that same year. A data analyst was involved with developing a product for the clients, which meant he was working directly with the end-users.

After talking with them, he learned that what had already been proposed would probably add little value to their needs and they likely would not use the product at all. He found out what the users really needed and determined that the modifications could be done without going over the approved hours. He visited with the executive sponsor to get her take on the situation, and she was very pleased with the new suggestions.

He then went back to The Managers with his recommendations. Did this person get a “good job” or “thanks for being proactive”? No way. He was called on the carpet for daring to suggest something outside of the carved-in-stone requirements already set down — and for being so concerned about the users. The next day, he was belittled in front of two other people (I know, I was one of the two people) regarding his “little users.”

The Managers had high disdain and little regard for the business, and they lasted another year before the CTO was asked politely to “pack up and leave by the end of the day.” A little later the manager who had reported to him left for another company, and our company ended up hiring a consultant to rebuild the IT department. I decided to stand with the business where possible and survived the subsequent management shuffle and mergers.

Just because someone is a manager doesn’t mean they have common sense. To survive — and help the business survive — a tech pro must be alert to such damaging conflicts within the company and determine where best to focus support. A little networking on the business side can do wonders for a technical person’s future.

This story “Ignoring business needs is a bad IT move,” was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com.

More on InfoWorld.com for IT careers and escapes

• One-on-one career advice from to Bob Lewis’ Advice Line blog and newsletter: There’s more to on-the-job performance than being right Employees should care about their company’s share price When the boss likes to create conflict, you have to learn how to win
• For career advice, interactive quizzes, snarky takes on technology trends, and the misadventures of technology professionals, turn to InfoWorld’s Adventures in IT Channel.
• For the lighter side of tech, check out Robert X. Cringely’s Notes from the Field blog and newsletter.