What's wrong with SLA? (part 2)

By Jean-Pierre Gilles, December 30th 2014 

 

Fact of life is that on modern days, business conditions evolve very quickly and companies need to adapt to that world to retain their customers, find new ones, and develop new products and services and move or stay ahead of competition. Therefore the type and quality of products or services that business organizations need to deliver are rapidly changing and require frequent and fast adaptations.

 

How much do the SLAs in place help with that objective?

 

Very little, most of the time, as the way Service Level Management is approached is rather focused on  SLA  and costs. In fact the current culture around SLAs may turn to be a real handicap as it is often built on a process-centric entropy that can have an adverse effect on the level of agility required to cope with business changes and expectations…Staying focused on what was needed in the past may not be the best way to cope with the business needs of tomorrow. 

On the other hand, how to trust and work on future needs with a supplier that is not even capable of delivering what was agreed? Good question …

 

Another question though: what is the other choice? Waiting for the end of the contract and change the supplier or fighting every day for those famous SLAs to be met and hoping the next supplier will be more capable? How does it help the business?

Let’s take a little detour: is there another IT area where not delivering agreed solutions was rather common, and/or where finally delivering them, at the end of a long period, was not enough anymore to meet business expectations?  Application Development has some miserable records…

And what was finally invented to improve the capability to better meet business expectations in that area? Agile Methodology, right?

To overcome the limitation of service management by SLAs, IT organizations need to become more agile! Service improvements should be approached in an agile way, with tangible progress/evolutions being identified, worked on and implemented in a step by step and regular iterations approach. 

 

So instead of building a CSIP (Continuous Service Improvement Plan) on an almost fixed SLA approach (better, cheaper, faster…), it should probably be handled as a development project, considering the needs and requirements, and run with a proper agile methodology. If missing the SLA targets really matters, then that will be treated with the right priority. If it does turn not to be that critical, time and effort should rather be spent to deal with new challenges, progressing step by step, delivering less progress at a time but faster and more often.  Possibly, new commitments and SLAs will be defined, not on the delivery of the service but rather on the capability to deliver agreed improvements or evolutions on time. A bonus-malus mechanism can also be introduced where the agility to bring improvements and to increase the business value of services can compensate a poorer level of achievement of the service based SLAs.

 

As a conclusion: IT services’ success stands above and beyond the SLAs: increasing value for the business has to become the focus, so Service Level management and CSIP need to be reoriented towards an agile way of coping with new challenges, orientations, directions rather than sticking to fixed SLAs were designed to answer the needs of the past. 

 

Copyright © 2014 - PRACT Publishing


Other articles

► No article link

► JP Gilles introduction


External links

► No link


Related products

►  No product