<?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: Don&#8217;t Prevent My Success</title>
	<atom:link href="http://tynerblain.com/blog/2006/10/19/dont-prevent-my-success/feed/" rel="self" type="application/rss+xml" />
	<link>http://tynerblain.com/blog/2006/10/19/dont-prevent-my-success/</link>
	<description>Software product success.</description>
	<lastBuildDate>Tue, 22 May 2012 20:46:27 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Scott Sehlhorst</title>
		<link>http://tynerblain.com/blog/2006/10/19/dont-prevent-my-success/comment-page-1/#comment-55868</link>
		<dc:creator>Scott Sehlhorst</dc:creator>
		<pubDate>Wed, 25 Oct 2006 05:53:26 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/10/19/dont-prevent-my-success/#comment-55868</guid>
		<description>Great points Sandy!  Thanks for the comments and continued reading.

This project is, as you suggest, an enterprise software system migration project.  The engagement contractually defines a sequence of &quot;deploy new system with minimal process change&quot; followed by &quot;explore process re-engineering that is enabled by new-system functionality.&quot;  This decision solves some problems, and introduces others.

Six of one, half dozen of the other.

I believe that the implementation approach is one that will not prevent future access to underlying functionality, although I&#039;m not involved in those implementation decisions.  Used to be.  Not this time.</description>
		<content:encoded><![CDATA[<p>Great points Sandy!  Thanks for the comments and continued reading.</p>
<p>This project is, as you suggest, an enterprise software system migration project.  The engagement contractually defines a sequence of &#8220;deploy new system with minimal process change&#8221; followed by &#8220;explore process re-engineering that is enabled by new-system functionality.&#8221;  This decision solves some problems, and introduces others.</p>
<p>Six of one, half dozen of the other.</p>
<p>I believe that the implementation approach is one that will not prevent future access to underlying functionality, although I&#8217;m not involved in those implementation decisions.  Used to be.  Not this time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sandy Kemsley</title>
		<link>http://tynerblain.com/blog/2006/10/19/dont-prevent-my-success/comment-page-1/#comment-55854</link>
		<dc:creator>Sandy Kemsley</dc:creator>
		<pubDate>Tue, 24 Oct 2006 20:00:45 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/10/19/dont-prevent-my-success/#comment-55854</guid>
		<description>Scott, you present some valid points about expectations and functionality, especially as it pertains to older development environments, where everything had to be built to order and therefore a function did not exist if it was not specified. There are many newer development environments today, however, such as the BPM systems that I commonly work with, where the systems are hugely functional and user-customizable, and could probably do whatever a business owner requires. The problem occurs when the implementation team -- whether internal or external -- writes a massive amount of customization code that effectively cuts off access to much of the native functionality of the underlying system. I don&#039;t think that allowing direct access to every bit of functionality is a panacea for business expectations, but I do believe that over-customization is definitely a problem in meeting the requirements -- both stated and unstated -- of the business.</description>
		<content:encoded><![CDATA[<p>Scott, you present some valid points about expectations and functionality, especially as it pertains to older development environments, where everything had to be built to order and therefore a function did not exist if it was not specified. There are many newer development environments today, however, such as the BPM systems that I commonly work with, where the systems are hugely functional and user-customizable, and could probably do whatever a business owner requires. The problem occurs when the implementation team &#8212; whether internal or external &#8212; writes a massive amount of customization code that effectively cuts off access to much of the native functionality of the underlying system. I don&#8217;t think that allowing direct access to every bit of functionality is a panacea for business expectations, but I do believe that over-customization is definitely a problem in meeting the requirements &#8212; both stated and unstated &#8212; of the business.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Deepak</title>
		<link>http://tynerblain.com/blog/2006/10/19/dont-prevent-my-success/comment-page-1/#comment-55779</link>
		<dc:creator>Deepak</dc:creator>
		<pubDate>Sun, 22 Oct 2006 19:28:42 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/10/19/dont-prevent-my-success/#comment-55779</guid>
		<description>Indeed.  Last thing you want is your brightest minds losing interest and thinking that their talents are not important any more.  How those objective ideas are conveyed is important as you suggest</description>
		<content:encoded><![CDATA[<p>Indeed.  Last thing you want is your brightest minds losing interest and thinking that their talents are not important any more.  How those objective ideas are conveyed is important as you suggest</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Sehlhorst</title>
		<link>http://tynerblain.com/blog/2006/10/19/dont-prevent-my-success/comment-page-1/#comment-55739</link>
		<dc:creator>Scott Sehlhorst</dc:creator>
		<pubDate>Sun, 22 Oct 2006 02:53:57 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/10/19/dont-prevent-my-success/#comment-55739</guid>
		<description>Thanks Deepak!

And your insight is great too.  I&#039;ve always tried (with varying degrees of success) to use objectivity to guide my passions.  Definitely a tough balance to strike.

Your comment makes me think of this too - it is important to not squash someone&#039;s passion when helping them absorb an objective analysis.  Redirecting the passion will help them continue to contribute to the project, and to generally enjoy life more.</description>
		<content:encoded><![CDATA[<p>Thanks Deepak!</p>
<p>And your insight is great too.  I&#8217;ve always tried (with varying degrees of success) to use objectivity to guide my passions.  Definitely a tough balance to strike.</p>
<p>Your comment makes me think of this too &#8211; it is important to not squash someone&#8217;s passion when helping them absorb an objective analysis.  Redirecting the passion will help them continue to contribute to the project, and to generally enjoy life more.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Deepak</title>
		<link>http://tynerblain.com/blog/2006/10/19/dont-prevent-my-success/comment-page-1/#comment-55727</link>
		<dc:creator>Deepak</dc:creator>
		<pubDate>Sat, 21 Oct 2006 18:40:55 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/10/19/dont-prevent-my-success/#comment-55727</guid>
		<description>Wonderful series of posts lately, and something we have all seen way too often and been guilty off ourselves.  I will add this though.  The really successful are those that find the right balance between passion and objectivity.</description>
		<content:encoded><![CDATA[<p>Wonderful series of posts lately, and something we have all seen way too often and been guilty off ourselves.  I will add this though.  The really successful are those that find the right balance between passion and objectivity.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

