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.


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.


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.


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.


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).


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]

14 comments on “Target Cost Contracts

  • Thanks Charles.

    By the way, I had a comment from another reader, but lost it due to a technical problem. As I recall, the comment said that the approach I’ve suggested is very similar to a government standard somewhere in Scandinavia (I think it was Sweden). If anyone knows the details, please post a comment. (I’ll try not to lose it this time! 😉

  • Customer will have the incentive to reduce costs only till the point that they’re convinced that the cost of the project will be within the target cost.
    This model would continue to have the same problems of a fixed cost contract (i.e. scope creep) as soon as the target cost is hit. Isn’t it?

  • @RamCM,

    I’m not sure whether your comments are about the target, or the cap. Your point about degenerating into a fixed-cost situation is true if the _cap_ is hit (or is likely to be hit).

    However, as long as the cap is not likely to be hit, I believe the customer always has an incentive to reduce scope. For each hour of work that is “saved” (i.e. not done, due to simplifying scope), there is always a cost reduction to the customer. E.g. even if the project looks like it is going to come in 10% below the target, the customer can save even more money if they reduce the scope further.

  • Loved this post and the idea. But I think the scenario works well when both customer and supplier work towards delivering under the target.As soon as the target is hit, the customer will want to have more scope included until the point where the cap is reached because he will have to pay less for getting the features done leading to the Fixed price type scope creep. Is that understanding correct ?

  • Chetan,

    Regarding the customer wanting more, since extra stuff is effectively half price, I think that is a valid concern. My preferred solution is to stick to a firm but fair interpretation of the rule mentioned above, that new scope requires a change request (and therefore additional “full-price” payment) but interpretation of existing scope (within reason) does not. While this may sound dangerous and vague, I believe it’s actually not really any more risky to either party than a normal fixed price contract – since similar discussions about scope happen on those projects too. The intended difference with a target cost contract is that neither party has to waste time haggling over the _small_ stuff, so in the end both are better off than they would have been under fixed-price.

    By the way, the mathematics actually work out in such a way that there’s really no difference in the way this contract behaves under, or over, the target. You can see that in the way that the cost line is perfectly straight, and on the same angle, both before and after the target is reached. So the concern about “getting work for half price” applies at all times, and always requires that steps be taken to address it, as above. Likewise, the incentive for the customer to reduce their total bill, by containing scope, also applies at all times, both below and above the target. (Except if the _cap_ is reached, in which case it degenerates into a fixed-price contract — and then you have to worry about the customer trying to get work for free).

  • hi my name is abdulkerim muhammed from Ethiopia and am student . if you voluntary to support me please answer the following questions.
    1 What is the difference between target estimate and guaranteed maximum price contract?
    a. What is their main feature?
    b. Compare the risks
    c. Discuss advantage and disadvantages
    2. What are sliding fee cost plus contracts?
    a. Discuss advantage and disadvantages
    b. Compare the risk with their counterpart . please send the answer to I wish with you all the best!!

  • Hi Abdulkerim,

    It looks like the questions in your comment are ones that you’ve been asked, by your tutor or lecturer. Answering them yourself is a part of the learning process, so I won’t answer them for you I’m sorry 😉

    Best wishes with your studies.

  • I’d love going over your posted notes and exploring about CTC. I’m a BSEE graduate, licensed engineer and works in a contracting firm with oil/gas, refinery and petrochemical project. Which course or higher stage of study shall I take in order to be a expert /specialist in TCT, estimation and pricing, etc…thanks in advance.

  • Allow me please, this is the second time I send comment. When the contract is awarded to us to undertake, complete and handover a certain project, LSTK/LSPB, EPC, etc., I normally review scope of works, item by item, stage by stage, delivery by milestone dates, till end or project completion. I don’t belong to corporate management level (ISO certified company) and so I’ve no contribution to kick-off meeting, cost estimation, risk surveillance, planning, procurement & pricing, except my line as QA/QC. Now, it’s high time that I want to prove to be in a corporate level since I do a lot of construction audit reviews and QMS implementation, monitoring its execution’s effectiveness, lessening if not eliminate doubts while in process, and hands-on responsibility in project development. Shall I pursue my goal in my first posted comment in order to be competitive in a diversified construction market? Thanks again.

  • Hi Domingo,

    I’m sorry to say, I only work in software engineering. I don’t believe I know enough about your branches of engineering to answer your question. I wish you all the best.

Comments are closed.