<?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: Project Processes Part I &#8211; The mechanics</title>
	<atom:link href="http://svprojectmanagement.com/project-processes-part-i-the-mechanics/feed" rel="self" type="application/rss+xml" />
	<link>http://svprojectmanagement.com/project-processes-part-i-the-mechanics</link>
	<description>Project management wisdom from practictioners and the UCSC Extension in Silicon Valley</description>
	<lastBuildDate>Tue, 16 Mar 2010 03:47:39 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
	<item>
		<title>By: Anuradha (Anu) Subramanian</title>
		<link>http://svprojectmanagement.com/project-processes-part-i-the-mechanics/comment-page-1#comment-5703</link>
		<dc:creator>Anuradha (Anu) Subramanian</dc:creator>
		<pubDate>Tue, 23 Jun 2009 15:24:14 +0000</pubDate>
		<guid isPermaLink="false">http://svprojectmanagement.com/?p=2620#comment-5703</guid>
		<description>Each of these can equally hard, IMHO, depending on the problem at hand. I&#039;ve found it best to implement lifecycle changes in parts so there is incremental progress, and also because people do not take to big changes easily. So, really then it&#039;s the same set of difficulties as it&#039;s really just a list of minor problems. 

In general, if you can involve people in architecting the change, they will become vested in it. That&#039;s the best way to make it happen. If you can break down a big lifecycle change into smaller minor parts you&#039;re looking at more opportunities to involve different sets of people.</description>
		<content:encoded><![CDATA[<p>Each of these can equally hard, IMHO, depending on the problem at hand. I&#8217;ve found it best to implement lifecycle changes in parts so there is incremental progress, and also because people do not take to big changes easily. So, really then it&#8217;s the same set of difficulties as it&#8217;s really just a list of minor problems. </p>
<p>In general, if you can involve people in architecting the change, they will become vested in it. That&#8217;s the best way to make it happen. If you can break down a big lifecycle change into smaller minor parts you&#8217;re looking at more opportunities to involve different sets of people.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Loyal Mealer</title>
		<link>http://svprojectmanagement.com/project-processes-part-i-the-mechanics/comment-page-1#comment-5677</link>
		<dc:creator>Loyal Mealer</dc:creator>
		<pubDate>Tue, 23 Jun 2009 00:09:22 +0000</pubDate>
		<guid isPermaLink="false">http://svprojectmanagement.com/?p=2620#comment-5677</guid>
		<description>Excellent post. i love your list of things to consider when developing or changing a project process. So, what do you find is the hardest? Implementing a new lifecycle? Or more minor things like getting everyone to use the same code control environment?</description>
		<content:encoded><![CDATA[<p>Excellent post. i love your list of things to consider when developing or changing a project process. So, what do you find is the hardest? Implementing a new lifecycle? Or more minor things like getting everyone to use the same code control environment?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
