Home » Contract Types

As a customer or supplier of software services at the beginning of a Software Development Project, you know that there is too much at stake to work with just a verbal agreement. A contract is really just a set of written playing rules. The right rules increase the chance of success for both parties. The wrong rules make cooperation difficult and hinder progress.

Typically while forming a contract, customers need to look at:
1. How is the contract structured?
2. How does it handle changes in scope (requirements)?
3. How does it apportion Risk and Reward between customer and supplier?
4. What model of customer relationship does it foster: competitive (my win is your loss), cooperative (win-win), indifferent (I don’t care-you lose) or dependent (heads-I-win-tails-you lose)?

Dhoondho typically executes custom software projects as any one of the following types of contract: (we focus on a win-win senario in any contract)

Time and Materials

Structure: Work for a month, then send the customer an invoice. The customer takes the risk of the project.

Scope Changes: Not explicitly defined by the model.

Risk: Customer’s risk is limited to one week’s worth of development costs.

Relationship: Cooperative. Both the customer and the supplier have an incentive that each release be successful, so that additional funding will be approved.

Fixed Price / Fixed Scope

Structure: Agree on the deliverables, deliver it. Send a bill. Customers like fixed price projects because it gives them security.

Scope Changes: The change request game (correction: change request process) is intended to limit scope changes. This process is costly, and the changes are usually not preventable. Since the customer almost by definition wants more scope, ending the project can be difficult.

Risk: Obvious risk is on the side of the supplier. If the estimates are wrong, the project will lose money. Less obvious risks are the change request game, through which the supplier negotiates additional revenue through scope changes.

Relationship: Cooperative. Both the customer and the supplier have an incentive that each release be successful, so that additional funding will be approved.

Phased Development

Structure: Fund quarterly releases and approve additional funds after each successful release.

Scope Changes: Not explicitly defined by the model. Releases are in effect time boxed. The knowledge that there will be another release next quarter makes it easier to accept postponing a feature to achieve the time box.

Risk: Customer’s risk is limited to one quarter’s worth of development costs.

Relationship: Cooperative. Both the customer and the supplier have an incentive that each release be successful, so that additional funding will be approved.