<?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: Knowing When To Stop</title>
	<atom:link href="http://effectivecio.com/2009/10/30/knowing-when-to-stop/feed/" rel="self" type="application/rss+xml" />
	<link>http://effectivecio.com/2009/10/30/knowing-when-to-stop/</link>
	<description>...ruminations on many things, all ultimately related to effective IT leadership...</description>
	<lastBuildDate>Wed, 21 Dec 2011 22:44:50 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Warsha Bhatia</title>
		<link>http://effectivecio.com/2009/10/30/knowing-when-to-stop/#comment-2325</link>
		<dc:creator><![CDATA[Warsha Bhatia]]></dc:creator>
		<pubDate>Sun, 28 Aug 2011 07:52:01 +0000</pubDate>
		<guid isPermaLink="false">http://effectivecio.com/?p=1453#comment-2325</guid>
		<description><![CDATA[Perfection depends on perception too ... 

One way I sell the &quot;good enough&quot; to my management is by INSISTING that the core solution be built and tested first. This way we can launch any time ... as the deadline nears &amp; if there are roadblocks to completion, we launch with the basic service and no one complains. 

Warsha.Bhatia@gmail.com]]></description>
		<content:encoded><![CDATA[<p>Perfection depends on perception too &#8230; </p>
<p>One way I sell the &#8220;good enough&#8221; to my management is by INSISTING that the core solution be built and tested first. This way we can launch any time &#8230; as the deadline nears &amp; if there are roadblocks to completion, we launch with the basic service and no one complains. </p>
<p><a href="mailto:Warsha.Bhatia@gmail.com">Warsha.Bhatia@gmail.com</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Links for November 1 2009 &#124; Eric D. Brown - Technology, Strategy, People, Projects</title>
		<link>http://effectivecio.com/2009/10/30/knowing-when-to-stop/#comment-1061</link>
		<dc:creator><![CDATA[Links for November 1 2009 &#124; Eric D. Brown - Technology, Strategy, People, Projects]]></dc:creator>
		<pubDate>Sun, 01 Nov 2009 13:55:34 +0000</pubDate>
		<guid isPermaLink="false">http://effectivecio.com/?p=1453#comment-1061</guid>
		<description><![CDATA[[...] Knowing When To Stop by Chuck Musciano on The Effective CIO [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Knowing When To Stop by Chuck Musciano on The Effective CIO [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wayne Bogan</title>
		<link>http://effectivecio.com/2009/10/30/knowing-when-to-stop/#comment-1060</link>
		<dc:creator><![CDATA[Wayne Bogan]]></dc:creator>
		<pubDate>Sat, 31 Oct 2009 15:23:40 +0000</pubDate>
		<guid isPermaLink="false">http://effectivecio.com/?p=1453#comment-1060</guid>
		<description><![CDATA[Good Post Chuck.  Very similar to the concept outlined in the Innovators Dilemma where lower quality steel production from Nucor ended up taking over the industry of what &quot;had to be produced&quot;.  I like the idea of the executive sponsor coming back and reviewing where things are.  One challenge I see, however, is that sometimes the vision of the executive sponsor is not being met because they did not realize how much detail was required to achieve their vision.  They need to be astute enough to understand that when it is good enough versus what they greatly desired in the first place.  If they can, great.  If not, they will drive the project deeper into the last 20% than the developers.  Thoughts?]]></description>
		<content:encoded><![CDATA[<p>Good Post Chuck.  Very similar to the concept outlined in the Innovators Dilemma where lower quality steel production from Nucor ended up taking over the industry of what &#8220;had to be produced&#8221;.  I like the idea of the executive sponsor coming back and reviewing where things are.  One challenge I see, however, is that sometimes the vision of the executive sponsor is not being met because they did not realize how much detail was required to achieve their vision.  They need to be astute enough to understand that when it is good enough versus what they greatly desired in the first place.  If they can, great.  If not, they will drive the project deeper into the last 20% than the developers.  Thoughts?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Charnovich</title>
		<link>http://effectivecio.com/2009/10/30/knowing-when-to-stop/#comment-1059</link>
		<dc:creator><![CDATA[John Charnovich]]></dc:creator>
		<pubDate>Fri, 30 Oct 2009 19:45:17 +0000</pubDate>
		<guid isPermaLink="false">http://effectivecio.com/?p=1453#comment-1059</guid>
		<description><![CDATA[A Trusted Technology Partner and Strategy Consultant makes for a very good &quot;Sudden Interrupter&quot;.  They are totally unbiased and do not have to keep score or worry about emotions of the players involved.  I know of a few good ones..]]></description>
		<content:encoded><![CDATA[<p>A Trusted Technology Partner and Strategy Consultant makes for a very good &#8220;Sudden Interrupter&#8221;.  They are totally unbiased and do not have to keep score or worry about emotions of the players involved.  I know of a few good ones..</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chuck Musciano</title>
		<link>http://effectivecio.com/2009/10/30/knowing-when-to-stop/#comment-1057</link>
		<dc:creator><![CDATA[Chuck Musciano]]></dc:creator>
		<pubDate>Fri, 30 Oct 2009 14:10:44 +0000</pubDate>
		<guid isPermaLink="false">http://effectivecio.com/?p=1453#comment-1057</guid>
		<description><![CDATA[I also think that the executive sponsor is a good sudden interrupter.  They have a high-level grasp of what they are trying to accomplish, they are often astounded at the detail that results from that vision, and they have the clout to eliminate features quickly.

As to testing, come back on Monday...]]></description>
		<content:encoded><![CDATA[<p>I also think that the executive sponsor is a good sudden interrupter.  They have a high-level grasp of what they are trying to accomplish, they are often astounded at the detail that results from that vision, and they have the clout to eliminate features quickly.</p>
<p>As to testing, come back on Monday&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: KAebischer</title>
		<link>http://effectivecio.com/2009/10/30/knowing-when-to-stop/#comment-1056</link>
		<dc:creator><![CDATA[KAebischer]]></dc:creator>
		<pubDate>Fri, 30 Oct 2009 13:47:31 +0000</pubDate>
		<guid isPermaLink="false">http://effectivecio.com/?p=1453#comment-1056</guid>
		<description><![CDATA[I remember a Microsoft developer saying that a trait he looks for in programmer is the ability to manage the balance between doing things right, and doing them right now.  In most cases perfection is indeed the enemy of good enough.  

Though we don&#039;t have anyone with the &quot;sudden interrupter&quot; title, we often use a member of the exec team championing a project for this role.  They understand the project but don&#039;t regularly get involved in the details.  As a result, they are often able to come to meetings when things are off track reset the focus.  Sometimes its a simple concession on features and other times it&#039;s bringing up work arounds to some issue those emersed in the project came to believe was a must.

Slightly off topic, but I&#039;m curious to see how you feel this doesn&#039;t apply to testing.  In my experience, the same issues exist there.  In any system of even mild complexity, the test landscape is too vast to cover all possibilities.  In this case you&#039;re mitigating risk (of going live with something with a serious flaw) versus never going live at all (due to too much time spent testing).]]></description>
		<content:encoded><![CDATA[<p>I remember a Microsoft developer saying that a trait he looks for in programmer is the ability to manage the balance between doing things right, and doing them right now.  In most cases perfection is indeed the enemy of good enough.  </p>
<p>Though we don&#8217;t have anyone with the &#8220;sudden interrupter&#8221; title, we often use a member of the exec team championing a project for this role.  They understand the project but don&#8217;t regularly get involved in the details.  As a result, they are often able to come to meetings when things are off track reset the focus.  Sometimes its a simple concession on features and other times it&#8217;s bringing up work arounds to some issue those emersed in the project came to believe was a must.</p>
<p>Slightly off topic, but I&#8217;m curious to see how you feel this doesn&#8217;t apply to testing.  In my experience, the same issues exist there.  In any system of even mild complexity, the test landscape is too vast to cover all possibilities.  In this case you&#8217;re mitigating risk (of going live with something with a serious flaw) versus never going live at all (due to too much time spent testing).</p>
]]></content:encoded>
	</item>
</channel>
</rss>

