Much has been said about outcomes recently. Indeed, many buyers seek to use Performance Based Contracts (PBCs) to contract for outcomes, because they are attracted by the simplicity of using a PBC. But this could be a costly mistake if you do not first carefully plan, set up and execute the requirements of your PBC.
Planning and correctly executing starts with defining what result, or outcome, you desire then evaluating the performance measures defined in the PBC specifically relating to input, outputs, and outcomes.
A PBC – being different from a conventional contract – is designed to reduce overall costs for buyers and provide profitable growth opportunities for sellers. We tend to view the PBC as the contract model of choice across a range of market sectors. The ability of organizations to effectively develop, implement and manage PBCs is critical to business success, because failure can often lead to long-term performance, financial and reputational damage.
The following two-part article explains how PBC contracting works and why focusing only on outcomes only is a mistake. Why is it critical for buyers and sellers to first identify and understand all inputs and outputs? Only then can they better define the overall outcome (success) as seen by the end customer.
The first step is to clarify whose outcome — the direct outcome of the trading (or partnering) relationship or the outcome as experienced by the final customer. Will your idea of a successful outcome vary with a change in perspective between – or among – various trading relationships?
To illustrate how an outcomes varies depending on your perspective picture your grocery store’s online ordering system. You select, order and have delivered a range of grocery items like fruits and vegetables.
Delivering your order requires a number of organisations each with individual roles and responsibilities, and a specific sequence as follows:
- Step 1 – End Customer (you) selecting groceries, defining the delivery date; paying the bill; and being home for the delivery.
- Step 2 – Information technology organisation ensuring the grocery ordering website, including the payment system, is available for the end customer, supermarket staff and transportation staff to document orders and deliveries.
- Step 3 – Grocery suppliers like farmers suppling all types of groceries to the supermarket based on the orders being placed to ensure there is sufficient stock available.
- Step 4 – Supermarket selecting the items you order online and loading them into containers for delivery. It’s ready to go!
- Step 5 – Transportation organisation taking groceries from the supermarket and delivering them to you.
Figure 1 shows the variety of organisation and their specific roles and responsibilities involved in delivering your order, in good condition, for the correct price at the agreed date / time, to you as the end customer.
As figure 1 illustrates, the process can be complicated, because many commercial organizations who are expected to get the groceries to you on time are not solely accountable for final success of that delivery to you the end customer. So, if you are contracting out the grocery transportation process, what is their outcome? Is it simply successfully delivering all groceries provided by the previous step, the Supermarket, in full and on-time without breakage? Or is it the end customer satisfaction, which may also depend on the farmers or the IT organisation? Which I right?
One method we use to help understand this difference in perspective is by describing the inputs and outcome to an individual organization, and then comparing to the end customer outcome. Here I use inputs and outputs to reflect the lower level organisation or process activities that as a total then make up the end customer outcome. Indeed, how all these inputs and outputs fit together to deliver the end customer outcome highlights the various interdependencies between the organisations.
One technique to help identify the relationship between inputs and outputs is to use consider using the Integration Definition for Function Modelling (IDEF0). Figure 2 describes a standard functional process block including four elements: inputs, output, mechanism (resource) and control.
Like other modelling approaches and tools the intent of IDEF0 is to provide a structured representation of the functions, activities or processes within the modelled system or subject area. Using the IDEF0 model, we can quickly identify whether we are measuring an input (something that enters the process) or an output (something that exits the process).
Let’s consider our grocery example again, and specifically the transportation organisation, which in this case we will contract out. Here, Figure 3 describes the input and outputs.
NOTE: Figures 2 and 3 correlate: Consumer law and Labour law represent Control; Packed grocery items and delivery represent input; Vehicle for delivery and delivery staff represent Mechanism (resource) and Grocery delivery is the outcome.
However, where is the outcome? More importantly, can the transportation contractor be held solely accountable for an end customer outcome? For example, if the Supermarket accidently packs oranges instead of apples, and these are delivered, who is at fault? All will agree that the end customer outcome has not been achieved, but where is the fault? Importantly, how do we treat this where there are commercial consequences, such as reduction in payment?
In the next article I will talk about one organisation’s response to this challenge by aligning both collective and individual requirements (i.e. the performance measures) with specific rewards and remedies (i.e. the consequences). In the interim, I look forward to hearing your thoughts on this very interesting topic.