Enough with the name-calling already! "Rogue IT" — cases where users have launched their own IT projects without inviting the IT department to the party — doesn't deserve that insulting name. Rogue implies that these users are unprincipled scoundrels or at least way out of line when they do IT themselves.
But they're not. They're doing the very messy, very necessary job of fixing business processes in near real time. We can't do that. We don't have the budget or the staff we'd need. We also don't have the intimate knowledge of the actual business processes, which change a lot faster than our systems can.
Business on the front lines is chaotic. Users have to cope with it. When the systems that IT implements don't do the job, users have to work around the problems. And when users see ways of automating those work-arounds using the consumer-grade technology they have access to, that's what they do.
They're not rogues. They're not out of line. They're just trying to survive.
Are there any IT projects that deserve the label "rogue"? Sure. When a non-IT executive or manager launches an IT project in order to pump up his budget and make himself look more important, that's a real rogue project — it's all about politics and self-promotion, not what's good for the business.
But that's not why most users do IT themselves. They come up with their own spreadsheet-based applications and script-based automation because they need specific process fixes right now, not a rough approximation of them in six months.
They plug in wireless LAN access points because it takes days or weeks for IT to let them move a desk or plug a new employee into the network. They hire their own application service providers because the IT department drags its feet and wants to rejigger the requirements, the terms and most of all the schedule for getting it up and running.
They want to use IT to make some small piece of the business run more efficiently and effectively. So they do it themselves — in the simplest, quickest way possible, with the most direct solution to the problem. And they do it entirely focused on the real business process.
That's why their project success rates compare favorably to those of our "real" IT projects, according to a recent Computerworld survey. When it comes to implementing a business process change, they know exactly what they're doing.
Of course, when it comes to creating IT that's scalable, maintainable and compatible with what we've already got, they're usually clueless.
That's where we come in. And the first thing we usually say is no. No, you shouldn't have done that. No, that won't scale up. No, it won't integrate with our existing systems. No, we've never done it that way before.
Hey, there are good reasons why we say no. We're understaffed and underfunded. We see all the complexity and work that will be required. We know our whole infrastructure is old and brittle, and it's a full-time job just to keep it running, never mind bolting on one weird, difficult, user-conceived addition after another.
And there are also not-so-good reasons: We're irritated that they stomped all over our turf, embarrassed that they got something working faster than we could have, bent out of shape because everybody is so impressed with their clever little hacks.
But we can't control the business needs these users are adjusting to. And we can't change our systems as fast as they need us to.
Users can. And they will.
So before you make your plans for dealing with user-initiated IT projects, understand this: Inconvenient or just plain miserable as it may be for us, these users are doing what's right for the business.
They're not rogues. And we really ought to stop calling them names.