Lessons Learnt Outsourcing Software Development to Asia
Many senior technology and finance executives have considered moving their software development projects offshore. Often the most important driver for making the move offshore is cost reduction, and sometimes that’s the only motivation. Many companies have already tried offshore development with mixed results. My most recent experience with offshoring took a different path and may provide some illuminating insights for those of you considering making the move for your own projects.
When I recently sponsored an offshore development project, the primary goal was the realization of total flexibility in the skills and size of the dev team. I needed to ramp up resourcing rapidly, but I didn’t want to make a long term commitment to funding a large team. I wanted access to a full range of skills as and when I needed them and to lower overall software development and maintenance costs.
The initiative I managed was driven, in terms of business needs, by a desire to reduce costs and to clear a development backlog that was having a negative impact on customer satisfaction. The backlog was mostly in maintenance of a large and complex codebase and the need to continually add new features to match those of our competitors’ solutions. The business vision had evolved too around using our Cloud solution architecture as a clear competitive advantage compared to other on-premises solutions and achieving the vision would require ongoing investment.
There were technology drivers, as well. I had a sense that the codebase would soon need a major retrofit, or perhaps even a total rewire. There were UI/UX issues that were long overdue for attention, and there was a lack of separation of concerns in the software architecture.
Finally, there were pressures on the size of the development budget at precisely the time that we needed to double dev team resourcing.
It was clear that addressing both the business and technology drivers required a larger dev team, and we wouldn’t be able to increase the size of the team in a first-world country when we were facing budget constraints. Offshoring development was clearly the only solution.
My first task was to convince the Board that the move was the right thing to do by helping them to appreciate both the upside and the risks. Convincing a Board, depending on the company, can be a huge challenge. Directors may be nervous or entirely against the idea of offshoring, and it can be difficult to get them to buy in. Fortunately for my project, I had a fantastic Board to work with. They understood that we were essentially running an experiment initially, and they were prepared to support the plan.
After I’d gained the support of the Board, I used my network to identify a number of potential partners in Eastern Europe, Southeast Asia and the Subcontinent. I already had a preference based on my past experiences, but I felt that it was important to take a fresh look at the options available. Ultimately, we received proposals from teams in Poland, Ukraine, India and Vietnam.
Over the past 15 years, I’ve had extensive experience with offshore development projects in Russia, Ukraine, India and Vietnam. Each country has its own advantages and disadvantages which I won’t try to cover here, suffice to say that my experience has led me to become a big fan of Vietnamese dev teams. Beyond offering reasonable costs and an excellent range of skills and experience, our Vietnamese team has proven to be dedicated to delivering, no matter what it takes. On several occasions, this meant they worked back-to-back 20-hour days to ensure that they delivered what we needed. That’s a very, very impressive commitment.
An important practical reason for preferring Vietnam is time zone. From where I work in Australia and New Zealand, it’s advantageous to work with a Vietnamese team because they are only three to five hours behind. That means there’s a good long overlap during the working day that we can exploit. We followed an Agile dev model, and we ran the project with two stand-ups each day. One was for the internal team at the start of our day, and the other was at the start of the Vietnam team’s day. As a result, we were able to use the first half of our day to be fully prepared for the stand-up with the Vietnam team at the start of their day.
What Was the Overall Experience?
It’s fair to say that both parties approached the project with a 100% commitment and were prepared to work very hard to achieve a successful outcome. There were more trips to the team’s Ho Chi Minh offices than I had expected — and they came to our offices as well so there were costs beyond the initial budget. However, I’d also argue that those trips paid a big dividend by resulting in far better communication and stronger personal bonds. The lesson learnt was to ensure there is a travel budget equal to about 10% of the overall project budget.
The Master Services contract gave me exactly what I needed: a flexible team size that could be adjusted as needed and skills that were relevant to each stage of the project, such as lots of UX/UI and BA expertise up front and much less after approval of the MVP release.
Overall, the Vietnamese company has demonstrated that they are prepared to invest in building a long-term relationship, something that is vital when establishing an offshore software development partner.
Greg Twemlow, March 2017
More articles on my website — http://www.gregtwemlow.co/