<?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: Deming&#8217;s 14 Points and Quality Project Leadership</title>
	<atom:link href="http://www.pmhut.com/demings-14-points-and-quality-project-leadership/feed" rel="self" type="application/rss+xml" />
	<link>http://www.pmhut.com/demings-14-points-and-quality-project-leadership</link>
	<description></description>
	<pubDate>Sun, 19 May 2013 15:46:59 +0000</pubDate>
	<generator>http://wordpress.org/?v=abc</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Stuart Whibley</title>
		<link>http://www.pmhut.com/demings-14-points-and-quality-project-leadership/comment-page-1#comment-22776</link>
		<dc:creator>Stuart Whibley</dc:creator>
		<pubDate>Thu, 15 Jul 2010 00:54:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.pmhut.com/?p=4894#comment-22776</guid>
		<description>I was searching for an article on Quality Management and came across this. How spot on Deming is in the 14 points outlined. Recommended reading for all Quality Managers finding experiencing difficulties in getting the message across.</description>
		<content:encoded><![CDATA[<p>I was searching for an article on Quality Management and came across this. How spot on Deming is in the 14 points outlined. Recommended reading for all Quality Managers finding experiencing difficulties in getting the message across.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Tailby</title>
		<link>http://www.pmhut.com/demings-14-points-and-quality-project-leadership/comment-page-1#comment-18241</link>
		<dc:creator>John Tailby</dc:creator>
		<pubDate>Wed, 03 Mar 2010 20:58:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.pmhut.com/?p=4894#comment-18241</guid>
		<description>If your project is expected to last 5 years you can't plan it so that you spend the first year gathering the requirements, the second year designing it and years 3-4 building it and year 5 testing and deploying it.

Planning a projct like that implies that your business requirements won't change for 4 years. That's just not an acceptable scenario. Projects planned on that basis never get out of requirements because the requirements are always going to change.

For a 5 year project you are far better delivering in in 5 one year projects. This then creates the opportunity for the business requirements to evolve over the life of the project and increases the ROI of the project by delivering busiess value early.

Thats what I understood the planning comment to mean.</description>
		<content:encoded><![CDATA[<p>If your project is expected to last 5 years you can&#8217;t plan it so that you spend the first year gathering the requirements, the second year designing it and years 3-4 building it and year 5 testing and deploying it.</p>
<p>Planning a projct like that implies that your business requirements won&#8217;t change for 4 years. That&#8217;s just not an acceptable scenario. Projects planned on that basis never get out of requirements because the requirements are always going to change.</p>
<p>For a 5 year project you are far better delivering in in 5 one year projects. This then creates the opportunity for the business requirements to evolve over the life of the project and increases the ROI of the project by delivering busiess value early.</p>
<p>Thats what I understood the planning comment to mean.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Laura Bamberg</title>
		<link>http://www.pmhut.com/demings-14-points-and-quality-project-leadership/comment-page-1#comment-18235</link>
		<dc:creator>Laura Bamberg</dc:creator>
		<pubDate>Wed, 03 Mar 2010 19:00:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.pmhut.com/?p=4894#comment-18235</guid>
		<description>If an incredibly large amount of project never make it to closure, is it because they were planned too rigidly, too much, and planned too slowly? No, I don't think that's it. You can never plan too much. While leadership and teamwork and quality are always going to be part of project management and are things a PM can usually improve consistently, as part of learning, planning is something you can't minimize without experiencing a significant problem. Putting off something to do two months from now that if, done properly at this moment, could be done BETTER at this moment, doesn't sound like a way to improve project management.</description>
		<content:encoded><![CDATA[<p>If an incredibly large amount of project never make it to closure, is it because they were planned too rigidly, too much, and planned too slowly? No, I don&#8217;t think that&#8217;s it. You can never plan too much. While leadership and teamwork and quality are always going to be part of project management and are things a PM can usually improve consistently, as part of learning, planning is something you can&#8217;t minimize without experiencing a significant problem. Putting off something to do two months from now that if, done properly at this moment, could be done BETTER at this moment, doesn&#8217;t sound like a way to improve project management.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
