The Real Reason Outsourcing Continues To Fail

Outsourcing:  The word American developers love to hate.  There are lots of stories out there about failed efforts that involve offshore development (“offshoring”).  I even have a few myself.  But this post is not about bashing outsourcing countries, the cheapskates that hire them, or the project managers who can’t control the resulting chaos.  This is about understanding why we have such a difficult time making offshore development work before any of those folks get involved.

Airline Disasters and PDI

What got me thinking about this subject was the book Outliers:  The Story of Success, by Malcolm Gladwell.  In it, Gladwell discusses the reason for a series of catastrophic airline failures.  Without repeating most of his excellent dialogue in the book, here’s the Cliff Notes version:

  • There was a study by Geert Hofstede, where he tracked the Power Distance Index (PDI) among selected world countries.
  • The Power Distance Index is an incredibly important measure of how a person in a country would generally react to an authoritarian figure.
  • Countries with high PDI would have more people willing to accept an authoritarian power figure in a paternalistic sort of way.  Like how you might defer to your father’s decisions, or to a king’s requests, for example.  People in higher PDI countries are less likely to question authority and more willing to accept instructions from those in higher positions of society.
  • Lower PDI countries are characterized by subordinates being more willing to question the orders of a superior.  Low PDI countries have people that tend to view themselves more like those in power than not.  In other words, you might judge yourself to be much like your boss in a low PDI country.

Crashes Caused By Power Differences

The NTSB regularly investigates airplane crashes to determine causes, but investigators were unnerved in the late 1990s to find a pattern of fatal crashes were found to be very airline (and also country) specific.  These two airlines with frightening records were Korean Airlines and Colombian Airlines.  The fatal crashes all had common attributes:

  • The pilots didn’t make any single fatal error.  They all started with several smaller errors that gradually built up to a catastrophic failure.
  • For any airline, the First Officers are always trained to double-check the Captain’s orders.  This is a safety protocol that prevents single-person failures from happening.  It is the First Officer’s duty to question and even override the Captain if the order he gives is unsound or improper.
  • In these particular cases, the black-box recordings indicated that the First Officers were hinting at problems, but were not strongly identifying them in a way that would make it very obvious.  Nor did they explicitly tell the Captain that he was acting against normal procedures.

Power Means Fear of Communication

In the aftermath, an astute researcher matched up the Hofstede PDI data with these two countries and found that both Korea and Colombia are high on the PDI scale.  What were the implications of this?

  • Clearly, a power difference would have existed in the cockpit between the First Officer and Captain.
  • The manner of communication between superiors and subordinates is very different if you are from a high PDI country than a lower one.
  • In a high PDI country, a subordinate must use the proper language, body posture, facial expressions and tone when communicating with a person of higher status or power.  In Korean, for example, there are no less than six distinct ways to address someone from the most formal to the least.  In the United States (a lower PDI country), we have a much looser style (“Sir”, which could apply to a General as much as a Lieutenant in the military, or even your father in some situations).
  • This disparity of power created hesitance on the part of the First Officer to embarrass his Captain when the Captain made mistakes (and in each of these cases, at least 3 mistakes were made).  So instead of using a direct method of communication (“This weather is really bad, we should turn back immediately or regroup for another airport”), he used a more subtle, formal and proper one (“Sir, look how it is raining outside.”).
  • The implication of a high PDI country is that there is a rich subtext going on between the two communicators.  But that subtext assumes that both sides are alert, paying attention and can clearly understand the implicit signals.
  • In the case of the airlines, the Captain was almost always sleep deprived and exhausted by the time the situation arose, making that communication impossible.

The researcher concluded that the pilots were inside a cultural framework that dictated how they should behave at a time when those behaviors turned out to be detrimental and outright dangerous to the safety and welfare of the passengers.  In other words, the fact they came from high PDI countries made it impossible for the proper communication to take place when it was most necessary to be plain and step outside the traditional power roles of these cultures.

Past Outsourcing Blames

What does all this have to do with outsourcing?  First, we need to understand why outsourcing has traditionally “failed”, according to both buyers (those who purchase outsourced services) and providers (those who perform the service in their local country, or send people to other countries to perform services).  Here’s a graph of combined data about a survey regarded failed projects from 2004.  The data are still relevant to today’s discussion.  (Source:  The Outsourcing Center)

