* How IT organizations can successfully offer internal SLAs
There is a lot of buzz in the industry right now indicating that IT organizations should offer internal service-level agreements. In most cases, this buzz skips right over most, if not all of the challenges associated with that task. This newsletter is the next installment in a series of newsletters that is focusing on how IT organizations can successfully offer internal SLAs.
Once the IT organization has identified the company’s key applications and services, the next step is to begin to craft the contents of an SLA for each application. Each SLA should be crafted in conjunction with the customers of that service. That may sound easy, but it can be quite tricky.
For example, assume that an IT organization that supports a 5,000-person company has identified that because of travel constraints, conferencing is one of their key services. The IT organization might be tempted to think that all 5,000 employees are the customers of the conferencing service and try to negotiate with them for what types of services they need.
That thinking is flawed in part because it would be extremely laborious to try to get input from 5,000 employees. A further flaw in that thinking is that most of those 5,000 employees are not involved with the funding of the IT organization. Human nature being what it is, the 5,000 employees would likely overstate what they need and the IT organization would end up overwhelmed with the thought of having to provide telepresence to every desktop.
The bottom line is that when determining how good of a job they are doing relative to service delivery, IT should consider all 5,000 employees as customers of their service. However, when defining what services will be offered and the levels of those services, the IT organization needs to work with whatever governance mechanisms are used to oversee the IT function.
The last newsletter mentioned a common governance mechanism – an IT steering committee. The SLA that gets crafted should be negotiated with the steering committee and hence must be written using terminology and concepts that make sense to the steering committee. For example, the steering committee members most likely care about and can understand what is meant by availability. In most cases, however, they would neither care about, nor understand, what is meant by jitter.
No IT organization wants to establish an SLA for the performance of the company’s key applications and services and then not be able to meet the requirements of that SLA. With that in mind, the next couple of newsletters will address some of the steps that IT organizations must take to avoid that situation.
In the meantime, we continue to seek your input about your experience with SLAs. In addition, the next IT Roadmap conference will be held in Chicago on April 2. If you are in the area, try to attend as we will continue the discussion of how IT organizations can best cope with the current economic challenges.
