<?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: Customization: Risk vs. Reward</title>
	<atom:link href="http://blog.lawsonguru.com/2008/10/15/customization-risk-vs-reward/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.lawsonguru.com/2008/10/15/customization-risk-vs-reward/</link>
	<description>Thought-Provoking Commentary for the Lawson Software Community</description>
	<lastBuildDate>Thu, 02 Sep 2010 17:21:13 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Should You Customize Open Source ERP? &#8212; Open Source Strategies, Inc.</title>
		<link>http://blog.lawsonguru.com/2008/10/15/customization-risk-vs-reward/#comment-330</link>
		<dc:creator>Should You Customize Open Source ERP? &#8212; Open Source Strategies, Inc.</dc:creator>
		<pubDate>Wed, 17 Mar 2010 19:34:08 +0000</pubDate>
		<guid isPermaLink="false">http://lawsonguru.wordpress.com/2008/10/15/customization-risk-vs-reward/#comment-330</guid>
		<description>[...] I have seen on this comes from my friend, John Henley of Decision Analytics. Henley details some advantages to customizing an application. They [...]</description>
		<content:encoded><![CDATA[<p>[...] I have seen on this comes from my friend, John Henley of Decision Analytics. Henley details some advantages to customizing an application. They [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: MTFF</title>
		<link>http://blog.lawsonguru.com/2008/10/15/customization-risk-vs-reward/#comment-162</link>
		<dc:creator>MTFF</dc:creator>
		<pubDate>Thu, 11 Dec 2008 16:29:18 +0000</pubDate>
		<guid isPermaLink="false">http://lawsonguru.wordpress.com/2008/10/15/customization-risk-vs-reward/#comment-162</guid>
		<description>Another reason to avoid custom coding is Technical Debt!</description>
		<content:encoded><![CDATA[<p>Another reason to avoid custom coding is Technical Debt!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alex Ladjimi</title>
		<link>http://blog.lawsonguru.com/2008/10/15/customization-risk-vs-reward/#comment-160</link>
		<dc:creator>Alex Ladjimi</dc:creator>
		<pubDate>Mon, 01 Dec 2008 14:51:34 +0000</pubDate>
		<guid isPermaLink="false">http://lawsonguru.wordpress.com/2008/10/15/customization-risk-vs-reward/#comment-160</guid>
		<description>I have a very strong feelings with this issue and they are very basic.

1.) If the product is working properly, ..........

2.) Look and see if a change in shop methodology is not a more appropriate answer than altering code.

I always try to explain to my clients that jumping on the code and making changes may not be the answer.</description>
		<content:encoded><![CDATA[<p>I have a very strong feelings with this issue and they are very basic.</p>
<p>1.) If the product is working properly, &#8230;&#8230;&#8230;.</p>
<p>2.) Look and see if a change in shop methodology is not a more appropriate answer than altering code.</p>
<p>I always try to explain to my clients that jumping on the code and making changes may not be the answer.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phil Simon</title>
		<link>http://blog.lawsonguru.com/2008/10/15/customization-risk-vs-reward/#comment-158</link>
		<dc:creator>Phil Simon</dc:creator>
		<pubDate>Sat, 01 Nov 2008 16:40:34 +0000</pubDate>
		<guid isPermaLink="false">http://lawsonguru.wordpress.com/2008/10/15/customization-risk-vs-reward/#comment-158</guid>
		<description>Far be it from me to argue with a guy who uses golf analogies (like I do), but I take a bit of issue with this:

3. The best method to keep / retain competitive advantage is to build your own software.

Maybe, maybe not.  If the internal resources can&#039;t handle the mod&#039;s, then you&#039;re left scrambling.  One Lawson client has so many internal experts that they regularly tweak the code but I would never recommend that unless IT could handle it.</description>
		<content:encoded><![CDATA[<p>Far be it from me to argue with a guy who uses golf analogies (like I do), but I take a bit of issue with this:</p>
<p>3. The best method to keep / retain competitive advantage is to build your own software.</p>
<p>Maybe, maybe not.  If the internal resources can&#8217;t handle the mod&#8217;s, then you&#8217;re left scrambling.  One Lawson client has so many internal experts that they regularly tweak the code but I would never recommend that unless IT could handle it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: MTFF</title>
		<link>http://blog.lawsonguru.com/2008/10/15/customization-risk-vs-reward/#comment-154</link>
		<dc:creator>MTFF</dc:creator>
		<pubDate>Mon, 20 Oct 2008 00:54:11 +0000</pubDate>
		<guid isPermaLink="false">http://lawsonguru.wordpress.com/2008/10/15/customization-risk-vs-reward/#comment-154</guid>
		<description>To customize or not customize?

The &quot;usual&quot; justification to customize a COTS package has been &quot;core competencies&quot;, or &quot;we do things differently, which is what makes us better&quot;. 

Before I continue, let me say this first. I personally have benefited from business requirements to customize software, i.e. I have a job. With that said, I am an OPPONENT of customizing COTS. I have 3 of reasons.

1.	Arguments for customizing “we do things differently, which makes us better” are flawed. Professional Photographer and an amateur photographer, both have a Nikon D90 camera, yet, the pictures they take, will come out drastically different. It’s not the “tool”, its how you use it. Software is a tool for us to run our business. I am a firm believer of using the right tool for the right job, with that said, one can argue the COTS is not the right “tool”; therefore, we need to make the tool better. Which leads me to my second reason? 

2.	Does anyone know how to measure the benefits of customization? I mean no holds barred, detailed analysis; including the cost of tech staff needed to maintain the code, fix it when there are problems, then, compare that cost to the benefits gained. I am willing to bet, NO ONE. Usually, this is a self-cheating exercise, because the cost/benefit analysis is done by the same people that approved / implemented the project. Unlike golf, which the players are required to be honest and keep their own scores………….

To have a true competitive advantage over your competitors, you can use the SAME tool better than them by hiring the right people. We see this example everyday in the work place. A task that takes the “right’ person 5 minutes, takes someone else 15. 

3.	The best method to keep / retain competitive advantage is to build your own software. By the time you spend the resources on the COTS, you may well have build your own. This also eliminates one other source of waste, un-used modules. I am wiling to bet, the COTS were sold as a “package”, and there are un-used components you paid for. 

Customizing COTS, is the same as taking steroids. What is the ongoing cost to the body? It’s better to exercise and build lasting strength by developing your employees or build your own software.</description>
		<content:encoded><![CDATA[<p>To customize or not customize?</p>
<p>The &#8220;usual&#8221; justification to customize a COTS package has been &#8220;core competencies&#8221;, or &#8220;we do things differently, which is what makes us better&#8221;. </p>
<p>Before I continue, let me say this first. I personally have benefited from business requirements to customize software, i.e. I have a job. With that said, I am an OPPONENT of customizing COTS. I have 3 of reasons.</p>
<p>1.	Arguments for customizing “we do things differently, which makes us better” are flawed. Professional Photographer and an amateur photographer, both have a Nikon D90 camera, yet, the pictures they take, will come out drastically different. It’s not the “tool”, its how you use it. Software is a tool for us to run our business. I am a firm believer of using the right tool for the right job, with that said, one can argue the COTS is not the right “tool”; therefore, we need to make the tool better. Which leads me to my second reason? </p>
<p>2.	Does anyone know how to measure the benefits of customization? I mean no holds barred, detailed analysis; including the cost of tech staff needed to maintain the code, fix it when there are problems, then, compare that cost to the benefits gained. I am willing to bet, NO ONE. Usually, this is a self-cheating exercise, because the cost/benefit analysis is done by the same people that approved / implemented the project. Unlike golf, which the players are required to be honest and keep their own scores………….</p>
<p>To have a true competitive advantage over your competitors, you can use the SAME tool better than them by hiring the right people. We see this example everyday in the work place. A task that takes the “right’ person 5 minutes, takes someone else 15. </p>
<p>3.	The best method to keep / retain competitive advantage is to build your own software. By the time you spend the resources on the COTS, you may well have build your own. This also eliminates one other source of waste, un-used modules. I am wiling to bet, the COTS were sold as a “package”, and there are un-used components you paid for. </p>
<p>Customizing COTS, is the same as taking steroids. What is the ongoing cost to the body? It’s better to exercise and build lasting strength by developing your employees or build your own software.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
