IT Contracts – part 2

By using agile approach to running the project under fixed price contract, we gain tremendous flexibility in terms of changing requirements and priorities. On the other hand, this causes problems on how to define the criteria for acceptance of the final product in the contract, especially if we want to outsource the work to an external company such as, for example, FP. These problems are connected with agile methods from the very beginning and, to date, we could not find the perfect solution. Nevertheless, there are several common approaches to creating agreements between the client and the supplier.

Change for Free and Money for Nothing

Few years ago Jeff Sutherland prepared a presentation on two approaches to Fixed Price contracts that are useful while working with Agile team.

Change for Free

It assumes that we use the typical fixed price contract, but we include the clause that changes are implemented according to time & materials principles. In addition, however, we add the ‘Change for Free ‘option, which is applicable when the client works with Agile (for example, if we have a Scrum Team, then the customer is an active Product Owner for each sprint). If client’s commitment and approach ‘do not work’, then we go back to time & materials for changes. In addition, there are also other conditions that define this commitment more clearly.

Money for Nothing

Somewhat different approach is „Money for Nothing „. It works in a way that we have a standard fixed price contract, to which we add the „Money for Nothing” clause. The clause is only valid if the customer acts in accordance with Agile principles. It allows the early termination of the project, when the client sees that the product / the investment will not pay off. For example, the supplier writes in the contract that the project can be terminated at any time, than the customer has to pay 20% of the remaining budget. It protects the supplier during the downtime and seeking new customers / tasks for the team.
An example of this type of contract.

Graduated Fixed Price Contract

In 2009, Thorup and Jensen have developed another type of contract – Graduated Fixed Price Contract. It involves shared risk for the date of delivery of the product. In short, it is based on the use of different rates (e.g. per provider’s working hour), depending on whether the project finishes before the agreed date, on time or after the agreed date.

Fixed Price Work Packages

In case of this contract, the rules are very similar to a typical fixed price contract. The difference is that the work is divided into modules (work packages), which are initially estimated, but while releasing each subsequent package both parties can re-estimate what remains to be done. For example, a client may have some trouble with budgeting and will want to change the scope of other modules – then new terms are agreed with the provider.

Fixed Price + collaboration with the customer to alter the scope

It is a rather risky approach for the supplier, as it is a standard fixed price contract plus it is based on trust, when we change the scope (supplier trusts the client and is very keen on working with changes, priorities, close collaboration with the client). The contract itself does not protect the supplier if the client doesn’t accept the final product or require the previously contracted / previously agreed functionality later (the one which is in specification and was already replaced by the new functionality, which is not stated in the specification). This way of collaborating is very effective but the contract itself is good only for the client.

Fixed Profit

This contract divides budget in two parts – effective costs and profit. Both sides agree on profit in advance. Early finish of the project means less money from the client (less work = less effective costs) but the supplier still gets the profit (earlier). Finishing the project late means no money paid by the client, but the supplier still gets paid for effective costs.

Time and Materials with Variable Scope and Cost Ceiling

The structure of this contract is the same as time and materials, except cost ceiling. Cost ceiling is used to minimize the risk of the client. There is a risk that the budget will expire without the product being delivered on time, but generally both sides are interested in finishing it on time (both sides know about budget limitations and the supplier wants to finish on time, as this is important in terms of long-term cooperation or reputation).

Time and Materials with Fixed Scope and a Cost Ceiling

The structure of this contract is almost the same as fixed price plus fixed scope, except if the supplier gets the work done early, the project costs less, because only the actual effort is included in the price.

Sprint Contract

This type is more of an agreement than a contract model itself. Product Owner and the Team agree on delivering the functionality in the next few weeks. Both sides agree on the specification of the product (acceptance criteria). Product Owner doesn’t change the requirements during the sprint. This model works like a fixed price model for every single sprint.

Fixed Price per function point or story point

The supplier and the client agree on a unit of delivery (story point, function points etc.) and then calculate the price based on each unit that has been delivered. Both sides set the price for one point; the client accepts these points when they are delivered (paying only for the delivered points, not the estimated ones). This causes the supplier to be more determined to deliver the points. This is also a good approach in terms of changing requirements.

Bob Martin’s idea

The idea of Bob Martin sets the basic fee per story point, plus a lower (lower than usual, close to or below the cost) fee per hour. It causes both sides to profit from earlier delivery (all points delivered, supplier is paid in per point mode) but also gives them some protection in case the work proceeds slower than anticipated at the beginning (supplier is paid in per hour mode).

Pay per use

XPLabs (development company from Italy) work with the clients in pay per use mode (originally described by Kent Beck in his book „Extreme Programming”). Every use of the system (custom-built or pre-built system that is deployed for a client) is summed up and the invoice is issued at the end of each month.

Ranges and changes

This is the contract described by Mitch Lacey in his book „The Scrum Field Guide”.
The project is covered by two different contracts:

• Discovery Contract – includes the pieces of information that are used later to write a meaningful contract:
  • Ascertain the ranges
  • Determine cost and timeline
• Project Contract – includes clauses to protect both sides and describes management change (changes)

The idea is to determine (discovery phase) the ranges necessary to write a meaningful contract (final phase).

Discovery Contract

It is covered by a fixed-fee, fixed-length contract which should describe:

• Product backlog (what can be delivered) – determining user types or personas, writing the stories and finally estimating the stories in story points. Here, the team works closely with the customer.
• Initial sprint release plan (by when) and costs – the team works on its own to determine the timeline (to set team velocity, calculate the cost per sprint, build a release plan, and to establish payment options).
• Payment options – determining the payment terms which will work for the supplier and for the client (pay per point, pay per sprint etc.). This should include the definition of a ready product and an explanation of how the work will be delivered to the customer.

Usually it is done by two or three team members for about 2 weeks.

Project Contract

The clause about changes is necessary as we expect the changes to appear and want to accept the mechanism which will work for both sides. This is what we should focus on in terms of changes:

• Work Reshuffle – allow the customer to reshuffle the work on the product backlog / add new stories – as long as the total number of points on the product backlog remains the same (Change for Free).
• Customer Availability – set number of hours per week, when / during which the customer can commit to being available.
• Acceptance Window – set the amount of time during which the customer has to accept the functionality delivered in sprint.
• Prioritization – set backlog grooming as a regular event.
• Termination Clauses – set the clauses which will determine the way of contract termination (option with Money For Nothing etc.)

Summary

As we can see, there are plenty of different options / variations for standard fixed price or time & materials approach. I think that Fixed Price contract itself doesn’t fit into agile way of delivering the software and we should simply avoid it. I also know that this is not always possible. That is why, in such situations we should try to change its form as much as possible, basing on the ideas given in this article.