The 5 Pillars of a successful Outsourcing Contract Pricing Model

Your organization is demanding more transparency in your Outsourcing operation and contract. The onus lies on your ability to study your operation and define your reasons for outsourcing. Then design a contract with your service provider in a way that you achieve the quality you need while forming a partnership with your service provider.
This post summarizes my last few posts of September and brings it together into the best practices that form the Five Pillars of an Outsourcing Contract Price model. The Five Pillars help you to model your operation into the pricing model – and can form the foundation and definition of your contract.

“STEER”ing your way to a successful Contract

The basis of a successful partnership with your service provider is a well-designed outsourcing contract. A successful contract stands the test of time if its pricing model is designed well. You can judge a pricing model by the way that it satisfies the following five best practices that I summarize with the acronym STEER (Scalable, Transparent, Encourage the Right Behaviour, Elastic, Risk-balanced):

5 Pillars Best Practice Outsourcing Contract

The 5 Pillars of a successful Outsourcing Contract Price Model

  • 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 contract.
  • 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

Has the STEER model helped you?

Are there parts of your existing contract that you want to change after reading these posts? What will you do differently the next time?

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?

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

Are IT Outsourcing Pricing models biased towards service providers?

Contemporary literature for pricing Outsourcing services addresses mostly the perspective of the provider 

Unfortunately contemporary literature on pricing of IT Outsourcing Application Management contracts largely deals with Application Pricing models from the perspective of a service provider:

  • Either they compare and contrast the the advantages and disadvantages of fixed price versus Time and Material models of pricing.
  • Or they advise on how to price to win – this takes the form of penetrative and skimming strategies. large_3881693277

Labor-based Pricing is unfortunately the norm Most commonly used pricing models (fixed price, time and material, volume based pricing) find their root in the labor costs of the provider. This is an input based pricing as each of these models are linked directly to effort drivers. These are the factors that go into the delivery of the services.

Environment-based Pricing is actually what you need

What CIOs actually need is a pricing that is based on the factors of their environment – and the ebb and tide in their environments. They need a way to transparently show the result of each change to the environment, and not each change to the input that the provider adds into the service.

This is the subtle difference – this is the difference between basing the price on the complexity of an application and its interfaces instead of only on the number of tickets that the provider has to solve.

So start encouraging the right behavior with your IT Outsourcing Provider The pricing model should encourage the right behavior. Creating a pricing model that is purely based on the effort drivers of a provider either unevenly balances the risk on each side, or removes the risk completely from the provider. The result: a service provider service provider has to take care of the inputs of the service instead of proactively trying to better the environment of the application.

As an example, ticket based pricing might appear attractive at first because of the variability of the price – but it might not encourage the right behavior in a provider who is paid based on the number of tickets they solve.  One would want to avoid a constantly increasing number of tickets – the first sign of a dissatisfied customer.

Is your IT Outsourcing Application Management Costing based on your environment and needs, or on the effort drivers of your provider?

See also:

The hidden inflexibility in IT Outsourcing contracts

Do standard application pricing models really cover today’s needs

photo credit: RHiNO NEAL via photopincc

Wordpress SEO Plugin by Wordpress SEO Plugin