<?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: Schedule Game #11: The Schedule Tool is Always Right</title>
	<atom:link href="http://www.jrothman.com/blog/mpd/2005/05/schedule-game-11-the-schedule-tool-is-always-right.html/feed" rel="self" type="application/rss+xml" />
	<link>http://www.jrothman.com/blog/mpd/2005/05/schedule-game-11-the-schedule-tool-is-always-right.html</link>
	<description>Management, especially good management, is hard to do. This blog is for people who want to think about how they manage people, projects, and risk.</description>
	<lastBuildDate>Fri, 18 May 2012 15:02:36 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: Will Sargent</title>
		<link>http://www.jrothman.com/blog/mpd/2005/05/schedule-game-11-the-schedule-tool-is-always-right.html/comment-page-1#comment-126</link>
		<dc:creator>Will Sargent</dc:creator>
		<pubDate>Sat, 07 May 2005 12:57:36 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=8154#comment-126</guid>
		<description>I once had a project that the PM estimated would take six months.  I disagreed, but couldn&#039;t back up any numbers, because the organization was completely new to me.  So I asked him for all the parameters (experience with technology, timeframe, number of stakeholders, level of detail in requirements) and the tool popped out 10 months as the estimate.  After that, the idea that estimates were really only vague guesses was something they had no problem with.</description>
		<content:encoded><![CDATA[<p>I once had a project that the PM estimated would take six months.  I disagreed, but couldn&#8217;t back up any numbers, because the organization was completely new to me.  So I asked him for all the parameters (experience with technology, timeframe, number of stakeholders, level of detail in requirements) and the tool popped out 10 months as the estimate.  After that, the idea that estimates were really only vague guesses was something they had no problem with.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave Smith</title>
		<link>http://www.jrothman.com/blog/mpd/2005/05/schedule-game-11-the-schedule-tool-is-always-right.html/comment-page-1#comment-128</link>
		<dc:creator>Dave Smith</dc:creator>
		<pubDate>Sat, 07 May 2005 02:59:32 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=8154#comment-128</guid>
		<description>Many years back a project management instructor who&#039;d done a lot of milspec work told a story about of how PERT was invented as a technique to distract the auditors on a big military project by giving them pretty charts with boxes and arrows to focus on. This kept them from getting in the way of people who were actually doing work.</description>
		<content:encoded><![CDATA[<p>Many years back a project management instructor who&#8217;d done a lot of milspec work told a story about of how PERT was invented as a technique to distract the auditors on a big military project by giving them pretty charts with boxes and arrows to focus on. This kept them from getting in the way of people who were actually doing work.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jared Richardson</title>
		<link>http://www.jrothman.com/blog/mpd/2005/05/schedule-game-11-the-schedule-tool-is-always-right.html/comment-page-1#comment-127</link>
		<dc:creator>Jared Richardson</dc:creator>
		<pubDate>Thu, 05 May 2005 19:22:04 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=8154#comment-127</guid>
		<description>I&#039;ve had to deal with people like this in the past. My strategy is to give them a schedule up front (as required), but to inflate the time estimates.
The inflated time estimates do two things. First, it gives the team time to find problems and fix them. The iteration time is in the padding.
The second thing a padded schedule does is give your team the chance to finish early and look good. I had one clueless executive who consistently told everyone how good my team was because we always brought projects in early. He never did figure out why. :)</description>
		<content:encoded><![CDATA[<p>I&#8217;ve had to deal with people like this in the past. My strategy is to give them a schedule up front (as required), but to inflate the time estimates.<br />
The inflated time estimates do two things. First, it gives the team time to find problems and fix them. The iteration time is in the padding.<br />
The second thing a padded schedule does is give your team the chance to finish early and look good. I had one clueless executive who consistently told everyone how good my team was because we always brought projects in early. He never did figure out why. :)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

