Outcome based contracts and Pricing in Software Services

Outcome based contracts in software services are a little difficult to implement. One way that outcome based contracts can possibly be arrived at that benefits both the customer and the vendor is as follows:

Let the contract have two components - A fixed component and a variable component. The fixed component will guarantee payment of costs incurred (manpower, hw/sw, standard operations costs per head etc) no matter what the outcome. Here the vendor shouldn't add any margins. Thus, the vendor's expenditure is atleast guaranteed to be reimbursed for services delivered. This is the extent of risk (a no profit, no loss risk) that the vendor should pledge to take .

The variable component can be the outcome based contract. The outcomes that we would like to measure will be different for different types of projects and should be arrived at in conjunction with the customer. Again here, there can be two parts. Part 1 will contain a set of outcomes that the vendor will guarantee to deliver and if delivered will receive certain compensation. Part 2 will contain outcomes that are directly related to the business of the customer and will most likely be defined by the customer.

Part 1 outcomes will be in the realm of good software development. These should be defined in terms of features that the vendor will give as part of the application regardless of whether these features were defined in the requirements or not. These will be of the nature mentioned in the post http://sharathshenoy.blogspot.com/2008/02/supportability-transform-making-non.html
. This is the vendor guaranteeing to build good quality software.

Part 2 outcomes will typically be defined by the customer. These could be things like:

1. %age increase in sales (for an e-commerce site),
   no. of times a utility built is downloaded (such as the Vista widget that was built for Move),
2. time taken (this is not page response time, but the ease of use/lead time for business users to see new copy they created to go live) to upload content and get it live vs. how long it used to take earlier (for CMS projects),
3. reduction in application support costs, improvement in SLAs to fix issues, reduction in rate of bugs arrived (for application management projects) etc.

This is just the beginning of a thought, obviously this has to be detailed well and remove as much ambiguity as possible.