Reasons of Failure for Outsourced Projects
Reasons of Failure for Outsourced Projects

Notice the even distribution of reasons once the provider & buyer survey data is combined.  This is interesting because neither party can clearly point to a single, differentiating causation factor in the failure of outsourced projects.  But I believe that’s because they asked the wrong questions in the survey.

The Real Issue with Outsourcing is Power Difference

If you have a buyer from a lower PDI country and a provider from a higher PDI country, there are already implicit consequences to your interaction that neither party will know about without prior outsourcing experience or natural cultural awareness(1).  And even with that experience, it’s not a given that they will understand the reasons behind the challenges of outsourcing.  Let me create an example from my own personal experience:

Suppose you had an American company (Buyer) and an Indian company (Provider).  The American company contracts with the Indian one to provide offshore outsourced software development at a fixed price per developer.  Certain key performance indicators are agreed upon by both parties and the game is afoot.  Let’s also assume the Indians agree to a six month project to write a content management system for the Americans.

A typical scenario of engagement might follow like this:(2)
  • The first month, everyone hammers out the requirements documents and in a great ball of fury, declares them sound and ready for implementation.  The American company at this point would typically reduce the daily oversight on the project to something more reasonable, like weekly updates.
  • The second, third and maybe even fourth months pass with little fanfare.  The Indian developers are quietly building the specified software and the Americans are receiving updates about it that are all positive and sound great.
  • At some point, the American company asks for a demo of the progress to date.  The Indians put together something after a bit of negotiation (since the Americans neglected to mention the demo as a deliverable before the end).  The Americans see the actual software and fly off the handle.  Performance is awful, the screens don’t look anything like what they want, and the software appears to be behind schedule.
  • Further code reviews by American developers indicate that the code quality is fairly poor, lacking in comments, unit tests, and filled with copy-paste blocks of duplicate code.  The Americans immediately demand the project be put under different management.
  • The project falls off of the rails somewhere after this.  It will either be canceled, brought back in house, or will be delivered extremely late after extensive modification to the original requirements.

There’s lots to pick on here on both sides of the table.  I would like to point out that the fact that I picked on Americans and Indians is actually irrelevant here. You could easily substitute “British” for Americans (3), and “Filipinos” for Indians with the same results.  But why are they so interchangeable in this fashion?  It’s because of PDI and the inherent cultural communication issues that come with it.

Dilbert
Dilbert says it best

Here is a list of the top 10 Outsource Providing countries in 2009, and their PDI scores.

  1. India (77)
  2. Thailand (64)
  3. Mexico (81)
  4. China (80)
  5. Indonesia (78)
  6. Malaysia (104)
  7. Philippines (94)
  8. Jordan (no data)
  9. Egypt (80)
  10. Bulgaria (no data)

For reference, the United States is 40 on the scale.  Western countries can run the gamut as high as Belgium (60) to as low as Austria (11).  The scale is from 1-120, where 120 is extremely high PDI.  You can see all the countries’ measurements in the original study on this colorful world map of PDI indices.  The gray countries are ones that weren’t measured.  India would be considered moderately high PDI at 77 (in the 61-80 range).

So what happens when you bring a low PDI buyer together with a high PDI provider?

In a word:  Disaster.

Cultural Context Matters In Communication

Each side expects a certain subtext to go on during a conversation because of their own cultural context.  Like this:

Low PDI Manager: So, is the new website ready for launch by Friday?

Low PDI Developer: No, and it’s going to be another 2 weeks because we need the new servers to arrive, for QA to finish with testing after they do, and then release the code.

Pretty straight question, pretty straight answer if you’re from a low PDI country like the United States.  There is little assumption about the subtext because a low PDI communicator is used to “speaking his/her mind” about it.  The information is supposed to be in the conversation as spoken words.  If it’s not there, it’s ignored.

But what if we change that a bit?  Assume the High PDI and Low PDI Developers BOTH have access to the same information and are equally competent:

Low PDI Manager: So, is the new website ready for launch by Friday?

High PDI Developer: Yes, it may be ready by then.  We are looking into it.

