DOING BUSINESS BETTER. TOGETHER

The ‘Risk to Reward Factor’ for outsourcing providers

9 Oct 2009 12:00 AM | Anonymous

The ‘Risk to Reward Factor’ for outsourcing providers

Naturally, perhaps, customers have been previously more inclined to focus on the risk element - in terms of shifting risk on to their outsoucer; whilst service providers have been more interested in the reward and less interested in accepting risks over and above their standard model.This can lead to an ineffective standoff that is portrayed as a risk and reward arrangement but does little to drive the right behaviours by both sides. It is therefore imperative that the service provider changes this process and adopts a more co-operative stance to share risk with their customers in order to build confidence for a long term relationship. As organizations become more mature in managing their outsourcing partners they can start to move to Outcome Based Agreements (OBA), where suppliers are contracted to directly achieve business outcomes for and with the customer.

Many organisations often talk about building in risk and reward into their IT services or outsourcing relationships, but what does “risk and reward” really mean in practice and is there really such a thing as a genuine, balanced “risk and reward” offering?

Risk to Reward’ – What’s it all about?

Risk and reward can mean different things to many providers and their customers. At the simplest level, it can mean introducing a system of service performance. So, for example, an outsourcing provider may receive a bonus payment if they consistently exceed service performance over a defined period of time. Therefore the reward for an outsourcer could include a financial bonus for over performing.

Furthermore, the reward for over-performance could, alternatively, be the ability to off-set or earn-back previously incurred service credits. At a more collaborative level, the incentive could include a share of the improvement achieved or a percentage of the revenue achieved by the business. The risks, however, could include a penalty payment for underperforming such as not completing a project at a set deadline.

A successful Risk to Reward System

A successful risk-reward system is often based on projected revenue generation or cost savings and predefined Service Level Agreements (SLA’s).

The most obvious way of measuring performance for the purposes of service reward is against defined SLA agreements. Incentive mechanisms could also be linked to overall industry performance. Therefore the service provider could, for example, be rewarded with extra incentives if its performance in certain key measures over a defined period of time puts it in the top quartile of industry performance in that particular set of metrics. Alternatively, a customer may prefer to tie risk and reward to their monthly SLA measurements, key business events or overall customer satisfaction measures.

It's important to realise, however, that a critical success factor in a risk and reward system should be aligned with the business needs of the customer. The outsourcer, regardless of economic conditions, should be focussed on what gives true value or benefit to the customer. There is little point in penalising a service provider for failing to meet a response time service level in a non-critical area of the business or, conversely, rewarding a service provider for meeting a specific availability target if the target, whatever this may prove to be, has no material impact on the end-user's ability to function effectively.

In one very successful example of risk and reward the service provider offered to pay the customer the projected cost saving up front in cash and then got on with reaping the rewards by exceeding the original cost savings estimate. Nothing like ‘putting your money where your mouth is!’.

As an industry, IT Services is still fairly immature in its approach to Risk and reward. At a recent Customer Forum one of our banking customers was asking why Service Providers did not take a broader view of risk (as the banking industry does) and price their services by individual transaction rather than by Project e.g. a standard price for all SAP upgrades delivered in a factory mode rather than a different price for each individual customer. Certainly it is an interesting argument and one that service providers may migrate to if they had the same transaction volumes as banks.

Powered by Wild Apricot Membership Software