<?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: Was Your Project Late or Underestimated?</title>
	<atom:link href="http://www.pmhut.com/was-your-project-late-or-underestimated/feed" rel="self" type="application/rss+xml" />
	<link>http://www.pmhut.com/was-your-project-late-or-underestimated</link>
	<description></description>
	<pubDate>Fri, 25 May 2012 01:59:22 +0000</pubDate>
	<generator>http://wordpress.org/?v=abc</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Rodney</title>
		<link>http://www.pmhut.com/was-your-project-late-or-underestimated/comment-page-1#comment-19979</link>
		<dc:creator>Rodney</dc:creator>
		<pubDate>Tue, 13 Apr 2010 03:14:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.pmhut.com/?p=5110#comment-19979</guid>
		<description>In the end... its not methodologies , tools, resources, customers or staff that make projects fail. Its just Politics.  By definition, Isnt Politics devoid of set measures and agreed principles..


Each Manager up the chain has their own agenda (KRAs)

their focus is only on the month ahead till the next set of performance figures are due. Its hardly surprising that they press well beyond the carefully constructed estimtes. Which is why just over 50% of all projects in the US fail. Yet if they had more faith in their IT staff, the projects would not fail with such alarming frequency. When presenting their end date to the upper managers, tney ought to guote this figure and suggest they reconsider the 25% reduction in time.

just a thought..</description>
		<content:encoded><![CDATA[<p>In the end&#8230; its not methodologies , tools, resources, customers or staff that make projects fail. Its just Politics.  By definition, Isnt Politics devoid of set measures and agreed principles..</p>
<p>Each Manager up the chain has their own agenda (KRAs)</p>
<p>their focus is only on the month ahead till the next set of performance figures are due. Its hardly surprising that they press well beyond the carefully constructed estimtes. Which is why just over 50% of all projects in the US fail. Yet if they had more faith in their IT staff, the projects would not fail with such alarming frequency. When presenting their end date to the upper managers, tney ought to guote this figure and suggest they reconsider the 25% reduction in time.</p>
<p>just a thought..</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ken Burrell PMP, Project Office Manager</title>
		<link>http://www.pmhut.com/was-your-project-late-or-underestimated/comment-page-1#comment-19872</link>
		<dc:creator>Ken Burrell PMP, Project Office Manager</dc:creator>
		<pubDate>Fri, 09 Apr 2010 11:41:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.pmhut.com/?p=5110#comment-19872</guid>
		<description>Interesting article Ben, that raises a question in my mind - how do we get better at estimating so that the same thing doesn't happen next time? There are a few options here, including (but not lmited to):

+ Modifying base or generic estimates using an efficiency / skill rating adjustment to compensate for variations in speed between individuals or groups of people; (needs careful management as people could be sensitive about the efficiency / ability pigeonhole you put them in)

+ Using three-point (aka PERT) estimation (optimistic / pessimistic / most likely) and presenting the estimate as a weighted average of these.

+ Expressing durations (and therefore delivery dates) as a range rather then a single, point value. Then your project isn't late unless it comes in after the latest date in the range.

Having said all that, if the delay is spotted early enough then it could/should be possible to extend the timescales with a Change Request, in which case the project isn't really "late".

But all this is academic if Someone In Power insists that you cut whatever estimate you present by 25%. Then you get into the padding / cutting game, which helps no-one.

Any thoughts anyone?</description>
		<content:encoded><![CDATA[<p>Interesting article Ben, that raises a question in my mind - how do we get better at estimating so that the same thing doesn&#8217;t happen next time? There are a few options here, including (but not lmited to):</p>
<p>+ Modifying base or generic estimates using an efficiency / skill rating adjustment to compensate for variations in speed between individuals or groups of people; (needs careful management as people could be sensitive about the efficiency / ability pigeonhole you put them in)</p>
<p>+ Using three-point (aka PERT) estimation (optimistic / pessimistic / most likely) and presenting the estimate as a weighted average of these.</p>
<p>+ Expressing durations (and therefore delivery dates) as a range rather then a single, point value. Then your project isn&#8217;t late unless it comes in after the latest date in the range.</p>
<p>Having said all that, if the delay is spotted early enough then it could/should be possible to extend the timescales with a Change Request, in which case the project isn&#8217;t really &#8220;late&#8221;.</p>
<p>But all this is academic if Someone In Power insists that you cut whatever estimate you present by 25%. Then you get into the padding / cutting game, which helps no-one.</p>
<p>Any thoughts anyone?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

