<?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: The Best Way to Improve ROI is With Good Requirements</title>
	<atom:link href="http://tynerblain.com/blog/2006/01/06/the-best-way-to-improve-roi-is-with-good-requirements/feed/" rel="self" type="application/rss+xml" />
	<link>http://tynerblain.com/blog/2006/01/06/the-best-way-to-improve-roi-is-with-good-requirements/</link>
	<description>Software product success.</description>
	<lastBuildDate>Sun, 12 Feb 2012 19:10:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Five measures of product manager performance -Tyner Blain</title>
		<link>http://tynerblain.com/blog/2006/01/06/the-best-way-to-improve-roi-is-with-good-requirements/comment-page-1/#comment-176</link>
		<dc:creator>Five measures of product manager performance -Tyner Blain</dc:creator>
		<pubDate>Tue, 31 Jan 2006 05:10:57 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/06/the-best-way-to-improve-roi-is-with-good-requirements/#comment-176</guid>
		<description>[...] We want our projects to succeed. We believe that successful projects will occasionally lead to repeat business, and failed projects will cause us to lose long term clients by weakening our relationships. We also believe this will differentiate us from our competitors. [...]</description>
		<content:encoded><![CDATA[<p>[...] We want our projects to succeed. We believe that successful projects will occasionally lead to repeat business, and failed projects will cause us to lose long term clients by weakening our relationships. We also believe this will differentiate us from our competitors. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tom Humbarger</title>
		<link>http://tynerblain.com/blog/2006/01/06/the-best-way-to-improve-roi-is-with-good-requirements/comment-page-1/#comment-175</link>
		<dc:creator>Tom Humbarger</dc:creator>
		<pubDate>Mon, 30 Jan 2006 17:42:09 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/06/the-best-way-to-improve-roi-is-with-good-requirements/#comment-175</guid>
		<description>Related to this topic, here are links to two simple ROI Calculators that help users identify the impact of poor and missing requirments on &#039;project re-work&#039; and in &#039;project delays&#039;.

http://www.irise.com/calculators/calc_rework.shtml
http://www.irise.com/calculators/calc_delays.shtml

Additional information can be found at www.irise.com</description>
		<content:encoded><![CDATA[<p>Related to this topic, here are links to two simple ROI Calculators that help users identify the impact of poor and missing requirments on &#8216;project re-work&#8217; and in &#8216;project delays&#8217;.</p>
<p><a href="http://www.irise.com/calculators/calc_rework.shtml" rel="nofollow">http://www.irise.com/calculators/calc_rework.shtml</a><br />
<a href="http://www.irise.com/calculators/calc_delays.shtml" rel="nofollow">http://www.irise.com/calculators/calc_delays.shtml</a></p>
<p>Additional information can be found at <a href="http://www.irise.com" rel="nofollow">http://www.irise.com</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tyner Blain &#187; Requirements document proliferation</title>
		<link>http://tynerblain.com/blog/2006/01/06/the-best-way-to-improve-roi-is-with-good-requirements/comment-page-1/#comment-118</link>
		<dc:creator>Tyner Blain &#187; Requirements document proliferation</dc:creator>
		<pubDate>Sat, 21 Jan 2006 04:51:20 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/06/the-best-way-to-improve-roi-is-with-good-requirements/#comment-118</guid>
		<description>[...] Cote&#8217; suggests that we need a single person/team that &#8220;does it all&#8221;, flattening the hierarchy. Several people commented on a post here about CRUD requirements, and the discussion touches on a similar issue- drawing the line between requirements and design. Some of those folks came to the same conclusion. And I agree, when we can find supermen who can write code that solves valuable problems (which they identify), we can have great software. When we have to collaborate as a team of specialists, we need to include requirements documentation to get the best return on our investments. [...]</description>
		<content:encoded><![CDATA[<p>[...] Cote&#8217; suggests that we need a single person/team that &#8220;does it all&#8221;, flattening the hierarchy. Several people commented on a post here about CRUD requirements, and the discussion touches on a similar issue- drawing the line between requirements and design. Some of those folks came to the same conclusion. And I agree, when we can find supermen who can write code that solves valuable problems (which they identify), we can have great software. When we have to collaborate as a team of specialists, we need to include requirements documentation to get the best return on our investments. [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

