IT Decision Maker

Why Most IT Departments Are Modeled After a DMV (Even Yours!)

You don't meet a lot of people who think their state's Department of Motor Vehicles (DMV -- or whatever it's called where you live) should be a model for how to run business. Don't get me wrong -- the Nevada DMV, where I live, is pretty awesome as far as DMVs go. But still. Long lines, arbitrary rules, surly employees who delight more in saying "no" than "here's your license, sir/ma'am."

Yet thousands of companies across the world are using a government agency as their model for how to run IT.

Campaign rhetoric aside, governments have a bit of a vested interest in slowing down change in the way government works. Governments are meant to be stable, reliable and predictable -- and change opposes those goals. When governments change, they do so very slowly, after much public and political debate, and after many periods of review and comment. Governments rarely have to worry about being first to market, since they kind of have a monopoly on governing. Governments don't seem to have any motive to maximize their profits or minimize their losses. Governments, in short, can afford to not pursue change too avidly.

Business, on the other hand, needs the ability to change rapidly. A new technology comes along that can double your margins? Use it. A new product offers the ability to reduce IT overhead? Get it. New techniques reduce downtime by half? Adopt them. Businesses -- good ones, at least -- thrive on change.

So why are so many businesses running themselves like a government agency? Four letters: ITIL.Yes, the Information Technology Infrastructure Library, the IT management framework you've all heard of and may even be using. Created by the United Kingdom's Office of Government Commerce, a department of the UK government.

No, I'm not trying to beat up on ITIL. It's actually a pretty solid, comprehensive framework for managing IT. Given that most of us weren't doing much better of a job, ITIL offers some universal structure. My problem is that ITIL pretty much abhors change. No, not on paper -- on paper, ITIL manages and controls change. In practice, IT organizations use ITIL as a blunt instrument to halt change.

Let's face it, IT loves saying "no." As far back as the earliest days of computers in academia, the robe-wearing dungeon-dwellers known as "sysadmins" reveled in telling people "no." No, you can't have more computer time. No, you can't have more punch cards. No, you can't touch that. We had (and still have) good reasons: Users break things. If it weren't for users, nothing would ever break. Our job is to keep things running, and users are the enemy of that goal. We also hate change, for exactly the same reasons: Change means broken things, and more work for us. With all those users running around, we're not exactly short of things to do, so change is just another unwelcome burden. A new application? No. A new server? No. New domain? No.

ITIL and other IT management frameworks can take our genetic tendency to say "no" and codify it. "You want a new application installed? Well, you're going to have to go through the Change Management Process." Dilbert's pointy-haired boss couldn't have come up with anything better. Users who ask for the simplest things can be told "no," simply because the Rules support that position. Worse, in many companies, admins who step out of the change management framework to help a user with something small are chastised, written up, and put at the bottom of the list for promotions and interesting projects.

Yes, we absolutely need to manage change -- which is what ITIL is all about. We don't need to bury change, which is what too many organizations use ITIL -- and frameworks like it -- to do. Take a few minutes and evaluate your IT team to see if you're using your change management process as a codified way of saying "no." Simple, obviously non-destructive changes should have a way of being expedited in your organization. Remember, IT is there for the business, not just to follow the rules in a framework. Managing change is something we do because it is allegedly good for the business; when the framework isn't helping the business, consider changing the framework a bit.

(For the record, I really do like ITIL -- when it's implemented with common sense and an eye toward what the business really needs).