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!
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.
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:
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.
