Are you ready to deliver your newly signed IT contract?

As this new business year begins, I want to start with a post that sets the note for my study topic in the first quarter of 2014. It is the demand for continuity in every sense – after signing an IT contract – a topic often ignored: SERVICE TRANSITION.

Service Transition has nuances that go beyond what is prescribed in ITIL. Discussing and negotiating large IT contracts requires more effort than one actually thinks it should entail. This often leads to the result that people are singled out for 5-6 months to design and close the contract. On the IT buyers side, this is usually treated as a project with definite goals. The providers put together what is generally known as the pursuit team (with sales, technology experts and solution architects).

The solutioning and contracting process is an effort intensive task and involves the above teams sitting together for 5-6 months – meeting every day and having very detailed discussions on how to set up future operations. Depending on how such discussions go and the amount of value each side finds in the other, these teams either grow apart or get closer to one another. The presence of an advisory party helps to bring balance into the contract in both situations. I have been on all sides of this table – and it has been a 360 degree learning experience. It is amazing how your current viewpoint can affect the way you interpret a situation.

After the contract is signed, the IT buyer team is relieved on having completed the “contracting project”, and the Pursuit team celebrates having won the contract. What both teams often neglect to do is getting their individual organizations ready for the contract.

After seeing many initiatives go through the trough of despair after signing the contract, here is my thought-jogger list:

If you are buying IT services…

Have you thought of:
a) Does your team know the scope of services of the contract?
b) How should your team reorganize themselves to face the new provider – what are the touch points?
c) What are the new roles and responsibilities on your side of the contract? Have you designated a Service Transition Manager?
d) Who should perform the above roles? Are they equipped for these roles (skill & experience)? Are they enabled to perform these roles (time and authority)?

If you are the Provider

Have you thought of:
a) How do you transfer the knowledge gathered during the contract into the delivery organization?
b) How do you ramp up to get the people who you need on the ground asap?
c) How do you continue the relationship that you have just painstakingly built over the last months with new members entering the picture?
d) What should you set up to manage the contract that you have negotiated?
e) How can you transfer the good relationship and rapport that you have built up with your new client to the future delivery team?

Ideally you don’t want to bring in the Delivery organizations on both sides into play only after the contract is signed.

Such discussions and decisions should happen long before. There is great benefit in bringing these parts of the organization earlier into the picture as periphery teams. The core teams should involve the periphery teams gradually into the discussion in the later stages of the contract. This should go through the stages: BRIEF THEM ON SOLUTION, INVOLVE THEM IN THE DISCUSSION, INVOLVE IN DECISION MAKING. Both sides should perform a contract readiness check based on questions such as the above.

I will be spending the first quarter of 2014 exploring the multiple facets of this situation. Stay tuned.

photo credit: qwrrty via photopin cc

How to discuss assumptions in proposals to your benefit

The ubiquitous Assumptions section

Each IT proposal has a section towards the end – just before the financials and pricing, there is a small section with a list of assumptions on which this proposal is based on. And when it comes to the discussion table, both providers and IT buyers fumble with how to deal with this section. From a provider’s perspective, this is their way of setting down the boundary conditions of the solution. It is their way of offering a solution that is based on certain parameters which if fulfilled will enable them to deliver the solution they have designed.

Should you remove Assumptions?

Well, yes – but not without a discussion.

From the other side of the table, assumptions look scary. All you see are hidden data points and conditions which can suddenly increase the price if this is not either discussed away or controlled. And the result is predictable: Often contract negotiators try to remove all the assumptions so that it comes down to a contract sans assumptions. I am not advocating making contracts with assumptions. But should you seek to remove blindly? That would be wasting a hidden opportunity to have an in-depth discussion that benefits both parties. But how do you start this discussion?

Question mark

Divide and Focus

First segregate the assumptions. There are multiple types of assumptions – there are those that have material impact on the solution since they drive the entire effort of the provider, and those that simply lay down the financial conditions on which the price is based (e.g. handling of lodging and travel costs). Focus on the ones that shape the solution or refine the problem definition.

Don’t insist on removing assumptions without understanding the impact – because the only way the provider can remove assumptions is to price it into their solution.
Discuss each of them using the following questions:

  • What is the basis of this assumption? How does this impact operations?
  • What happens if this assumption is proven wrong?
  • What happens if a value increases or decreases?
  • Who can control this value? what are the means of controlling these values?
  • What can either of the two sides do to control these values?

Have this discussion dispassionately without first assigning responsibility – after this find out which party can control this risk best – this will give you the optimum balance between responsibility split and price.

