How to run your IT like a business using Service Levels

There is growing interest in running IT like a business. Internal IT departments are competing against alternative services (a.k.a. Shadow IT) and are under pressure from growing expectations due to what the industry calls consumerization of IT. IT leaders across organizations are stepping up their act to go from an internal operations to fill the shoes of an IT department that is increasingly becoming part of the overall business.

In this new world, an internal IT department is being forced to cast away its traditional mode of operation, and compete and position itself in this new IT marketplace.

The new role of IT

Positioned between the Business and the Service Providers, IT has the opportunity to carve out a new role for itself – based on an orchestration of internal and external IT services. In doing so, it should be careful not to turn into “just an administrative interface”.  It should rather leverage its position.

Using Service Levels to run IT like a business

Using Service Levels to run IT like a business

IT should now focus on:

Creating Value: The new IT thinks differently – it does not necessarily think “profit” but it thinks business. It seeks to understand the intricacies of the business, and then analyses how IT forms a part of the business delivery chain. In doing so, IT shows the business how its service offerings are relevant. IT tracks technology trends and translates these trends into a concrete service offering that makes sense for business. In doing so, it takes make vs. buy decisions. It chooses to procure commodity services, or even partner with innovative providers for co-creation. The role it always retains is “driving the business relevance of IT”.

Integrating Services: IT goes from operating traditional technology silos to a service integration and orchestration. It converts rigid capital costs into flexible operating costs.. It decides how the regulatory compliance laws and guidelines of the business are translated into its IT hosting strategy (internal and external). In doing so, it translates its understanding of how IT intermeshes with business into a modularization of its service landscape. It fills the nooks and cracks in between the services it procures (esp. external providers) to offer a smooth integration.

Optimizing Operations: IT differentiates between core tasks where it is crucial that IT plays a leading role and commodity tasks and services that can be procured. It shifts its attention from solving incidents and tickets to enterprise strategy. It focuses on measuring the impact of its service integration instead of performing the individual commodity services.

IT should go now step beyond just doing the above – the charm lies in being able to demonstrate it quantitatively. This is where Service Levels come in.

Can Service Levels help in positioning?

The art of designing service levels lies in the context of the interface that you are managing – whether this is an interface towards your service providers, or towards your end client.

Start the Value Conversation towards your End Client / Business through a Service Level discussion by following these three steps:

1. First help your client understand the service you offer in terms of Service Levels.
2. Then, together design Service Level Objectives that aid their decision-making,
3. And finally, aid them in fixing service level targets that they can afford.

More about these three steps in “Three Steps to Demonstrate the Value of your IT service“.

Design your service orchestration layer and manage your service provider interfaces by asking very different questions. Irrespective of whether you are measuring service levels with your provider, or setting operating level agreements with adjacent departments, the questions that you should ask are:
a) Can you use these measures to control and manage your delivery landscape?
b) Can the levels that you have set for yourself be attained?
c) Are you able to measure these service levels properly?

More about these three questions in “Are you using the right measures to control your operation?“.

After a detailed appraisal of your operations and strategy using the above, concrete Service Levels will help you as an internal IT department to compete and differentiate yourself in this new IT market place.

Are you facing pressure to demonstrate the value of your IT services internally? Are you facing the constant threat of “Shadow IT”? Have you ever thought of using Service Levels to position yourself?

Are you using the right measures to control your operation?

In my last post, I dealt with how you can use service levels to demonstrate the IT Value of your services.
Now we get into the engine room – we deal with how you should use service levels and operational level agreements to measure your own delivery operation. Your “delivery landscape” will be a myriad mixture of the services delivered by your own team, adjacent departments and the providers who handle the scope that you outsourced. I will not dive into how to manage each of these components since this is a subject in itself.
Instead I want to deal with the service levels and measurements that you should have in place for these interfaces.  While designing service levels for such interfaces, I have learnt to appreciate the difference in their nature to the ones that you used towards your business services.


