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.
Now we look at:
Best Practice #3: Encourage the right behavior from your service provider for Application Management.
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: