 |
Software Testing & QA Online Community > Detail: Lessons Learned about Starting a Development Group in India, Part 1
| A StickyMinds.com Original |
|
 |
 Hear more about this topic in the StickyMinds SoundByte podcast interview with Peter Clark.
In 2005, our company decided to create a software development group in India. There were several motivations behind this decision: We wanted to be able to service the South-Asia market with our products, and we wanted to take advantage of lower development costs in India.
By this time, our company had been in India for nine years working with a Calcutta-based company manufacturing our equipment. We sited our manufacturing facility in Bangalore. It grew like crazy over the next few years and became one of the dominant players in material handling in India. We then expanded this business to do mechanical and electrical engineering, for both the North American and Indian markets.
Now it was time to offshore software development. Our company set aggressive goals. We would hire a development lead and bring him to the United States for training with the existing software development group. He would then go back to India and hire five or six additional software developers.
A highly qualified individual from one of our competitors was identified and recruited. We brought him over to the U.S. for three months of training. He received the same training that new hires received: a stack of user and design documentation and an engineer who was assigned to mentor him. The trainee was then assigned some maintenance work to gain familiarity with the system. He also toured customer sites to see exactly what we do.
Training didn't go as smoothly as expected in the States. While some individuals helped him, others did not. The rest of the team was reluctant to give him the support he needed. They felt that he was there to learn how to do their job because he and other Indians would soon be replacing the States-side team. Unfortunately, the trainee was isolated and never really integrated into the remainder of the American team.
At the end of three months he went back to India. We set up a VPN connection from our engineering office in Bangalore to our offices in the U.S. Our newly trained correspondent began recruiting people for his team, most of whom were his former co-workers.
His team received their first major assignment when our German subsidiary received an order for a small system in the Middle East. The engineering group in Bangalore would develop this product, including the software portion.
We decided to reduce the scope of our standard product to reduce project risk. A prototype system was installed in a facility in Bangalore, and testing commenced. Regular progress phone conferences were held, and equipment was configured and integrated.
About a year into the effort, the software team in the US needed help with a large backlog of work. I requested that two engineers be sent over from India for training. They were scheduled to be in the U.S. for three months, after which they would continue to work on U.S. projects when they returned to Bangalore.
When the first engineer arrived, I gave him a simple programming assignment to assess his skills. He had been working for our company for about ten months, which he had spent working on our product. I expected that a programmer should take no more than one week to complete the assignment and that an experienced programmer could complete it in a day. After two weeks, with no visible progress, I became concerned.
I sat the engineer down and talked to him. I found out that prior to working for my company, he had no computer programming experience. His background was in electrical engineering. After he was hired by our trained programming lead, he had spent all of his time reading books on programming in C++ and reading code. He had never written any code.
I called the project lead in India who told me that he had hired three experienced people and one trainee. The person I had in the US was one of the experienced people. At that point, I became extremely concerned.
I shifted gears with the person in the States and assigned him some QA work to do, which he excelled at. Then I cancelled the second person’s trip—he was the trainee.
By the time the three months were up, all of the people remaining in India had left the company, including the team leader. The person returning to India was reassigned to the electrical engineering group. Eventually the prototype system in India was scrapped after it was discovered that it didn't work at all, and none of our staff could figure out how to fix it.
In the next installment, find out what lessons Peter's company learned from this experience and how it affected the company's second attempt at outsourcing to an offshore team.
In part two, Peter will explain what he did differently the second time.
Click
Here to Read Lessons Learned About Starting a Development Group in India--Part 2.
Click Here to Read Lessons Learned About Starting a Development Group in India--Part
3.
About the Author
Peter Clark has twenty years of experience in industrial automation. He currently manages teams working in materials handling, especially baggagehandling systems. A regular columnist on StickyMinds.com, Peter can be reached at pclark@jerviswebb.com.
Back to Top
|
