Let’s assume that you run an IT department or, perhaps, the whole IT organization. It follows that you control all the technology projects, choosing the platforms, monitoring performance, and authorizing spending.

Right?

Well, not exactly. In lots of organizations, many technology projects and significant spending are actually controlled by business units, who jealously hoard these resources. Not only doesn’t the IT organization support these projects—in some cases, they don’t even know that the projects exist.

These “rogue IT” or “ghost IT” projects naturally irritate IT managers and executives. With today’s spending constraints, many IT organizations are attempting to rein in rogue IT projects, controlling their spread and limiting their funding.

However, in this column, I’m going to argue that before you shut down all the rogue IT projects in your company, you should try to figure out the message your internal clients are trying to tell you.

Building empires—or just trying to get things done?
I started thinking about this issue after reading an article in the current issue of CIO Insight called “Rooting Out Rogue IT.” It profiles the efforts of senior IT management to find and shut down ghost IT projects—technology initiatives that are run by business units outside the control of IT organizations.

Here is how one CIO described the problem in the article:
Just ask UPS CIO Ken Lacy. He says UPS partners, on the fringes of the UPS extended enterprise, “sometimes feel there are ways to get around us in IT,” perhaps believing they can do IT projects more cheaply and quickly than Lacy’s corporate IT shop. “Somebody can say, ‘I can do this for $150,000 when it would take Ken Lacy $1 million to do the same job,’” he says. The trouble with that? “Most of the time,” Lacy says, “when people go out on a limb, they’ll end up spending that $1 million they said they could save by going outside [the IT department], and then still not have the ramp-up they need” to make the project work on a larger scale throughout the corporation. In those cases, Lacy says, he is called in to redo the project, often at many times the original dollar cost, and at the expense of time that could have been spent on other initiatives.

All of us know the kind of project that Lacy is talking about here. Further, it’s certainly true that many rogue IT efforts end up in disaster, with business units trying to cope with spiraling costs, balky, or unscalable applications, and ruinous oversight responsibilities.

However, when I finished the article, I wanted to ask a different question. Rather then catalog the many reasons why rogue IT projects are a mistake (which they are), I wanted to know why they exist in the first place.

Why do so many business units—not just at Fortune 500 firms like UPS, but at organizations of all sizes and industries—try to do an end-run around the IT department to spearhead and manage their own technology projects? Don’t business unit managers have enough to do without taking on the responsibilities of IT managers?

Of course they do. So why do it?

If I can assume, for the sake of argument, that these business unit managers aren’t power-crazed jerks, then there can be only one reason why they’d set up these rogue IT projects: They don’t feel the regular IT organization is meeting their needs.

Right or wrong, these business unit leaders are so skeptical about the ability of your department that they are willing to take on the technology project themselves, rather than wait to have you do it.

Now before you start screaming at the monitor or dispatching a blistering e-mail my way, let me state up front that there are valid reasons why the IT department isn’t satisfying its internal clients. Here are just a few:

  • There aren’t enough resources: Money and talent—there’s never enough. On the other hand, the desires of internal clients are endless.
  • Someone has to play traffic cop: The whole point of centralizing IT is so the organization can set priorities. That means that not every project will be assigned to the top slot.
  • Someone needs to be skeptical: One of the problems with many rogue IT projects is that business unit leaders too often fall for vendor hype, being unfamiliar with how often the product claims differ from product performance. One of the functions of IT leadership is to tell business unit leaders up front when a vendor or even an entire technology is not ready to be deployed.
  • They might not be reasonable: Sometimes business leaders don’t have a realistic understanding of how long a project should take or how much it should cost.

Are you really listening to what they’re trying to tell you?
All of those are valid reasons, but they aren’t really relevant to this discussion. I’m not arguing in favor of rogue IT projects. I’m saying that if a business unit leader goes to the trouble of setting one up, he or she is giving your department of vote of “no confidence.” Whether that’s fair or not is almost beside the point. The very fact that he or she thinks so is a real problem for you.

So what should you do? I’ll make two suggestions.

First, have a conversation with the business unit leader. Try to do it in as non-threatening a way possible. Among the topics you might cover:

  • Find out if this project has been brought to your department queue before. If it has, what happened to it? If it has not, ask why not.
  • Find out how important the project is.
  • Eventually, you need to get to the trust issues; you have to be able to trust that the business unit leader isn’t going to go behind your back and launch yet another technology initiative. For your part, your internal clients need to be able to trust that you’re doing everything your group can to meet their needs.

That is where the second suggestion comes in. Take some time to review your communication processes with the various internal clients you support. You need to ensure that your group is being as transparent as possible. Your internal clients need to know you don’t have some internal agenda that favors one group over another.

In the end, no matter how irritating they are, rogue IT projects need to be treated as a wake-up call.

From the IT Leadership Web log

The rogue IT article began as a post on TechRepublic’s blog for technical managers and their bosses. It’s called IT Leadership—check it out today. It’s free, and I post to it almost every business day.