<?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 for Ben Menoza</title>
	<atom:link href="http://menoza.org/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://menoza.org</link>
	<description>Neither faster, better, nor cheaper.</description>
	<pubDate>Fri, 04 Jul 2008 06:14:39 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>Comment on 13 Ways to Guarantee Project Failure by Sal Darji</title>
		<link>http://menoza.org/2008/06/24/13-reasons-to-guarantee-project-failure/#comment-16</link>
		<dc:creator>Sal Darji</dc:creator>
		<pubDate>Wed, 25 Jun 2008 18:42:24 +0000</pubDate>
		<guid isPermaLink="false">http://menoza.org/?p=11#comment-16</guid>
		<description>&lt;strong&gt;Document Storage&lt;/strong&gt;
When possible, make sure to have as many dispersed repositories for document storage as possible.  Providing varying levels of access to different team members is also suggested.  Obviously, you never want to turn on versioning or track changes.  And lastly, documents should always be saved in a different format than the previous one, and opened using multiple platforms.  For example, if the document was first saved in a .DOC format in Microsoft Windows, it should then be saved as an .ODF file using Linux.</description>
		<content:encoded><![CDATA[<p><strong>Document Storage</strong><br />
When possible, make sure to have as many dispersed repositories for document storage as possible.  Providing varying levels of access to different team members is also suggested.  Obviously, you never want to turn on versioning or track changes.  And lastly, documents should always be saved in a different format than the previous one, and opened using multiple platforms.  For example, if the document was first saved in a .DOC format in Microsoft Windows, it should then be saved as an .ODF file using Linux.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on 13 Ways to Guarantee Project Failure by Jim Coleman</title>
		<link>http://menoza.org/2008/06/24/13-reasons-to-guarantee-project-failure/#comment-15</link>
		<dc:creator>Jim Coleman</dc:creator>
		<pubDate>Tue, 24 Jun 2008 21:56:34 +0000</pubDate>
		<guid isPermaLink="false">http://menoza.org/?p=11#comment-15</guid>
		<description>Suggestion #3
Requirements, Use Cases, Wireframes, Demos, Production...but not necessarily in that order.</description>
		<content:encoded><![CDATA[<p>Suggestion #3<br />
Requirements, Use Cases, Wireframes, Demos, Production&#8230;but not necessarily in that order.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on 13 Ways to Guarantee Project Failure by Jim Coleman</title>
		<link>http://menoza.org/2008/06/24/13-reasons-to-guarantee-project-failure/#comment-14</link>
		<dc:creator>Jim Coleman</dc:creator>
		<pubDate>Tue, 24 Jun 2008 21:55:49 +0000</pubDate>
		<guid isPermaLink="false">http://menoza.org/?p=11#comment-14</guid>
		<description>Suggestion # 2
End Users should be consulted as such ... at the END.</description>
		<content:encoded><![CDATA[<p>Suggestion # 2<br />
End Users should be consulted as such &#8230; at the END.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on 13 Ways to Guarantee Project Failure by Jim Coleman</title>
		<link>http://menoza.org/2008/06/24/13-reasons-to-guarantee-project-failure/#comment-13</link>
		<dc:creator>Jim Coleman</dc:creator>
		<pubDate>Tue, 24 Jun 2008 21:54:09 +0000</pubDate>
		<guid isPermaLink="false">http://menoza.org/?p=11#comment-13</guid>
		<description>Suggestion #1
Never Base your technology choices on the requirements needed for your project... that's too time consuming... let the technology choose you.</description>
		<content:encoded><![CDATA[<p>Suggestion #1<br />
Never Base your technology choices on the requirements needed for your project&#8230; that&#8217;s too time consuming&#8230; let the technology choose you.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on A Good Mixtape Website, Like Breaking Up, is Hard to Do by terry</title>
		<link>http://menoza.org/2008/05/07/a-good-mixtape-website-like-breaking-up-is-hard-to-do/#comment-2</link>
		<dc:creator>terry</dc:creator>
		<pubDate>Fri, 09 May 2008 15:33:16 +0000</pubDate>
		<guid isPermaLink="false">http://menoza.org/?p=9#comment-2</guid>
		<description>muxtape = works on iphone.

i'm not sure why, but i think muxtape's simplicity is really compelling. you just load someone's muxtape, and it's obvious what to do. i thought mixwit was a lot less obvious.</description>
		<content:encoded><![CDATA[<p>muxtape = works on iphone.</p>
<p>i&#8217;m not sure why, but i think muxtape&#8217;s simplicity is really compelling. you just load someone&#8217;s muxtape, and it&#8217;s obvious what to do. i thought mixwit was a lot less obvious.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
