Software development is a generally challenging, expensive and a complex activity. In an effort to counter these challenges, organisations increasingly migrate software development to lower cost regions.
Proponents of migration, or offshoring, argue that this makes the software development process cheaper, quicker and more flexible.
However experience has shown that this is not a silver bullet and badly implemented offshoring can result in increased cost, complex processes, a loss of intellectual knowledge and a general increase in stress levels.
This article explores some practical ways in which you can ensure you make the right decisions when starting an offshoring project.
What is the reason to offshore?
Firstly, you must have a clear reason why you want to offshore and this must link to your organisation’s strategy. There are six common reasons for offshoring:
- Costs savings is the most common reason. Simple tasks normally generate the most savings but hidden costs must be noted (e.g. transitional costs). Therefore you must fully understand the payback period and if any savings are small then you should ask ‘is it worth the effort? and could we focus our effort elsewhere’.
- The next reason is flexible resourcing. This is becoming increasingly common. A model is implemented to you to flex up and down resourcing levels using the offshore team. In effect the resourcing problem is ‘given’ to the offshore team and it saves you the hassle, time and cost of managing this.
- A third reason is ‘access to a talented and scarce resources. Offshore have more people and they can be accessed quicker and often cheaper. This can be used to either (a) obtain access to newer technologies for new developments and/or (b) obtain access to older technologies for, say, supporting legacy systems.
- A fourth reason is to take advantage of the differing offshore working hours to provide wider working window. Although this reason is often used in conjunction with another reason.
- Some organisations see software development as a non-core element and is it outsourced (or offshored). The logic is that development is a ‘black box’ which can be moved outside the organisational boundary with no issues. However, apart from the challenge of implementing offshoring, technology is key to all organisations. Therefore this reason is often not valid.
- Finally you could offshore to provide ‘back-up’ sites for onshore teams. Although this is often a by-product of actually offshoring.
When you have finalised your reason to offshore, there are a number of stakeholder management issues that need addressing. Firstly it is important to note that some of the reasons listed are contradictory and stakeholders need to understand the pros/cons of each reason. For example implementing a ‘flexible’ model could actually cost more and, if this reason is selected, then stakeholders need to understand this. Secondly, regardless of the reason selected, stakeholders must understand that offshoring is an organisational-wide transformation which could take years to complete. It is not a silver bullet or quick fix.
Therefore if you cannot clearly define the reason to offshore then you should stop the process immediately.
(It is also worth noting that once you have offshored then your reason could change as your situation changes. For example if you offshored for cost-savings then as your model matures it may allow you to implement a flexible model).
Selecting the suitable model
Now you have selected your reason to offshore then you need to select your operating model. There are two types of model:
- Captive Offshoring. This is where your organisation will create their own office in the offshored location. This will involve upfront costs and effort around selecting a location, recruiting staff, building the infrastructure, etc. However once it is up and running then it will provide cost savings because its running costs are pretty fixed.
- Outsourcing Offshoring. This is where your organisation will engage an offshore vendor. This will involve smaller upfront costs but higher ongoing costs which means it does not suit you if you are looking to save costs. It is more suited towards smaller organisations looking at a flexible model. However it is important that you do not under-estimate the effort required in selecting a supplier. This covers ensuring there is a good cultural fit and commercials in place. Having multiple suppliers increases complexity as well.
There is no evidence on which model is best although large organisations who want to save costs tend to following the Captive route whereas smaller organisations (regardless of reason) tend to following the Outsourcing route.
Now you have confirmed both the reason and your model then it should be possible develop a business case (with associated business benefits, costs, timelines, etc) for senior approval.
Managing the implementation barriers
Assuming the business case is valid then you can move onto the implementation. This is not an easy process and it will involve addressing cultural, operating model and transitional issues.
Consider the following issues:
- There will be cultural and language differences which need identifying and addressing. To help both groups work together, it is important to treat both the onshore and offshore teams as a partnership. Offshore needs to been seen and feel as an extension of the onshore location. This will require compromise on both sides around working hours, processes and regular face-to-face visits.
A number of operational model barriers will need addressing:
- You need to define what ‘offshore development’ is and clear principles need to be in place to determine what goes offshore. Easily codified tasks (like development or simple support) are easier to offshore but any work offshored must be big enough to benefit. Therefore each piece of work must be judged on its own and you should dodge the urge to send ‘X %age’ of work offshore. You could look at pushing higher value tasks 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.
An appropriate Operating Model needs to be implemented. At the top there should be strong Governance covering (a) processes, demarcations, roles/responsibilities and standards supported by (b) controls such as weekly reports, weekly meetings and senior management meetings. On the ground then should be controls that cover (a) allocating and tracking work (b) ensuring quality of specifications and code and (c) a joint SDLC.
You will need to make onshore organisational changes to cope with offshoring. Jobs will change, new roles will be created (e.g. Oversight) and current roles could be redundant. This will be unsettling for your onshore people and they will need to be helped through the process.
You will need to ensure communication tools (like email, tele/video-conference, etc) are in place. However do not forget face-to-face communication is best. Therefore regular visits (to both sites) should be planned in.
Finally it is important to keep some knowledge in-house (such as architectural design, project management and business analysis). This helps challenge offshore estimates, plans and work. It would also support any exit plan when/if you decide to exit the offshore arrangement.
- There are also a number of transitional barriers:
Expect and allow for mistakes in the initial stages. Therefore start with simple tasks and then build up as confidence grows.
You also need to remember that offshoring is unsettling for the onshore people. Therefore full communication is required with the impacted people to ensure they understand why the change is necessary and how it impacts them.
Thirdly allow sufficient time to complete the Knowledge Transfer. It must be thorough. It is important to note that onshore people may need motivation to help complete this work.
Allow sufficient time to put the technology infrastructure (such as network links, email, test environments, etc) in place. Implementing networks across national borders takes time.
Finally the onshore team should take an active role in training the offshore team in both business and technology skills. Offshore teams have higher turnover rates which means training is an ongoing process.
And finally Brexit
A large amount has been written about Brexit but from an offshoring point-of-view, nothing has really changed. Some offshoring projects are being delayed but that is true of many projects currently.
