<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Target Cost Contracts</title>
	<atom:link href="http://www.agilekiwi.com/estimationandpricing/target-cost-contracts/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.agilekiwi.com/estimationandpricing/target-cost-contracts/</link>
	<description>The neglected essentials of software development</description>
	<lastBuildDate>Fri, 03 Feb 2012 07:28:23 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Estimation Summary for Agile Projects &#8211; Nov 2011</title>
		<link>http://www.agilekiwi.com/estimationandpricing/target-cost-contracts/comment-page-1/#comment-530</link>
		<dc:creator>Estimation Summary for Agile Projects &#8211; Nov 2011</dc:creator>
		<pubDate>Sat, 19 Nov 2011 00:10:40 +0000</pubDate>
		<guid isPermaLink="false">http://dell-pc/AgileKiwiWordpress/pricing/target-cost-contracts-2/#comment-530</guid>
		<description>[...] commitments and benefits,&#160; but avoids the harsher downsides of absolutely fixing both.&#160; Here’s an approach that I’ve tried and liked.&#160; It’s not for everyone, but in cases where it’s [...]</description>
		<content:encoded><![CDATA[<p>[...] commitments and benefits,&#160; but avoids the harsher downsides of absolutely fixing both.&#160; Here’s an approach that I’ve tried and liked.&#160; It’s not for everyone, but in cases where it’s [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Rusk</title>
		<link>http://www.agilekiwi.com/estimationandpricing/target-cost-contracts/comment-page-1/#comment-514</link>
		<dc:creator>John Rusk</dc:creator>
		<pubDate>Fri, 23 Sep 2011 07:41:23 +0000</pubDate>
		<guid isPermaLink="false">http://dell-pc/AgileKiwiWordpress/pricing/target-cost-contracts-2/#comment-514</guid>
		<description>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 &quot;full-price&quot; payment) but interpretation of existing scope (within reason) does not.  While this may sound dangerous and vague, I believe it&#039;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&#039;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 &quot;getting work for half price&quot; 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 &lt;em&gt;free&lt;/em&gt;).</description>
		<content:encoded><![CDATA[<p>Chetan,</p>
<p>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 &#8220;full-price&#8221; payment) but interpretation of existing scope (within reason) does not.  While this may sound dangerous and vague, I believe it&#8217;s actually not really any more risky to either party than a normal fixed price contract &#8211; 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.</p>
<p>By the way, the mathematics actually work out in such a way that there&#8217;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 &#8220;getting work for half price&#8221; 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 &#8212; and then you have to worry about the customer trying to get work for <em>free</em>).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chetan</title>
		<link>http://www.agilekiwi.com/estimationandpricing/target-cost-contracts/comment-page-1/#comment-513</link>
		<dc:creator>Chetan</dc:creator>
		<pubDate>Thu, 22 Sep 2011 12:01:59 +0000</pubDate>
		<guid isPermaLink="false">http://dell-pc/AgileKiwiWordpress/pricing/target-cost-contracts-2/#comment-513</guid>
		<description>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 ?</description>
		<content:encoded><![CDATA[<p>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 ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Rusk</title>
		<link>http://www.agilekiwi.com/estimationandpricing/target-cost-contracts/comment-page-1/#comment-500</link>
		<dc:creator>John Rusk</dc:creator>
		<pubDate>Wed, 17 Aug 2011 21:08:03 +0000</pubDate>
		<guid isPermaLink="false">http://dell-pc/AgileKiwiWordpress/pricing/target-cost-contracts-2/#comment-500</guid>
		<description>@RamCM,

I&#039;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 &quot;saved&quot; (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.</description>
		<content:encoded><![CDATA[<p>@RamCM,</p>
<p>I&#8217;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).</p>
<p>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 &#8220;saved&#8221; (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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: RamCM</title>
		<link>http://www.agilekiwi.com/estimationandpricing/target-cost-contracts/comment-page-1/#comment-499</link>
		<dc:creator>RamCM</dc:creator>
		<pubDate>Wed, 17 Aug 2011 08:48:52 +0000</pubDate>
		<guid isPermaLink="false">http://dell-pc/AgileKiwiWordpress/pricing/target-cost-contracts-2/#comment-499</guid>
		<description>Customer will have the incentive to reduce costs only till the point that they&#039;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&#039;t it?</description>
		<content:encoded><![CDATA[<p>Customer will have the incentive to reduce costs only till the point that they&#8217;re convinced that the cost of the project will be within the target cost.<br />
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&#8217;t it?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Rusk</title>
		<link>http://www.agilekiwi.com/estimationandpricing/target-cost-contracts/comment-page-1/#comment-307</link>
		<dc:creator>John Rusk</dc:creator>
		<pubDate>Sat, 15 Jan 2011 09:03:21 +0000</pubDate>
		<guid isPermaLink="false">http://dell-pc/AgileKiwiWordpress/pricing/target-cost-contracts-2/#comment-307</guid>
		<description>Actually, looks like it was Norway.  Called the PS 2000 contract. See http://alistair.cockburn.us/Agile+contracts</description>
		<content:encoded><![CDATA[<p>Actually, looks like it was Norway.  Called the PS 2000 contract. See <a href="http://alistair.cockburn.us/Agile+contracts" rel="nofollow">http://alistair.cockburn.us/Agile+contracts</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Rusk</title>
		<link>http://www.agilekiwi.com/estimationandpricing/target-cost-contracts/comment-page-1/#comment-306</link>
		<dc:creator>John Rusk</dc:creator>
		<pubDate>Wed, 12 Jan 2011 08:22:13 +0000</pubDate>
		<guid isPermaLink="false">http://dell-pc/AgileKiwiWordpress/pricing/target-cost-contracts-2/#comment-306</guid>
		<description>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&#039;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&#039;ll try not to lose it this time! ;-)</description>
		<content:encoded><![CDATA[<p>Thanks Charles.</p>
<p>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&#8217;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&#8217;ll try not to lose it this time! ;-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dr. Charles Suscheck</title>
		<link>http://www.agilekiwi.com/estimationandpricing/target-cost-contracts/comment-page-1/#comment-305</link>
		<dc:creator>Dr. Charles Suscheck</dc:creator>
		<pubDate>Tue, 11 Jan 2011 16:33:20 +0000</pubDate>
		<guid isPermaLink="false">http://dell-pc/AgileKiwiWordpress/pricing/target-cost-contracts-2/#comment-305</guid>
		<description>Love the post.  I&#039;d like to see people&#039;s experience with this approach.</description>
		<content:encoded><![CDATA[<p>Love the post.  I&#8217;d like to see people&#8217;s experience with this approach.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

