It is no secret that, using programmers in Eastern European or Asian countries is a lot cheaper than using inhouse resources in European or North American companies. Therefore, many Dynamics NAV partners have created departments in these countries or use an external partner for the more “heavy” development tasks, and we just have to realize that there are a lot more resources in those countries than we have.
I met a CEO of a consultancy company in a hotel in New Delhi and whilst small-talking, I naturally asked how many consultants do you have?
The answer was 54.000 consultants.
Ok, so since outsourcing-companies have that amount of resources, we might as well benefit from that and use them to lower our average hourly rate.
Very often these employees have college degrees that matches our own, and when you travel in e.g. India, it becomes evident that here are employees, that are eager to please you and to learn more about your product and about the culture, that you come from.
However, this is not just another department in your company.
There are cultural differences that needs to be handled somehow. In my time as a department head in a Dynamics NAV partner, I got involved in the remains of one of the first Danish outsourcing adventures. Another Dynamics NAV partner had outsourced the programming of an entire add-on module to a company in India. Of course, we were all eager to hear the result of the project to see if we should mirror the action, outsourcing our own projects. However, a call from my colleague from that partner, requesting all the consultants I could spear to help him to get the project back on track, made us a bit reluctant.
The problems started early in the project and only escalated. The problems were the result of a lot of “trial and error” from both sides. The outsourcing company had problems understanding what the partner wanted. But the problem was mostly the expectations of the Dynamics NAV partner, that treated the outsourcing department of the company as any other Dynamics NAV department.
This project and many others later taught me some of the issues there are:
-
Project Management
There is a huge difference in how a project is managed in Europe and North America and in India. So therefore, it is necessary to find project managers that understand the demands and the culture at the Dynamics NAV partner. Some Dynamics NAV partners think that the project manager can work from remote supervising the project via Skype or others, and that can work, but more often it doesn’t. In some cases, project managers are sent to the outsourcing country to supervise. However, a newcomer is not always appreciated to “come here and tell us how to do our job”.
-
Education
Even with the eagerness to obtain knowledge about Dynamics NAV and the standard application, there is a gap between a European or North American consultant with many implementations behind them and maybe twenty years of experience, and someone who never implemented Dynamics NAV on their own.
-
Cultural differences
Working with companies in other countries is always interesting. Working with the Middle East there are different holidays and different working days (Sunday to Thursday). In many Asian countries there is a different culture of “not wanting to lose face” meaning that you might not get the full truth about, if they actually understood the task, and therefore worked in a different direction because they didn’t get back to you to clarify if that was the right path.
-
Communication
Communicating with the employees in the outsourcing company, it is very often done in English. However not all Europeans speak English well enough to explain the problems to the employees of the outsourcing companies, whose English is very often called Singlish (Singapore English) or Minglish (for Malaysian English), not to mention that the English of many Indian and Pakistanis can be difficult for other nationalities to understand.
-
Documentation
Often the level of documentation in Dynamics NAV partners is based upon a consensus that “we all know which direction the project should be taking”. It could also be that the information of the task is somehow implicit in our country, but for all other nationalities it is totally unknown. Just last week someone asked me where he could buy a gift basket with Swedish specialties and a bottle of wine. He didn’t know that wine and other alcohol is only bought in special government shops in Sweden.
-
Infrastructure
We, in Western Europe and North America are used to having a stable electricity and Internet connection. That is not something to take for granted in some of the outsourcing countries. Therefore, a certain amount of down-time must be expected.
-
Knowledge of the culture at the client companies
Employees at the outsourcing company cannot know, what the organization and culture is at the client companies they program for. Even within Europe it is hard to know the differences between the countries not to mention the differences in the legislation.
-
Time difference
Lastly, there might me a time difference to handle. Some companies have introduced
shifted working hours in the outsourcing company matching then with the Dynamics NAV partner working hours, but that might be a tall order for other companies.
So, am I saying that we should not use outsourcing?
Not at all. We should just be prepared to handle the issues that I described above:
- Use a project manager that has experience with working with other cultures
- Have daily skype meetings if the project management is off-site
- Invite the developers to join the Dynamics NAV partner for education and bonding with the other employees
- Read up on the culture in the country where the outsourcing company resides
- Use a spoken language that everybody understands and do not be afraid to admit that you didn’t understand, what he or she said. Use written communication if the spoken communication fails.
- Document the programming task in the smallest details. Explain the functionality as if they do not have opportunity to ask you questions about it. The documentation must include information that you or the client company consider implicit information.
- At the Skype meetings, ask questions to clarify if the programmer have fully understood the task.
- Incorporate slack in the time schedule to handle down-time and make sure to calculate the local bank holidays in the time schedule.
- And of course, make sure to handle the time difference so you don’t assign a task, just before you leave for the day, leaving them with no possibility to get answers to questions that they might get.
I have seen many projects successfully completed on time and on budget using partly local developers and partly outsourced developers. And in many cases the reduced hourly rate on some of the development tasks help to land the project in the first place.
