A large amount has been written around offshoring software development and whether it provides benefits, etc. However I think that it is possible to implement an offshored software development model by following the following three steps.

Step 1 – What is the Strategic Reason to Offshore Software Development

Organizations must have a crystal clear strategic reason for offshoring software development and this reason must link with the organization’s strategy. 

Furthermore all stakeholders (viz: Staff, Management, Clients, Investors, etc) must fully understand the advantages and disadvantages of the reason to offshore and need to understand that offshoring is an organisational wide transformation activity which could take one or two years to complete fully.  It is important to stress that offshoring is not a silver bullet or quick fix and organizations should resist the temptation to rush implementation and ramp-up (esp. if cost savings are the main reason).

If an organisation cannot clearly define the reason to offshore then they should stop the process immediately.

Anyway there are typically six reasons why organizations offshore software development:

Reason 1 – Cost Savings

This is the most common reason (although there is evidence that this is reducing).  Basically organisations want to save costs by either more output from the same cost or the same output but with a reduced costs.

Normally simple tasks generate the most cost savings. However hidden costs must not be ignored (e.g. the transitional costs, new running costs, etc). Therefore organisations must fully understand the payback period and if any savings are small then they should ask themselves “is it worth the effort?’

However it is relatively easy to measure the success of this – i.e. costs after should be lower than the costs before.

Reason 2: Flexible Resourcing

This reason is becoming more and more common. In effect a model is put in place to allow the onshore organisation to flex up and down resourcing using the offshore location. The resourcing problem is ‘given’ to the offshore location and it saves the onshore organisation recruiting staff which can be expensive and time consuming.

However this reason is hard to measure because it is subjective.

Reason 3: Access or use of talent resources (often at a lower cost)

Offshore sites have more resources and they can be accessed quicker and often cheaper. This can be used in two ways; namely (a) access to newer technologies and / or (b) access to older technologies – e.g. COBOL or PL/1

However this reason is subjective and harder to measure

Reason 4: Wider foot print

Onshore organisations take advantage the differing working hours of offshore to provide wider coverage. This reason is often used in conjunction with some of the other reasons.

Reason 5: Software Development is seen a non-core element

Software development is seen as non-core element is therefore outsourced (and sometimes offshored).  The theory is that development is seen a ‘black box’ or ‘commodity’ that can be moved outside the organisational boundary. However there are problems with this reason; viz (a) technology is key to most organisation and (b) outsourcing or offshoring is often seen as risky

Reason 6: Resilience and Business Continuity

Organisations move offshore to provide ‘back up’ sites for the on-shore development teams and locations. Although this reason can be a by-product of actually offshoring

Two final points

Firstly some of the reasons listed above are opposites. For example “cost savings” and “flexible resourcing” are opposites. In fact by implementing a “flexible” model then it could actually cost more. It is important that all relevant stakeholders are aware of this.

Secondly, many organisation who have offshored have actually changed reasons as their model matures. For example they originally offshored for cost savings reasons but as the model mature it allow them a flexible resourcing pool

Step 2 – Decisions to be made once a Strategic Reason is agreed

In fact there is only really one main decision – although it is important. Once the decision to offshore is made then the organisational must chose the type of offshore model:

• Captive Offshoring – i.e. the onshore organizations create their own office or presence in offshore location
• Outsourcing Offshoring – i.e. the onshore organisations uses vendor for their offshore presence

There is no real clear evidence on which model is best or worse – however the decision is driven by the size of the organisation and / or the reason to offshore. Again if an organisation cannot clearly define what model they require then they should stop the process immediately.

Captive Offshoring

This will involve large upfront costs and effort around finding a location, recruiting staff and building a suitable infrastructure. However once it is up and running then it can provide cost savings because it is driven a fixed cost. Therefore this model is often suitable to large organisations (who have the capital to fund the set-up) who are looking for cost savings

Outsourcing Offshoring

This will involve smaller upfront costs but higher ongoing costs which means it does not really suit organisations looking to save costs. It is more suited towards smaller organisations looking at flexible resource pool. 

However it is important not to under estimate the effort required in selecting a supplier. This covers ensuring there is a good culture fit and well as ensuring clear commercials are  agreed (covering (a) definition of services (b) service levels (c) KPIs around costs, quality, defects, rework and so on (d) penalties for breaches as well as bonuses for good performance and (e ) an Exit plan). Organisation should not be afraid of choosing a less well known supplier or even niche suppliers – but need to remember that having multiple suppliers increases complexity.

