What is outcome-based contracting?

Many of us have given at least some thought to outcome-based outsourcing or contracting. Whether in evaluated such a model as a buyer of services – or as an advisor or seller of services, designing a contract based on "outcomes" has certainly crossed our mind.

So, what is outcome-based contracting? 

Simply speaking, it's a means of contracting by which buyers of a service can measure sellers of a service by outcome – either a business outcome or some sort of milestones that measures project outcome progressively.

Let me caution you, however, that outcome does not necessarily means SLAs. SLAs are usually KPIs that measure performance not outcome.

The outsourcing industry – especially application outsourcing – has largely thrived on input-based contracting (e.g. Time and Material), fixed priced (“managed”) or in some cases via SLAs (performance indicators).

"SLAs are usually KPIs that measure performance not outcome."

There are several reasons why it has been difficult to adopt outcome-based contracting, especially in technology. These range from lack of historical baselines; to the inability to link service provider scope and performance to outcomes; to dependencies etc.

However, the good news is that contracting for DevOps allows for Outcome based contracting.

DevOps is a set of practices that builds on Agile to deliver IT work faster, with quality and stability. It is centered on optimizing deployment into production and enables continuous improvement.

The most fundamental shift while adopting DevOps is that teams focus on customer business outcomes, rather than their performance metrics (exactly the difference between SLAs and outcome-based contracts).

A brief adaptation of traditional contracting model vs DevOps contracting is shown below:

By defining such KPIs, IT departments can link their metrics to business outcomes. In fact, the impact of DevOps is felt not just in contracting but in service delivery and governance as well. If executed properly, it can result in higher satisfaction levels for provider services as determined by the following factors:

However, DevOps contracting comes with its own set of challenges that need to be addressed:

1. Outsourcing contracts can hinder DevOps – Existing outsourcing contracts generally tend to divide work between Development and Operations and engage separate vendors – which goes very much against the idea of DevOps
   
   
2. Lack of maturity and understanding – DevOps is still evolving to reach a critical scale and size. This means that, contractually, clients still engage with vendors in traditional format and DevOps may have to take a back seat.

As the industry evolves, we will see an increased adoption of DevOps-based contracting. It’s not rocket science but will require a shift in organizational structure and way of thinking.
Whoever does this faster will benefit.

The rest, as the saying goes, will be “Followers”.

Editor's note: we first raised outcome-based agreements six years ago: read Gavin Bowden-Hall's article here.

Join the discussion on LinkedIn

[inlinead]