A brief history of offshore software development

Offshore software development today is a pretty normal thing. However, getting to that point meant that many companies had to learn it the hard way! A better understanding of this history will help in a better appreciation of today’s best practices, and will also prevent making unnecessary mistakes.

Over the years outsourcing and offshoring have evolved from a low efficiency/high maintenance operation with the goal to save costs, into a strategic sourcing activity that can enable new business opportunities.

The reason is that this evolution brought the possibility of having high efficiency and agility levels, accompanied by high predictability and quality levels. Key in this is proper knowledge management by using a people and team centric approach, implementing a high sense of ownership at sourcing partner level, and using supporting methodologies such as Agile Software Development.

It was not always like this.

How it started

Offshore Software development started from the notion that you could have work executed elsewhere, but since there was no context, background or understanding of the work, this had to be totally broken down into tasks that could be executed as transactions.

This lead to the situation that there was a total mismatch between what was on the customers mind and what was in the suppliers or remote employees minds. Just reducing pretty complex things to transactions is a daunting task, and the results can hardly be expected to be very good.

Qualities would be poor, predictability low, preparation costs and transaction costs very high, and the retention rates of people would be disastrous, because intelligent people would be easily scared away by these practices. Taking responsibilities was difficult.

From this, we all learned that we should not outsource our problems, that we would definitely get what we asked for (even if we actually needed something different), and that sense of involvement is as high or low as you would reduce your task to. And: the further away you take it, the harder it bites you if you do it like this.

How it evolved

Having seen how this transaction sourcing did not really work well, it was a small step to give more responsibility and entrust entire components to the offshore teams. This did work, but still there were some problems.

Quality was better, predictably was better, but retention of talent was still poor, and with the increasing responsibilities, certain perception differences would become important factors. Distrust and negative competition Did happen.

From this, we learned that just giving more delivery ownership alone is not enough. There needs to be a certain understanding of the processes, and also building trust and giving responsibilities to the offshore teams proved to be a very important factor. This lead to the final situation: distributed insourcing.

What it is like now

Because ownership, responsibility, understanding of the domain and process are all very important, and especially in highly complex processes like product development, the best model to do this is "distributed insourcing".

What this distributed insourcing essentially is, is fully fledges cooperation with remote teams that are integral parts of the organization. Especially in high complexity processes like software development, product development and other highly custom activities, this is the only way to really enjoy the benefits of offshore capabilities.

The prerequisites to do this are:

• Proper knowledge management
• Agile ways of working (like scrum)
• Some solid Governance structures to steer the operations
• Few but strict policies how to do things
• A very keen eye and full attention for human capital development

If you don’t honor there aspects, offshoring and outsourcing adventures might very well be a total failure. Especially with core business or highly complex activities. If you do honor these aspects, you can enjoy a lot of the benefits of offshoring, like:

• easy access to talent
• latest technologies
• a very competitive price-point
• superb flexibility
• ways to achieve growth potential
• and more

Summary of Lessons learned

• Approach offshoring from a general sourcing perspective, not as a procurement process: Partnership instead of customer-supplier
• Approach it as a growth path: it takes time to learn how to do it, it takes time to build trust
• Use a people and team centric approach: process is extremely important but worthless without peoples buy-in: Agile Software Development can help!
• Try to avoid/reduce the need for large scale Knowledge Transfers, in stead try to build and retain the knowledge by the people that have to use it.
• Respect each others culture, don’t try to influence or even change it

Want to Know more?

coMakeIT specializes in offshore development teams in India. We learned the hard way how to do offshore software development. And now we know! And we are happy to help you. We are available for a free consult with no obligations.