Pricing

Software development pricing will usually be on a time & materials or a fixed price basis, or a combination of the two. Both methods require different contractual provisions;

Time and Materials
Time & materials development projects have less potential contractual pitfalls than fixed price projects, because contractually you charge for the costs you incur. However to ensure that time & materials development projects do not create risks that you didn’t anticipate, it is necessary to manage the risks in the following contractual areas.

• Time & materials with a “cap” on the time is a typical way for customers to try and limit the charges they pay, regardless of the charges you incur. Contracts of this nature should commit you to delivering a certain amount of effort, not commit you to completing a certain deliverable. Failure to do this leaves you in the worst possible situation – a commitment to deliver for a fixed price without building contingency into either your plan or price.
• Long-term time & materials projects or Framework/Call Off Agreements with rate tables attached should provide you with the contractual right to uplift your rates. These can either be open-ended increases, or, if your customers won’t agree, the increases can be tied to widely accepted indices that track IT employment cost increases.

Fixed Price
Fixed price development projects can result in tangible risks to the bottom line of your business unless the projects are tightly scoped and managed and sufficient contingency built into the project plans and the costs.

Many of the ways to contractually manage the risks of fixed price development are addressed elsewhere (see Projects and Bespoke Development Agreements) points below, additionally however, the contract should ring-fence work being provided for the fixed price and identify what it excludes (if anything) - for example, travel and accommodation expenses, third party software/kit that you will need to acquire on behalf of your client.

Milestone payments need to be tightly specified in the contract with no ambiguity when the milestone is delivered. For example, a milestone should be the point at which you notify your customer that a particular discrete part of the development has been completed or delivered. A milestone should not be signature of an acceptance certificate by the customer – they may never get around to doing that, and contractually your right to payment would never be triggered, leaving your business to spend wasted time trying to agree with the customer that you have met the obligations necessary to trigger the milestone payment.

Details of pricing considerations for Licence Agreements can be found in the Exploiting IT pages.