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
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.
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?