Why defining your Transformation collaboratively can be one of the best business decisions you could make

At the heart of your outsourcing contract is usually the desire to get a better service at a lower cost. However as this article on Outsourcing from Stephanie Overby rightly points out, “….the typical outsourcing contract contains a paragraph committing the parties to develop a plan for transformation — and that’s it”.

If you are in the midst of defining the goals of your transformation, you are likely to face the following questions:

  • Should I define the transformation in isolation, or do it along with the provider?
  • How do I reach the balance between being prescriptive (tell the provider what to do) and looking for a solution (ask him what to do)?


Photo courtesy: Lego

I have achieved my best results by collaboratively defining Transformation. This is one of the unique advantages of an outsourcing dialog.

Be clear about what you want to achieve

  • You should be clear about the business goals of your program – state it clearly so that there is no ambiguity. Avoid buzz words.
  • But do not land into a “paralysis of analysis” – broadly define what you want to achieve and welcome ideas on how others have achieved the same or similar goals

Tap into the experience of your outsourcing provider

  • Ask your potential providers where they have helped other providers achieve similar goals.
  • Your questions should follow this line of thought: “what were these goals, how were they defined, how were they achieved?”
  • The answers to the above questions make sure that you stay in the “fact-domain”.
  • Do not fall into the trap of asking the provider how to achieve your goals – if you do this, you are forcing him to put on his “sales cap”.
  • Assume positive intent. Help your provider to show their technical and operational expertise.

Adapt your transformation approach in an iterative manner

  • Translate what you are hearing to your own situation
  • Questions that you need to ask yourself when you hear something interesting – does it fit? Why does it not fit? Is your situation similar? What are the parallels between your situation and what you have just heard?
  • It need not be applicable in its original form. However, can you adapt it or take pieces of what you are hearing to improve your own approach?
  • As you continue to do this – formulate your approach in greater detail and tune it based on the above inputs.
  • Take a reality check – what were the goals that you had initially defined for yourself and how these have adjusted over time after your dialog with your service provider. Are you satisfied with the changes you made?

Service providers who specialize in transformation do this as a living – and they get to see these situations everyday in varying circumstances and combinations.

Instead of forcing your provider to specify how to achieve your goals early in the game, you should tap into their experience. It is easy to forget this in the heat of the dialog.

How are you defining your transformational approach? Are you doing it collaboratively?

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.


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

How to design a transparent Application Management Services pricing model

Best Practice 2: Your IT Outsourcing Contract should be transparent and granular – and this should show in the pricing model

Transparence and granularity in an Application Maintenance contract directly translates to a price per application. An ideal model goes further and prices the service depth required on the application.


Let’s look at transparency and granularity from various viewpoints to understand the needs of the design.

Viewpoint: Application Business owner

  • In the midst of signing a maintenance contract for an Application portfolio, the effect of the contract on an application should not be lost.
  • While a total price might make perfect business sense from the perspective of portfolio management, there are business owners who use and sponsor these applications. The pricing structure should be able to translate the costs and benefits of the entire portfolio bundling program to an individual application.
  • Else such an overall program could be stalled by the business department which feels that the costs to its applications have not been correctly allotted.

Viewpoint: Application Maintenance Contract Manager

  • A granular pricing structure – which means applications are either priced individually or according to a scheme that is laid down – greatly eases the job of a contract manager.
  • Granularity should go beyond just price for application and also model the various ebbs and tides that the service could take. Explore all the dimensions of your service whether it is service depth or service time e.g. some applications might need only level 2 support, other applications might need 24/7 support.
  • The more granular your model, the less discussion the contract manager would have while discussing portfolio changes during the contract duration.

Viewpoint: IT Procurement

  • Valuable procurement bandwidth can be saved if all service conditions are laid clear and separately priced in the form of factors.
  • Procurement can then concentrate on the larger ticket items and leave the management of the pricing to the contract manager of the application portfolio.

Viewpoint: CIO

  • A CIO will normally highlight the overall savings that have been achieved through the clustering of applications into an overall application portfolio.
  • However, he also has to demonstrate these savings to individual business departments – and showcase the overall benefit that they have achieved by taking part in the clustering program. He needs their support.
  • A transparent and granular pricing system serves such a cost allocation in a seamless manner. No more clumsy Excel sheets as an after-thought.

Effort put ahead of the curve in defining a transparent and granular pricing system, calibrating your application portfolio against it, and signing contracts based on this pricing system will go a long way in keeping the contract and change management smooth and frictionless.

Next –  Best Practice 3 : Encourage the right Behavior – stay tuned!


In this series, see also:

Best Practice 1: How to design a scalable IT Outsourcing contract

For a background of this topic, see:

The hidden inflexibility in IT Outsourcing Contracts
Are outsourcing pricing models skewed towards service provider needs
Do Standard Application Pricing Models really cover today’s needs?

photo credit: marcomagrini via photopincc

How to design a scalable IT Outsourcing Contract

Your IT Outsourcing Contract and the accompanying Application Costing model should accommodate any change to the application portfolio over the duration of the service contract.


Design your IT Outsourcing Contract for Scalability by following these four main practices:

Allow for new portfolio entrants
    • An application portfolio is never steady state – it is under constant churn. Applications enter and leave a contract due to multiple reasons.
    • A predominant driver of such churn is the lifecycle of the applications – when
    • IT Make or Buy decisions can also lead to applications retiring or new ones entering a portfolio.
    • Design your model so that it scales not only with the size of the application portfolio but also with the individual nature of the applications – an application that today is serving only the users in the UK might tomorrow serve users in Asia Pacific. You should not be in a situation where you renegotiate the costs for with each such change.


Follow the Demand Curve
  • Design your contract so that the costs follow the curve of demand
  • Demand can come in multiple forms – in terms of time, services rendered, support required (additional hand-holding), and reaction time
  • Your negotiated costing model should flex with the demand enforced upon it.


Facilitate What-if scenarios
  • Go beyond following the demand curve – you should be able to predict its impact.
  • The demand on an application often depends on the costs of the impact of the demand. The change in costs of running an application in reaction to business circumstances should be pre-designed.
  • Make these changes easy to calculate – so that the model lends itself to developing what-if scenarios and the business cases of such changes.
Ride over the spurts of additional support
  • Scalability should also lend itself to temporary and foreseeable bouts of spurts in support required.
  • Discuss and negotiate the costs for such spurts. This prepares both sides – the IT service provider is aware that such an event could occur and at least prepares for emergencies in the operating model. Your IT team budgets for occasional spurts in costs.

In summary: Discuss and negotiate a scalable contract so that it gives peace of mind to both your IT team and the service provider. It avoids unnecessary friction during the management of the service contract.

Is your current IT Outsourcing Contract scalable? What are the dimensions influencing your scalability?


photo credit: tricky (rick harrison) via photopincc

Wordpress SEO Plugin by Wordpress SEO Plugin