<?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>Project Management</title>
		<link>http://www.kubernetes.co.uk/2007/05/24/the-zone-of-uncertainty/</link>
		<comments>http://www.kubernetes.co.uk/2007/05/24/the-zone-of-uncertainty/#comments</comments>
		<pubDate>Thu, 24 May 2007 16:05:07 +0000</pubDate>
		<dc:creator>Jeremy</dc:creator>
				<category><![CDATA[Project Management]]></category>

		<guid isPermaLink="false">http://www.kubernetes.co.uk/?p=54</guid>
		<description><![CDATA[Working through some navigation exercises and came across this diagram from the RYA Yachtmasters course guide

What the manual says is that the errors associated with trying to measure your position (without GPS) accumulate exponentially.  In navigation this becomes critical as you try to avoid hazards during a passage.
It struck me as a useful analogy [...]]]></description>
			<content:encoded><![CDATA[<p>Working through some navigation exercises and came across this diagram from the RYA Yachtmasters course guide</p>
<p><img src="http://www.kubernetes.co.uk/wp-content/uploads/2007/04/EP%20Cut%20Down1.jpg" alt="Estimated Position" id="image59" /><br />
What the manual says is that the errors associated with trying to measure your position (without GPS) accumulate exponentially.  In navigation this becomes critical as you try to avoid hazards during a passage.</p>
<p>It struck me as a useful analogy for any planning activity, specifically project planning for IT systems.  I challenge anyone to be able to see exactly the &#8220;course&#8221; of an project at the beginning.  Even in the middle and sometimes right at the end something will happen to throw you &#8220;off-course&#8221;, but at least in these circumstances you know about it.</p>
<p>The real issue is the &#8220;Zone of Uncertainty&#8221; were little delays here or errors there add up exponentially to make a significant delay or project creep.</p>
<p>This is where <a href="http://www.dsdm.org/" target="_blank">DSDM </a>as a project management methodology is both theoretically correct and common sense.  DSDM&#8217;s primary technique is the application of rigid timeboxes of between 2 and 6 weeks in which the project team decides what are the deliverables.  The project review and lessons learnt sessions at the end of each timebox act as &#8220;GPS&#8221; positioning for the project so that one knows what course the project is on and whether it is heading too close to a &#8220;hazard&#8221;.</p>
<p>Just a thought; if you are running a project without the discipline of timeboxes how can you be sure that you are not about to &#8220;hit the rocks&#8221;?</p>
]]></content:encoded>
			<wfw:commentRss>http://www.kubernetes.co.uk/2007/05/24/the-zone-of-uncertainty/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

