Free Newsletters

   All InfoWorld Newsletters
Advice Line | Bob Lewis » Agreeing to disagree about Service Level Agreements

February 17, 2008 | Comments: (0)

Agreeing to disagree about Service Level Agreements



Dear Bob ...

You were quite critical of Service Level Agreements in your recent column, "Run, IT run ... but not as a business," (Keep the Joint Running, 1/28/2008), describing them as formal contracts between IT and the rest of the business.

My opinion is that the concept of a Service Level Agreement is very sound. The implementation has run amok. An SLA should not be treated like a legal contract but an agreement between business units of the same company.

Here is one definition I have seen that fits into what you are describing.

Service Level Agreement: An Agreement between an IT Service Provider and a Customer. The SLA describes the IT Service, documents Service Level Targets, and specifies the responsibilities of the IT Service Provider and the Customer. A single SLA may cover multiple IT Services or multiple Customers.

It is perhaps the result of IT's importance to the business and the increasing percentage of the overall budget that has given rise to the SLA. Rarely do you see Accounting or Human Resources (both "service" organizations) submit any statement of service levels. In some cases Human Resources can encumber business growth more than IT. Faulty and ineffective recruiting and employee retention policies cost real money. Have you ever heard of an HR department agree to a 10% or less turnover rate?

I have seen the level of complexity in SLA's increase in recent years. The main problem is that the business and IT need to effectively communicate to each other to make service level agreements work. IT needs to understand how the business uses their services and the business needs to understand, at a high level, what it takes to deliver those services.

The credibility of IT is still not strong with the business. In the eyes of the business leaders, IT projects and initiatives still do not deliver good value for the investment. C-level leaders are happy when a major project is completed and the business is still standing - e.g. SAP installations. Am I able to establish and maintain an agreement with someone whose competency I question?

Contracts are very different from agreements. In a legal sense, a contract must completely define a business or personal arrangement. If it isn't in the contract, it doesn't exist. The quality of the relationship between the business an IT required for success cannot be totally defined in a contract. The requirements change daily. It is almost like a marriage, once the "contract" is signed, the real work begins.

- Service leveler

Dear Leveler ...

I guess we'll have to disagree on this one. I certainly agree that monitoring performance is essential. I agree that understanding what the business requires in terms of ongoing service is as important as understanding what it requires of new software.

I've yet to see an SLA that wasn't the product of negotiation. That's what makes them contracts, and it's the first place SLAs break down: They put IT and the rest of the business on opposite sides of the table, when they need to be collaborators who sit on the same side.

You hit on another, also not covered in the column you referred to - that SLAs, are another step toward one of the great evils of the modern age - establishing a supplier/customer relationship between IT and the rest of the business.

That's how I've seen and heard of SLAs playing out in real companies that have put them into place, and it's rarely a positive step. As regular readers of Keep the Joint Running know, I'm not a big fan of the whole "internal customer" philosophy (for a white paper that covers this subject, click here).

If you've managed to implement SLAs as collaborative understandings with your peer collaborators throughout the business, more power to you. My unsolicited advice is to be very careful in keeping them at that level.

At the first sign of trouble they can easily deteriorate into tools to support mutual finger pointing.

On an entirely different subject, I do have to pick one nit in your letter. While HR is, in many organizations, guilty of a variety of sins, it rarely has much impact on employee retention. When turnover is high, the fault is almost always systemic, the result of pervasive bad management and poor leadership.

The head of Human Resources can only wish he or she had enough influence over management behavior to have an impact on employee retention.

- Bob

Posted by Bob Lewis on February 17, 2008 07:15 PM


RATE THIS ARTICLE:





 

  •  
  • COMMENTS




