<?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: Estimating - Getting the Right Feedback From Your Project Team</title>
	<atom:link href="http://www.pmhut.com/estimating-getting-the-right-feedback-from-your-project-team/feed" rel="self" type="application/rss+xml" />
	<link>http://www.pmhut.com/estimating-getting-the-right-feedback-from-your-project-team</link>
	<description></description>
	<pubDate>Tue, 22 May 2012 19:10:25 +0000</pubDate>
	<generator>http://wordpress.org/?v=abc</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Dina Garfinkel, PMP</title>
		<link>http://www.pmhut.com/estimating-getting-the-right-feedback-from-your-project-team/comment-page-1#comment-9534</link>
		<dc:creator>Dina Garfinkel, PMP</dc:creator>
		<pubDate>Thu, 01 Oct 2009 02:38:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.pmhut.com/?p=3813#comment-9534</guid>
		<description>Great post! I found in past projects that I had to really talk them through best/worst case scenarios to get the (programmers in my case) to confidently make a low/high estimate. They went into it thinking everything would go perfectly and made the initial estimate based on that, but once you discuss some of the risks involved they understand the value of making a low/high estimate. 

Not unrelated, LiquidPlanner (www.liquidplanner.com) is an excellent tool for recording task estimates in ranges, and building a much more reliable project schedule. The worker can go back and revise estimates as s/he continues to work on the task, so nobody will be stuck committing to a single point estimate that was probably unrealistic from the beginning.</description>
		<content:encoded><![CDATA[<p>Great post! I found in past projects that I had to really talk them through best/worst case scenarios to get the (programmers in my case) to confidently make a low/high estimate. They went into it thinking everything would go perfectly and made the initial estimate based on that, but once you discuss some of the risks involved they understand the value of making a low/high estimate. </p>
<p>Not unrelated, LiquidPlanner (www.liquidplanner.com) is an excellent tool for recording task estimates in ranges, and building a much more reliable project schedule. The worker can go back and revise estimates as s/he continues to work on the task, so nobody will be stuck committing to a single point estimate that was probably unrealistic from the beginning.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

