ecaminc.com

  • Increase font size
  • Default font size
  • Decrease font size
E-mail Print PDF
RSS

Cultural Faux Pas

Cultural issues can be devastating on any project. It is much larger than the obvious language barrier. In fact, since it is so obvious, language is often the smaller issue. It is critical to understand cultural differences and change the management style to accommodate it. Everyone should spend time learning about the different cultures on the project. A few examples help underscore the point.

Polite Cultures

Some cultures are very polite. They can hardly say the word no. In fact, they will say yes when they mean no; the meaning is determined by the context. I learned this the hard way while in Asia in the mid-nineties. When I first arrived, I was very proud of my progress, everyone agreed with me. Little did I know, they only agreed with my point of view as being sound, they still disagreed with the direction of the statement. It was only later that I understood the three yeses—yes, I agree with you; yes, I heard you and yes, that is valid, but that is incorrect solution. Understanding the nuances of how they used English and following their side of the conversation better allowed a grasp of the real meaning.

Argumentative Cultures

On the opposite end of the spectrum are the "merchant cultures" that need to haggle over every point. They expect both sides to concede items in any discussion. Never think of coming into one of these meetings with an honest compromise. These cultures need the trading and seeing something forfeited. Know the desired compromise and have plenty of items to concede to get to that point. They will equally surrender items to meet in the middle.

The best example of the need to haggle was on a remote project where I was trying to resolve numerous disconnects between specifications. After reviewing one, it was apparent that one database field had one context for one record type and another context for a different record type. Business rules applied to other data in the record determined its meaning. A meeting was setup with the customer's project manager and their Database Analyst to request a change to the structure. The DA was adamant that the design was fine and I did not want my client liable for the design.

The culture of the country was to argue rather than discuss. The discussion was failing to produce good results and was looking like a standoff. Being worn out, after six weeks of remote work, I suggested completing the discussion in a week, after returning from my scheduled trip home. The customer's project manager insisted the meeting continue and pressed for more discussion to resolve the concerns. The meeting was turning into a brawl (horrible when mixed with exhaustion). I refused to join in the argument. Instead, the customer's project manager switched to his native language and had a fierce yelling match with the DA. At the end of the meeting, the decision was to redesign the database as I had originally requested. I was dumb founded, getting the proper design with hardly a word. It seems that culturally they just needed the argument.

Language

Never assume the strength of someone's use of a second language. Being that I am only conversant in English, knowing barely enough Mandarin to buy food at the market, I rely on my client's use of English. After spending a couple months negotiating a project recovery, the customer's project manager asked, "What does caveat mean? You use it a lot."

Delicious Delicious
Add to Technorati Favorites

The stopped dead in my tracks thinking of the hundreds of times I had used that word and wondered how the he had actually interpreted those lines. I was additionally surprised that he had not asked for clarification earlier. He asked me on other occasions what something meant. I had grown lax, trusting him to admit his lack of knowledge. I explained the word to him, complimented him on his use of English and reminded him to ask for clarification next time he was uncertain of the meaning of a word. I doubt I ever used that word with him again.

All of these examples are troublesome on any project, on a red project, the failure exacerbates the differences due piqued emotions.

Tags:

Previous Blog Next Blog
 

Add comment


Security code
Refresh


Project Failure Insight:

The following blogs regularly have articles on project failure, recovery and good management practices.
Chris Curran
CIO Dashboard
Michiko Diby
Preventing Project Failure
John Estrella
Dr. John A. Estrella's Blog
Mike Krigsman
IT Project Failures on ZDNet
John F. Moore
Random Thoughts of a Boston-based CTO
Roger Sessions
Simple Architectures for Complex Enterprises

Not in the US?
Don't want a personalized copy?
No problem. Rescue the Problem Project is available in your local bookstore and online around the world. You can even buy it as an eBook and start reading in minutes! Here are some options:

 

Amazon logo
Book or Kindle
Flag of Canada Flag of the United States
North America
Flag of the United Kingdom Flag of Ireland
United Kingdom
Flag of Germany
Deutchland
Flag of France
France
Flag of Italy
Italia
Flag of the PRC
中國
Flag of Japan
日本の
Barnes and Noble Logo
Book or Nook
Sony Reader Store logo
Sony Reader
Worldwide: Many other
book sellers worldwide.

Suggested Books

Many of these books have reviews in the "Books to Read" section of this site.

Critical Chain
by Eliyahu Goldratt
BFR Class Image

Earn PDUs with the online class Recovering Failing Projects