Follow me on Twitter

Thursday, 5 January 2012

Outcome-based Contracts are NOT the same as solutioning

I've been told many times that outcome based contracts, such as flying hours, power by the hour, availability etc. are actually solutions-based contracts. (more on outcome based contracts at my previous blogpost here)

It's not.... so I thought l'll blog about the difference. Much of these insights come from my research in OBC so if you want the papers, check out my academic site

1. Diferent capability. Ability to achieve outcomes on Outcome based contracts means a capability to co-create, partner, collaborate and work together with your customer (see blogpost on value co-creation). That means you recognise that you need to keep your customers engaged and working with you and you develop your capability to do that. Solutions imply a passive customer. When you deliver 'a solution' it implies you do everything, and everything is under your control and the customer stays as a passive 'consumer'. Companies that don't really know how to collaborate, co-create and partner often prefer solutioning. Why? Because they want everything under their control. Co-creating and partnering is hard because they lose control. The ability to achieve outcomes on OBC is therefore a different capability from solutions. It's a capability of managing customer autonomy and complexity.

2. Different system. The system of solutioning is complicated. The system of achieving outcomes is complex. Complicated systems often means there is a central 'command and control' to achieve a solution. Complex means parties are autonomous and collaborating to achieve an outcome (see blog post on complicated vs complex). Complicated systems are based on reductionistic engineering science. Complex systems are based on holistic and systems science. Two completely different ways of understanding, viewing and analysing the system. Complicated systems are usually closed systems where anything outside comes into the system through designed and pre-specified conduits for inputs and outputs and predetermined 'touchpoints'. Complex systems are usually open systems where, because of autonomy, allows for a freer flow of people and information. I must stress that there are often closed complicated-type systems within complex systems so the distinction is a logical one, rather than a physical difference. We have inherited a world where often managers use reductionistic science to carve out the 'problem space' and solve it in isolation which can create more complexity from unintended consequences elsewhere in the system so its hard to tell the line between complicated and complex (there usually isn't one).

3. Paradox of solutioning is that the more you provide 'solutions' and relegate your customer to a passive role, the harder it is for you to please your customer. The logic is that an engaged customer is a happy customer because you respect their autonomy and yet able to manage the cooperation. Wanting your customer to be passive is like wanting your child to be passive and you provide everything for a child. it usually doesn't make for happy children.

4. Sometimes more expensive. Solutioning is sometimes more expensive than OBC. Why? Because to provide the 'solution' a provider need to price resources where ideally, some of these resources should not be provided by the provider but by the customer, because the customer, at the use end, has more updated information. For example, say you provide a security service for a house. If your customer wants 'incident-free' as an outcome, it goes beyond just patrolling the grounds or cctvs. It is also knowing when there may be a particular event in the house (e.g. a celebrity visit) where the event could attract security incidents. Your customer knows it but you may not. Not knowing it may make it costly for you as you need to overprovide or be overly cautious. If the customer is also responsible for the risk, the total cost of the outcome may come down. Of course, OBC could also be more expensive sometimes because of cost of cooperation/engagement. Hey, its a capability right? It's not meant to be easy.

5. Complex outcomes vs functional complicated outcomes. Some outcomes are impossible to be 'solutioned'. For example, if you may be able to provide the 'solution' of constructing a 'village' (build houses, townhall, parks, roads etc.), but you can never provide a 'community'. that can only be co-created. Similarly, many emergent properties of systems e.g. family, experience are co-created and not 'solutioned'. So if you are outsourcing a service of your firm be very careful what outcome you are outsourcing.  I see firms specifying functions to be outsourced and then becoming very unhappy because they got the outcomes wrong. Its easily to think the world is about functions. Often the outcomes we want are complex outcomes and not complicated functional outcomes. Specifying only the complicated functional outcomes for outsourcing is the most common problem I encounter because it underestimates the full outcome of the 'outsourced' element and reduces it to only a function when that element was achieving more complex outcomes before it was outsourced (and when it was part of an internal division).

6. Variety. Solutions and reductionistic engineering science in systems are really useful when there isn't much variety in the system i.e. in the context of customer 'use' of your service, there aren't many anomalies e.g. the experience of a flight. In such cases, a fully systematic system could be put in place where almost every contingency have been covered. When you have a customer in an enclosed cabin, there isn't really much else s/he needs except sleep, eat, drink, entertain (which is why I always think they dont want to give us internet access). In systems where customer 'use' of a service could have high variety e.g. a resort hotel, trying to 'command and control' the experience could end up with the customer disengaged. Be careful how you try to limit variety because not only do you end up not co-creating value, you engineer a disengaged customer. 'Variety' is double edged. It means more work for you but also an opportunity to create a better experience.

So in short, outcome-based systems are not 'solutioning' systems!

-- Posted from my iPhone


  1. Professor Ng,

    Your post looks very interesting and I will devote more time to reading it but wanted to provide some quick feedback.

    Whoever described "outcome-based contracts" being defined by "flying hours, power by the hour, availability etc." was wrong. These types of metrics are not outcomes. Instead, they are outputs. Outputs can be a means to enable outcomes.

    Outcomes are focused on enabling people, teams, communities, organizations, and/or enterprises to be more effective and/or efficient. The achievement of these outcomes are defined by key performance indicators (KPI).

    Lastly, in terms of this quick feedback, solutions are not defined by the degree of customer engagement and collaboration. Solutions do enable the achievement of repetitive process outcomes; they solve problems. A solution's development, depending on the solution's objectives, scope, and functionality, may involve collaboration with the customer but as far as the definition of a solution, that is not a pre-requisite or defining characteristic.

    A great example of a consumer multimedia solution, now being increasingly adopted as an enterprise solution that did not involve collaboration with the customer, is Apple's iPhone.

    More to follow ....

  2. Hello Sanchez

    Tks for the feedback. The difference between outcomes and outputs/performance is addressed in this blog in another post at

    and the following papers:

    Ng, Irene C.L., Roger Maull and Nick Yip, (2009) “Outcome-based Contracts as a driver for Systems thinking and Service-Dominant Logic in Service Science: Evidence from the Defence industry”, European Management Journal, Vol. 27, No. 6, pp377-387

    outcomes are usually a consequence of use.

    The apple iPhone for example, only achieve outcomes when co-creating use value with the customer. it is a platform for a solution. the outcome is a phone call, which, at use, must include the customer in co-creating that value. for more on value co-creation, also extensively written about from an SDLogic perspective and in this blog, is at

    Outputs are defined as outputs from performance or activities. They are defined differently and are often a result of linear or sequential activities or processes (e.g. supply chain performance). Hope this clarifies.


  3. With 'solutioning' or push-type service delivery, the assumed passive role of the customer makes it very easy to ignore the customer's real needs cf. lots of material from John Seddon and others. The assumption of co-creation means the supplier actually has an active interest in real user needs. Also avoids the costs of failure demand.

  4. the content in your site is really helpful. I am definitely going to use it.