Mutual Benefit Contracts

This post is in response to a question about contracts in a comment to my article The Customer Drives the Car.

The text is an excerpt from a book I am writing about Clarity, a software development method based on systems thinking. This book is on the back burner at the moment. 

I am currently writing a book about strategy and organization with Strategic Navigation. This book will stand on its own, but it will also provide a much needed framework for the Clarity book. The reason is that originally, Clarity, like other agile methodologies, took a bottoms up approach to methodology development. Partly because of my work on Clarity, partly because of my involvement with The Theory Of constraints, Strategic Navigation, and Systems Thinking, I have become convinced that a top down approach will work better. Therefore, Clarity will be redesigned, and thoroughly tested, before I publish a book about the method as a whole.

Here is Clarity's (current) take on contracts:

A contract is an agreement to take on certain responsibilities, or to do things a certain way. All projects have contracts. Individuals in an open source development team usually have an unwritten and implicit social contract. Business partners usually have a formal, written and legally binding contract. Clarity has a few recommendations for the latter kind.

Zero Sum Game Contracts
When playing the software development game as a zero sum game, it is very hard to trust your business partners. After all, the rules of the game say that whatever one party wins has to come from what some other party puts on the table.

There is no reason for the parties to trust each other. Therefore, contracts are used as a replacement for trust. Such contracts contain a lot of information about the terrible woes that will befall deal breakers. Usually they also contain rules for how risk is going to be divided.
 
There are basically two variants. In a fixed price contract the vendor takes the risk. In a time-and-materials contract, the customer takes the risk.

Because the basic assumption is that the project has a fixed value the customer will quite naturally try to get as much functionality as possible per dollar, and the vendor will try to do as little as possible per dollar. Both of these strategies increase the risk that the project will fail to yield the maximum possible return on investment.

Clarity views a contract as a framework for building a relationship based on mutual benefit. The game is set up so that the parties have a common goal. Both parties win, or both parties loose. Such contracts engender trust and cooperation.

Business Practices
An important point about the mutual benefit contracts described below is that they all have negotiable scope. If the scope can’t be negotiated, there is no point to prioritizing stories. There are no less important stories that can be cut out of a delivery if need should be.

This section provides a brief overview of contract types only. For more a more in-depth treatment of mutual benefit contracts, I recommend Lean Software Development[16] and Implementing Lean Software Development[15], both by Mary and Tom Poppendieck.

Clarity does not govern in any way which types of contracts you use. The recommendation though, is that you go for mutual benefit and trust between you and your customer.

Shared Benefit Contracts
One way to engender trust is with shared benefit contracts. The parties share the development costs, and they also share the profits generated by the product. Such contracts are suitable when building a pay-per-use web site or service. In other situations, for example when building a billing system, or a free web site, the economic worth is harder to assess, and this form of contract is hard to use.

Multistage Contracts
Multistage contracts are useful in many situations. Let’s say a job is expected to take six months. The vendor might make six monthly deliveries, getting paid a fixed price after each one. This reduces risk for both vendor and customer. The investment per stage is only a sixth of the entire project cost, so the customer does not risk as much. If things should go very awry with the customer relations, the vendor can also terminate after each month. There is no risk for either party of getting trapped in an eighteen month project from Hell.

It is fairly common for customers to order more functionality, in more increments than originally agreed. This offsets the risk of loosing a contract half-way through now and then.

Target Schedule Contracts
A target schedule contract sets a fixed final delivery date. With a target schedule contract, the development team can add resources and reduce scope to meet the final delivery date. The customer knows from the outset when the product will be ready, but not how much it will cost. The most important features are worked on and delivered first. It is important to make small releases, and see to it that they are actually deployed each time, or the delivery date may slip due to unforeseen problems.

Target Cost Contracts
A target cost contract has fixed cost, but leaves the scope negotiable. It is very important that the most valuable features are worked on and delivered first. A target cost contract may induce the customer to cram extra features into the application once development is under way. This is usually handled by having a clause in the contract that triggers negotiations about equitable cost sharing if the actual cost is significantly different from the target cost.
Vendor incentive is often provided by giving the vendor a bonus if the project
is completed below the target cost.

Comments

Good info article... thanks for sharing this info.

Popular posts from this blog

Waterfall - The Dark Age of Software Development Has Returned!

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Interlude: The Cost of Agile