Tuesday, April 7, 2009

How government is like IT

It just occurred to me how much government is like IT. Maybe those of you that have never seen the interior sausage making bits of IT will get a flavor for how it works (or doesn't) based on what you know of how government works (or doesn't).

First off, in IT, there is what is known as the 80-20 rule: 20% of the users consume 80% of the resources. Now, the numbers are not scientific, but they ballpark pretty well. There is always one group of whiners that take up all of your time, use all the disk space and absolutely refuse to follow protocol. They'll bust into your office when you're right in the middle of really doing something and demand to have a new mouse or something equally as trivial. "Did you call the help desk?" Of course not. And they are the first one's to throw you under the bus when some "IT evaluation" goes around. The guys you spend the most time and resources supporting are always the ones that are dissatisfied with the outcome. Sound familiar?

And there is always a general consensus in the user community that IT sucks. It needs change. And every 3-4 years, someone comes in and promises change. They reorganize everything from top to bottom. There are meetings and announcements and memos and user forums where they ask for input. But on the back side, the same handful of people are all still working on the same issues using the same equipment. The only thing that changes is a few guys at the top and the letterhead on the documents. Still seeing the similarities? Read on...

Decision making in IT is an extremely odd process. More often than not, decisions are not made by the technical people that build and maintain the systems and might have actually done a task before. No, more often than not there is a pointy-haired person that pre-decides how things will work. It might be a project manager that decides "this will take 3 weeks... because that is when we need it". It might be a fiscal manager that decides "this will cost $20,000... because that is what is in the budget." It might be a lawyer that decides "This is what the network will look like... because that is what we agreed to in the merger." No matter what, though, it is rarely the person solving the problem that decides how it will be solved. Someone says "use this hardware, make it look like this and give it to me in 3 weeks" and you just... somehow make it limp along.

And while we speak of limping along, let's speak of the temporary solution. In IT it is extremely common for there to be "trying times" that need some sort of stopgap "extraordinary measures." What this means is that someone says "oh, forgot to tell you: we need this working by 8am tomorrow." And what happens is that you scramble to steal parts from closets, desktops and actual working systems and cobble something together on a late night caffeine high as a "temporary solution" that will be replaced with a well thought out and fully funded solution "some time in the future." Well, just like what happens in government, let me assure you that in well over a decade and a half of IT (which is like 100 years of government) I have never seen a temporary solution upgraded, replaced or turned off. Temporary solutions are permanent fixtures and will need hours and hours of future coddling and babysitting -- because they were never built well in the first place. They are a computer equivalent to a TARP fund or a social security system.

I sort of glossed over it a little, but lets flesh it out. Do you know how equipment is really acquired in IT? More often than not it is common for a non-technical managerial type to have a few free lunches with a vendor (lobbyist), get a few free T-shirts, then just buy a whole truckload of servers for a project -- sometimes without even a hint of a working drawing on paper of how something will work. Those resources are then expected to be used. It would look bad if they weren't... and we won't get enough money for next year's projects if we don't utilize the hardware today. However, hardware needed for normal maintenance is never funded. (Stuff breaks.... it really does.) What this means in the end is that viable parts are stolen from other over-engineered systems, effectively letting one well funded pet project leak its budget into totally unfunded but necessary projects. Note again the 80-20 rule comes into effect: 20% of the projects get funded and the remaining 80% have to steal from them.

And let's talk staff, shall we? I have a college degree, and those who have dealt with me can decide whether I am qualified or not. But from what I've seen it means diddly squat in the IT world. I've seen more than a handful of college trained "computer scientists" that couldn't build a maintainable system if came perfectly shrink wrapped that way from the vendor. (By the way: They don't.) I've also seen more than my share of high school educated folks that can poke around in the kernel code and have things running smoother than glass. Add to that the plethora of useless certifications everyone seems to want and you have a mirror to the candidates for government. It's like the professional politician that cannot even be bothered to pay taxes. Organizational certifications like ISO and SOX consume incredible time and money and accomplish nothing -- think FEMA or any one of 100 other acronymific organizations.

Yes, IT is almost exactly like government: hated, unchanging, necessary but often pointless, expensive and yet underfunded. And, just like in government: a pan of home baked cookies given to the right low level flunky will get you top shelf service.

No comments: