The drive to continually reduce costs, do more for less, raise productivity, deliver projects faster and reduce rework is relentless in most companies.
Invariably this will include, at a minimum, some form of assessment of using offshore resources for various work, including software development and maintenance. Senior technology and finance executives have moved their software development projects offshore for well over 30 years, but there are pitfalls and projects need careful planning and management.
The most common driver for moving offshore is cost reduction, and sometimes that's the only motivation. Many companies have tried offshore development and experienced mixed results.
The failed project reviews often point to issues with communications, quality control, and incomplete or inaccurate business analysis as the core reasons offshoring didn't deliver.
My most recent experience with offshoring took a different path and may provide some illuminating insights for those considering moving offshore for your 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 development team. I needed to ramp up resourcing rapidly to achieve a critical delivery milestone, and 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 clear a development backlog that was negatively impacting customer satisfaction, leading to higher churn.
The backlog was mostly in the maintenance of a large and complex codebase and the need to continually add new features to meet customer demands and match the features of our competitors' solutions.
The business vision had evolved around using our Cloud solution architecture as a clear competitive advantage compared to other on-premise solutions, and achieving that vision would require ongoing investment.
There were technology drivers, as well. I sensed that the codebase would soon need a major retrofit or a total rewrite. There were serious 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 we needed to double the development team resourcing.
It was clear that addressing both the business and technology drivers required a larger team with different skills, and we wouldn't be able to increase the team size in a first-world country when facing budget constraints. Offshoring development and maintenance was the only solution.
My first task was to convince the Board that the offshore model was the right thing to do by helping them to appreciate both the upside and the risks. Depending on the company, Convincing a Board can be a huge challenge. Directors may be nervous or entirely against the idea of offshoring, and getting them to buy in can be a real challenge. Fortunately for my project, I worked with a fantastic Board. They understood that we were initially running an experiment and they were prepared to support that plan as a first step in long-term offshoring.
After gaining the board's support, 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 it was important to take a fresh look at the available options. 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. Each country has its advantages and disadvantages, a personality that varies based on the country's culture.
I won't attempt a detailed analysis of these cultural differences and how they impact the management of an offshore project in this article. Suffice to say that my experience has led me to become a big fan of Vietnamese development teams.
Beyond offering reasonable costs and an excellent range of skills and experience, the Vietnamese company I contracted proved dedicated to delivering, no matter what it takes. On several occasions, 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 the 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 a good long overlap during the working day can be efficiently exploited.
My project followed an Agile 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 important to say that both parties approached the project with a 100% commitment and were prepared to work hard to achieve a successful outcome. There were more trips to the team's Ho Chi Minh offices than I had expected - and they also came to our offices, so there were costs beyond the initial budget. However, I'd also argue that those trips paid a big dividend, resulting in better communication, improved business analysis, and stronger personal bonds. The lesson learned was to ensure a travel budget equal to 10% of the overall project budget.
The supplier's Master Services contract gave me exactly what I needed: a flexible team size that could be adjusted as needed on a rolling 30 day commitment 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 demonstrated that they were prepared to invest in building a long-term relationship, which is vital when establishing an offshore software development partner.
Short-term or once-off projects can be successful, too, providing a very detailed specification. Not a very common approach now, given how Agile methodologies and rapid prototyping have been proven far more productive.
Running my For-Purpose company means I have to use resources that get the job done for the least cost - my sponsors and donors demand this. Over the past few years, I have built a team of multi-skilled freelancers based in Spain, India, Ukraine, and Vietnam. They deliver the precise outcomes I need and enable total flexibility for a minimum cost.
I offer a half-day workshop for senior executives wanting to explore offshoring to help design projects for success, and I can assist with identifying the ideal offshore partner.
You can get in touch with me via enquiry form.
About the author:
Greg Twemlow is a Sydney-based CEO of a For-Purpose Company | Founder of SEVENmile Ventures | Startup Mentor | CEO | Writer | Speaker | Podcaster