Monday, 12 October 2009 00:00

Cultural Faux Pas

Rate this item
(0 votes)

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

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.

Read 4391 times

Related items

  • Process Mapping

    Process is at the core of any business. It makes work predictable, repeatable, and transferable. Without it we cannot scale our businesses. However, process can be a bane to making progress. Processes that work for a $10 million company have difficulties supporting a $30 million company. Trying to scale them to a $300 million company will not only fail but not address the issues that larger companies have that were never dreamt of in a smaller organization. Processes need to be discarded, revamped, and built—all of that without creating an overburdening bureaucracy.

    Anytime you need to go someplace, you first have to know where you are. Processes are never static and your company's current state is probably far from where you think it is. Hence, the first step is mapping out you company's current state followed by defining the future state. This is more than a logical map of the process; it must also include physical maps. Whether your process is solely to provide a service (say, website development) or physical (say, manufacturing) there are logistical issues that complicate the process flow. Without fully understanding those nuances, future state processes will not reach the desired efficiencies.

    For more information about process mapping fill out the form to the left and we will get in touch with you.

  • Success vs Culture

    The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • The Executive-Project Manager Gap

    It was such an innocuous question, "Working on an article; what is the biggest problem you see with project governance at orgs? Can you comment?" Can I comment? Really? That is like cheese to a mouse. Where could I start—bureaucracy, draconian process, poor executive sponsorship, disengaged leaders? Plenty of fodder, because they all lead to project failure. I fired off, "Creating an over bureaucratic morass stifling innovation & implementing process instead of cultivating leaders." Then the maelstrom started and it went directly to the gap between the executives and projects managers. Naomi Caietti, Robert Kelly and I had a great conversation. Most of the thread is below.

  • Your CRM Implementation Is Going To Fail

    Customer Relationship Management (CRM) implementations fail at an alarming rate. For the last fourteen years, numerous independent parties have come up with the same dismal statistics. In fact, your implementation probably will not meet your goals either. The graphic above does not bode well for anyone heading out on that journey. To be sure, configuring the software is significantly more difficult that it appears at first glance. As much as one wants to blame Salesforce, Microsoft, or some other software vendor, though, the trouble lies much closer to home.

    For the astute onlookers it is easy to tell when the implementation is going the awry. It is the argument over who is going to drive the project—IT or Sales and Marketing. Unfortunately, these are the wrong people to have in the discussion.

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References

Sitemap