Despite 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.
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:
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).
Now you have selected your reason to offshore then you need to select your operating model. There are two types of model:
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.
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:
A number of operational model barriers will need addressing:
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.
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.
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.
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.
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.
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!
And how is this looking after the members of what after all is the British Computer Society? It may help the owners/share holders/senior executives but moving jobs overseas doesn't help the workforce
Outsourcing generally and offshoring arrangements in particular succeed and fail for variety of reasons. You are right about software project offshoring being a strategic (long term and organisation wide) concern rather than a simple operational matter. That then means the cost of failure can be far higher, with terrible consequences for all concern.
Unfortunately, majority of outsourcing decisions are based more on short term cost savings, with very little attention to long term impact on the business and people. Factors such as cultural parity, comparable professional standards, and respect for intellectual property right in offshore territories are significant but too often ignored.
With attention firmly fixed on the current Brexit debate and implications this may have for future tech talent in the UK, your article is without doubt timely and important contribution to the discussion.
Well thought out article. Heartily agree with "if you cannot clearly define the reason to offshore then you should stop the process immediately." Cost benefit analysis is vital. Businesses are finding alternative cost savings in technology that allows end user development, easier reporting tools, new rapid development languages, design-to-code conversion, automated testing. CBA should take this into account.
Transferring roles (wherever they go) always seems to lose something down the cracks; exceptional or non-routine processes, non-documented changes to process; shared responsibility functions, ability to deal with the unexpected for example. Existing services have drifted into "cradle to grave" services, and this needs to be understood as part of the bedding in process - customers understanding that the cost to continue. Conversely, this is an opportunity to decide that some services should NOT continue.
Business relationships and how the customer accesses the service need to factor in the business relationship/BA non-formal functions (just a quick chat...., how would I go about....., what do you think about...), OR they need to be costed and more formal, as a generic overhead, or retained in-house.
It is a shame that, having gone back to the more interactive partnership, shared ownership style of development of the 70s, to go back to a more formal approach being far more specific about requirements seems to be the trend with outsourcing of all locational types. To avoid this outsource teams need to be instilled with the confidence to question and offer advice, and given the time/funding to do investigations, technology backlog/ refresh and upskilling (you can be very sure that suppliers will be exaggerating skills and experience).
Many failures in 2nd party outsourcing can be directly attributed to lack of a complete set of expectations, and flexibility clauses (absence of which can be very expensive). If this is recognised from the outset, then checkpoints can be built in to enable variation of the agreement.
AND as more and more routine functions are automated, there is less opportunity/ need to outsource at all.