That seems like a bad answer if you’re from a low PDI country (mostly because we know the context from the first scenario), but it may be taken at face value because the Low PDI Manager expects straight conversation.  If there was a problem, the Low PDI Manager expected the developer would say something specific about it.  When they didn’t, the Low PDI Manager assumes that Friday will be the date.

And what about the High PDI developer?  He didn’t want to offend the Low PDI Manager, because that’s what you are careful to do in a high PDI country.  The High PDI Developer assumed that the Low PDI Manager would understand his subtext “may be ready” and either ask further questions, or understand that Friday wasn’t necessarily a realistic date.

This is just the tip of the iceberg.  If this happens on a simple conversation about a deadline, what about really big stuff like:

  • Requirements
  • Deliverables
  • Quality control testing
  • Development standards
  • Documentation

The implications are literally staggering.  In fact, I’d go so far as to say the fact that every outsourced project hasn’t failed is something of a miracle.  It’s a testament to having the right people who naturally and instinctually bridge these gaps through extra communication.

The Survey, In A New Light

Getting back to the survey questions, if you look at all of them and how they would be viewed relative to PDI, it’s arguable that PDI differential is the one, single, leading cause that relates to how providers and buyers have a hard time seeing eye-to-eye during the outsourcing process.  Of the eight named factors, I can see 6 of them that directly relate to PDI differential:

  • Buyer’s unclear expectations up front (buyer assumes he is understood when the provider stops asking questions, but that’s a typical low-high PDI interaction)
  • Poor governance (see my deadline example above)
  • Poor communication (again, the deadline example)
  • Poor cultural fit (again, the deadline example)
  • Interests become misaligned over time (you don’t understand each other’s communication needs and are frustrated)
  • Not mutually beneficial (you can’t work together because you don’t understand how to interact…)

Adding those 6 factors up, 72% of project failure reasons can be connected to PDI differential. If both sides understood that single factor going in to the process, everyone would be better served in the end.  Think I’m just making this all up?  It’s not just the buyers that complainHigh PDI country providers say the same things.

So what’s so hard about outsourcing?  It’s hard because of the cultural baggage we bring to the table on both sides, and neither side necessarily realizes it because of assumed interactions.  We need to be more aware of the cultural assumptions going in to projects like this, or we’re doomed to repeat them ad absurdum.

(1) I think it’s fair to say that most other countries would NOT say most Americans are blessed with “natural cultural awareness”.  🙂

(2) Before I get lots of angry comments from Indian readers about the interaction above, yes, there are other potential outcomes and perhaps you’ve been on projects where they are all successful.  I have a mixed bag of experience on this, and it’s not about bashing Indian developers.  Like American ones, they run the gamut–good, mediocre, and what-the-hell-are-you-doing-coding.  I’ve run into all three in about the same proportions as American developers, more or less.

(3) I’m sure one or more British readers are horrified at thinking they are interchangeable with Americans at this point.

Outsource Rank Country PDI
1 India 77
2 Thailand 64
3 Mexico 81
4 China 80
5 Indonesia 78
6 Malaysia 104
7 Philippines 94
8 Jordan
9 Egypt 80
10 Bulgaria
11 Hungary 46
12 Ghana 77
13 Pakistan 55
14 Chile 63
15 Poland 68
16 Czech Republic 57
17 Argentina 49
18 Romania
19 Ukraine
20 South Africa 49
21 Russia
22 Vietnam
23 United States 46
24 Israel 13
25 Canada

