Één van de meest geciteerde oorzaken van problemen in (offshore) outsourcing is ‘communicatieproblemen’. Als ik mensen dit hoor zeggen vraag ik me altijd af wat ze bedoelen met ‘communicatie’. Omdat de term zelf heel breed en vaag is geloof ik niet dat het ons tot de oplossing kan leiden. Specifiekere oorzaken zijn ‘we konden de extra documentatie die nodig was voor het project niet aan’ of ‘omdat we niet in dezelfde kamer zijn missen we de frequente interactie die we normaal hebben met collega’s’. Als we naar deze specifieke oorzaken van problemen kijken wordt het duidelijk wat er verbeterd kan worden.
Wat kunnen we doen om communicatie te verbeteren?
Ik geloof dat de communicatie niet het uitgangspunt is maar het proces. Natuurlijk zal het helpen om teamleden communicatietrainingen te geven en als wij hen zelf leren hoe cultuurverschillen communicatie beïnvloeden. Maar het belangrijkst voor succes is een duidelijk proces.
Drie heel praktische procesingrediënten die prestatie versnellen in (offshore) outsourcing:
1. Een duidelijk ritme van dagelijkse en wekelijkse meetings.
Dit is verreweg het belangrijkste handvat dat beschikbaar is voor de outsourcing wereld. In de Agile software methodologie zijn standups altijd georganiseerd. Maar niet alle outsourcing is software en niet alle software bedrijven gebruiken Agile. Door de teamleden elke dag 15 minuten en elke week ongeveer een uur te laten vergaderen gebeurt er iets. Communicatieproblemen lijken zichzelf op te lossen omdat mensen dagelijks de kans hebben om ze te benoemen en hun gedrag op elkaar af te stemmen. Teams beginnen hun eigen oplossingen te vinden zonder dat het management dagen moet spenderen om hen training te geven in probleemoplossing. Problemen die ervoor zorgden dat mensen vast kwamen te zitten in hun werk worden meteen opgelost zonder tijd te verspillen.
De tijden, de mensen die aanwezig zijn en de agenda moeten duidelijk opgeschreven worden in een procesbeschrijving. The times, the people attending and the agenda should be nailed down in a clear process description. If the process is followed in a structured way and the meetings become a routine, you have laid the most stable foundation under the outsourcing engagement to streamline communication. But there is more.
2. Een sterk online project management tool
Vooral in een internationale outsourcing setting is een online project management tool essentieel. Met betrekking tot softwareontwikkeling moet deze tool aparte delen hebben voor het attenderen op bugs, taken en vragen. Ook hier is het cruciaal een routine te krijgen in het gebruik van deze tool. Dit begint met het opschrijven van duidelijke richtlijnen voor het gebruik van het online systeem (als 3 mensen hetzelfde systeem gebruiken maar op een andere manier is dat precies waar communicatieproblemen beginnen!). Het management moet ervoor zorgen dat het systeem ook op de overeengekomen manier gebruikt wordt. En de gouden regel moet zijn: ALLE communicatie vindt plaats in de online tool. Management moet het gebruik van e-mail verbieden en moet iedereen vragen een samenvatting van een (skype) gesprek of chatprogramma te uploaden in het systeem.
3. Een duidelijke set van richtlijnen over hoe vereisten te ontwikkelen
Dit kan het grootste obstakel in software projecten zijn: het schrijven van duidelijke documenten waar vereisten op staan. Teams besteden uren aan het schrijven van dit soort documenten en de volgende dag heeft het externe team 5 pagina’s met vragen over het document. Het probleem is dat er vaak geen standaard is voor het ontwikkelen van specificaties. Als er 1 voorbeeld is dat als uitgangspunt wordt genomen zullen de auteurs en de lezers de vereisten beter begrijpen. Verder geeft een set van richtlijnen een mogelijkheid voor mensen om iets te leren: als er een misverstand is kan dit toegevoegd worden aan de richtlijnen als een verbetering.
Een ander simpel maar vaak vergeten instrument is het organiseren van een telefoongesprek van een uur aan het begin van het project zodat teams de vereisten kunnen bespreken. Vaak wordt alles opgeschreven en mensen proberen elkaar zo schriftelijk te begrijpen maar vaak wordt onduidelijkheid veel sneller en effectiever opgelost door mondelinge communicatie.
Pingback: How to manage expectations across borders and cultures? | Bridge-Blog
Hi Hugo,
Communication gap in outsourcing can mitigate only when both offshore and onshore take some steps to neutralise their accent(prime culprit of communication gap).Generally we see that offshore is given haffty amount of training to learn culture,accent,written communication but not onshore people.Also during verbal and written communication we should use simple words because our main emphasis should be on getting our ideas or view communicated to other rather than making people perplexed with words.
Hugo
Yes Communication Problem is one of the biggest challenge towards Offshoring/Outsourcing…..As Ian suggested when you select a vendor who is having the Local presence in your area will keep these problems aside as you will be having a person(I am sure that the person would be from the Management Level)…to communicate whenever you need to have.
Here are some suggestions which can eradicate the communication problems
1.Have a manager from the offshore team who should work on your local time.You can demand it from the provider before you hiring them as your partner/vendore…And have it as a Mandatory one…..
2. Be sure to have some communication lines while you start like Chat,email,phone,Video conferencing etc
3.Always have a verbal communication with written correspondence to the offshore team(some times the writing style/Words can create some problem).
4. Make sure that the scope & requirements you provided is clear to the offshore team(It is important to get the work done at your expected level& deadlines)
5.Can use communicative tools like Google docs…or some project management tools….
Other than these As a Service buyer you can consider the language barriers…….You cant expect the Offshore team to speak perfect English.Be sure that the Offshore team is not disadvantaged because of the language hitch…….
I have been listening/reading to the problems while offshore/outsource quite some time now….. whatever i read out through some articles in the past have been collaborated to my views are posted here
I would like to see more answers from the people around here …….
hope it will helps you Hugo and Thanks for asking this question here
Hugo,
Only outsource offshore if the vendor has local country presence (your country). If you find that for whatever reason you cannot get immediate problem resolution or are able to talk to a senior operational person when you want to regardless of time of day go to the local representative in your country and build in the communication process – access any time, any day. I have found most vendors to be reasonably compliant when they have local representation but offshore solutions.
Hugo, I would encourage you to consider the broader research in sourcing in particular IT outsourcing, to help you with what might be the underlying issues that present themselves as communication issues. Willcocks, Feeny, and Olson have published a considerable body of work on IT outsourcing and what contributes to failures. Similarly, I would encourage looking at the various sourcing maturity and capability models to gain additional understanding around what might be underlying issues that present themselves as communication issues.
What you might conclude from these readings is that organizations likely to use sourcing often have low capability and low maturity in the sourcing function – that’s why they look to third parties. It is their readiness as a sourcing recipient that also makes them resistant to the structure you seek to offer them and that would help overcome the cultural or language challenges.
Also remember there are some functions that are best left onshore so as to eliminate the language variable.
Hugo,
Based on experience, process is absolutely the key. Many of these issues are rooted in issues that can be addressed through process. As an example we operate 24×7 with widely varying shifts between programs with clients spread across the globe.
To address the basic scheduling issue (and, to a certain extent, English communication skills); we set-up a help-desk to be both a resource to all stakeholders and to assure communications are routed and properly addressed. All issues are logged into our support app, Zendesk, and then open items are reviewed at the outset of each of the three shifts/day and then escalated appropriately.
The help desk personnel all have experience working with tough clients (collections, telecom billing or moves/adds/changes). This has been effective in terms of maintaining continuity of communication (clients know the help desk people by name), assuring nothing gets lost in shift transition, and to provide a single point of contact. It also develops accountability for resolution since only the person who requested the ticket can close it. We therefore have a result-oriented basis for managing the communication process.
Hi Hugo,
My 10 years experience of work in Russian IT outsourcing companies shows that it’s always painful (for the first 2-5 weeks) to find the comfortable way (for both sides) to communicate to each other (customer team and outsourcing team). After that it becomes clear and effective. And after that it is very helpful to plan the regular trips (once per 2-3 months) for team members for both sides (frequency depends on project duration of course and its budget) – ideally to allow every person involved to the project from both sides to work together in one location for 1-2 weeks.
Hugo:
There are multiple reasons for failures in communications, many of which are cultural. Others are contextual. There is one type, though, that can be relatively easily remedied through training, and that is the improper usage of English by native English speakers.
The reference I would recommend, very strongly, is a book by Edmond Weiss, called “The Elements of International English Style”, published by M.E. Sharpe, 2005, ISBN 0-7656-1572.
To give a couple of examples: to a native English speaker (whom Weiss would call E1), the following sentence has only one meaning; “Last year, our company’s sales took off 20 percent.” However, to a non-native English speaker (whom Weiss would call E2), the meaning is unclear. From personal experience with my foreign students, I can tell you that 50 percent understand it as an _increase_ of 20 percent, but the other understand it as a _decrease_ of 20 percent. A dictionary’s first entry for “take off” is to “remove.”
Add to this type of problem the number of E1 writers who misspell commonly-confused words, such as “accept” and “except”, which sound similar but have radically different meanings, and add a couple of grammatical errors, and the E2 reader is thoroughly confused. Take “Our company would like to except your offer …” To an E1, it’s clearly a typo/misspelling of “accept”, but to an E2, it can easily be understood as the opposite, that the company wants to take exception to the terms of the offer.
Weiss has many more examples and does a wonderful job of presenting the issues in a very organized manner. I strongly recommend you consider using his material in your training.
Good luck.
Pierre
Hugo, I think you’ve hit on the very necessary first step for improving “communications” with offshore resources. That is, both the local and offshore people need to understand and accept how their different cultures impact what they say and what they hear. For example, things that are critical to North American business people may not carry the same urgency for offshore resources, and vice versa. The willingness to say “I don’t know” or “I’m not ready” may vary across cultures, as do attitudes toward organizational power structures. I am speaking from my own experience, some of it painful, as an IT Director working with offshore operational and call centre resources.
So, I would work on the cultural understanding between the local and offshore people first, then work on the tactical communication issues with as much collaboration as possible between the two groups.
Very relevant question, and very valid ingredients. I’d like to highlight a couple of aspects that I find key – I think they would all fall under points one and two above:
- Management needs to be aware of the “remote” challenges, set expectations, and create processes and rules. The processes described, and the team’s success, will only thrive with active monitoring and managing. In order to do so, some managers may benefit from training, or reading about the challenges of virtual teams.
- Make the team members as “tangible” and real to each other as possible. The degree to which this is the case will vary by project or offshoring relationship. In a longer-term relationship, I’ve found benefits in sharing some personal information such as birthdays, pictures… anything that would help the transition from abstract e-mail writer to actual person. Team members will make more of an effort to understand the remote party when they are “people” with interests, dislikes etc. It’s much easier to dismiss, misunderstand, or even trash somebody who doesn’t have a face.
- Exchange information frequently, and don’t assume that the other party has it. One challenge in virtual teams is the “interpretation of silence”. If the other party doesn’t reply, does that mean that they actively ignore me, did they take a day off without telling me, or are they at home celebrating a national holiday that I’m not aware of? Removing the “black box” helps set expectations, and prevents people from assuming the worst-case scenario. Again, if we don’t know the other party, or if the relationship is already on a downward trend, we tend to assume the worst motives for certain types of behavior, which can escalate otherwise insignificant issues, and magnify them out of proportion.
- A project management tool and written communication, including call minutes, can be of tremendous help whenever there is a language barrier. When I worked with an Indian BPO provider and I gave them assignments on a phone call, I asked them to take notes, and keep minutes. It helped me see if the instructions were really understood in the way they were intended.
Hello Hugo,
In my own experience, SCRUM solves it all for you, even if offshore. I am working in an environment, where the Product Owners are based in Munich, the Development is based in Yerevan, Armenia.
The development and product owner teams come together every 2 weeks, first for the Review of the Previous Sprint (SPM), then kicking off a new Sprint Planning Meeting. We try to reduce to minimum the communication during the sprint. And, at the end of the day everything depends on the quality of the User Stories. If the user stories are well formed and well understood by the team, then the problems are solved. On the other hand we also have a tool, where all the user stories, tasks are opened, and tracked.
At the moment the only problem we sometime have, is the connection problems. The more stable and clear is the communication in SPM and SRM, the less are headaches.
I have to agree with you that communication is a broad topic and it’s not just about the language a person speaks. Yes, language barrier is the top cause of communication problems in outsourcing, but there’s so much more – like not setting goals and expectations right prior to the delegation of tasks at hand. Then, there’s cultural barrier. If your business plans to outsource, make sure that communication guidelines are in place.