The questions that you would now ask yourself are very different in nature to those that you use to demonstrate your value. Irrespective of whether you are measuring service levels with your provider, or setting operating level agreements with adjacent departments, the questions that you should ask are:
a) Can you use these measures to control and manage your delivery landscape?
b) Can the levels that you have set for yourself be attained?
c) Are you able to measure these service levels properly?

Can you use these measures to control and manage?

  • Control does not mean measuring each and everything that you can. Seek Emphasis in Service Levels. Sometimes the ease of measuring something serves the propensity to measure and report it.
  • Differentiate between measuring (for the sake of control) and reporting (for the sake of understanding) metrics.
  • Before you delve into finding out what you can measure, rather first concentrate on “what must you measure and why?”
  • previous exercise with your business department would have shown you how the service that you deliver inter-twines and actually affects the business operation
  • This will tell you whether you should look out for critical timelines, large transaction volumes, accuracy,…?
  • Concentrate on the few key measurements that you can actually use to control the key parts of the service components that you are managing. Derive these directly from the understanding of what makes or breaks your business.

Can the levels that you have set for yourself be attained?

  • Defining a Service Level Objective for each of your service components are not enough. You should  set values that are attainable within the costs or boundaries of delivery that you have been given.
  • It is no use to accept a 99.9999% availability target from your end client when you are unable to break this down across your applications and infrastructure or are not able to deliver this to within the budget constraints.
  • This is particularly important when you are getting zealous in managing your provider. In your eagerness to measure and manage your provider, you might be setting target values that are either too expensive.
  • After you have set values that you can attain, find ways to actually control how you attain these values. I have seen some IT managers cleverly build in latency into their system – a latency that can be gradually removed as the load on the system increases. These are many such smart practices one can borrow from system architects.

Are you able to measure these service levels properly?

  • There are miles between the intent to measure something and actually being in the position to do so. And the more holistic the intent (like Business Impact), the more precise you need to be in how you measure it.
  • So as you design your service levels, make sure that you actually know how this can be measured. I once had to convince a client that a particular Service Level Calculation (System Availability) was not fully thought through – it took us two hours to could come up with a formula to measure it.
  • Do the math. Start by very carefully designing the algorithm and formula for the measurement – what goes into the numerator? what goes into the denominator? What is the sample size of measurement? Are you aiming at a %age based measurement, or a number based measurement? What are the implications of both?
  • Then ask yourself: Do you have the service management capacity to measure and follow up all that you have designed?
Best practices from the industry, Service Level Agreement Examples, internet searches, and tool vendors will give you a plethora of choices of what you can measure. Reading about and gathering such measures is the easy part. The tough part is making the choice of what you spend your precious service management capacity on – and the art lies in translating this in summation to your understanding of how you are delivering IT value.

photo credit: via photopin cc

Three Steps to demonstrate the Value of your IT Service

It is Monday morning 09:00 AM – and you are in your monthly IT Service Quality meeting with your “internal client” – the Sales Department of your company. The Head of Regional Sales is pushing you with unrealistic expectations – you have discussions about 99.999% availability where you already know that such a Service Level Objective is either horrendously expensive or probably also not attainable. You are on the defensive.

And you are thinking to yourself: “This is not the discussion I want to have – I want to instead show him the value that my IT department provides”.

Start this Value Conversation through a Service Level discussion by following these three steps:

  1. First help your client understand the service you offer in terms of Service Levels.
  2. Then, together design Service Level Objectives that aid their decision-making,
  3. And finally, aid them in fixing service level targets that they can afford.

Analogue 5426_BW

