The right way to develop software in foreign countries

Motivation behind developing software abroad

As more countries open to foreign trade, firms gain an access to a wide pool of opportunities to seek resources abroad. They can export products to new markets, establish relationships with foreign firms or move production to new locations. The trend is reflected in the industry, as 50% of American Fortune 500 companies are using offshore software development in their business[1]. Countries offer different prices for resources, for instance the cost of developing the same software is 50% less in India compared to the US[2]. The savings come mainly from the lower labour cost. Moving software production to another country can also make the firm have access to wider labour pool and therefore skills and expertise.

Software development business models

The software development can either be onshore, meaning that it stays in the same country as the firm or offshore meaning that it is developed abroad. It can also be insourced meaning that the same company needing the software is developing it, or it can be outsourced, meaning that the client company contracts another vendor to do the development. The business model of developing software is therefore divided into four categories: onshore insourcing, onshore outsourcing, offshore insourcing and offshore outsourcing. The complexity of conducting these business models is displayed in Figure 1.

1.png

Figure 1: Process complexity of different software development business models

Source: Prikladnicki, R. et al., 2007. “Distributed Software Development: Practices and challenges in different business strategies of offshoring and onshoring”. International Conference on Global Software Engineering” (ICGSE 2007), pp. 262–274[3]

Challenges of offshore development

Companies that engage in software offshore outsourcing suffer from challenges related to culture of people involved in the process. Because two nationalities with different organisational cultures are exposed to working together, there is a high chance of clash where work practices of each of them do not match. For instance, if a German company sends its development to India it may find itself adjusting to more relaxed and laid back attitude towards being on time. If the company offshores to a country where the language is an issue, it may suffer miscommunication problems such as incorrectly understood requirements specification by the developer. Also, because the company is engaging in a new partnership, initially it may suffer from trust issues. For instance, the objectives of the developer may not be aligned with the objectives of the client. The developer for instance may want to just develop the specification and cash in on that without looking at the long-term code quality and such.

The process of offshoring the development may mean that the overall cost of production will be smaller given lower labour costs. However, there are many transaction costs associated with the production. For instance, the cost of more coordination or management and supervision of the offshore developer. Also, the country’s infrastructure has to be taken into account. For instance, if the educational institutions are weak in a specific state, then the labour pool, even though cheaper, may not be suitable for employment or require more investment into initial training. There is also the risk of miscommunication between companies in the process, which may mean that wrong product will end up being developed and therefore lead to a potential costly project failure. In a report produced by Gartner, the company states that 50% of offshoring software development projects fail due to all the challenges they face[4].

Deciding on the right business model

Because of all the hurdles of global software outsourcing, it is deemed the best to relocate only highly structured work. The creative part such as problem understanding, requirements engineering and specification generation is best to stay in house, whereas the “manual work”, such as highly structured programming, can be relocated abroad. This will ensure that the savings are achieved through workload relocation, while the quality of the product is not negatively impacted, as the client company develops its strict software specification and testing.

In his “In Defense of Not-Invented-Here Syndrome” blog post[5] Joel Spolsky arrives at a similar conclusion. In it, he says that the core of the business, where its competencies are shining has to be developed in house, whereas the functions that are not core and can be substituted, may can be relocated to elsewhere. Companies should not let go of their unique capabilities and not be afraid to relocate substitutable activities. For instance, if the company is great at requirements engineering, whereas mediocre at programing, it should do the former in house, whereas not be afraid to substitute the latter for more beneficial alternatives such as outsourcing. However, if the company is exceptional at programming it should recognise it as its unique capability and not outsource it. This situation is illustrated by Figure 2 below.

2.png

Figure 2: Parties in Outsourced Software Development

Source: Batra, D. 2009. “Modified Agile Practices for Outsourced Software Projects” Communications of the ACM, vol. 52, no. 9, pp.143-148[6]

Having interned in one of the web development vendors in India, I have seen many of our US and UK clients approach outsourcing incorrectly. They have contracted my office to develop their core product, for instance a main web portal that will be used to generate revenue for the client. The specifications we were receiving for these projects were not specific enough and resulted in us making many design mistakes while developing. For instance, we had to invent the database structure ourselves, only to later realise that we did not understand the client’s needs completely and had to redesign them. This instance was one of several where the client along with programming outsourced the requirements engineering parts and involved us in decision-making rather than just coding.

In my opinion the decision whether to develop software abroad is context specific and depends on the nature and the size of the project or capabilities of both the client and vendor. If the company decided to develop abroad to gain cost advantages, it should first acknowledge the cost and benefits of both offshore insourcing and offshore outsourcing. When deciding to use the first model, it should understand that it will be able to control its production, however it has to understand the culture and the infrastructure of the country it relocates to to avoid project failures related to the international expansion risk. If deciding to offshore outsource, it has to understand that it will be able to achieve higher cost savings, as it will not have to worry about running a firm in a foreign environment, at the expense of less control on the product quality. In my opinion the offshore insourcing is a better business model, as the company has more control over the quality of the product, which in software development is the most crucial competitive advantage the company can have. Offshore outsourcing may be more lucrative in terms of savings, but at the same time much more risky, as the outcome of such partnership is more difficult for a client company to fully control. In either scenario, before investing a lot in outsourcing the company has to first gain experience on how to best handle it. To minimise the risk it may want to start small, with possibly onshore outsourcing, seeing how the process develops and then expanding to offshore opportunities.

Conclusion

On the surface seeking cheaper labour in foreign countries may seem like a plausible idea. However, when looked at holistically, offshoring thr software development may introduce many problems and hidden costs that may make the initiative produce a loss. The decision to outsource is therefore context specific and depends on the project and capabilities of the client, the vendor and the countries involved.

References:

[1] Carmel, E and Agarwal, R. 2002. “The maturation of offshore sourcing of information technology” MIS Quarterly Executive, vol. 1, no. 2, pp. 65-78

[2] Carmel, E. 2003b. “The new software exporting nations: success factors” The Electronic Journal on Information Systems in Developing Countries, vol. 13, no. 4, pp. 1-12

[3] Prikladnicki, R. et al., 2007. “Distributed Software Development: Practices and challenges in different business strategies of offshoring and onshoring”. International Conference on Global Software Engineering” (ICGSE 2007), pp. 262–274

[4] “Gartner Says Half Of Outsourcing Projects Doomed To Failure”. URL: http://www.crn.com/news/channel-programs/18822227/gartner-says-half-of-outsourcing-projects-doomed-to-failure.htm. Date Accessed: 10/03/2014

[5] “In Defense of Not-Invented-Here Syndrome” by Joel Spolsky. URL: http://www.joelonsoftware.com/articles/fog0000000007.html. Date Accessed: 10/03/2014

[6] Batra, D. 2009. “Modified Agile Practices for Outsourced Software Projects” Communications of the ACM, vol. 52, no. 9, pp.143-148