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 fo

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.