A two minute management seminar: How to convey unpleasant messages

A while ago I had a short break at a bakery in Munich. I bought a Brezel at the self service counter and took a seat in the bakery’s coffee house. I ordered a Cappuccino and began to eat the Brezel. Suddenly the waitress came back and said: “I’m very sorry, it’s not allowed to eat outside food in the coffee house area. We have a different service tax compared to the self service counter. So I would like to ask you if you can move to the self service area, I will take care your Cappuccino is served there immediately. (pause) Do you accept this?”

Without hesitation I said “No problem”, and moved to the self service area. Two minutes later I got the Cappuccino served and enjoyed my Brezel.

Self service area and coffee house area were in the same bakery and served by the same staff, so what sense did it make to annoy a customer with such a weird move to the self service area? Actually, it didn't matter to me. I accepted her request and appreciated the way the waitress communicated an unpleasant message. She included 3 key points to convey an unpleasant message without annoying the customer:
Politeness
The waitress phrased the message in a polite way: “I’m very sorry...”, “I would like to ask you...”.
Reason
The waitress clearly gave the reason for the message: “We have different service tax...”.
Feedback
The waitress asked for customer feedback: “Do you accept this?”.

If you are with North American or Asian background, this might sound normal for you. Unfortunately such kindly service is of rare occurrence in Germany.

Sometimes a two minutes talk matters more than an 8 hour management seminar. These 3 keys can be used whenever you need to communicate “bad news”, no matter if you talk to your boss, a client, or your spouse.

1. Be polite
2. Explain the reason
3. Ask for feedback

 BTW: The bakery’s brand was Rischart in Munich (OEZ branch).

Challenge India Part 2: How to handle specifications?

This article is a follow up to: Challenge India (for western cultures) Part1, section “specifications”

Work packages for external service providers are set down in specifications. A specification document is created by subject matter experts in the client company and passed to the service provider. After implementation the service provider hands over the deliverable to the client, expecting his acceptance.

Unfortunately that’s the way western companies handle their business relation with Indian vendors and even believe it really works this way. Eventually the companies realize that the deliverables are far from what was expected. If the specification was written on abstract level, the service provider team doesn’t know exactly what to do. But without demanding further information they start to work according their own interpretation; needless to say that the deliverable won’t match your expectation.

If the specification is written on a very detailed level, the service provider team follows each instruction without reconsidering if things make sense or not. In most cases the deliverable also won’t match your expectation. So how to write the “perfect” specification?

1) Let the service provider write the specification.
Give a rough guideline of the specification contents and the expected deliverables. Let the service provider write the specification in their own words with their understanding. Accompany the creation of the specification, ask for drafts on regular basis and clarify different views immediately.

2) Use an incremental approach.
If it takes 10 months to implement a deliverable, insist to get provisional results presented on regular basis, e.g. every 4-8 weeks. This ensures that misunderstandings are identified as soon as possible and corrective actions can be taken on the spot. Include the approach of iterative delivery cycles already in the specification document, i.e. what is presented when. Not at any time accept an approach with a single final deliverable only.

For sure, both points take more time in setting up the specification and lead to higher costs in the very beginning. But this additional effort will definitively save costs in subsequent project phases.

Challenge India (for western cultures) Part1

No doubt, the evaluation of outsourcing and offshoring locations brings you in touch with India. Mumbai, Chennai, or Bangalore are emerging cities offering services for any kind of business processes. Low labour costs, strong technical expertise, and good English skills are the pulling factors making India an attractive place. However, dealing with the Indian subcontinent can be a challenging task especially for people from a western culture. Here are the 3 most challenging issues when doing projects with Indian contractors:

Feedback
In India weaknesses and failures are not admitted in public; it might result in losing face. So before someone admits a failure he tries to cloud it with vague statements. Therefore the client can’t expect an early warning if a milestone is not achieved. Western cultures treat a deadline as given, so 5th of September means 5th of September and not 6th, 7th or 15th. From Indian perspective time is stretchable; they see a few days delay still as delivery in time. Together with the Indian "optimistic" style of planning this brings projects into trouble.

Specifications
Projects start with user requirements usually written down in a specification document. If the specification is written on abstract level, people don't know exactly what to do. Without demanding further information they start to work according their own interpretation. If it's written too detailed, people follow each instruction without reconsidering if things make sense or not. The first presentation of an interim deliverable (and I hope you have interim deliverables in your project) ends up with an unpleasant surprise for the client.

Contracts and agreements
In western cultures contracts are final after signed by both parties. An agreed fixed price is a fixed price. In India a fixed price is often treated as guideline, a point of reference. It is considered normal to renegotiate or to charge extra cost during the contract period of validity. The major issue is that during contract negotiation, the Indian party fully agrees to the fixed terms without mentioning the possibility of extra charges. On the other hand, the western counterpart does not even think on upcoming extra charges after signing; they take the approval of the Indian counterpart as fixed agreement. And as soon the Indian party starts the first attempt to renegotiate the price, the clash is inevitable.

Feedback, specifications, and contracts; 3 Indian challenges. In the next “Challenge India” articles I will advise how to deal with these challenges and make projects with Indian contractors a success story.

What are global organizations?

The marketing team is located in Singapore, the IT in Bangalore, and headquarter is based in London. Call it global organization? Sure, you can. This is one type of global organization; the departments are acting from different continents, but the functional responsibility is clearly assigned to one site. The challenges for a team lead, project manager, or business analyst are the interfaces between the different departments. This type of global organization has external interfaces which are cross functional and cross cultural.

However, there is another type of global organization. For example, an IT department responsible for the company accounting software. The project is managed in London, the database software developed in Mumbai, and the user interface configured in Hong Kong. Additionally the accounting rules are adapted according regulatory rules by the local operation teams in each country. All functions are needed to generate one product, the global accounting software, and all functions are reconciled in one IT department. So you still have the external interfaces to Finance, Accounting, Sales, and every other department using the software, but additionally you have internal interfaces within the department. E.g. the database developer in Mumbai needs support from an interface programmer in Hong Kong and vice versa. As this kind of global organization has internal and external interfaces, it is much more difficult to manage compared to organizations with external interfaces only.

When I write about global organizations, I reference to organizations with

• internal and external interfaces
• cross functional and cross cultural interfaces

The biggest challenges in my career were the alignment of internal interfaces; to make worldwide teams with different backgrounds, interests and goals, pulling in the same direction.

Welcome to Michael's blog

Organizations in multinational companies pretend to be global. In reality they are not aligned, losing performance, and do not cooperate. This blog supports you in working with global organizations and how to make them more effective. It focuses on the cooperation between South East Asian and European cultures.

Global organizations and intercultural management, two subjects tied together and are most important in today’s business life. I managed international projects in Asia and Europe, projects which further developed the global position of the company I am working with. Cultural diversity was the most essential factor in all projects. Team members from Singapore, Taiwan, India, China, Germany, Portugal... joined my challenge. I saw projects succeeding, I saw projects failing, and most important, I saw projects turning around.

• What does it take to make projects turn around?
• How to keep the team’s performance on high level?
• Whom to involve to successfully achieving milestones?

With this blog I want to share my experience and give you pointers which are helpful in your daily work with global teams. Even more I am interested in your view on the articles and on the subject. Please share your experience with me and leave a comment or send an email.

Happy reading!