Can Assumptions help you?

  • Often assumptions can lead you to finding a solution to your problem.
  • If you release a list of goals that you want to achieve and ask for a solution – you will get a solution that is driven by assumptions.
  • Such assumptions are not a nuisance – use them wisely to bring more refinement into the definition of the problem, or the enrichment of the solution depending on which side of the table you are sitting on. More on this topic in this article on Request for Solutions.
  • A smart provider should also think of using assumptions to coach the IT buyer – but they should not do this by talking down to the IT buyer
  • A smart provider should coach the IT buyer into what should be added to the problem, what they have potentially missed, what they should be demanding in addition. Believe me, IT buyers value this coaching as it shows them that you are thinking for them.
  • Use this discussion to find out where the buyer want to draw the line to split the responsibility.

Assumptions work both ways

IT buyers should not stop at only discussing assumptions that the provider has raised. They should create a list of assumptions of their own as the solutioning dialog progresses. Use these questions as a kick-start:

  • What are you taking for granted?
  • What are you being promised? How can you verify this for yourself?
  • What assets are you relying on? What are these assets performing that will be useful to you?
  • How can you check and measure that this is actually the case?

Now use these assumptions to drive due diligence on both sides. Giving each party the possibility to check the assumptions will go a long way in avoiding any conflict situations after the contract is signed.

In summary

Often the actual persons that are available during the contract phase on both sides (the deal team on both sides) leave after the contract is signed, and this is then handed over to the delivery team on both sides. Discussing the assumptions on both sides, and documenting the results of the same by baking it into the problem definition or into the solution will bring the required rigor into the contract.

The parties on both sides that are forced to live the contract over the next five years will thank you for it.

photo credit: Marco Bellucci via photopin cct

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

The tricky balance of risk in your IT Outsourcing contract

Many Application Services Pricing Models today are skewed in terms of Risk-Modelling. The balance of risk between the service provider and the procurer of the IT Outsourcing services is usually lopsided. And this imbalance gets factored into the price. Is there a way to avoid this?

Today we look at Best Practice #5: Balance the risk in your Pricing Model

Balancing the Risk

There is no free lunch in Pricing Definition

An imbalanced risk leads to one of these two situations:

  • One ends up paying more than what is required for the service, or
  • one finds oneself in constant service management escalations arguing about who is responsible for ensuring that a certain thing happens.

Example: a standard T&M model keeps only staffing risks on the side of the provider – while this might be the desired mode of operation for some situations, this transfers a huge portion of the operational risk to the buyer. There are many situations where one would like the service provider to take over some of the execution risk. However if you ask a service provider to price in elements that he cannot influence, you are forcing him to add a risk premium. This is not always the wisest approach.

Operation Risk should be baked in where it belongs

The golden rule – Allocate risk in the pricing model in a way that the party who can best control the risk deals with it. If your requirements are volatile, do not try to bake in fixed efforts into your pricing model – there is no free lunch. Your service provider will recognize this risk and is forced to add a risk premium to his price.

If the dimensions of your service vary across time, do not demand a flat rate for the service. Instead model the varying dimensions so that you can specify them. At the same time, dimensions that constitute execution risk can be shifted towards the service provider in terms of a flat rate or fixed price.

In summary

Over the last five posts, we looked at the best practices of designing an application pricing model.

A best in class Application Pricing model has the below five characteristics:

Scalable to handle Future Scope: the model should scale and accommodate all kinds of changes to the application portfolio over the duration of the service contracts
Transparent and Granular: Establishes a price per application and makes the price effect of each service easily calculable and transparent.
Encouraging the Right Behavior: the pricing should encourage good intent and reward good behavior from the service provider.
Elastic: the model should be flexible and breathe with the business and, at any given point of time, should reflect the effort required to provide the service.
Risk-balanced: – the model should allocate operational risk to that party (IT Department or Service Provider) that can mitigate the risk best

Incorporating the above five best practices will go a long way in creating an Application Services Pricing Model that serves you well throughout the duration of your contract.

 

Have you incorporated the above in your Application services contract with your service provider? What has been your experience so far? How did you design the pricing definition in your IT Contract?

photo credit: Julia Manzerova via photopin cc

Can your IT Outsourcing Pricing Definition flex to the demands of your service?

A pricing model derives its elasticity from the scope of service being offered. The scope of services in turn derives its dimensions from the Application Portfolio for which the Outsourcing Services are designed. So how does one go about building this elasticity into a pricing strategy?

Best Practice #4: Your pricing definition has to be elastic to fit the various combinations of services across your portfolio.

elastic

Each Application Portfolio is unique. The service combinations across the usage of an application portfolio should be analysed keeping not only this in mind, but also the needs and spread of the user community.

