

Why Most IT Departments Are Modeled After a DMV - msredmond
http://redmondmag.com/blogs/it-decision-maker/2011/06/itil-it-dept-modeled-after-dmv.aspx

======
snorkel
I've seen another cause change of aversion in big organizations: admin bonus
pay was tied to application uptime. This created a hilariously dysfunctional
situation where the admins locked the developers out of production and refused
to deploy any code changes to production, including bug fixes, for several
months. Senior leadership in the organization insisted this was the best model
to ensure service stability. In the meantime agile competitors ran circles
around them until the service became irrelevant, but just look at those uptime
numbers!

------
jinushaun
The problem is that IT gets inundated with tons of requests and everyone
thinks their problem is more important than someone else's. The moment you
start queuing up requests and trying to apply some order to the chaos is the
moment IT's bad reputation develops. It's a thankless position for sure.

The article doesn't offer a solution, but points out what we already know.
Even though the "cloud" is to supposed to eliminate the need for a big
internal IT department, you still need someone to support your cloud
environment, which takes you back to square one.

------
F_J_H
This is a well known problem - Joel has a great post on how procedures can
kill creativity in his "Big Macs and the Naked Chef" post:
<http://www.joelonsoftware.com/articles/fog0000000024.html>

Slides 40 to 56 of the following NetFlix presentation could be a solution.
Instead of adding more processes and procedures, hire good people who are
effective at managing complexity:

[http://techcrunch.com/2009/08/05/other-companies-should-
have...](http://techcrunch.com/2009/08/05/other-companies-should-have-to-read-
this-internal-netflix-presentation/)

------
wccrawford
"Simple, obviously non-destructive changes should have a way of being
expedited in your organization."

One man's 'simple non-destructive change' is another's 'horrifying perversion
of everything.'

Management is so slow to implement change because even the smallest changes
can have lasting and far-reaching effects.

------
phlux
I think that adherence to codified change control is really not the cause as
this article suggests. These issues are management issues - claiming a
framework for managing the chaos which results from bad management is poor
root cause analysis.

Poor management results in both poor testing and underdeveloped project
understanding.

If you have solid, well funded (with both money AND time) testing - the impact
of change is minimal.

Further, the propensity for IT to say no stems from their understAnding of how
poorly upper management allocates resources to IT as it is historicLly been
seen as a liability/cost center rather than integral to business. (obviously
this is far less true in silicon valley).

Clearly though, having good IT managers and staff are important and you find a
lot less 'no' with good staff.

IT organizatiOns typically report to the CIO/CTO and are overshadowed by the
CEO. If the CEO is of the typical Sales/Marketing DNA (or the "I used to be a
developer - we don't need that much redundancy!" DNA, which can be worse) then
they typically underfund all infrastructure projects.

Finally, IT gets the blame for all downtime, so it's their asses if the shitty
managers decisions impact service.

So, ITIL is not the issue. People are. IT needs competent leadership to
succeed.

~~~
johnohara
_IT needs competent leadership to succeed._

And fewer TPS Reports.