40 Replies to “The Real Reason Outsourcing Continues To Fail”

  1. Yep, can definitely relate to this. Been there and done that. Well identified. I was however, lucky enough to be British born, but with enthnic ties to the outsourced country so that helped me identify the issue much quicker, otherwise it could have been an all out disaster.

    More people need to see this post.

  2. One approach I have seen used before is to put a paid employee of the American firm onsite at the outsourcer firm. I.e. put an Indian guy who understands how to speak to both sides in India, make him an employee of the American company, and give him a desk at the outsourcer site. Not a guarantee of success, but it helps a lot. Also very hard to pull off. We used this at one former company, and as a result we got a lot of very good work from the outsourcer firm. I have not seen it work anywhere else, though…

  3. Before investing too much faith in the theory of PDI as a “leading cause”, be sure to examine the counter arguments. Many have pointed out that simple lack of experience is a much better explanation for airline disasters than PDI. Unlike Malcom Gladwell, Philip Greenspun has actual flying experience. I strongly recommend reading his essay:

    http://philip.greenspun.com/flying/foreign-airline-safety

  4. I think you are oversimplifying things. The reality of human interaction is complicated and gets even more complicated when you can’t see or feel the other party.
    I’ve been working remotely (from Argentina) for ten years now, and in my experience, the number one issue is trust.
    Trust is a complex perception, hard to build and very easy to destroy. When you are thousands of miles away every little thing becomes huge, because there’s no other signals but those that are, usually, transmitted via email so they are hard to defuse.
    Transcultural differences gives completely different meanings to small things, so if an endeavor is to be undertaken, you must acknowledge those differences and be very precise and patient on you communications.
    Experience is a must, like in any other field. It can be done, I did it and still doing it.

  5. Trust is important. But if you stop and think about it, trust is also generated when each party feels that the other understands them and believes in them. Given my arguments above, you can say that in a PDI differential environment, that communication is seriously impeded and therefore, trust will not naturally develop.

    Incidentally, Argentina’s PDI of 49 puts it on par with the US, so if you’re doing work for US-based companies, this is not a big problem for you.

  6. Trust is difficult to build when you’re not sitting face-to-face every day. That’s inherent in any outsourcing relationship. However, I suspect you don’t see the PDI problem personally because Argentina is lower on the PDI scale (49) so other factors probably come into play. But I agree, trust and experience are critical to successful outsourcing. My point is that PDI can derail things when it’s present and neither party is aware of it.

  7. @Stuart: The comments at the end point out that this kind of power differential was problematic until training was introduced, and even though other countries do the same training, they don’t have the same PDI background the American pilots do. Dismissing this out of hand is perhaps a bit blaise without reading the entire argument…

  8. I’m strongly disagree with you on your Point in TYPICAL SCENARIO “Further code reviews by American developers indicate that the code quality is fairly poor, lacking in comments, unit test …”

    We do all stuff write good code, have proper Unit test documentation and deliver product/project with high quality.
    If good quality would not be there, Outsourcing (esp in IT) should have stopped till now. Its happening and increasing day by day ….
    But I admit Americans are better designer, coder, thinker and tester too than any 3rd world one:)

  9. Interesting point of view.
    I am Brazilian (PDI 69) and I was VP of a US company, responsible consulting results of Mexico (PDI 81), Hong Kong (PDI 69), Japan (PDI 54). Yep, my subordinates in these countries lied to me, promissing to deliver things that I knew they could not do. Then I had to explain to my American boss (PDI 40 or lower)why I was forecasting less than the consultants were forecasting… now I know a cientific explanation, or sot of.

  10. This is a great post. I’m glad I read it. I disagree completely.

    This effect might be true, but I don’t think it matters. What I’ve seen and what intuitively makes sense, is that the one providing service will do and say anything to be agreeable and keep the contract going.

    At some point, usually long after sane persons recognize that the project has failed, everyone HAS to admit it. So the project is killed, the project managers get promoted, and the whole cycle starts over.

    I’ve seen this with local developers, contractors brought in by a regional company, and outsourcing.

    If the project is small enough and the damage hasn’t hit the newspapers or the courts, it can instead be declared done, a success, everyone gets paid, and then it is turned over to staff to do over, quietly.

  11. BigA: Your own post would seem to argue against your point:

    “I’m strongly disagree with you…”

    “We do all stuff write good code…”

    “If good quality would not be there, Outsourcing (esp in IT) should have stopped till now.”

  12. “Colombia” is the correct spelling of the country. Good write up, I am currently evaluating outsourcing a small development contract, I will take PDI into context now!

  13. You can sum it up in one word: communication.

    It’s the hardest part of any multi-human endeavor, and development is no exception.

    Same reason even remote development/work at home only works sporadically.

    Cheers,
    Carson

  14. Very interesting viewpoint and very convincing. But after a little thought, i think its not that simple.

    Sure- you might be right on the communication part failing because people might not be able to read between the lines. But we have seen this happen when a company outsources to another company in the same region. There are cases when an outsourcing company will outsource their work to another outsourcing company- smaller in size just to meet deadlines! And the example of communication breakdown you took- will and has repeated in these scenarios.

    Some part of the problem is understanding outsourcing itself. Just because you have paid someone to do something and you have shared your vision, doesnt mean the end result will come by on the specified date the way you wanted it.

    The outsourced team should be taken as an extension of the current team. This would mean you invest the same amount of time tracking the progress of your project as it were being developed in-house- if not more. After all, if you are saving on cost or time (or both)- there might be more effort involved somewhere.

    Just my 2 cents

  15. The cultural and communications issues mentioned in this article are well founded. I founded a software development company in India, and ran it for a couple years. I learnt a lot from that experience.

    One key lesson, which I applied when implementing my second software development company (in Vietnam) was that agile methodologies are necessary to expose and resolve these problems early. Agile is a good idea in the West, it is essential with global, multicultural projects. Here are a few of the key elements.

    Early delivery of working products, and frequent (weekly) iterations, along with doing the most business critical things first, makes a big difference. Weekly interaction about priorities and feedback from a business owner at the client company are essential to ensure things stay on track. Misunderstanding are identified and resolved early. Implementation challenges are identified and addressed early. Mistakes don’t derail a project, just marginally delay it. Trust and understanding gets built early.

    Test driven development ensures that developers think about “what *working* looks like” and “how can I demonstrate this works properly” **before** starting to implement code. Showing tests continually, during development, rather than after, helps build confidence that real progress is being made.

    Finally, paired programming ensures that people have a colleague (a peer and not a superior) to talk to about what they don’t understand and think about ideas for best implementation. And if someone ever quits without notice (or gets hit by a bus) the project doesn’t get derailed.

  16. Why are you confusing offshoring and outsourcing? There are obvious technical differences. You can offshore a part of your organization and if they remain part of your company this isn’t outsourcing. You can outsource your cleaning your bathrooms to a specialist and this isn’t offshoring (obviously).

    No wonder the outsourcing data referenced doesn’t match up with your conclusions.

    But I think there are further problems with your argument.

    Human factors is a very serious discipline in the aircraft industry, but let’s be clear that it wasn’t the investigation that applied PDI it was applied in research afterwards.

    It doesn’t help there is no PDI data for Russian, especially with their air safety record!

    Also the application of PDI in the research illustrates the problems that might occur between high PDI participants.

    Saying that I do have a certain sympathy for the argument, but I would say I’d be more interested in data which proved that the rate of IT project failures could be shown to increase with the use of offshoring.

  17. I agree to this post to some extent. First of all you all should know, Outsourcing is not meant to be a great success. When you want 100% of success with your software, probably you dont want to outsource it. You spend more money, you get more success. You spend less money you get less success. When you outsource, you spend less money, you get less success. So outsourcing can not be blamed even if it is a failure.

  18. Interesting article, reminds me a lot of my international business and culture courses at university.

    The power disparity and the communication gaps that arise between can also be extended down from a national culture perspective to a company culture perspective.

    In a company where questioning the boss is encouraged you would encounter the same problems when dealing with a company within your own geographic/national region that does not value questioning the boss.

  19. Interesting article and following question came to my mind: What is the end result when “High PDI buyer” buys from “Low PDI” supplier? For example Chinese customer buys services from US based supplier.

  20. I can understand that cultural differences can complicate things, but I find the concept that a company would hammer out requirements with a subcontractor and then leave them to their own devices as far as code until problems become apparent difficult to grasp. (I’m not being skeptical that it happens, I’ve seen it personally, I just don’t understand how anyone can think it will work.)
    As a programmer, my guiding principles for subcontracting coding would include:
    1. Early and frequent releases: It doesn’t really matter what functionality they provide, but work with the contractor to identify a subset of functionality that can be delivered as soon as possible, and make delivery of that functionality a priority, repeat as much as possible. (I understand some functionality will require longer development times, but SOMETHING should be deliverable soon)
    2. Audit deliverables: Have known experienced Software Engineers review the deliverables. This includes source code and secondary documentation (logs of code review process and unit tests, for instance). As with the first point, this should be happening very early in develipment so feedback has time to be acted on.

  21. Interesting article. It made me think because I’m from Uruguay and I live in the US and I have a company that we specialized in developed projects in Uruguay. We are a small company by design but our rate of customer satisfaction is high. We specialized in projects developed with a tool GeneXus that allow us to develop using the agile approach. In the list Uruguay appears with a 61 PDI and US with a 40 PDI, which that supposedly will put us in the category low-high interaction, so why we don’t experience failures? The only type of project that has not been sucessful for us is when the project is to change code somebody else have done but when it comes to develop projects where we do the requirements onsite and then all the agile cycle, the recipe works.
    Maybe technology used, size and experience plays a bigger role than PDI?

  22. This article is right on the money. In fact, it’s the entire reason that my job exists.

    Scenario: A major American software company hired a major International provider to create and document multiple country-specific versions of their product. The provider was headquartered in the US, but the Indian team was tasked with this project. After months of frustration on both sides due to high PDI – low PDI communication issues, the buyer demanded that something change. The provider resolved the issue by adding a couple of their own American writers and editors to the team. As a relatively low-PDI American Lead Writer who is a member of the relatively high-PDI Indian team, I sit in on meetings to help bridge this communication gap later in private meetings with my Indian management. It’s working out better and better as time goes on. As you said in the article, to make this type of arrangement work, you need to have key people on both sides to bridge the communication gap.

    When I started in this role, an American friend of mine suggested that I order a book about this very subject. It has been invaluable to me in my role as “gap-bridger”. (I’m sure there are other good titles out there, as well. This one was the best I read personally): http://www.amazon.com/gp/product/1931930341/ref=ox_ya_oh_product

    I hope this is helpful to everyone!

    Thanks,
    RB: Lead Technical Writer working from a home office in Arizona for an Indian offshoot of an American provider that is servicing an American software company based in Seattle.

  23. I certainly agree with most of what you’ve written, and while I am Indian, I do realize that this happens a lot of the time. I think it can rightfully be summed up into one word: communication.

    On some of our client projects, we have failed to deliver what the client wanted, while with others projects we were cheered with “Wow! This is awesome.”

    While I’d agree PDI does factor into failed outsourcing, I wouldn’t say that PDI is only country-specific. There’s a thing we call “rapport” which when established with a client leads to better project delivery and execution. For example, I have a client with who I share an excellent rapport: If he asks me to have a look at “the 23 32 problem,” I *know* what he means without him having to explain or file a ticket. Of course, this isn’t against filing tickets, but establishing a rapport early on pays off.

    There’s another side to this story that you seem to have ignored. Some clients tend to be extremely demanding and prefer to be “professional” creating a space around them that no one can enter to establish a good rapport. These are extremely hard to deal with and wind up causing more trouble than there needs to be even when they may be dealing with a low-PDI individual.

    I’ve just stumbled across your article, and I’d like to read the other side of the story as well. 🙂

    Thanks for an excellent write-up.

  24. @RB: Great link, thanks!

    Turns out, there’s a review of that book by an Indian guy (Puneet) who says that PDI is exactly what Westerners are up against:

    “The fact is that most of the western people face Indians when they outsource their IT work. In India, customer is god. Thats what Gandhi told us and thats what we are told from childhood. And in most interactions western people are customers, so Indians tend to respect them. Also, in India, respect for older people is a given thing. And most westerns are old as comparison to young IT people working on their projects. These are two prime reasons that Indian people don’t openly oppose western people.”

    He didn’t call it that, of course…but the description is right there, to a tee.

  25. 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’ll actually get it. When you don’t know what you want, you can ask the right people for that, and you’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’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’t personally outsource a large project.

    -Kelly

  26. 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.

  27. +1 to Stuart and others pointing at Philip Greenspun’s critique of Gladwell’s “just so” 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.

  28. It’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’s about mutual trust. 🙂 )

  29. 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.

  30. 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’ve found that the engineers don’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’t get any true SMEs and you will get requirements like “make it work like the current one does”. Then 6 months later you get a million dollar copy of the system that you already have. American developers don’t have a problem being pushy and telling the managers that their crazy schedule won’t fly. It may cause conflict, but it generally results in better products and sets realistic expectations for the end users.

Comments are closed.