<?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: Avoiding Project Management Landmines</title>
	<atom:link href="http://www.pmhut.com/avoiding-project-management-landmines/feed" rel="self" type="application/rss+xml" />
	<link>http://www.pmhut.com/avoiding-project-management-landmines</link>
	<description></description>
	<pubDate>Sat, 11 Feb 2012 22:29:13 +0000</pubDate>
	<generator>http://wordpress.org/?v=abc</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Jim Clarke</title>
		<link>http://www.pmhut.com/avoiding-project-management-landmines/comment-page-1#comment-8619</link>
		<dc:creator>Jim Clarke</dc:creator>
		<pubDate>Mon, 24 Aug 2009 21:15:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.pmhut.com/?p=3578#comment-8619</guid>
		<description>Jeffery makes a good point, in that, if you break a large project into smaller implementations, then you run the risk of increasing cost through resulting additional overhead.  Jeffery's ideas on change requests may be true ... multiple small implementations could result in fewer CR's.

My reason for addressing the "Light Switch" error was due to one of the most common sayings regarding change ... "Change should be a process, and not an event".

The event-driven project gets very confusing immediately after implementation due to a vast number of change variables.  Implementing the project in smaller pieces has the effect of isolating the possible causes of unplanned consequences.  This makes for a more managed approach to the project that allows for more time for careful analysis of problems before moving on to the next phase of implementation.

- JC</description>
		<content:encoded><![CDATA[<p>Jeffery makes a good point, in that, if you break a large project into smaller implementations, then you run the risk of increasing cost through resulting additional overhead.  Jeffery&#8217;s ideas on change requests may be true &#8230; multiple small implementations could result in fewer CR&#8217;s.</p>
<p>My reason for addressing the &#8220;Light Switch&#8221; error was due to one of the most common sayings regarding change &#8230; &#8220;Change should be a process, and not an event&#8221;.</p>
<p>The event-driven project gets very confusing immediately after implementation due to a vast number of change variables.  Implementing the project in smaller pieces has the effect of isolating the possible causes of unplanned consequences.  This makes for a more managed approach to the project that allows for more time for careful analysis of problems before moving on to the next phase of implementation.</p>
<p>- JC</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeffery</title>
		<link>http://www.pmhut.com/avoiding-project-management-landmines/comment-page-1#comment-8420</link>
		<dc:creator>Jeffery</dc:creator>
		<pubDate>Mon, 17 Aug 2009 19:18:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.pmhut.com/?p=3578#comment-8420</guid>
		<description>I don't understand how your proposed solution to the first point works. If you split the project into mini-projects, will you have less change requests? Have you thought about the overhead of integration later on, and the bugs resulting from this.

For the records, I totally agree with you on #5, I, as well as many Project Managers, have been (and continue to getting constantly) burnt by it.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t understand how your proposed solution to the first point works. If you split the project into mini-projects, will you have less change requests? Have you thought about the overhead of integration later on, and the bugs resulting from this.</p>
<p>For the records, I totally agree with you on #5, I, as well as many Project Managers, have been (and continue to getting constantly) burnt by it.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

