In reviewing someone's data processing operation the first thing you ask for is the service level agreement [SLA] because that's the preeminent control used in that type of organization.
Like all DP organizational artifacts the SLA has a long history - going back, in this case, to 1920s job descriptions for data processing management requiring incumbents to guarantee things like the on time delivery of the printed AR reports.
In today's context, however, the SLA is mostly used as a get out of jail free card: as a limitation on service expectations by DP people; as a critical element in getting an easy ride from the auditors by both DP executives and the senior people they report to; and, as barrier keeping DP people in a distant and clearly subordinate role by executive management.
Basically the problem is that an SLA commits DP to meeting specified expectations - and thus both relieves DP of any need to exceed those expectations and acts as a barrier separating those on each side of the agreement. As a result its existence in an organization testifies to that organization's ability to resist change by passing costs on its customers - meaning that its existence is characteristic of government and monopoly, or near monopoly, organizations; including industry level IT monopolies in which the employers compete but all use the same, essentially interchangeable, IT people, tools, and methods.
When confronted with an organization that relies actively on SLA enforcement through some kind of DP management committee but is now facing genuine cost pressure - say an American state or municipal agency facing sharply falling tax revenues- there aren't a lot of good choices.
One is to take advantage of the nature of the SLA process itself to recommend and strongly support out-sourcing all IT work. You do this nominally because outsourcers always promise quick savings and because use of the existing SLA as the basis for the contract means that no significant organizational change will be needed - but really because out-sourcing under cost pressure is a bad idea whose eventual reversal should - assuming cost pressures continue - lead to the kind of IT change the organization needs but is not yet ready to undertake.
The more dangerous alternative is to go after real change now - but that's extremely hard to do largely because you've got to pull off two miracles at once: change senior management perceptions, and change the way IT is run.
At the senior management level you'll be dealing with people who mostly don't want to hear it: and getting them to first internalize the reality that IT provides the organization's "nervous system" and isn't an arms length expense center at all, and then accept that DP's relatively poor performance, organizational isolation, and freedom to escalate project costs have historically been due to the SLA centric management processes in place, is usually more of a challenge than most of us can handle.
At the IT management level you'll be replacing bodies because what you need is an outward, service oriented, focus to replace the inward, utilization oriented, focus in place - and you're just not going to get it with people promoted under the existing system.
And the complication? it's been my experience that senior executive commitment to change seldom lasts long - so once you get them on side, you typically have between four and six months to get your IT changes set in stone because otherwise the little picture players in the organization will gut your efforts and leave the organization worse off than it was before.