<?xml version="1.0"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Page comments</title>
		<link>http://www.silverstripe.org/home/</link>
		<atom:link href="http://www.silverstripe.org/home/" rel="self" type="application/rss+xml" />
		<description></description>

		
		<item>
			<title></title>
			<link>http://www.silverstripe.org/tackling-project-risk-how-long-is-that-piece-of-string/#PageComment_18425</link>
			<description>Great post Diana! <br /><br />Having worn both developer and project manager hats, the whole idea if expecting change and emergent requirements is very important... but as you say, having the big spec document is a security blanket for clients. <br />I have seen it a number of times, by the end of the project you can pretty much throw that document in the bin due to it being now irrelevant based on changes over the project lifecycle.<br /><br />Writing code is more of a creative and messy process than many clients think and projects rarely follow a straight line from start to end. Niether party wants to take the risks, but if they can be shared and the project more cooperative I think all parties can get good work done with a fair and realistic time/cost/quality balance.</description>
			<pubDate>Thu, 14 Feb 2013 19:14:23 +1300</pubDate>
			<dc:creator>Cam</dc:creator>
			<guid>http://www.silverstripe.org/tackling-project-risk-how-long-is-that-piece-of-string/#PageComment_18425</guid>
		</item>
		

	</channel>
</rss>