Ignoring business needs is a bad IT move

In this tech tale, IT managers who put bureaucracy before business needs get their just due

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.

Off the Record submissions

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.

1 2 Page
Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies