1. Germans don't speaks English
Looking at the success of American and English companies with offshore projects: I wonder: - why are others successful whereas "we/Germans" fail? The first language might be a reason. Oddly enough, when I posted the article to a number of Indian friends, they all concluded that Indians are not very good in speaking or learning German. An issue I would never have thought off - nor expected. Having more than 20 languages listed as languages which enjoy official support by the India Government, Indians tend to be, by and large, wizards in mastering languages. However - I was talking about the ability of the average German to express his/her thoughts clearly and unambiguously in English. Many projects suffer from a failure in project communication. Replacing your native language with a foreign language does not help. I think it is to easy to assume, that only because English is taught in schools, we can also use it professionally at a level which is required to get the job done.
2. Implicit colonial attitude
Many project members look at their offshoring team members with the attitude of a 19th century colonial officer or missionary zealot. Or both. It is easy to find a scapegoat for project problems with that attitude. During my review process for this blog entry an Indian friend told me the following:
I would expand on this point, because it is so important but rarely understood. I agree with you on the point but my own experience with the difficulties in getting this idea across to people even in London for example, makes me feel that crucial idea must be well laid out.Some people highlight that soft skills are a key factor in making offshoring projects a success. But soft skills are not a tool where you coach people into doing what you want to do them, they are not a tool to interpret a wobbly head shake if it is a yes or no, and neither are they a tool to amuse yourself about the Indian ability to say "understood" if according to our world nothing is clear. If anything, soft skills are the tool to question yourself what it is exactly that makes you "white" (and if you actually like that). They should address your cultural heritage directly, because many of the conflicts arise because of you.
3. All hail the waterfall model
If "we" need to do all the brain work, and them the boilerplate code, GUI frontends, the patching up - it makes sense to send a document over the ocean which contains all the analysis and design before the implementation can start. Hail the waterfall model! It does not work when you sit next door to your analysts, architects and designers - why should it work with a 1000 mile gap in between?
4. The lousy cost of living equals lousy project costs myth
Whenever I hear about off shoring projects, the main driving factor is the desire to reduce costs. Why after all are countries like India so attractive for German companies? Globalization in this context is not a market force which opens new markets for products, but opens new markets for a workforce which has a considerably smaller salary. The comparison in the costs of living is pretty fast equalled to the amount of potential savings for the projects. What is most often neglected in projection costs comparisons and success stories are the substantially increased costs in communication, travel, lawyers, standstills due to different time zones etc. Some of these problems are problems were e.g. American companies are indefinitely better than Germans. Americans are used to different time zones, have a much more multicultural society, are excelling in telephone conferences. We suck at most of these.
5. Who cares if the source code is in German?
Well everyone in your project cares. Have you ever tried to make sense out of Hindi class names? Despite of this, very often the old projects which are ready for maintenance and fixing are being offshored. Exactly those projects which have not been adapted to English as the main documentation and code language. You will have to get someone to a) understand the legacy code, the b) domain and translate the c) non-existing, outdated documentation and d) fix the spaghetti code. If you are done, you probably will already have fixed the problems yourself.
6. The "Oh, hello - who are you?" effect, also known as the good guy left the project syndrome
Personnel fluctuation was a big problem in India, I do not know how much it changed, but I cannot blame anyone for acting like a private version of Homo Economicus. After all, international companies throw around the money to lure people to their company and the next offer used to be just a step away from the freshly signed contract. On the other hand I think the model of comparing programming costs to costs of living is flawed. At least each clever programmer will easily find out, that a line of code which is easily shipped to any destination in the world is truly global and can command a price which is global. So why would anyone code for 1 Rupee if he can make a buck instead? Welcome to a flat world.
7. Mirror, mirror upon the wall, who is the fairest manager of them all?
Offshoring decisions are management decisions. Managers communicate their decisions. Managers are tempted to look good, after all their career depends on making right decisions. I tend to believe that this is the reason why we seldom hear about offshoring failures. Having lived in India I heard from the projects that were taken back. But not from the managers, but from the employees who contributed to new offshoring projects.
8. A plan is a plan is a plan
Plan to avoid the mistakes listed above. Certificates, Add more... Quote from Web: "The problem is to identify the right supplier and even then it takes a lot of work to get the ODC settled and integrated in clients processes. Certificates like CMMI, ISO or SPICE show the suppliers professional orientation, but much more has to be done do successfully integrate the ODC." etc. elaborate.
9. Put your own reason here - leave a comment if you agree or don't.
Reasons for success:
- Patience: it took us about two years to become remotely successful, to establish best practices and procedures, to build domain knowledge.
- Agile processes: everything was agile. If it did not work, we would change it. Every single process, every rule, every everything. We were two small companies, and could afford that (or had to endure it?).
- On-site German speaker (on a local salary): Most of the time I was the only German speaking person within the workforce, and it helped a lot to smooth the transition.
- Small is beautiful: we made tasks extremely small, since no amount of communication would prevent us from having misunderstandings. Working code led to realizations on both sides.
- Dedication: My colleagues were the most dedicated bunch of people I ever worked with.
- We did not exist to save money: Well, at least not primarily. We did exist to enable a company to increase its workforce.
- Use the domain experts. Some time after I left the company tables turned (a little bit) and the company brought a system to the indian market which they had previously developed together with their German partner. Why is this important. It shows a true partnership and lets each partner excell in the qualities they are good at. If you outsource - outsource Research and Development, not just what you think is the boring part of software developments. Most companies I know of use the knowledge of their local partners in order to bring products to the Indian market, which are adapted to it, brought to it by people who understand the culture etc
Postscript: I had been thinking about this already for quite awhile - the current status of this entry is a draft. Not all the arguments have been polished, some are basically just ideas, but I simply wanted to go ahead.
With gratitude I would like to thank Ray Ayyar, George Kurian and Aditya Dev Sood for their helpful comments and contributions.