This page outlines one way to formulate Target Cost Contracts for agile software development.

The goals of this approach are to:

• Share risk fairly between Customer and Supplier
• Give the Supplier the peace of mind of being protected from significant cost overruns
• Offer enough flexibility to get the best out of an agile development process
• Align goals by giving both parties an incentive to minimise scope

The ideas here are still under development, having only been used on a small number of projects so far.

Overview

The contract is based on two figures: the “target price” and the “cap”.  The cap is the maximum that you (the Customer) will pay. The target is lower than the cap and the contract gives both parties a financial incentive to meet the target.

If we (the Supplier) come in under the target, the savings are shared equally between both parties.  Likewise, if we come in over the target, the extra cost is shared evenly – but only up to the cap.  If we reach the cap, it acts like a fixed price.

Benefits

This approach gives you certainty about the maximum that you will pay (the cap), while still sharing risks and benefits fairly.

As explained below, both parties have a financial incentive to minimize the scope and cost.  Minimizing scope and cost reduces overall project risk.  Contrast this with standard fixed-price or time and materials contracts, where one party has an incentive to increase scope and the other has an incentive to decrease it.  Only a target cost contract incentivizes both parties in the same direction.

Details

There are two ways do formulate a target cost contract.  Both are mathematically identical, they are just different ways to describe the same thing.

Formulation 1:

1. Up to the target cost, you pay our standard rate of $x per hour.
2. If the project comes in under the target, we split the savings evenly.  For instance, if we come in $10k under budget, you pay us half of that (5k) and keep the other half yourself.
3. If the project goes over the target, we split the extra cost evenly. In effect, that means you pay half our standard rate ($x / 2) for any hours between the target and the cap.
4. Your total payment (for full-rate work up to the target plus any half-rate work beyond) will not exceed the cap.

Formulation 2:

1. Payment is composed of two elements.  You pay half the target as a fixed fee.  You also pay us on an hourly basis, as we work, at half our standard hourly rate.  For instance, if the target is $100k, you’ll pay a fixed fee of $50k plus half our standard rate ($x / 2) for every hour that we work.
2. Again, your total payment (fixed portion plus hourly portion) will not exceed the cap.
3. The fixed portion can be paid in several instalments, with timing negotiated up front .  The last instalment will typically be on completion of User Acceptance Testing.  For small to medium projects, two instalments is the easiest approach – one at the start and one at the end of UAT.  So for a project with a target cost of 100k, the two fixed payments would be 25k at the start of the project and 25k at the end of UAT (giving a total fixed payment of half the target, as always).
4. The per-hour portion will typically be invoiced on a month-by-month basis.

Graph

This graph shows how the contract works.  (Both formulations result in the same graph, because they are just different ways to describe the same thing).

Note that if the project completes exactly on target, working exactly the target number of hours, then total billing is exactly equal to what it would have been under a Time and Materials (T&M) contract.

Also note that there is no hard and fast rule for the gap between target and cap – it depends on the degree of risk in the project, with the gap being bigger if there is more risk.  One guideline is that the gap should be big enough that neither the supplier nor the customer expects to hit the cap.  (Since, if the cap is expected to be hit, the situation degenerates into a fixed-price contract.  When that happens, the beneficial effect of aligned incentives is lost).

Incentives

Under a target cost contract the customer has an incentive to minimize scope, because that minimizes the total cost.  The supplier also has an incentive to minimize scope, because under this model lower scope means higher profit.  (The supplier maximizes profit by minimizing the number of half-price hours they must work.)

Sample Wording

Here is sample wording for a project with a target of 100k and a cap of 115k. The wording is based on formulation #2.  Bold sections may vary for projects of other sizes or at different charge-out rates.

Target Cost: $ 100,000

Payments will be as follows:

$25,000 at the start of the development and $25,000 on completion UAT

Monthly payment of actual hours worked at $xx/hr until the development is complete or yyy hours of effort has been expended.  [yyy * xx = 65k.  That 65k plus the 50k in fixed payments = the cap of 115k]

Total payment of ($25,000 x 2 + $xx per hour) will not exceed the cap of $115,000.

In the event that the capped price is reached <supplier> will complete the development without billing <customer> for any further hours (other than agreed change controls).

Change Controls

The contract is based on an initial agreed scope.  If you want to add to that scope during the project, you can do so using an agreed change control process.  (Just like you can under a fixed-price contract.)  In such cases we will negotiate an appropriate change to the target and the cap.

We recommend that the following approach should be taken to change control:  if it is a brand new requirement, a change control must be raised.  However, if it is simply a question interpretation of an existing requirement, no change control is necessary.  The cap and target are not changed by issues of interpretation; only by brand new requirements.  We make this recommendation to preserve the flexibility and collaboration that is offered by agile processes.

Conditions Under Which this Approach Can be Used

Note: this approach can only be used where all of the following are true:

• The up-front scope can be identified and written down well enough to serve as the basis for any future discussions of what is, and isn’t, a change.  (The scope definition doesn’t have to be perfect, just good enough to be used as a baseline for telling the difference between what does, and doesn’t, require a change control)
• All parties agree that if changes are identified then either the cap will increase or something else must be removed from scope.
• The key stakeholders in both organizations truly understand the model.  (Don’t want nasty surprises where, for instance, customer is surprised to receive final fixed payment because they thought they were just paying by the hour!)
• Key stakeholders in both organizations know how they will process the payments through their respective billing/financial systems (since such systems tend to assume either fixed price OR hourly rate, but not both).

Ideally, the upfront scope will be accurate enough to serve as basis for future discussions, but loose enough leave room for refining the details, agile-style, during the project.  The level of detail depends on the organizations concerned, and the risk level of the project.  In some cases the level of detail required for this approach may be excessive, leading to too much Big Design Up Front, in which case this contract structure is probably inappropriate. In such cases, other contract structures should be considered instead.

We do not mandate any particular way to document the initial scope, as long as it meets the needs above.  E.g. index cards or other simple formats may be appropriate, depending on the situation.

Payment for Change Controls

The following approach is suggested:

Firstly, the size of the change is estimated by the development team.  Then, based on that estimate, two things happen:

1.     The capped number of hours is increased.  This is the figure yyy in the example above. The increase is equal to the estimated hours to implement the change, plus an appropriate contingency buffer.  AND

2.     An additional fixed payment is made.  This fixed payment corresponds to half the target cost of the change. For a small change this can be a single payment at a time agreeable to both parties.  For larger changes it can be broken into instalments, with the final instalment being due at the end of UAT.

The net effect is as shown in this graph:

[Update August 2015: Here is a detailed account from a team who used this approach, and also broke their project up into several separate mini-projects]

[Update June 09: a similar approach is described here]