Outcome based outsourcing, it’s the double black-diamond ski run of outsourcing, amazing if you nail it, but screw it up and you’ll be in a world of pain. So how do you successfully implement one of the hardest outsourcing models to achieve the promised benefits without breaking any bones?
If you are in a hurry skip this whole article and take away these two points, or read on for why they matter and how to do it right:
- Culture, culture, culture. The best outcome based commercial construct in the world is useless if your culture doesn’t support it.
- One size does not fit all. Everyone will have a different view of what outcome they want, so you need a flexible spectrum of outcomes.
But hopefully reading my articles is part of the fun, so grab a coffee, or a glass of wine (that way you’ll be in the same mindset I am when I write them) and read on to find out why these points are key.
What is Outcome Based Outsourcing?
I typically don’t spend time explaining what a concept it, preferring to focus on what it can be used for, but it’s important to differentiate outcome based outsourcing from other forms of outsourcing.
Outsourcing models can be viewed as a spectrum, there aren’t separate defined models, rather a gradual spectrum along which you can operate. On one end is input based, in which the customer defines what inputs will be used to deliver, at the other end is outcome based in which the customer provides the vision of the outcome they want to achieve, and the outsourcer works out how to achieve it. How about some examples to explain that in plain English:
Technology Example:
A government department that manages public housing has a large software application that needs constant updating to meet changing business rules. They decide to outsource the application updating.
Input Based: Provide the following resources, qualified to the associated level, at our office from the hours of 8:30am-5pm Mon-Fri. Provide hourly rates and CVs for proposed resources.
1 x Oracle Integration Architect, TOGAF qualified, ITIL V3
5 x Oracle Developers, qualified in E-Business Suite version 12.1.
2 x Oracle Testers
Outcome Based: Manage our business application to deliver 80% of business rule changes within 10 working days, and to achieve a customer satisfaction rating of >75%, and reduce application TCO by 3% each year.
Public Transport Example:
A City is seeking a company to run their bus network.
Input based: Provide fleet of no less than 75 vehicles, with up to 100 available within 48 hours notice. Bus drivers must have at least 2 years of clear driving record. Bus specifications must be 50+ seat bus, diesel powered, dual entry doors, rated to EEC 99/199 standard, and no more 8 years old. Pricing to be based on driver hours and bus mileage.
Outcome based: Achieve a public transport usage of >37%, a reduction in inner-city car traffic by 4% per annum, maintain operating costs at current budget for next 5 years.
Hopefully that’s painted a fairly clear difference between the two ends of the spectrum. One tells the provider exactly how to deliver, the other tells them what the customer wants to achieve and leaves the what and how up to the provider.
Why use Outcome Based Outsourcing?
Wouldn’t it be best to be crystal clear with your provider and tell them exactly what you want, that way there’s no confusion and everyone gets what they want? Then you can easily compare providers and simply select the lowest cost one.
Ask yourself, do you know more about how to do the thing you are outsourcing than the providers? If you really do then perhaps you shouldn’t be outsourcing it. If your business is the best at doing the task then don’t outsource it, make it a competitive advantage and a core competency.
However, it is highly unlikely that a City knows how to run a bus network better than companies that do it in dozens of cities around the world. Or that a government department that provides housing to low income people knows how to develop Oracle applications better than any IT company.
When I hire a painter to paint my house I don’t tell him how to prepare it, what sandpaper to use, where to put his ladder, how long to let the paint dry between coats. I just tell him what colour I want and that the outcome I would like, which could be either:
- Slap some paint on it so I can sell it quick, do it cheap.
- Ensure that my home wont leak and the paint job will last at least 10 years.
I can ask my painter what paint they plan to use, then google it as we do, and suggest a longer-lasting or lower cost option to help align it to my outcomes, but ultimately I’m hiring a professional that knows far more about house painting than I do. So I should trust him (or her) to select the best paint to meet my outcome.
What would happen if I hired a painter on an input based model? The cost of painting the house would go up dramatically, would take longer, and the paint would probably fall off in the next rain storm. Why? Because I would be forcing the painter to do things in a sub optimal way, and perhaps to even do the wrong things. The painter has been painting houses for years and knows which paints work best, how much prep is really needed, how to best reach those high spots, and what combination of brushes/roller/spray-guns to use. What do I know about painting a house?
This is the reason that outcome based outsourcing is the desired model, it allows the expert that you hire to deliver the outcome in the most optimal way, leveraging all their experience, knowledge and resources to achieve your outcome.
Sounds good? Unfortunately it’s not that easy.
Five Keys to an Outcome Based Success
As you can see, an outcome based model should deliver far greater benefits than a traditional input based outsource, unfortunately it’s not that easy to successfully implement one. The five keys to making outcome based outsourcing successful are:
- Vision: A clear vision for what the desired future for the customer looks like, and therefore what the contract should aim to achieve.
- Outcomes: Clear definitions of the outcomes required to support this vision.
- Incentives: A simple pricing model that enables a focus on the outcomes.
- Culture: A culture shift to support an outcome based relationship, with a focus on trust and transparency.
- Evolution: Regular, open reviews of the progress towards the vision, supported by a commercial model that allows course corrections where needed.
I call this the VOICE model (sorry there’s no clever pun here, it just happens to spell VOICE). Let’s walk through each of those five items:
1. Vision
Before any work is done on defining the outcomes to be delivered, the vision of what customer’s desired future looks like must be defined. It sounds fluffy but it’s vital. The next step of defining outcomes is the hardest part, so unless you are clear about what you are trying to achieve you are likely to come up with the wrong outcomes.
Using the example of painting my house, the vision sets the tone for the outcomes, for example:
“Ten years from now my home still looks brand new and I have spent my weekends playing golf.”
What has this got to do with contracting someone to paint your house? Well it defines the future you want to achieve by having the house painted – in this case I want a paint job that lasts at least 10 years, and I don’t want to be spending my weekends maintaining that paint job. This helps directly inform the outcomes.
Let’s use an IT context now, based on the earlier example of the government housing provider looking for application support their vision might be:
“By 2025 over 98% of citizens will be in warm, safe housing. We have achieved this by rapidly adjusting to changes in housing demand and stock, and by making it simple and easy for citizens to get into and out of social housing.”
Again, this sets the context for the outcomes, it points to flexibility, rapid changes, and a customer experience focus.
2. Outcomes
Outcome based outsourcing is a highly ambiguous term and can often lead to confusion and missed expectations. Without a clear definition of what the outcomes are, and why they are required, peoples’ own perceptions and roles will create a wide disparity in what the expected outcomes are.
For example, a Service Desk manager might want an outcome focused on the resolution of incidents on first call. An infrastructure manager might want an outcome based on the health of servers measured by patch status, CPU load and uptime. A developer might want an outcome to be the availability of a new test environment within a certain timeframe. A business process owner might want an outcome focused on the availability and performance of a key business application. A business unit owner might want an outcome based on the time it takes for a business process to be completed and the accuracy of the process.
On top of all this, an executive may want an outcome focused on reduction of operating costs, improvement in customer satisfaction, and time to market for new services.
All of these different outcome expectations occur because there are multiple layers in the outcome stack, and depending upon where the engagement takes place the outcomes will vary widely. This is shown in the diagram below (this is a very IT System focused example):
All of these are valid outcomes and can be contracted, however it is vital that the outcomes align throughout the business stack. If an outcome is agreed at the application level, then it should be measured against application based metrics, and there should not be conflicting outcomes further down the stack such as a server health outcome. This double up of outcomes would lead to a restriction in the way the application outcome is achieved.
For example, if an application outcome is agreed for a common application such as email, then it is over to the outsourcer to manage all the components underneath the provision of email in the best way the outsourcer sees fit to achieve the outcome. The customer has entrusted the outsourcer to provide an email outcome and therefore should not question how the outsourcer is managing the CPU utilisation of the servers that the email application sits on. Having a conflicting outcome of “healthy servers” that has a KPI of a maximum CPU utilisation of 70% may conflict with best practice for running an email system, which may recommend a 90% maximum load on servers due to the peaky nature of email. This would mean that due to conflicting outcomes, the outsourcer is forced to run a sub-optimal platform beneath the email system, driving up the cost of the email outcome and delivering a poor result for both the customer and the outsourcer.
The Challenge of Transparency
When you outsource an outcome and trust the outsourcer to deliver it the way that they see fit, this brings into question the matter of transparency. How do you know that their way of delivering the outcome aligns with your view of the world? This is explained in this example of outsourcing the painting of your house:
The outcome of the house painting contract may be that “the house appears to be well painted at all times”, and this is measured by KPIs based on no flaking or peeling being visible and the overall cost to keep the house painted. It is therefore up to the painting outsourcer to determine how often to paint, what paint to use, how many coats to apply, and how much preparation to undertake. It may be that the outsourcer decides to delay painting to two coats once every 10 years instead of single coat every 5 years, this could provide a clear benefit in cost reduction and still meets the KPIs.
However, by delaying the painting to every 10 years it is slowly creating unseen rot on the house, which over a 15-year period degrades the integrity of the weatherboards resulting in expensive repair work for the customer. The outsourcer would argue that they have been fully within their KPIs, but the customer would argue that if they had painted every 5 years the house would not have needed repair. Who is right?
The customer can’t agree to pay a fixed amount for a house painting outcome, and then determine how often the house gets painted, that is unfair on the outsourcer, yet the outsourcer shouldn’t make a decision that shortens the life of the house without consulting the customer.
The solution to this challenge is not an easy one, and it requires a culture and set of principles that both parties operate under. This is a culture that drives and rewards mutually beneficial outcomes, allows both parties to lift the lid on how outcomes are delivered, and provide feedback, but ultimately leaves the outsourcer to determine the best way to deliver the outcome. Conversely it is a culture in which the outsourcer has the customer’s best interests at heart, and understands what those interests are. For example, do they want to minimise the costs of painting or maximise the life of the house?
One Size Does Not Fit All
Another factor in defining outcomes is that different parts of a customer’s business will want outcomes at different levels in the outcome stack. For a commodity such as email it may be best to have the outcome at the application level, with the customer only interested in email availability and security. But for more bespoke and line of business specific systems, such as those that run a factory automation system it may be more appropriate to have the outcome at the platform or operational level, leaving the customer to manage the application.
This mixing of outcome levels will work so long as there is clarity on the systems being provided and where in the outcome stack each system sits in terms of outcomes. For example, if email is at the application layer but factory automation is at the physical layer, the KPIs that apply to the physical outcomes agreed for factory automation cannot be enforced upon the physical equipment used to deliver email.
This concept is illustrated in the diagram below (using an IT systems example), and shows that over time there should also be a concerted effort to continually lift the level of outcome as the level of trust and culture matures to enable it.
3. Incentives
Having defined the outcomes, it is then vital to align these to how the outsourcer gets paid. Traditional thinking states that it would be pointless, if not destructive, to have an outcome focused on customer satisfaction, and a charging model based on FTEs. The two need to align. Or do they?
This is where the wheels often fall off. While it is fairly easy to create a payment metric around an outcome, Customer Satisfaction for example is a measurable item that can be used to calculate a payment scheme, it is often harder to agree on a metric that is fully under the control of the outsourcer. Customer Satisfaction will be impacted by the performance and availability of the IT systems provided by the outsourcer, but it will be impacted to an even greater degree by the customer’s services and products, which have nothing to do with the outsourcer.
This has been the single biggest issue with outcome based outsourcing, the inability to define meaningful metrics that measure the outcome the customer wants, but are within the outsourcer’s sphere of influence. As a result, one of two things typically happens:
- many outcome based contracts end up being based on traditional input based metrics such as number of FTEs, number of things being managed, and/or the number of incidents. This completely destroys the outcome based model and drives traditional behaviour, or
- an outcome based metric is used, and when the outcomes aren’t met an argument begins around who was to blame, was it the outsourcer’s fault, or was it something in the customer’s domain? The relationship becomes hostile and either ends or gets moved back to traditional outsourcing.
So how do we fix this? How do we set meaningful, fair, measurable payment metrics for the outsourcer? The answer is simple, you don’t need to.
Incentives reduce Performance
Over the past decade a lot of research has gone into the relationship between incentives and performance when dealing with complex tasks. The common finding from all the research is that the more complex the task, the greater the negative impact of an incentive scheme. Read that again, if someone is doing a complex task, an incentive scheme will lower their performance. This goes against everything we have known to be true for decades, but it makes good sense.
In a complex task environment, the focus should be on how to achieve the task (or outcome), but when people (and outsourcers are just organisations of people) have the distraction of “how will this action impact my incentive?” it gets in the way of thinking about the task.
Rewards do not create a lasting commitment. They merely, and temporarily, change what we do.
There are two very good articles on this concept that I highly recommend:
Why Incentive Plans Cannot Work, by Alfie Kohn – HBR: September–October 1993 Issue (https://hbr.org/1993/09/why-incentive-plans-cannot-work)
Is Incentive Compensation a True Motivator? by Donald Delves – Forbes: Feb 2011(https://www.forbes.com/sites/donalddelves/2011/02/16/is-incentive-compensation-a-true-motivator/#175f678d7904)
Don’t pay the Outsourcer for producing Outcomes
This sounds like the most stupid idea since “don’t pay sales people for selling”, but it is the key to making outcome based outsourcing work. Benchmark the cost of producing the outcomes, and pay a fixed fee based on that. You can agree that the outsourcer will provide it for x% less than the benchmark, or that the price will fall by x% every year, these will ensure you are getting a competitive deal, but don’t use the fees as the motivation for delivery.
By making the fees stable over a long term you give the outsourcer room to invest in long term improvements. They know they have certainty of income which allows them to invest in tools, research and development, process improvement, and staff development to better deliver the outcomes for you.
If it doesn’t work for employees, it won’t work for an outsourcer.
Would you pay your own internal finance team based on an outcome of increased sales revenue? Would they be happy to put their salaries at risk based on that metric? No, there are too many factors outside the control of your finance department to make that a fair measure. Are your products attractive, are your sales people any good, does the market need your product? Finance can’t control these things so you can’t pay their salaries based on it. Yet we might think that if we outsource our finance department it would make sense to pay the outsourcer based on an outcome of increased sales revenue. If it doesn’t work for employees, it won’t work for an outsourcer.
It’s still important to measure outcomes
Just because you shouldn’t pay the outsourcer based on outcomes, doesn’t mean you shouldn’t measure the outcomes. However, the achievement of outcomes becomes a joint goal for you and the outsourcer, something you work as a team to achieve. If they are missed you jointly and openly look for reasons why and work together to improve. When they are exceeded you celebrate together.
This feeds the Cycle of Success – when outcomes are meet or exceeded the customer should be successful. This leads to growth in the customer’s business, and longevity of relationship. Which leads to a healthy, stable income for the outsourcer. Enabling investment by the outsourcer, which produces better outcomes.
Use Intrinsic Motivation to delivering Outcomes
If you get the culture right, and enable the outsourcer to influence the success of the outcomes, they will naturally strive to deliver the outcomes. If you don’t believe they will, then either they are the wrong partner, or you are not ready for outcome based outsourcing.
Which leads us to Culture.
4. Culture
If you are going to outsource an outcome then you must have faith in the partner you are outsourcing to. If you don’t believe that they have your interests at heart then don’t use outcome based outsourcing, or don’t use that provider. If you must use a provider that you don’t trust, use a more traditional input-based model.
Trust doesn’t usually get given by default, nor does it get established during a formal RFP process. To create trust between the customer and the outsourcer requires high levels of interaction in an open and supportive environment. Given that outcome based outsourcing is not a simple and straightforward thing to achieve, a good way to approach it, and to build a level of trust is through the use of Design Thinking.
By all means, use an RFP process to select your partner, but leave the outcome definition until you have a partner selected, and then use Design Thinking to work together with your partner on the outcome definitions.
A Culture of Empowerment
Under traditional input based outsourcing, the customer often specifies the tools and processes that must be used by the outsourcer. At first this may seem to drive cost efficiencies by requiring the outsourcer to use pre-existing tools and processes, thus removing the cost of additional tools and integration between the customer and providers processes. However, it blocks the ability of the outsourcer to use their own best practice, to optimise how things are done, and to bring innovation, all of which would normally result in far greater cost efficiencies.
In an outcome-based contract, the outsourcer is given far greater control over how the services are provided – including methodologies, tools and locations – so that they can adapt their service delivery models as appropriate to achieve optimal outcomes. This is reflected in less focus in the contract on input-based specifications and definition of service delivery processes.
Relinquishment of control requires a culture change for customers, and can be a challenge for many organisations (and people) whose natural tendency is to micro-manage service delivery.
6. Evolution
We should not simply convert the deliverables of today into an outcome based contract. With the ever increasing pace of change, by the time the contract is implemented today’s deliverables will already be outdated. Therefore, you should construct the services around what the customer will need in 6-12 months, and even more importantly, embed into the agreement the flexibility for ongoing evolution.
The more the relationship can be based on a vision and high-level principles, the more flexibility it will have. If you allow the contract to become specific around the services required at day one, it will hold both parties back.
One of the key issues many outsourcing contracts face is the lack of service evolution and innovation delivered by the outsourcer, and enabled by the customer. This is not to put the blame on either party, but to say that traditional agreements, and more importantly a transactional customer/vendor culture doesn’t support innovation or evolution of services. Too much focus is placed on what the contract states, rather than what the relationship intends.
Summary
Outcome based outsourcing isn’t simply a change in contract, or a new way of writing service schedules, it is a cultural shift that requires a fresh set of thinking.
This was intended to be a quick article, just two pages, but the topic isn’t a simple one to explain, and even with the rather lengthy article I’ve written I’ve only just scratched the surface. So to summarise it and bring it to a close, here are the five keys to outcome based outsourcing:
- Vision: A clear vision for what the desired future for the customer looks like, and therefore what the contract should aim to achieve.
- Outcomes: Clear definitions of the outcomes required to support this vision.
- Incentives: A simple pricing model that enables a focus on the outcomes.
- Culture: A culture shift to support an outcome based relationship, with a focus on trust and transparency.
- Evolution: Regular, open reviews of the progress towards the vision, supported by a commercial model that allows course corrections where needed.
In Plain English 