<?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"
	>
<channel>
	<title>Comments on: Seven Deadly Sins of Project Management</title>
	<atom:link href="http://www.miloriano.com/seven-deadly-sins-of-project-management.page/feed" rel="self" type="application/rss+xml" />
	<link>http://www.miloriano.com/seven-deadly-sins-of-project-management.page</link>
	<description>Young man's journey to become a CEO &#38; succeed</description>
	<pubDate>Thu, 04 Dec 2008 02:29:31 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.1</generator>
		<item>
		<title>By: Wayne Turk</title>
		<link>http://www.miloriano.com/seven-deadly-sins-of-project-management.page#comment-3031</link>
		<dc:creator>Wayne Turk</dc:creator>
		<pubDate>Tue, 14 Nov 2006 16:21:36 +0000</pubDate>
		<guid isPermaLink="false">http://miloriano.com/?p=152#comment-3031</guid>
		<description>Thanks for reading and commenting on the article. Let me start by pleading that (1) I was limited by space on what I could say and (2) the sins are meant to apply to all (or at least a wide range of) project management. Let's go through your comments on the "sins" so that I can reply:

Sin 1 - I agree that stable requirements are almost an impossibility, but you need to strive for them, even in SW. If you have read some of my other articles I talk about the near impossibility of firm and stable requirements, but how stablizing them to the greatest extent possible is a goal. If the requirements keep changing, how can you complete the project? It can be a matter of "scope creep" which can kill a project. I pretty much agree with your second para.

Sin 2 - I can tell that you do most of your work with private industry. With Government projects (the primary audience for the original article), resources and schedules can be set by others outside of the project and the PM sometimes has little or no input. I agree with your idea of slipping the schedule if you don't get the resources, but it can't always happen.

Sin 3 - Thanks. Processes are great, but can cause problems if they are inflexible, overstructured or become more important than the product (and sadly that does happen at times).

Sin 4 - Thanks. Agree wholeheartedly.

Sin 5 - I can accept the crticism on this one. "Bleeding edge" technology doesn't always work out in the long run. When it does, PMs using it are ahead of the curve. When it doesn't (and there are thousands of examples), it has wasted resources. Leading edge (proven) technology should be used, but the "toys" that sometimes enamor folks can cause problems. 

Sin 6 - That should be a given, but I have seen too many PMs (and other managers) who don't or can't communicate well.

Sin 7 - I guess that I just didn't have the space. Sounds like a good excuse, anyway. Some of my other articles get into specifics on good and bad people management, but even those don't get into some of the things that you mentioned. So the next time that I write an article on good/bad people management, I will keep those ideas in mind.

Again, thanks for reading and commenting on the article. I accept your comments as good criticism. 

Wayne Turk</description>
		<content:encoded><![CDATA[<p>Thanks for reading and commenting on the article. Let me start by pleading that (1) I was limited by space on what I could say and (2) the sins are meant to apply to all (or at least a wide range of) project management. Let&#8217;s go through your comments on the &#8220;sins&#8221; so that I can reply:</p>
<p>Sin 1 &#8211; I agree that stable requirements are almost an impossibility, but you need to strive for them, even in SW. If you have read some of my other articles I talk about the near impossibility of firm and stable requirements, but how stablizing them to the greatest extent possible is a goal. If the requirements keep changing, how can you complete the project? It can be a matter of &#8220;scope creep&#8221; which can kill a project. I pretty much agree with your second para.</p>
<p>Sin 2 &#8211; I can tell that you do most of your work with private industry. With Government projects (the primary audience for the original article), resources and schedules can be set by others outside of the project and the PM sometimes has little or no input. I agree with your idea of slipping the schedule if you don&#8217;t get the resources, but it can&#8217;t always happen.</p>
<p>Sin 3 &#8211; Thanks. Processes are great, but can cause problems if they are inflexible, overstructured or become more important than the product (and sadly that does happen at times).</p>
<p>Sin 4 &#8211; Thanks. Agree wholeheartedly.</p>
<p>Sin 5 &#8211; I can accept the crticism on this one. &#8220;Bleeding edge&#8221; technology doesn&#8217;t always work out in the long run. When it does, PMs using it are ahead of the curve. When it doesn&#8217;t (and there are thousands of examples), it has wasted resources. Leading edge (proven) technology should be used, but the &#8220;toys&#8221; that sometimes enamor folks can cause problems.</p>
<p>Sin 6 &#8211; That should be a given, but I have seen too many PMs (and other managers) who don&#8217;t or can&#8217;t communicate well.</p>
<p>Sin 7 &#8211; I guess that I just didn&#8217;t have the space. Sounds like a good excuse, anyway. Some of my other articles get into specifics on good and bad people management, but even those don&#8217;t get into some of the things that you mentioned. So the next time that I write an article on good/bad people management, I will keep those ideas in mind.</p>
<p>Again, thanks for reading and commenting on the article. I accept your comments as good criticism.</p>
<p>Wayne Turk</p>
]]></content:encoded>
	</item>
</channel>
</rss>
