<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>let x=x &#187; contracts</title>
	<atom:link href="http://www.crazymcphee.net/x/tag/contracts/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.crazymcphee.net/x</link>
	<description>programming idiom and methodology</description>
	<lastBuildDate>Wed, 11 Aug 2010 01:13:24 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>Are fixed-price contracts evil?</title>
		<link>http://www.crazymcphee.net/x/2009/04/09/are-fixed-price-contracts-evil/</link>
		<comments>http://www.crazymcphee.net/x/2009/04/09/are-fixed-price-contracts-evil/#comments</comments>
		<pubDate>Thu, 09 Apr 2009 08:27:15 +0000</pubDate>
		<dc:creator>Scot Mcphee</dc:creator>
				<category><![CDATA[business]]></category>
		<category><![CDATA[professional practice]]></category>
		<category><![CDATA[agile]]></category>
		<category><![CDATA[contracts]]></category>

		<guid isPermaLink="false">http://www.crazymcphee.net/x/?p=319</guid>
		<description><![CDATA[Alef Arendsen asks &#8216;Are fixed priced contracts evil?&#8217;, especially to the agile process, and summarises there a number of responses that others have had into this question. Especially in the contractual arrangements that consulting companies need to make in the agile development sphere. He points to an excellent post by Seth Schubert on this matter. [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://blog.jteam.nl/2009/04/08/selling-agile-projects-part-i/">Alef Arendsen asks</a> &#8216;Are fixed priced contracts evil?&#8217;, especially to the agile process, and summarises there a number of responses that others have had into this question. Especially in the contractual arrangements that consulting companies need to make in the agile development sphere. He points to an <a href="http://www.codesqueeze.com/how-to-sell-agile-to-fixed-bid-contract-clients/" target="_blank">excellent post by Seth Schubert</a> on this matter.</p>
<p>My two cents on this issue is simply that yes, fixed price, fixed scope contracts <em>are</em> &#8220;evil&#8221;, in the sense they are harmful for the project being delivered. Alef and Seth have some excellent points why client organisations,  especially when initially dealing with a consulting organisation for the first time, want to manage their risk by choosing fixed price and fixed scope, and why it&#8217;s harmful to project success.</p>
<p>I&#8217;ve had some clients exactly like that &#8211; the company is negotiating with one now. The real concern of theirs &#8211; and ours &#8211; is that they can build a trust relationship between the two organisations. I think, like Seth, once that trust relationship is built, managing the scope of the delivery is much easier. Seth recommends using <a href="http://cyrusinnovation.com/downloads/agile2005_cyrusinnovation_targetcostcontracts_paper.pdf" target="_blank">target cost contracts (PDF)</a>. I know that agile contracts were one of the areas the <a href="http://www.meetup.com/Scrummaster/" target="_blank">Brisbane Scrum User Group</a> were hoping to do a session on.</p>
<p>In my view, the real danger isn&#8217;t from the fixed <em>price</em>. After all if you quote me a dollar figure I can tell you how many days of involvement that buys from my consulting firm. Exactly what that builds is completely  dependent on what is being asked. The problem comes of course with fixing the <em>scope</em>. There are a number of issues around fixing the scope, which together present a huge huge of project failure:</p>
<ul>
<li>It assumes you have perfect information at the start of the project, before anything is even attempted. Most developers can easily tell you that you don&#8217;t even know 20% of what you&#8217;re getting yourself in for &#8211; even if you just finished completing something very similar just the day before.</li>
<li>Problems, being unforeseen, can&#8217;t be accomodated in &#8220;buffers&#8221;, because we don&#8217;t know actually know what is unforeseen.</li>
<li>It closes off all prospect of innovation with the project as the project progresses. Discovered insight (the most valuable kind) is simply excluded, or it is buried alive in a negotiation or a change control process.</li>
<li>It might not match with the price even if everything goes to expectation (i.e. it is simply an unrealistic scope for the money). This is related to but not quite the same as the &#8220;9 women pregnant 1 month each&#8221; problem, which is to say, it&#8217;s just not possible to do it.</li>
</ul>
<p>The real problem is, that I see, is that clients tend to close off the scope before they close of the price. You can see this in the standard &#8220;tender&#8221; procedure so loved of big companies and governments. But I&#8217;ve had that experience too inside an enterprise dealing with internal clients. Most developers will be familiar with that sort of conversation &#8211; <em>&#8220;All the scope is non-negotiable up-front and please tell me it will cost 4 weeks? What do you mean &#8216;at least&#8217; 4 months?&#8221;</em> In a previous life I used to have exactly this conversation about every month. On the other hand, if you tell me your <em>budget</em> first, I can tell you the <em>approximate</em> sort of system you&#8217;ll get from that.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.crazymcphee.net/x/2009/04/09/are-fixed-price-contracts-evil/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>
