How to ensure offshoring success

February 2017

Paul TaylorDespite a large amount of negativity around offshoring software development, Paul Taylor - a change consultant - outlines a simple three step process to allow firms to successfully offshore software development.

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.

Comments (3)

Leave Comment
  • 1
    Ram Kundnani wrote on 1st Mar 2017

    An excellent article. I have extensive experience of offshore centric software development / support and hence would like to add that

    01. The offshore development company should have an active office with employees in the UK. Communication and coordination with UK based team will be easier rather that the team in offshore location directly.
    02. The infrastructure should be in the UK that has an access for offshore team. This reduces risks for the organisation in the UK, although, it could be expensive.
    03. UK organisations should accept the festive seasons of host country and offshore country. This can have an impact on over productivity during that period.

    Report Comment

  • 2
    David Ferguson wrote on 2nd Mar 2017

    This is a good article but the subject matter highlights everything that is wrong with the industry today.

    For some reason communication is not valued, yet for over a decade it has been acknowledged that agile software development with an emphasis on effective communication is the best approach.

    Out-sourcing is never the best way to do it so it depends what you want to achieve.

    If you want poorly written code created by people who have next to no idea about the business context with barriers to communication then go ahead, but I can tell you from personal experience over the last 15 years of working in such environments it is deeply unsatisfactory and the real costs in terms of lost business, reputation, staff turnover etc will never be measured.

    The only hope is that things come full circle, as they might with Donald Trump in the White House, and companies start to value their employees and what they can offer rather than out-sourcing to people in a different culture who speak a different language in a different timezone. Madness.

    Besides, the business model that is built on being able to provide a small army of people won't last, advances in automation mean that you don't need lots of people increasingly these days, and in any event you only ever wanted one person who knew what they are doing.

    I am being polite here, the reality is horrendous, and I have worked with some of the biggest companies in the industry, depressingly the results are always the same.

    Please do the needful and revert.

    Aaaaargh.

    Report Comment

  • 3
    Siegs wrote on 3rd Mar 2017

    Offshoring should only be considered for quick and dirty projects. i.e. it should NEVER be considered for strategic solutions. Most of the time Software Devs provide the backbone of 3rd level support and have a good knowledge of the business domain and architectures. This knowledge is extremely valuable. Why would you want to loose or not have that?? It would be better to outsourse the management that make these idiotic decisions..
    Software devs are not Code Monkeys!

    Report Comment

Post a comment