STEP #1. Does your client really understand the service you offer?

  • Does your business really understand the IT service that you are providing? Do you understand the direct correlation between your IT service and their business? Do they see the impact of what you do or provide on their business?
  • If not, help them first see this relevance. And in the process, you will develop a feeling for the aspects of the business that are important.
  • Feign from asking direct questions about what is important to them – you might not get the correct answer.
  • Instead quiz them more about how your service inter-meshes with what they do.
  • Their answers will bring out aspects that are important to them – is it timing, is it the impact of a downtime, is it availability, is it throughput at certain times of the year? Is it handling large volumes?
  • This constructive dialog will give you not just an understanding of your end-clients business, but also the aspects of your service that are important. Use Service Level Agreement Examples if this helps.
  • Derive your service level objectives from these aspects – this will help you to capture your mutual understanding of this relevance of your service and make this transparent to your client.

STEP #2. Can your client take decisions based on the Service Levels you measure?

  • You have come up with a set of service level objectives which directly measure the aspect of your service that is important to your client – now go to the next stage.
  • Discuss with them about how certain aspects drive business decisions
  • Lets say you are hosting a Sales Application, and the SLA on availability of the application is tantamount for sales closure.
  • Your discussion might show that availability of this application is critical as you approach Christmas. This is when they would want your application availability on full throttle.
  • But what about the rest of the year? Maybe keeping this application on full throttle high availability for the rest of the year is too expensive.
  • How can your SLA Definition help you decide what to do? What if you design a threshold level for your availability – so that falling below a certain level sets off a signal for both your client and you to take this to the next level of availability?
  • Don’t stop at just designing a service level and a target for the same – mutually decide with your end client on what happens when services fall below the minimum level.
  • There is a dual benefit – your client will see directly how to use and tune the service you offer via SLA Management, and you will be prepared beforehand about how to react and what to consider when certain levels are reached.

STEP #3. Help your client manage the Cost of Service.

  • If you have done the above two, you would both have a good mutual understanding about how service levels can be used to manage the service that you are providing.
  • Now steer your discussion towards the Cost of Quality. What is the balance of cost versus the quality of the service you provide?
  • Continuing the example of a hosted Sales Application: Lets say that the high availability of this application is only desired during the Christmas season.
  • You can now suggest that the SLA on availability of the application be reduced during the “idle” months by shutting down a few servers – and you would pass this cost benefit on to your client.
  • When the sales volumes increase, you could kick in the additional computing power.
  • This will help you define two levels of service for the two periods. And you could design the switch between the two levels of service based on a target threshold for your service.

The above three step process will help you have a fact-based quantitative dialog with your end client. You can demonstrate the relevance of your service quantitatively to your client through Service Levels, and also together decide on how this is measured and used.

And with this, you will have quantitatively established the added value that your IT adds to your business.

photo credit: Thorbard via photopin cc

How to design Performance SLAs that your Business will love

Service Level design discussions are one of the most interesting parts of designing a contract. When you find yourself in the midst of one, eventually someone asks your advice: “What Performance Service Level Standards does one see in the industry today? Do you have any Service Level Agreement Examples?”.

The search for best practices is tempting. Why reinvent the wheel, right?

But there are no silver bullets. Copying performance SLA definitions from the market never really helps you to truly bring out the value of your service. A good SLA for performance is one that is in tune with the nature of your business.

Flux Capacitor

photo credit: Stuck in Customs via photopin cc

What is the nature of your business?

You should start by asking the question: “What is the nature of your business? And what does performance mean in the context of your business?” Dissect and boil down the nature of the business to the effect it has on the IT landscape and consequently the IT service you are trying to measure.

Over time,  three distinct patterns of services have emerged from such discussions. While there could be a mix of these patterns in any given service, one of them usually dominates the others and forms the base of your Service Level Objective.

The three Patterns of Service

Reaction-Intensive Services:

  • An e-commerce website selling books online is an example of such a business, where the website along with its underlying applications and infrastructure should orchestrate together to deliver information within the desired reaction time.
  • If you were buying such a service as a Platform as a Service, you would define Performance SLA Management based on the reaction time for events like searching for books, retrieving information on a particular book, clicking “Send to Shopping Card” etc.
  • It would also make sense to further analyse whether your reaction intensive business is based on retrieving information efficiently or servicing interactive requests quickly.
  • Therefore a performance SLA for an interface to a credit risk Agency (retrieving information) would be designed differently from the e-commerce bookstore example that we have been describing.
  • Equally important is whether the service you are measuring has to show a consistent average reaction time or whether it is ok to have erratic response times during periods of high traffic. Such decisions can have a major impact on the price that you would require to pay for the service.

