<?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 Real Reason Outsourcing Continues To Fail</title>
	<atom:link href="http://www.lessonsoffailure.com/developers/real-reason-outsourcing-fails/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.lessonsoffailure.com/developers/real-reason-outsourcing-fails/</link>
	<description>Humans + Software Development = Always Interesting</description>
	<lastBuildDate>Fri, 03 Sep 2010 20:35:44 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Top Three Motivators For Developers (Hint: not money!) &#124; Lessons of Failure</title>
		<link>http://www.lessonsoffailure.com/developers/real-reason-outsourcing-fails/comment-page-1/#comment-354</link>
		<dc:creator>Top Three Motivators For Developers (Hint: not money!) &#124; Lessons of Failure</dc:creator>
		<pubDate>Tue, 13 Apr 2010 15:48:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.lessonsoffailure.com/?p=277#comment-354</guid>
		<description>[...] The Real Reason Outsourcing Continues To Fail [...]</description>
		<content:encoded><![CDATA[<p>[...] The Real Reason Outsourcing Continues To Fail [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: 8xSolutions.com</title>
		<link>http://www.lessonsoffailure.com/developers/real-reason-outsourcing-fails/comment-page-1/#comment-243</link>
		<dc:creator>8xSolutions.com</dc:creator>
		<pubDate>Mon, 08 Mar 2010 16:58:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.lessonsoffailure.com/?p=277#comment-243</guid>
		<description>The point is that you need to find trustworthy outsource partner...</description>
		<content:encoded><![CDATA[<p>The point is that you need to find trustworthy outsource partner&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Min Power</title>
		<link>http://www.lessonsoffailure.com/developers/real-reason-outsourcing-fails/comment-page-1/#comment-223</link>
		<dc:creator>Min Power</dc:creator>
		<pubDate>Tue, 02 Mar 2010 19:20:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.lessonsoffailure.com/?p=277#comment-223</guid>
		<description>This aligns with what I have observed.  I have noted that the outsourcing company will give you *exactly* what you asked for.  This may sound great, but there is a lot of back and forth to settling on how the final product will function.  It could be said that this is just part of contracting work.  But I&#039;ve found that the engineers don&#039;t do much probing when it comes to hashing out the details of requirements.  The subject matter experts from the from the buyer can sometimes tend to tell the developers *how* to do it instead of telling them what needs to be done and letting the developers figure out the best way how.  Or worse yet, you won&#039;t get any true SMEs and you will get requirements like &quot;make it work like the current one does&quot;.  Then 6 months later you get a million dollar copy of the system that you already have.  American developers don&#039;t have a problem being pushy and telling the managers that their crazy schedule won&#039;t fly.  It may cause conflict, but it generally results in better products and sets realistic expectations for the end users.</description>
		<content:encoded><![CDATA[<p>This aligns with what I have observed.  I have noted that the outsourcing company will give you *exactly* what you asked for.  This may sound great, but there is a lot of back and forth to settling on how the final product will function.  It could be said that this is just part of contracting work.  But I&#8217;ve found that the engineers don&#8217;t do much probing when it comes to hashing out the details of requirements.  The subject matter experts from the from the buyer can sometimes tend to tell the developers *how* to do it instead of telling them what needs to be done and letting the developers figure out the best way how.  Or worse yet, you won&#8217;t get any true SMEs and you will get requirements like &#8220;make it work like the current one does&#8221;.  Then 6 months later you get a million dollar copy of the system that you already have.  American developers don&#8217;t have a problem being pushy and telling the managers that their crazy schedule won&#8217;t fly.  It may cause conflict, but it generally results in better products and sets realistic expectations for the end users.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dimitar Bakardzhiev</title>
		<link>http://www.lessonsoffailure.com/developers/real-reason-outsourcing-fails/comment-page-1/#comment-210</link>
		<dc:creator>Dimitar Bakardzhiev</dc:creator>
		<pubDate>Sat, 27 Feb 2010 08:49:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.lessonsoffailure.com/?p=277#comment-210</guid>
		<description>It is a pity there is no PDI data for Bulgaria, even though we are ranked 10th for year 2009. From my experience I would say that what I consider the main reason for our strong relationships with clients is that we are proactive. It means not only communicate openly but always try to present ideas about how to make the product better.</description>
		<content:encoded><![CDATA[<p>It is a pity there is no PDI data for Bulgaria, even though we are ranked 10th for year 2009. From my experience I would say that what I consider the main reason for our strong relationships with clients is that we are proactive. It means not only communicate openly but always try to present ideas about how to make the product better.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Five Pervasive Myths About Older Software Developers &#124; Lessons of Failure</title>
		<link>http://www.lessonsoffailure.com/developers/real-reason-outsourcing-fails/comment-page-1/#comment-139</link>
		<dc:creator>Five Pervasive Myths About Older Software Developers &#124; Lessons of Failure</dc:creator>
		<pubDate>Tue, 23 Feb 2010 16:04:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.lessonsoffailure.com/?p=277#comment-139</guid>
		<description>[...] The Real Reason Outsourcing Continues To Fail [...]</description>
		<content:encoded><![CDATA[<p>[...] The Real Reason Outsourcing Continues To Fail [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitry Leskov</title>
		<link>http://www.lessonsoffailure.com/developers/real-reason-outsourcing-fails/comment-page-1/#comment-118</link>
		<dc:creator>Dmitry Leskov</dc:creator>
		<pubDate>Thu, 28 Jan 2010 11:24:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.lessonsoffailure.com/?p=277#comment-118</guid>
		<description>It&#039;s a pity Russia was not included in the research you are referring to. Given the historical retrospective, I would expect its PDI index to be well above the US, but I can tell you that it is much lower in IT companies selling their products and services primarily on the international market. 

We are small (20+ people), but sell out product to and do consulting work for companies of all sizes all over the world. We have never had any problem asking even our biggest customers to refine incomplete or controversial requirements, suggest improvements to their UI design, or report an anticipated delay in development.

As others have pointed out above, trust is the king in such relationship. Open, timely communication about any potential obstacles on the way to project success builds trust like nothing else (maybe with the exception of advance payment, but that&#039;s about mutual trust. :) )</description>
		<content:encoded><![CDATA[<p>It&#8217;s a pity Russia was not included in the research you are referring to. Given the historical retrospective, I would expect its PDI index to be well above the US, but I can tell you that it is much lower in IT companies selling their products and services primarily on the international market. </p>
<p>We are small (20+ people), but sell out product to and do consulting work for companies of all sizes all over the world. We have never had any problem asking even our biggest customers to refine incomplete or controversial requirements, suggest improvements to their UI design, or report an anticipated delay in development.</p>
<p>As others have pointed out above, trust is the king in such relationship. Open, timely communication about any potential obstacles on the way to project success builds trust like nothing else (maybe with the exception of advance payment, but that&#8217;s about mutual trust. <img src='http://www.lessonsoffailure.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />  )</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Greg Wilson</title>
		<link>http://www.lessonsoffailure.com/developers/real-reason-outsourcing-fails/comment-page-1/#comment-112</link>
		<dc:creator>Greg Wilson</dc:creator>
		<pubDate>Mon, 25 Jan 2010 16:36:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.lessonsoffailure.com/?p=277#comment-112</guid>
		<description>+1 to Stuart and others pointing at Philip Greenspun&#039;s critique of Gladwell&#039;s &quot;just so&quot; story about PDI and plane crashes.  As he so often does, Gladwell is stitching together factoids to make a story simple enough for people in business class to digest in a single flight.</description>
		<content:encoded><![CDATA[<p>+1 to Stuart and others pointing at Philip Greenspun&#8217;s critique of Gladwell&#8217;s &#8220;just so&#8221; story about PDI and plane crashes.  As he so often does, Gladwell is stitching together factoids to make a story simple enough for people in business class to digest in a single flight.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Martin</title>
		<link>http://www.lessonsoffailure.com/developers/real-reason-outsourcing-fails/comment-page-1/#comment-110</link>
		<dc:creator>Martin</dc:creator>
		<pubDate>Sun, 24 Jan 2010 14:26:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.lessonsoffailure.com/?p=277#comment-110</guid>
		<description>Very interesting article. Also the numerous comments are very helpful.
Thanks also for the link to the book, which promises to profoundly deal with those challenges.
After reading all of this, my impression is that being aware of the PDI and handling this challange properly is a necessary condition to successfully work with people from high PDI cultures. However, I do agree with some of the authors of comments, who pointed out that it is not the only issue.

I am currently involved in offshoring and outsourcing software development to India. We are a small software company not having an internal hierarchy and, therefore, relying on trust between the developers, project managers and bosses.
I am an Italien citizen with Austrian roots working in Switzerland and I consider myself as a low PDI person.
I also need to say that we do not have previous experiences with outsourcing development. However, we already do have two different development sites in Switzerland which already requires us to bridge a language-gap.
Since the foundation of the company we successfully practice agile development, weekly iterations and automated testing. Our company culture gives space for creativity and relys on the sense of repesonsibility of each individual developer.

In order to proactively face any kind of challenges regarding the project in India we have always at least one person from our Swiss team in India on site working with the Indian teams.
Still we are experiencing the result that the author Dave pointed out.

I truly believe that trust and respect are fundamental factors in communication. That has also been pointed out in two comments. However, I think that unawareness regarding the PDI will result in a loss of trust with respect to work. If developers do not clearly point out potential issues you will no longer trust on their judgement, even if you consider all of them your friends, unless you are aware of the cultural difference allowing you to correctly interpret their subtle communication.

Another point that I would like to mention as a potential issue is the lack of common understanding about quality. People in different cultures are used to different levels of quality. Thus, their level of sensitivity might be very different than in Western cultures. This situation requires an initial effort to establish a common understanding about quality standards. This includes making the responsible people sensitive to symptoms revealing poor quality.</description>
		<content:encoded><![CDATA[<p>Very interesting article. Also the numerous comments are very helpful.<br />
Thanks also for the link to the book, which promises to profoundly deal with those challenges.<br />
After reading all of this, my impression is that being aware of the PDI and handling this challange properly is a necessary condition to successfully work with people from high PDI cultures. However, I do agree with some of the authors of comments, who pointed out that it is not the only issue.</p>
<p>I am currently involved in offshoring and outsourcing software development to India. We are a small software company not having an internal hierarchy and, therefore, relying on trust between the developers, project managers and bosses.<br />
I am an Italien citizen with Austrian roots working in Switzerland and I consider myself as a low PDI person.<br />
I also need to say that we do not have previous experiences with outsourcing development. However, we already do have two different development sites in Switzerland which already requires us to bridge a language-gap.<br />
Since the foundation of the company we successfully practice agile development, weekly iterations and automated testing. Our company culture gives space for creativity and relys on the sense of repesonsibility of each individual developer.</p>
<p>In order to proactively face any kind of challenges regarding the project in India we have always at least one person from our Swiss team in India on site working with the Indian teams.<br />
Still we are experiencing the result that the author Dave pointed out.</p>
<p>I truly believe that trust and respect are fundamental factors in communication. That has also been pointed out in two comments. However, I think that unawareness regarding the PDI will result in a loss of trust with respect to work. If developers do not clearly point out potential issues you will no longer trust on their judgement, even if you consider all of them your friends, unless you are aware of the cultural difference allowing you to correctly interpret their subtle communication.</p>
<p>Another point that I would like to mention as a potential issue is the lack of common understanding about quality. People in different cultures are used to different levels of quality. Thus, their level of sensitivity might be very different than in Western cultures. This situation requires an initial effort to establish a common understanding about quality standards. This includes making the responsible people sensitive to symptoms revealing poor quality.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Links! (v4) &#171; spiral_code &#124; blog.trydionel.com</title>
		<link>http://www.lessonsoffailure.com/developers/real-reason-outsourcing-fails/comment-page-1/#comment-106</link>
		<dc:creator>Links! (v4) &#171; spiral_code &#124; blog.trydionel.com</dc:creator>
		<pubDate>Sat, 23 Jan 2010 03:31:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.lessonsoffailure.com/?p=277#comment-106</guid>
		<description>[...] The Real Reason Outsourcing Continues To Fail &#8212; I hope to not run into the issue of outsourcing at all, but I&#039;m more well-prepared now if I do. [...]</description>
		<content:encoded><![CDATA[<p>[...] The Real Reason Outsourcing Continues To Fail &mdash; I hope to not run into the issue of outsourcing at all, but I&#39;m more well-prepared now if I do. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kelly</title>
		<link>http://www.lessonsoffailure.com/developers/real-reason-outsourcing-fails/comment-page-1/#comment-105</link>
		<dc:creator>Kelly</dc:creator>
		<pubDate>Fri, 22 Jan 2010 20:52:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.lessonsoffailure.com/?p=277#comment-105</guid>
		<description>I noticed the cultural difference between programmers from different countries several years ago. When I posted my experiences, I was pounced upon as a bigot and racist. Thanks for stating this in a more politically correct fashion and with scientific background. My basic rule of thumb is that when you have a very good specification, and you want it followed, pick an authoritarian culture. When you have a fuzzy specification, choose someone from a culture that is non-authoritarian. In between, pick someone in between. 

That way, if you know exactly what you want, you can ask for it and have a fair expectation that you&#039;ll actually get it. When you don&#039;t know what you want, you can ask the right people for that, and you&#039;ll get something that might work. 

In my personal experience, smack dab in the middle between doing what they want and doing what you want are the Romanians. They don&#039;t seem to question what you want unless there is a good reason to do so, but they do question you when there is. I really love Romanian programmers for outsourcing small projects!

I wouldn&#039;t personally outsource a large project. 

-Kelly</description>
		<content:encoded><![CDATA[<p>I noticed the cultural difference between programmers from different countries several years ago. When I posted my experiences, I was pounced upon as a bigot and racist. Thanks for stating this in a more politically correct fashion and with scientific background. My basic rule of thumb is that when you have a very good specification, and you want it followed, pick an authoritarian culture. When you have a fuzzy specification, choose someone from a culture that is non-authoritarian. In between, pick someone in between. </p>
<p>That way, if you know exactly what you want, you can ask for it and have a fair expectation that you&#8217;ll actually get it. When you don&#8217;t know what you want, you can ask the right people for that, and you&#8217;ll get something that might work. </p>
<p>In my personal experience, smack dab in the middle between doing what they want and doing what you want are the Romanians. They don&#8217;t seem to question what you want unless there is a good reason to do so, but they do question you when there is. I really love Romanian programmers for outsourcing small projects!</p>
<p>I wouldn&#8217;t personally outsource a large project. </p>
<p>-Kelly</p>
]]></content:encoded>
	</item>
</channel>
</rss>
