<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Bad Requirements? Actually, That&#8217;s Your Fault</title>
	<atom:link href="http://jessefewell.com/2010/07/06/bad-requirements-actually-thats-your-fault/feed/" rel="self" type="application/rss+xml" />
	<link>http://jessefewell.com/2010/07/06/bad-requirements-actually-thats-your-fault/</link>
	<description>by Jesse Fewell</description>
	<lastBuildDate>Sat, 21 Jan 2012 03:48:09 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Jesse Fewell</title>
		<link>http://jessefewell.com/2010/07/06/bad-requirements-actually-thats-your-fault/#comment-403</link>
		<dc:creator><![CDATA[Jesse Fewell]]></dc:creator>
		<pubDate>Wed, 28 Jul 2010 15:07:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.jessefewell.com/?p=675#comment-403</guid>
		<description><![CDATA[Sean, I totally agree. Many times project managers looks sight of the business case, and focus only impact changes have to a project schedule. Sometimes it makes sense to blow your budget, in order to make a lot more money down the road.]]></description>
		<content:encoded><![CDATA[<p>Sean, I totally agree. Many times project managers looks sight of the business case, and focus only impact changes have to a project schedule. Sometimes it makes sense to blow your budget, in order to make a lot more money down the road.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sean Hull</title>
		<link>http://jessefewell.com/2010/07/06/bad-requirements-actually-thats-your-fault/#comment-402</link>
		<dc:creator><![CDATA[Sean Hull]]></dc:creator>
		<pubDate>Wed, 28 Jul 2010 13:27:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.jessefewell.com/?p=675#comment-402</guid>
		<description><![CDATA[Excellent article. My two cents: create a business case for the project â€“ i.e. what part of the organizationâ€™s strategy benefits from the project and how. Then, when evaluation change (or even scope), also evaluate against the business case.]]></description>
		<content:encoded><![CDATA[<p>Excellent article. My two cents: create a business case for the project â€“ i.e. what part of the organizationâ€™s strategy benefits from the project and how. Then, when evaluation change (or even scope), also evaluate against the business case.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mauvaise dÃ©finition des exigences ? En rÃ©alitÃ©, c&#8217;est votre faute &#171; Dantotsu PM</title>
		<link>http://jessefewell.com/2010/07/06/bad-requirements-actually-thats-your-fault/#comment-401</link>
		<dc:creator><![CDATA[Mauvaise dÃ©finition des exigences ? En rÃ©alitÃ©, c&#8217;est votre faute &#171; Dantotsu PM]]></dc:creator>
		<pubDate>Tue, 20 Jul 2010 04:44:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.jessefewell.com/?p=675#comment-401</guid>
		<description><![CDATA[[...] Mauvaise dÃ©finition des exigences ? En rÃ©alitÃ©, c&#8217;est votre&#160;faute Voici un article de Jesse Fewell qui m&#8217;a paru intÃ©ressant: &#171;&#160;Bad Requirements? Actually, Thatâ€™s Your Fault&#160;&#187; [...] ]]></description>
		<content:encoded><![CDATA[<p>[...] Mauvaise dÃ©finition des exigences ? En rÃ©alitÃ©, c&#8217;est votre&nbsp;faute Voici un article de Jesse Fewell qui m&#8217;a paru intÃ©ressant: &laquo;&nbsp;Bad Requirements? Actually, Thatâ€™s Your Fault&nbsp;&raquo; [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jesse Fewell</title>
		<link>http://jessefewell.com/2010/07/06/bad-requirements-actually-thats-your-fault/#comment-400</link>
		<dc:creator><![CDATA[Jesse Fewell]]></dc:creator>
		<pubDate>Wed, 07 Jul 2010 16:13:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.jessefewell.com/?p=675#comment-400</guid>
		<description><![CDATA[Hey rich, great to hear from you. Yes, change can be tough for some people and some personalities. However, I think the difference between success and failure is not WHETHER you have change, but HOW you process and coordinate it. Every project evolves along the way. The weak PM will cry foul and complain about scope creep.  The strong PM, as Glen mentioned, will simply escalate the changes to the right decision makers, offering pros/cons/accountabilty. Change is not the enemy; fear and helplessness are the enemy. You WILL encounter change, but you are NOT helpless to do something about it.]]></description>
		<content:encoded><![CDATA[<p>Hey rich, great to hear from you. Yes, change can be tough for some people and some personalities. However, I think the difference between success and failure is not WHETHER you have change, but HOW you process and coordinate it. Every project evolves along the way. The weak PM will cry foul and complain about scope creep.  The strong PM, as Glen mentioned, will simply escalate the changes to the right decision makers, offering pros/cons/accountabilty. Change is not the enemy; fear and helplessness are the enemy. You WILL encounter change, but you are NOT helpless to do something about it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jesse Fewell</title>
		<link>http://jessefewell.com/2010/07/06/bad-requirements-actually-thats-your-fault/#comment-399</link>
		<dc:creator><![CDATA[Jesse Fewell]]></dc:creator>
		<pubDate>Wed, 07 Jul 2010 16:07:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.jessefewell.com/?p=675#comment-399</guid>
		<description><![CDATA[Glen, that is an excellent story. I find that the biggest cause of requirements / scope creep is that some big wig has his pet idea, and nobody has a recourse to politely say &quot;NO&quot;. Filtering all change requests against the stated mission of the project is a good way to support PMs in declining the latest so-called &quot;urgent need&quot;.]]></description>
		<content:encoded><![CDATA[<p>Glen, that is an excellent story. I find that the biggest cause of requirements / scope creep is that some big wig has his pet idea, and nobody has a recourse to politely say &#8220;NO&#8221;. Filtering all change requests against the stated mission of the project is a good way to support PMs in declining the latest so-called &#8220;urgent need&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rich</title>
		<link>http://jessefewell.com/2010/07/06/bad-requirements-actually-thats-your-fault/#comment-398</link>
		<dc:creator><![CDATA[Rich]]></dc:creator>
		<pubDate>Tue, 06 Jul 2010 21:35:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.jessefewell.com/?p=675#comment-398</guid>
		<description><![CDATA[hey Jesse -- great article.  i think the idea of welcoming change is tough for a lot people who have for many years been entrenched in cultures that try to fight it.  in any project undertaking there will almost always be a point or points where stakeholders will want more than you are prepared to give based on already agreed upon terms (&quot;that&#039;s not a new story - that&#039;s what I thought was being delivered today&quot;).  the ability to keep your sanity and the trust of your stakeholders in those moments is a critical skill and truly an art.    it will be interesting to see what kind of strategies and tactics teams come up with to successfully cope with that kind of  natural tension and not lose their ability to remain agile.]]></description>
		<content:encoded><![CDATA[<p>hey Jesse &#8212; great article.  i think the idea of welcoming change is tough for a lot people who have for many years been entrenched in cultures that try to fight it.  in any project undertaking there will almost always be a point or points where stakeholders will want more than you are prepared to give based on already agreed upon terms (&#8220;that&#8217;s not a new story &#8211; that&#8217;s what I thought was being delivered today&#8221;).  the ability to keep your sanity and the trust of your stakeholders in those moments is a critical skill and truly an art.    it will be interesting to see what kind of strategies and tactics teams come up with to successfully cope with that kind of  natural tension and not lose their ability to remain agile.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Glen B Alleman</title>
		<link>http://jessefewell.com/2010/07/06/bad-requirements-actually-thats-your-fault/#comment-397</link>
		<dc:creator><![CDATA[Glen B Alleman]]></dc:creator>
		<pubDate>Tue, 06 Jul 2010 21:24:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.jessefewell.com/?p=675#comment-397</guid>
		<description><![CDATA[One way in the defense and space business, we start off on a better footing with requirements, is to define what &quot;capabilities&quot; are needed for mission success. Or in the case of a commercial project, what  business capabilities are needed to fulfill the business plan.

For example there were three capabilities needed for a Hubble Robotic Servicing mission (the program got canceled).
1. Do no harm to the telescope
2. change the wide field camera
3. Attach the battery umbilical for the service module attached to Hubble to the power plug on the side of Hubble.

From there 1,000&#039;s of requirements can be &quot;flowed down,&quot; as we say.

Then several things happen.
1. When someone comes up with a requirement deep in the bowels of the project, we can ask &quot;what capability does this support.&quot;
2. When we start tossing requirements overboard, we can connect the decision to a capability that will be adjusted.

In all cases this traceability between capabilities and requirements enables the conversation of &quot;why are we doing this?&quot;]]></description>
		<content:encoded><![CDATA[<p>One way in the defense and space business, we start off on a better footing with requirements, is to define what &#8220;capabilities&#8221; are needed for mission success. Or in the case of a commercial project, what  business capabilities are needed to fulfill the business plan.</p>
<p>For example there were three capabilities needed for a Hubble Robotic Servicing mission (the program got canceled).<br />
1. Do no harm to the telescope<br />
2. change the wide field camera<br />
3. Attach the battery umbilical for the service module attached to Hubble to the power plug on the side of Hubble.</p>
<p>From there 1,000&#8242;s of requirements can be &#8220;flowed down,&#8221; as we say.</p>
<p>Then several things happen.<br />
1. When someone comes up with a requirement deep in the bowels of the project, we can ask &#8220;what capability does this support.&#8221;<br />
2. When we start tossing requirements overboard, we can connect the decision to a capability that will be adjusted.</p>
<p>In all cases this traceability between capabilities and requirements enables the conversation of &#8220;why are we doing this?&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tweets that mention Bad Requirements? Actually, Thatâ€™s Your Fault -- Topsy.com</title>
		<link>http://jessefewell.com/2010/07/06/bad-requirements-actually-thats-your-fault/#comment-396</link>
		<dc:creator><![CDATA[Tweets that mention Bad Requirements? Actually, Thatâ€™s Your Fault -- Topsy.com]]></dc:creator>
		<pubDate>Tue, 06 Jul 2010 20:17:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.jessefewell.com/?p=675#comment-396</guid>
		<description><![CDATA[[...] This post was mentioned on Twitter by Andreas Splett. Andreas Splett said: RT @sara_broca: Bad Requirements? Actually, That;s Your Fault http://bit.ly/ajWDXu #pmot [...] ]]></description>
		<content:encoded><![CDATA[<p>[...] This post was mentioned on Twitter by Andreas Splett. Andreas Splett said: RT @sara_broca: Bad Requirements? Actually, That;s Your Fault <a href="http://bit.ly/ajWDXu" rel="nofollow">http://bit.ly/ajWDXu</a> #pmot [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