Volume-Intensive Services:

  • A batch-processing service like reconciling bank transactions is a typical volume-intensive business.Performance in such a business is measured very differently from a Reaction-intensive business.
  • In such a situation, you should study the patterns in the transactions: are there peaks and troughs in the volume demand, are there differences in the complexity of the processing logic for various types of transaction batches? What is the impact of these patterns on the performance expectations?
  • Answer these questions, and look for patterns. Study the make-or-break scenario. This will help you design the service levels that you need to keep the business running at average volumes, at peak demand and at low intensity periods.

Deadline-Intensive Services:

  • The third type of service is one that is fraught with deadlines and has to deliver on critical due dates.
  • A typical example is month-end and year-end processing software. Such software is expected to perform complicated calculations and handle large volumes of data at certain times of the year. These services simply have to work as expected at exactly these times of the year.
  • Such a service oscillates between low intensity periods and periodic peaks where the software and its infrastructure is firing on all six cylinders with punishing volumes of data.
  • Performance Service Level Calculation in case of such systems will have to take care of these two types of usages and the performance expectations during these two states.

Dissecting your service

Designing an SLA concept to measure and track performance of your service will start with what might sound like a navel gazing exercise.

Step 1: What is the nature of your business?
Analysing the nature of your business and the demands that this nature puts on the IT services will tell you what kind of performance SLAs you should be designing.

Step 2: What is the impact on your IT landscape?
You will also find that this impacts different parts of your IT landscape differently. If you are defining your service at such a component level, separate out the parts of your application landscape that are reaction-intensive from those that are volume-intensive.

Step 3: What is the granularity is your service? At what level are you measuring?
Analyse the granularity of the service that you are establishing. Check whether this service is delivered by an entire stack of components. Are you measuring the behaviour of a part of your application landscape? What are the expectations on this part (reaction/volume/deadline). Or are you measuring the performance of a business process (with a underlying interconnected components across the technical stack)? What is the nature of this business process (reaction/volume/deadline)? What does this imply for expectations in performance?

The above three steps should lead you in the right direction to create Performance SLAs that mirror your business needs.

There is no one-size-fits-all

As you can see, there are no one-size-fits-all Performance SLAs, and searching for best-practice Performance SLAs is futile. Instead, take the time to study the intricacies of the business you are serving and use the patterns above to design a Performance Service Level measurement that not only matches your business, but also closely demonstrates the value that your IT service is adding to the business.

You have often looked for the chance to demonstrate that your IT service contributes to business – here is your chance to put some skin in the game.

Do you have performance based SLA definitions today for your IT service? Do they truly mirror the nature of your business?

The Zen of Service Level Agreements: 4 Design Principles for an Optimal SLA

Designing Service Level Agreements is an art. It is important to invest time and energy into defining a good Service Level Agreement upfront in an engagement to avoid unnecessary friction downstream.

This post summarizes the four Design Principles of Optimal Service Level Agreements.

Pedestrian Bridge in B+W

Design Principle #1 – It is all about Emphasis

Bring focus and emphasis into the Service Level Agreement Metrics that you design. Don’t spread yourself thin and define multiple metrics across multiple dimensions. A sea of metrics will only lead to an average mediocre performance across the board. Here are three steps that will bring focus into your SLA design.

Design Principle #2: Do the Math:

You have just finished defining your Service Level Agreement metrics and targets. You are satisfied that you now have a true measure of your service and your outsourcing contract. However, if you have not done your math, this could backfire with unintended consequences. Here are five mathematical traps that can set your SLA definitions up for failure.