Step 3- Manage the Implementation Barriers

Now the organisation has a clear reason to offshore and have determined their model, they can move to the actual the implementation of the offshore model. However, like any organisational transition, this is not an easy process and a number of barriers will need to be addressed.  (For the purposes of this document, these have been grouped in Cultural, Operating Model and Transition barriers).

Cultural – Understand and managing cultural differences

There will be differences and these need to be identified and both onshore and offshore need to work together to address them.

Cultural – Treating on and offshore as a partnership

This is true for both captive and outsourcing models. Offshore needs to been seen and felt as an extension of the onshore location because it will help build a good working relationship. Compromise will be required on both sides around working hours and regular visits. This partnership should support the legal structure (see above) as well as the governance model (see below).

Cultural – Manage language differences

Similar to above – there will be differences and they need to be managed. Verbal communication should be supported by written follow-ups – e.g. emails

Operating Model – The on-shore organisation needs to define what ‘offshore development’ is

Clear principles need to be in place to determine what goes offshore. Typically easily codified tasks can be offshored easier such as development, 2nd or 3rd line Production Support, Testing, etc. 

However the work offshored must be big enough to provide sufficient benefit – therefore each piece of work must be judged on its own merit. Organisations should try and dodge the urge to send ‘X %age’ of work offshore

Some organisations are looking at pushing higher value task off-shore (such as R+D) but there are split views on this. The No’s say this work cannot be codified but the Yes’s say that creating a closer partnership will allow this to happen

Operating Model – Implementation of appropriate Operating Model

An operating model needs to be put in place for offshoring which both sides follow; this covers both captive and outsourcing models

At the top the level there should be a strong Governance model in place. It should cover (a) process flows, demarcations, roles/responsibilities and standards supported by (b) regular controls and checks such as weekly reports, weekly meetings, senior management meetings, etc. Good governance will help foster a partnership

On the ground then should be a series of process and controls that cover (a) allocating and tracking work (b) ensuring specifications are of sufficient quality e.g. by employing walkthroughs or re-play sessions (c) a joint SDLC and (d) processes that ensure the quality of software is acceptable; e.g. defects, does it match the spec?, testing and so on

Operating Model – Onshore may need to make organisational changes to cope with offshore

Onshore jobs could be changed and new roles could be created (e.g. Oversight) which will require filling and training.This will unsettling and hard to take for the onshore folk. However it is important to remember that implementing offshoring is an organisational transformation activity.

Operating Model – Ensure tools are in place for communication

Tools like email, IM, Tele Conference, Video Conference, etc should be used but face-to-face communication is always best. Therefore regular visits by both parties will help. The costs for this need to be included in any business case.

Operating Model – Keep some Knowledge in-house

It is important to keep a spine of knowledge in-house (such as architecture design, project management and business analysis) because it helps challenge offshore estimates, costs and plans. Furthermore it would support any exit plan

Transition – Expect and allow for mistakes in the initial stages

Therefore it is best to start with simple tasks and then build up as confidence grows. One needs to learn to walk before running

Transition – The onshore team need to be managed through the process

Offshoring (like any change) is unsettling especially if redundancies are taking place. Therefore full, proactive and open communication is required with all directly and indirectly impacted people. They need to understand why the change is being made and how it impacts them..

Transition – Allow sufficient time to complete the Knowledge Transfer

It must be thorough and do not ‘cut corners’. It is important to note that onshore may need motivation to help complete this work

Transition – Allow sufficient time to put the technology infrastructure in place

Network links, email, test environments and so on take time to be put in place.

Transition – Training and support for the offshore team

The onshore team should take an active role in training the offshore team. This covers both the captive and outsourced models This training should not just focus on technology skills. It should focus on business skills. It is important to note that offshore teams tend to have higher rate of staff turnover. Therefore training is a constant process

Summary

Therefore I believe that it is possible that offshoring software can provide benefits but it is important that the following points are taken into consideration:

• Organisations must have a crystal clear reason for offshoring
• Organisations select the model they require carefully (i.e. captive vs outsourced) based on the reason to offshore.
• Organisations must recognise that the transition is a ‘rocky path’ and will require effort to complete
• Even when the transition is complete, it will take time to ramp up to full capability
• Finally full Stakeholder support is required.