Time Capsule: Rogue IT Shops: Provide Rules, but Leave Them There

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in April 2007.

Rogue IT Shops: Provide Rules, but Leave Them There
By Mr. HIStalk

An ongoing hospital IT dispute involves the common existence of so-called “hidden IT shops.” Those are pockets of specialized IT that, instead of reporting to IT, are managed within their individual departments, such as patient financial services, human resources, and laboratory.

I’ve been on both sides of that particular fence, so I feel qualified to opine.

More than once, I’ve been in an IT leadership role as we reined in rogue IT operations. We cracked down on non-rules following departments that were spending IT funds unwisely, exposing the organization to risk, and insulting our IT leadership by flaunting their minimally supervised existence.

Also more than once, I’ve worked for a clinical department’s rogue IT operation, born of necessity after a Dilbert-esque IT shop couldn’t meet our department’s needs. The IT suits talked endlessly about professional IT management, but they were mostly known for starting projects they could never finish, using help desk analysts as human shields to prevent users from talking to the few experts they had, and conducting endless meetings to grind down the rational opposition to whatever they had already decided to do behind closed doors. They were much like a questionably motivated vendor, in other words.

If I have to take a position, I’ll side with allowing user departments to keep their existing IT employees.

“Common plumbing” is an IT responsibility. Departments shouldn’t have their own network technicians, e-mail administrators, server experts, or database administrators. They should not negotiate IT contracts or make capital purchases. I’m sure we agree on this.

Beyond that, my experience is that departmental IT people do a better job than their IT counterparts. They have the luxury of working hands-on with their users, free of the distrust that IT departments often generate. Since they understand the workflow and the specific technologies in place, they excel at setting priorities, can develop creative system workarounds and extensions, and are unsurpassed at retrieving and analyzing system data.

They also are keenly motivated because they are judged exclusively by their departmental co-workers, who ensure their high performance by lauding them for even the most mundane and sometimes comically easy accomplishments that seem hard to a layperson (I think that last issue is what steams the IT guys.)

I know the IT arguments because I’ve used them myself, although only half-heartedly:

• IT systems involve risk that only an IT department can assess and manage
• Centralizing IT creates efficiencies and prevents critical reliance on an individual
• Project funding should be centrally administered based on overall organizational priorities, not the needs of a single department
• Standardized practices should be used for the help desk, change management, knowledge management, and project management

What I’ve seen in reality from both sides of the fence:

• All the logical arguments aside, the primary motivator for IT centralization is the ego of the IT department’s management
• The IT department’s insistence on rules is often at the expense of creativity and flexibility
• Despite all the available tools, the IT department can’t match the service levels of locally assigned and managed IT employees
• As soon as IT gets in trouble or tries to hide staff shortages like a balding man’s comb-over, it’s all hands on deck to save the tanking projects, meaning those previously dedicated departmental resources will be yanked to put out some new fire, often self inflicted by poor planning
• Department employees often despise working in the detached, command-and-control bureaucracy of the IT department, so they leave, taking years of specialized experience with them and disproving the theory that IT can provide more resource depth than was already in place

I have loyalties both ways. These conclusions come from multiple personal observations.

Certainly other less dramatic options exist. You can have local IT resources report via dotted line to the IT department, providing guidelines on what they can and can’t do. You can insist that those teams follow documentation and change management standards. You can steer them toward standard technical tools, provide them with training, invite them to meetings, roll up their budgets under IT, and even move their chairs to the soulless cubes that IT departments love.

If you do decide to absorb the hidden IT shops, beware. Unless your IT shop is superbly managed, you’ll probably set unattainable expectations that you can’t deliver.