Design Principle #3: Design for Resilience

A contract lifetime of 3-5 years can feel long in fast-paced industries like telecommunications and media. Even brick-and-mortar industries could see a complete business cycle in this time, and encounter at least one downturn during the life of the contract. Situations like these change priorities and expectations. This begs the question: Can your Service Level Agreements and KPI target values adjust to these changes? Here are three factors to consider so that the SLAs adjust to the demands of the situations.

Design Principle #4: Bringing Balance

A balanced Service Level Agreement is a sign that you and your provider have a healthy working arrangement.Do you have an early warning system built into your Service Level Measurement? Have you balanced the risk? Here are three ways to balance the risk in your SLA design.

If you have designed your SLA metrics well, your laser focused attention on these metrics while managing your service can lead to step changes in the quality.

What has been your experience with your current SLA model? Which part of your Service Level Agreement will you redesign after going through the above four Design Principles?

photo credit: w4nd3rl0st (InspiredinDesMoines) via photopin cc

3 practical tips to help you balance your SLA

Designing an SLA system is a balancing act. The art lies in how you choose to balance the risk between two parties. A skewed SLA definition might look good at first, but can prove harmful to both parties on the long run.

 Zen Habit #4: Balance

Here are three tips to bring balance into your Service Level Agreement.

Do not dwell in the past; do not dream of the future, concentrate the mind on the present moment. Buddha

Walk the Risk Tightrope

  • Outsourcing is essentially the transfer of risk from one party to another in a way that the party that has the most skills to handle the risk through operational expertise and authority also has the responsibility for execution.
  • If this risk is imbalanced, you will end up either paying too much for the service, or you will not be able to attract a serious provider to sign up to these conditions. In either case, unbalanced risk is a losing option for both parties.
  • Therefore balance the SLA system in a way that you focus the Service level Measurement rigour on the more critical parts of the operation. Do not spread yourself thin across your service portfolio.
  • For less critical parts of the operation, use key performance indicators (KPIs) which act as a dashboard to the system but do not attract any penalties.

Risk/Reward – the Ying and Yang of SLAs

  • Balance Penalties with Reward – Encourage the right behavior more effectively with a carrot and stick approach, and not only with the stick.
  • Raise the performance bar on the critical parts of the operation by fixing robust SLA targets and ensuring them with penalties.
  • But equally reward the focus of the provider when they over-achieve.
  • This has two benefits:
    • This will focus the provider on the critical parts of the operation.
    • When your system also equally rewards over-performance, this gets factored  into the price of the service and will negate a risk premium.

Adopt the Football Foul Card approach

  • Adopt the yellow and red card approach from football into your Service Level Measurement System.
  • Build a “yellow card” – an early warning system into your SLA measurements.
  • When a provider is dangerously close to defaulting on a SLA target, an early warning in the reporting should alert both you and your provider.
  • In the “yellow card” dialog, don’t chastise your provider, but caution him.
  • Have a constructive dialog with your provider on an early warning sign – find out mutually what both parties can do to avoid a service level default (the red card). While a provider might feel the pain of a penalty on a default, you face a reputational risk that a penalty payment cannot remedy.
  • Decide on the remedial actions that both parties will take to make sure that the service returns to normalcy.
  • Lastly, set a date in the future where you will meet to see the effect of the remedial action and whether this has positively affected the service measurement.

A balanced Service Level Agreement is a sign that you and your provider have a healthy working arrangement. It is important to invest time and energy into defining this upfront in an engagement to avoid unnecessary friction downstream.

Do you have an early warning system built into your Service Level Measurement? Have you balanced the risk?

Other posts in the Service Level Management series:

SLA – Zen Habit #1: Emphasis
SLA – Zen Habit #2: Do the Math
SLA – Zen Habit #3: Design for Resilience

photo credit: uteart via photopin cc
Wordpress SEO Plugin by Wordpress SEO Plugin