Onshore, Offshore – are you sure?

Mike Bromwich, Technical Director, PDMS

With the ever-changing dynamics of the IT industry, there are not many organizations involved in the delivery of systems who have not considered alternative models for development. Onshore, offshore, near-shore, subcontract, outsource – the options have become as baffling as buying coffee. The incentives are enticing – reduced cost and risk, compressed timescales, access to specialist skills and so on, but each of these paradigms comes accompanied with a variety of hazards which need to be acknowledged and mitigated if the advantages are not to be diluted or even washed away completly.

The most prominent approach over the last decade has been off-shoring – a term typically used to describe the use of overseas development teams from distant shores such as India and China. One of the primary drivers is reduced cost - these countries have highly-skilled workforces who command salaries often twenty percent that of their US counterparts. The scale of the operations specializing in providing such services means that teams can be expanded and contracted quickly to meet the project profile – helping to keep the project on-track even in the face of slippage.

There are, however, downsides. Firstly, the results achieved are likely to be very sensitive to the quality of the requirements provided, although you could argue that this is always the case. With an in-house development team, a cohesive approach which keeps all project stakeholders involved in the developing system allows requirements to be continually refined, and allows misunderstandings to be spotted and rectified early. The current trend for agile development can exacerbate this problem, as can misunderstandings resulting from language and cultural difficulties and differing time-zones.

Other problems which can arise are related to intellectual property and data privacy. For example, a disgruntled Indian employee may take source code and deliver it to a competitor. Taking action under Indian intellectual property laws may be difficult since India has no laws against trade theft.

If the intention is to bring the ongoing support and development of a system in-house following delivery, additional issues arise which require careful consideration at the outset of the project. Common-sense can be remarkably subjective, and conventions and standards which an in-house team consider to be standard practice can be lacking if not explicitly stated and agreed in advance. Technical documentation delivered by the offshore team will need to be closely scrutinized if an in-house team is going to pick-up where the offshore team left off.

Some of these disadvantages can be resolved or reduced by refinements of the offshore model. In particular, having representatives of the offshore development organization onsite to manage communication and delivery can make the offshore team more effective. Taking this a stage further, a hybrid model where a proportion of the development team works onsite, typically on user-interface and related elements, can provide additional advantage on larger projects.

A variant of the offshore model is near-shore. This involves organizations who typically provide offshore services establishing teams geographically closer to their clients. For example ICICI OneSource, one of India’s leading business process outsourcing companies, has recently established an operation in Belfast with 400 employees. Their Londonderry centre will employ 600 people by the end of next year.

This approach brings a variety of advantages – more opportunity for liaison between the development team and the customer, similar or identical time-zones, and more familiar legal regimes. In certain industries, such as healthcare and financial services, regulatory requirements prohibit personal information from passing outside of the EU – the near-shore approach allows tighter control over such issues.

There a numerous other options available – rural outsourcing, home working and so on. In each case, it is important to carefully choose the development methodology to be used, and then consider each stage of the project lifecycle in turn. For each element, responsibilities and communication channels have to be defined and managed. Testing, in particular, required careful consideration, since this is often an iterative process which can be impaired by disparate time-zones. Subsequent support also needs to be carefully considered – particularly for highly technical systems. If the developers are on the other side of the planet, diagnosis and troubleshooting can cause difficulties.

We will not doubt see further refinements to these models in the years ahead. The key to any of these approaches working successfully is communication – luckily, the technical advances which are driving these changes are also providing better communication tools which can help.