Cultural differences

Understanding how people work and what motivates them is important to getting the most out of them and having a good working relationship.

I have been working with an offshore company for the past 6 months in New Zealand, with whom we have partnered to do some work to build a technology solution. Over these past 6 months I have observed some differences in the way they operate than what I have previously experienced working with New Zealand companies, and once I had identified these differences this has made it easier to communicate.

Having different cultures brings different dynamics to a project, which is great in terms of having people who look at a problem space from a different perspetive; these are my observations with this particular company and the people we have on the ground in New Zealand.

1. Safety in numbers.
In general, with many of the people I am dealing with (in particular the technical people, not so much with the Business Analysts), I have observed that they are not willing to voice their concerns in a 1 on 1 situation. They are however very vocal in a 1 to many environment where they can use the "power of the mob" behind them. Previously I have in fact observed the opposite with some other cultures.

2. Don't document unless it's 99% correct.
I have heard numerous complaints from the New Zealand team about lack of quality of documentation, but when I stepped back and thought about it, it became apparent that the offshore team (in general) were not willing to document anything unless it had been agreed already as being correct by:
a) the Business Owners, and
b) their Company (i.e. the Company is acknowledging they can implement it and will stand behind the solution).

I am used to Solution Architects documenting assumptions, passing this off to a Business Analyst to confirm / deny, and in parallel continuing to drive detail into the document. This is not the model which the offshore team I am currently working with adher to, so understanding this and continually encouraging them to work in this way is the current plan of attack. I have now also changed my approach to provide them with working assumptions to work to, whilst "behind the scenes" work is done to get the assumption ratified.

3. Only take something as being agreed if this has come from somebody high up the chain of authority.
Another common complaint I hear is that the same question is being asked yet again. Until this question is answered by or signed off by somebody who is deemed by them as having sufficent authority, it appears that they will continue to ask the question.

4. Only document as much as is required to keep people happy
All too often the New Zealand culture for IT projects in corporates is to document the solution up front in minute detail before commencing to build; this obviously has its pros and cons. With this particular project we are following an Agile-like methodology, and from what I have observed so far, I think they are working on the assumption that once they build something and present it back to us that:
a) we will be changing our mind about some things, and
b) testing will identify any problems.
With this in mind there is indeed a reasonable amount of detail being documented in some areas, but other areas are reasonably open for interpretation, and therefore it is expected through multiple iterations these areas will be ratified; which in many ways I think is actually a good approach.


Popular posts from this blog

IT & Enterprise Architecture Conference 2015 - Day 2

Using Raspberry Pi as a Time Capsule to backup a Mac

Considerations when responding to an RFI or RFP (a view from the receiving end)