If I had to summarize my approach to explore the elasticity demands of a service for an Application Portfolio, I would recommend the following steps. These steps are not necessarily sequential but rather iterative.

Step 1: Explore the dimensions of the Application Services

Analyse the dimensions which formulate the service. Typically these are the depth of the service, the hours of the service, the kind of service required, the days in which service is required, the regions of the world that have been supported, the languages being spoken etc.

Step 2: Analyse the parameters that define each dimension

Analyse the parameters that define each service – if you consider service time, check whether service is needed on holidays are not; check if the service distinguishes between regional and national holidays etc.

Step 3: Define the basic mode of service

After the above two steps, define the absolute basic mode of service across all the dimensions using the parameters. Establish this basic mode of service as the minimum scope definition. To continue our example, you might find that the basic mode of service is management of incidents from 9am-5pm on weekdays central European time. Feel free to include the IT Service Company you have or plan as a provider in the discussion.

Step 4: Design the add-on modes of service

Now study the service consumption across the regions, and user communities. Configure the rest of the parameters into add-on modes that make sense. In our example from above, you might find a community of users in Singapore and Thailand using a third of the applications in the portfolio. So you would design an add-on service that covers these working hours. These parameters would be additionally “turned on” for this part of the application portfolio.

Following the above steps would help you define a parameter & dimension system which will represent the elasticity you have in the service today. If these are now baked into the pricing model you have with your service provider, you will have a system that automatically ensures a close linkage between the ebbs and tides of your service and your pricing model. IT Outsourcing trends are also showing a movement away from traditional models into such elastic models.

Elasticity is only one of the areas you need to design into your pricing model. Refer to my previous posts on how to also design for scalability, transparence and encouragement of the right behaviour.

Next Post: Best Practice #5: Balance the risk. Stay in touch.

Is your current pricing model elastic? Have you defined the elasticity in the services that you require? Will your pricing model survive the duration of your contract?

Encourage the right behavior from your IT Outsourcing Service Provider

The long term success of your IT Outsourcing Contract and the accompanying Application Costing model lies in your ability to design it in a way that it encourages the right behavior from your IT Outsourcing Services provider. This is easier said than done.

In my previous posts, we have seen that an application management pricing model should be scalable, and transparent/granular.

Now we look at:

Best Practice #3: Encourage the right behavior from your service provider for Application Management.

220/365 [My name is Rubbish, Rubbish Bin]

 

Required behavior has to map directly to the interests of your Provider

  • Your Application Services pricing model should encourage the right behavior with a provider.
  • The right behavior can only be encouraged if you take the providers interest into consideration
  • You must consider that a providers interest is to either increase revenue or margin or both. The conclusion being that the only way to encourage the right behavior on the long term with a provider is to see that his interests are worked into the model.
  • You could argue and say that the right behavior can also be encouraged by strict SLAs and a penalization scheme. However if this is done in an unbalanced manner, this can backfire with other consequences. E.g. a strict SLAs on a ticket resolution time can encourage the provider to manipulate the system to see that the number of tickets increases and the percentage of easy to resolve tickets increases so that the SLAs are met.

Map the Outcome and not the Input

  • Be careful to interpret and express the behavior you want – this should be expressed as an output that should be achieved, and not the input that goes into the system.
  • Therefore develop your Application Services pricing model based on outcome-based metrics and not input metrics.
  • This might sound obvious and intuitive at first – but you will be amazed at how many contracts are based on ticket-based pricing models.

Ticket based pricing for Application Management can backfire

  • Ticket based pricing models sound attractive at first as it creates the illusion of a flexible outflow of cash as opposed to a fixed price contract.
  • But tickets are an input based metric – if you pay a provider based on the number of tickets he solves, you should not be surprised when the number of tickets in your operation increase or at least not reduce. Do not encourage the provider to increase tickets…..rather encourage him to reduce them.
  • Distinguish between effort drivers and outcomes – your pricing model will have to be mapped to effort drivers but do it in a way that you encourage the outcomes.
  • So this means let your provider baseline his efforts based on the number of tickets today, measure him by the reduction of tickets, reward him by giving him the opportunity to redirect any saved effort in other value adding activities – like new implementation efforts. Don’t let your provider lose revenue in this way – as you will pay on the long run anyway.

Have you implemented pricing models in your organization which encouraged the right behavior? Did they succeed or fail? And why?

 

Next –  Best Practice #4 : Your Application Services Pricing model should be elastic. Stay tuned!

In this series, see also:

Best Practice 1: How to design a scalable IT Outsourcing contract
Best Practice 2: How to design a transparent and granular Pricing model

 

photo credit: Jiuck via photopincc

Wordpress SEO Plugin by Wordpress SEO Plugin