I've been following this debate back and forth, and it seems to me to be a lot of "straw-man" argument. Yes, you can choose examples to make SLAs look silly. Certainly it makes no sense to think of one part of a company sueing another to enforce a legal agreement. I think you can find examples equally silly the other way. Do you really want the IT department to "collaborate with you to develop strategy" regarding putting a phone a new hire's desk? Seems pretty obvious that there should be a standard way to order it, a standard way the cost is handled (which probably looks like chargeback; direct employee expenses like this make more sense in my budget than IT's), and some standard expectation of how long it takes. Don't call it an SLA if the term offends you, but it reflects an agreement about a level of service, if it quacks like a duck....

It seems to me the real issue is not that SLAs are good or bad, but that there are places they're appropriate and places they're not. specifically, they seem appropriate for routine, commoditized services, where operations should have a consistent expectation of performance, and not appropriate where IT's role is more collaborative, and issues of strategy are involved. This doesn't seem like a statement about SLAs at all, just an application of a more universal principle: almost anything, done well, works well; done stupidly, it becomes stupid.

Posted by: John Stork at February 20, 2008 12:24 PM

Some of this discussion reminds me of General Eisenhower's answer to a question about the worth of the D-Day plan once the invasion started: "The plan was nothing, the planning was everything." The negotiations of "who will what for-to whom on what schedule at what cost and how do we know we are delivering properly" need to get done, whether for an SLA or not. Formalization in an SLA can be a minor detail or a big deal depending on the trust levels.

Posted by: TomV at February 21, 2008 06:53 AM

I think there are LOTS of ways to succeed or fail but the most significant determinant is the organizational culture. Bob has pointed this out in a variety of his columns and I have seen plenty of examples in my 35-year career. I categorize cultures into 3 (very) broad groups. Here is a gross generalization but I think it still has merit.

1. Combative: probably self-explanatory. We have all been there at some time and I do not want to think about it long enough to describe this culture (any more than to simply name it).
2. Cooperative: better than combative but not necessarily optimal because it is usually accompanied by a negative connotation of loss. When compromising, the focus tends to be on what each party has to give up in order to agree. This is hard to swallow because we tend to remember what we did not get.
3. Collaborative: I prefer collaboration over cooperation because collaboration encourages a positive attitude about the outcome (even if the outcome is a compromise). This is because collaboration focuses on what each party will attain instead of what each party has to give up.

Culture is closely related to attitude. Attitude is a building block for culture. The builders who use those blocks (creating your culture) are your leaders, both the official leaders and the unofficial ones (seniors, PMs, etc). SLAs, OLAs, processes... all just details. A healthy culture can succeed with less-than-optimal processes while a sick culture will almost certainly fail regardless of using the best processes.

Posted by: Chris White at February 21, 2008 08:47 AM

Three books. Three ways to change the world, your life, or at least Bob Lewis' bank account.

Leading IT: The Toughest Job in the World distills the world of IT leadership into eight learnable skills and gives you concrete, practical techniques for each one of them.

Bare Bones Project Management: What you can't not do makes project management manageable, even for first-time project managers with no formal training in the discipline.

ManagementSpeak: What managers say/What they mean … well, it won't help your career, and won't make you a better manager. Mostly, it will make you chuckle, guffaw, and maybe even chortle. Make friends - it's the perfect gift for anyone who has ever suffered through one of those meetings.

Order your copies today!





Technology White Papers

 

InfoWorld Technology Marketplace

  • Protect Your Data with SSL - Discover how to increase customer confidence in your site with the latest solution in SSL, Extended Validation (EV) SSL ...
  • Need simple, low cost server virtualization? - Do more with less. Support fewer servers. Simplify disaster recovery. Implement proven, easy-to-use server virtualization...
  • Virtually Limitless Virtual Storage - Do you need virtualization space savings of 50% or more with virtually no performance impact? You might be able to get storage...
  • Invisible IT? - The goal of IT is to become an invisible entity within a larger organization. Eliminating visibility and road blocks IT ...
  • It Really Is Easy to be Green - "Green IT" is a popular concept. And IT organizations are learning the influence that IT purchase decisions have on data...
  • Key Strategies For SOA Testing - SOA requires a unique approach to testing. Unless you're willing to reorient your testing procedures and technology now,...

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert

Find out when the latest white paper is available:
 
 
» BUY A LINK NOW

Sponsored Technology Links