SLAs undermine business alignment

With the exception of outsourcers, IT departments are not a distinct business inside the business, and they should not behave like one. We are all on the same team, so we should be working in a spirit of trust and collaboration. SLAs introduce an adversarial formal negotiated relationship which is inappropriate when two units of the same organisation interact.

It is bad enough that SLAs reduce flexibility by requiring renegotiation to amend them. Far more damaging is the message they send of distrust. While they help business alignment by defining delivery in terms of business requirements, at the same time they damage business alignment by polarising the relationship into one of "us and them", spearated by a written contract.

This idea came from the person who started this whole ITIL skeptic train of thought for me [it's your FAULT Alan]. It is not my position. I think he has a point, but he was working at an organisation then that had that kind of culture. I can see the realities are that

  • formalising the relationship can clarify things and aid communication
  • relationships in many organisations, especially larger ones, are so broken that contracts are required to prevent endless bickering

Bears thinking about though, doesn't it? Do SLAs do damage as well as good? Are SLAs culturally inapproproate in some organisations?



I think it was in the mid 90's, during a debate about why few SLAs were effective, that one of my Dutch colleagues convinced me that SLAs are essentially a flawed concept. They are only asked for by customers so that they can highlight how far away the IT department is from being able to meet their basic requirements for a decent service. They actually become a barrier to effective communication between the customer and IT. Take one simple example, IT thinks the performance levels defined in the SLA are a target to be achieved, whilst the customer considers them to be the very minimum level of service that is acceptable.

I'm all for SLAs where they work

Actually, I'm all for SLAs where they work. I don't see them as flawed in all situations. And I side with the customers in your example: SLAs set the minimum not the target, but I see your point that different groups see them differently.

Another example is the aspect that I have experienced of some Chinese cultures, where a contract is regarded as an excellent starting point for negotiations rather than a conclusion.

Where the SLAs work in the organisational (and national) culture, fine. They are one more arrow in our quiver. But they must not be a fundamental building block of process: we must be able to leave them out.

It's mainly the consultant that creates chaos in the SLA

SLA's should only be established where the risks of non-delivery have a significant business impact and needs agreed upon control and delivery (or growth of). Unfortunately I have seen too many SLA's measuring the perspectives like a BSC (Balance Score Card) without any proper definition of its benefits. In fact, reviews are done on a yearly basis with half yearly submission of measurements for the indicators of successful service delivery. Although one might find business criticality in the attendance percentage of an IT Forum meeting, it is not directly providing me a comfortable feeling that the business understands the value IT can bring.

The worst thing is that most of these SLA's are products of a long term consulting engagement by ITIL certified consultants... surviving the project because they see a bit more in the chaos than their customers.

Please don't shoot me; I am not saying that ALL ITIL certified consultants are incompetent. Just that many are inexperienced.

Which per definition makes them… nah, lets not go there.

SLAs only do damage to the

SLAs only do damage to the extent that the IT organization believes it can impose them on the business organization.

Responsible negotiation and good communication from ANY business partner is useful. SLAs do not reduce flexibility - they are simply a "meeting of the minds" between two responsible groups. They needn't polarize the situation unless the negotiators adopt a combative attitude.

It may, as you suggest, be cultural. However, more likely it is the individuals involved.

Definite cultural element

I think SLAs may work best (obviously if they can be constructed and negotiated in a non-adversarial manner) in corporations, particularly those which have a cultural bent towards robust documentation, like maybe Big Pharma. However, in other types of firms (and specifically those in which you don't have a defined CEO type of role, such as in the case of Partnerships, e.g., legal or accounting services firms) I don't think it's either as feasible, or a particularly good idea. One thought I'm toying with is to create SLAs that we can use as IT-centric measurements on how we and our infrastructure are doing(after defining a service catelogue, associating the relevant CIs together, etc.) Do you think there's any value in doing that down the road?

An expression of expectation...

SLA's are everywhere your expectations are set. One of my early mentors in commercial Project Management (read selling some IT stuff to Customers) told me there are two things you never tell the Customer until you are dead sure of the requirements, Dollars and Dates because they remember them and hold you to them.

When I speak to my Lawyer or Accountant and I initiate a piece of work with them they give me a cost estimate and tell me that if there is a propensity for them to exceed this estimate they will advise me and not proceed until I instruct them.

These are de facto SLA's. SLA's are not an IT & T construct.

SLA's at the end of the day are simply a promise to deliver to an expectation. The good thing about writing it down and agreeing with the other party is there is no room for grey if the agreement is written in plain english and understood by all parties.

When I am asked to deliver a solution for a client I ask all the typical questions, such as:
> How many users do you expect?
> When do you want them to be able to access the system?
> If the system stops working how long on any given business day can you work without it?
> Do you want staff to be able to access the system when they are not in the office?
> Do you have remote access services?
> How do you access them?
> what is the available bandwidth?
> Can the Bandwidth be priortised?
> Do you have an SOE?
> What Operating Systems do you use?
> Do you have in-house IT Support?
> Do you want your in-house IT to support the system?


From these and other questions I get a picture of the Client's Requirements for the System/Service. If I have to transition the System/Service to in-house IT I talk to them about how I hand it over to them.

These form the basis of the business' expectations for when the System/Service is in production.

Surely from these I have the Service Description and am able to derive some initial Service Level Obligations - I recommend SLO's to my clients for new systems so that they can be bedded own, once the SLO's are met for more than n consecutive months they can then become SLA's. If you want an SLA to be a target only then get you business to accept SLO's. The problem with a target is what happens when you miss it?

Surely in your example, don't the Partners want better focus from IT & T than the associates and them better service than the admin support staff, then surely these are Service Expectations and therefore undocumented SLA's. In this type of organisation one partner performs the functions and role one would expect of a CEO.

Take the time to define the Service(s) you provide as you suggest and then make some objective commitment to deliver this service to the client base. This also helps you to communicate to your client base what you deliver.

There is always value in communicating, I am suggesting that as well as taking an IT&T centric view, ask the Client base what IT&T could do to deliver better service. Work these within IT&T and then when you are ready - engage the business to determine if what you are doing is making life better. But always remember that your client's expectations will change over time and what is beyond expectation today could be tomorrow's poor performance.


Looking in her eyes I felt as near to Icarus as to the city before me as to the death of the sun. (The Long Road of the Junkmailer, Patrick Holland, 2006)

Semantics... always semantics

Semantics... always semantics. I spend half my time on this blog defining stuff, usually to show there is no difference of opinion or position. The term SLA defines a formal written document as described in ITIL. i.e. an SLA is what ITIL says it is. See the red book 4.1.4 p 28 and 4.4.4 p 35. The term SLA was invented to get people to think about writing down the informal agreements to which you refer.

Debasement of terms is not permitted on this blog so please do not redefine SLAs as something informal - they aren't. All of the following exist and are good things, agreed, but none of them are SLAs: Client's Requirements for the System/Service... the business' expectations ... the Service Description ... Service Level Obligations [BTW, I generally hear them called Service Level Objectives rather than Obligations]... Service Expectations ...undocumented SLA's ... objective commitment


Dear Skeptic. Firstly allow me to apologise for not using my terms correctly, I did mean Service Level Objectives...not what I typed.

I was highlighting that the source for written down SLA's is there in what we have gathered from the client in the engineering phases of the IT Project. I was also highlighting that out there in the wild are all kinds of expectations as to what the Service Levels are and until you write them down and get agreement they are not worth the paper they are printed on. If this did not come through in my post I apologise to you and you readers.

I manage Services COntracts almost everyday so I see and hear these problems to the point of monotony. I remind my clients that if it isn't written down it isn't happening.


Looking in her eyes I felt as near to Icarus as to the city before me as to the death of the sun. (The Long Road of the Junkmailer, Patrick Holland, 2006)

the appropriate vehicle for all organisational cultures

I agree that expectations are better written down. I guess the question raised is whether a formal, two-party, negotiated contract (i.e. an SLA) is the appropriate vehicle for all organisational cultures.

I have consulted in organisations where that form of SLA would damage the close and informal relationship between IT and the business. Marketing don't write SLAs with the business, finance don't, HR don't (though they do with individual employees for legal reasons, and they often bear little resemblance to the real informal agreements).

I have consulted in public service organisations that are so new-age touchy-feely that the very idea would have had me buried in a group hug to quell all that negative karma.

I have worked in countries where a formal written contract is regarded as an excellent basis for commencing the real negotiations.

Diff'rnt strokes...

I'll do a blog or an article one day on how the Service Catalog is the essential, the foundation, the central pivot of SLM. Not SLAs. SLAs are optional.


I have a real problem with intra-organisational "contracts" where do you go for mediation and what do you do when you want to terminate.

This highlights that there are too many things you can't do effectively with the internal shop that you can do with external providers.

I like to tell my clients that it is all about behaviour (I typically work with the business - not IT). What are the behaviours you want the users and the suppliers to exhibit, that is how you need to document the service. If you choose to include SLO's or SLA's then ensure they reinforce the desired behaviours.

Make sure any metrics for service quality are measurable and achievable and someone is accountable if you don't make it. Always include measures on the client side - IT&T need them to keep their part of the agreement

Service Credits in an internal shop do not engender, and this is my opinion, the right behaviour it is difficult enough to get an external supplier to 'fess-up and pay out

BTW the quote is from my nephew's book.

Looking in her eyes I felt as near to Icarus as to the city before me as to the death of the sun. (The Long Road of the Junkmailer, Patrick Holland, 2006)

big British mainframe sites of the 1980s

Absolutely we should do service level reporting even when there are no SLAs. "You can't manage/improve what you don't measure" or so we are told. In fact I recommend a catalog and SL report early but SLAs very late in the maturity development.

You are dead right about the appropriateness of SLAs. They work in large siloed formal organisations such as ...oh um... big British mainframe sites of the 1980s. This is a prize example of the cultural bias of ITIL and how it is non-representative of the broad user base it purports to appeal to.

Syndicate content