Offshoring: does it EVER work?

Question

I know there has been a fair amount of discussion on here about outsourcing/offshoring, and the general opinion seems to be that at best it is difficult, and at worst it fails.

I have direct experience of offshoring myself; a previous company where I was a dev manager wanted to send some development offshore, and we ran a pilot scheme to see how well it would work.

Of course it was a complete failure, although it is not completely clear to me whether this was down to the offshore devs being less talented, the process, or other factors (no doubt it was really a combination).

I can see as a business how offshoring looks attractive (much lower day rate), but as far as I can see, the only way it could possibly work is if you do exceptionally detailed design up front, with incredibly detailed specifications; and by the time you have invested in producing that, you have probably spent as nearly as much as if you had written the actual code locally (which I think is an instance of No Silver Bullet)

So, what I want to know is, does anyone here have any experience of offshoring actually working ever? Especially if there are any success stories of it working in a semi-agile way?

I know there are developers here from all over the World; has anyone worked on an offshore project they consider successful?

Answer 1

I think it should. Because some of the top companies are outsourcing their IT and ITES to Big 5 companies in India.

WITCH (Earlier referred SWITCH-Satyam is almost closing)

W-Wipro I-Infosys T-TCS C-Cognizant H-HCL

Their collective revenue is more than $10 billion and 80% of their business is repeat business with the same clients. Their clients include almost 95% of fortune 500 companies. So I guess nobody will repeat their business if its not working.

I do agree that you might face hell lot of problems if you work with a smaller company who have unskilled talent sometimes.

Answer 2

The only case I have seen that worked well was when we were able to outsource a full subsystem and we were able to just specify the external behaviour. It seemed to work better than when you try to control the details.

Answer 3

At my workplace we are pretty big into using offshore consultants. As a matter of fact, half of my team is offshore.

We use a Globant for an offshore resource provider (http://www.globant.com) In two words: Highly recommended. Our interaction with the Globant team is somewhat different then what I am used to with an offshore development team.

• They are considered full fledged members of a development team.
• They all speak excellent English
• They work our hours
• They join all regular meetings
• They are able to travel onshore when required

There are always certain inefficiencies of working remote, some of them I can relate to (I work away from the main office most days of the week). However, there are always ways around them.

• It is sometimes hard to get in touch with a person in a moments notice. This usually requires planning, as well as an ability to put off your "onshore" things when you receive calls from a member of an offshore team. Time Management and flexibility is key.
• Regular scrum meetings are a must. It is very critical to have understanding between everyone on the team, on what all tasks are delivered, when, and by who.
• I found it extremely useful to have offshore developers come onsite for at the beginning of the engagement to establish communication. This allows all members of the team (offshore and onshore) to understand how the engagement will work. Offshore developers get a chance to see firsthand how their product effects the business, possibly meet the end users. Most importantly it opens up the communication channel where offshore developers are able to openly engage onsite team.
• Having an offshore project manager to help with the engagement helps.

Offshore consulting is not something to be afraid of. Most people I know, work for companies that are split across multiple locations, sometimes across the street, but sometimes across the country or the world. Who knows, your business partner might be considering you "offshore"

Answer 4

Yes, it works. Most of my career I was working as outsourced developer and most of our customers was happy. With some we had long lasting relationships that lasted 10+ years. But it's not easy, I should say and it's probably isn't cheap either. One of our customers actually calculated that price per developer they paid wasn't different from what they spent on their own guys. But it was cheaper anyway because company has stayed smaller, they wasn't spending that much money on rent and so on.

There's few techniques how to make outsourcing works. The biggest one - you have to outsource projects, so remote team could work on them independently. Another one is that you have to stay in touch with the remote team, know every developer and treat them as a part of your own team. It keeps them from thrashing and doing something you don't want to. You probably would have to interview them also to be sure they good. The third huge one is that you have to formulate all the business requirements yourself and be always available to their questions.

But as I said, it's hard anyway, it depends on so many different factors. You would be better of running couple of months trial before starting main job and even then there could be huge failure.

Answer 5

An interesting quote i read just a couple of days ago:

"Many companies don't understand yet that outsourcing isn't about exporting jobs. It's about importing innovation."

Answer 6

I think it can, but not the way lots of companies appear to be doing it at the moment.

Every time I've seen work just shipped off I've gotten back rubbish every time - sometimes you get back 100% code covered, unit tested, code analysis passed applications that exactly follow the specification to the letter, but they usually manage to somehow completely miss the point.

It's as if they do the exact opposite of dogfooding.

@Timur Fanshteyn (+1) has explained quite well below - you have to do a lot of work with them to make it work. They have to travel to your country a lot. Obviously with all that they ask for bigger salaries back home or quit for your country where they can earn 4 times as much (that's UK - US is more like 8).

Basically the cost cuts really aren't as massive as the initial figures suggest. Doing it right ends up costing almost as much as doing at home, and is much harder to get right.

I think it's gotten a lot better over the last few years, but over the same period salaries in regularly offshored to countries have gone up too. As their economies grow our one shrinks and eventually it all balances out.

@prashant_sp's argument that big companies wouldn't do it if it wasn't successful doesn't really work - big companies tend to do loads of deeply unsuccessful long term things that make the short term gains - big cost cut = nice fat dividend = poorer software in 2 years for the next CEO to worry about.

Not only that, but they repeat it - organisational learning gets harder the larger the business. Look at it this way - would you tell the big boss of your division that the software they just spent millions on (but will never use themselves) is rubbish? Or would you just quietly go back to the old system and get on with hitting your targets? In a small company someone might shout it out anyway - but do you think the decision maker hears that when they're 20 floors up?

Read up on enterprise software and the failure rate (based on whether the software is still in use after 2 years) is depressingly high - lots of very big names in that list.

I'm certain that offshoring can be done well - I just don't think it often is.

My current company does have an offshoring division, although I've never had a chance to work with them. All my direct experience is a few years out of date (with previous employers) and, unfortunately, negative.

Answer 7

Offshoring works. Most companies don't go through the same interview process, often hiring less-trustworthy outside consultants.

They are people too with varying levels of education.

Answer 8

It works, but it is never the panacea that was expected. Many times it costs just as much or more if you factor in other things than developer salary.

The biggest risk I see is losing control of your domain expertise.

There are also many cases where it does not work out too well.

So, like many other tricksy questions - "It depends".

Answer 9

I may be overly paranoid, but I find it quite frightening to hire someone. When you are hiring a developer, you are entrusting someone with permissions and intellectual property that your company relies on. In the case of a local developer, you have many options of recourse if something goes awry.

In the case of outsourced work - you are hanging on a thread. If you work with one of the larger companies, they have some equity and reputation to protect - but remember that the person actually doing the work probably owns very little and has very little to lose. In the case of smaller companies, or a grab-a-coder scenario, you've got nothing. They could decide to replicate your business model, install backdoors, etc. It's simply a matter of risk/gain. First, it would be quite difficult to detect if something bad is going on, and second, if you should suspect/detect something, legal recourse is prohibitively complex and expensive.

With almost every country in economic turmoil, I suspect that offshoring will occur less and less as patriotism and common sense drives development local.

I think the offshoring model works best when the product is a manufactured good and the consumer is located in the offshored country - i.e. Toyota USA, Honda USA, etc. I suspect the offshoring software model will fade away within the next 5-10 years.

Answer 10

I think the reason why offshoring seems to be successful so rarely has to do with the companies and/or managers who do so. Most of the time, they're the people that are looking for the cheapest possible option. The problem is that you get what you pay for. If you're cheap, you'll get cheap software no matter what country it's written in. Simply put, developing software is expensive and there's no silver bullet to make it cheap.

Answer 11

My experience is that offshoring works (better) when the offshore team is effectively a black box with their own management, development and qa. Feed in detailed requirements and a quality standard, and only accept delivery when met. Attempting low level management of a detailed development program remotely usually fails.

And always make sure you have access to the source code in development - a client I have been working for recently had to decompile their own products after an outsourcer refused to hand over the source during a financial wrangle.

Answer 12

Most out-sourced software development ends up with a product that is late, over budget and delivered without all the agreed upon features. As we all know, this never happens with in-house software development.

With that said, the only out sourced system that I've seen actually work well was one that was a reverse engineering project. There were two old clunky vb6/sybase apps that were to be ported to be web apps. The out source firm did a screen-by-screen report-by-report port to asp.net/sql server2k on time and almost on budget. My involvement was to listen in on the by-weekly status phone call where they would request clarification and we would agree to send screen shots and word documents.

This project was a success. After spending a boat load of money, the clunky vb6 app with a dated UI and antiquated feature set that no one knew how to support was replaced with a clunky asp.net app with a dated UI and antiquated feature set that no one knew how to support. Mission accomplished.

Answer 13

I work in a large company (50k+ employees worldwide) with design and technical centers in the Philippines, China, India, etc.

For the particular project I'm working on at the moment the team includes several people from each location.

I don't know what the price difference is, so I can't speak towards whether it 'works' because I don't know whether there is a true cost benefit - I can only assume there is since they continue to run business this way.

It works well enough - usually the parts that are assigned are either well documented, or only require minimal orientation throughout the development work. As long as we have developers here that can review the work, comment and re-direct, it gets done, and it's done well.

Minor issues we still have to deal with include:

• Turn over. Once someone gets sufficient experience, they move to a new job (given that many companies simply don't offer raises, this is the only way to progress economically)
• Language barriers. They understand and speak english well, but many members of our team here still have difficulty with the strong accent. Due, I suspect, to cultural barriers it's often easier for people to say, "I understand" over the phone even when it's obvious they don't. Some conversations take several times longer than they should.
• Time delay. It takes a day to realize they worked on the wrong thing, and to re-direct their efforts. Often it pays to check email at 9PM or later and check in with them as they start their day.

Their written English is great - good for technical documentation, and they are awesome for testing and code review. Their technical capability is very, very high. Communications is really the biggest issue. The company often brings them here for weeks at a time so people can get to know each other, and they can better understand how work progresses here. This has substantially increased communications ability over time.

Given globalization, I thinks it's foolish to dismiss outsourcing out of hand as unsuccessful. Even if it looks unsuccessful from the developer's point of view, it's obviously successful from the accountant's point of view. Keep in mind that often outsourcing enables use of different accounting methods so that even if it costs more in terms of dollars, it costs less in terms of overall company resources.

Learn how to work with others on different terms (time, space, language, culture) and you'll be ahead of the game.

Answer 14

Talking from personal experience of having managed off-shore projects from an on-shore base the most significant challenges are:

• misaligned interests

• availability of information

• control

• security and compliance

• communication

As far as "does it EVER work" concerned: it does. It doesn't work well though. Most people can run, doesn't mean that most people can run as fast as Usain Bolt.

Communication

Normally this is brought forward as the biggest challenge. But it is not, it is the least of all problems, which doesn’t make it less significant though. You need to communicate using same language and it is almost always the language of the client. Needless to say that off-shore devs with a good command of, lets say, English are more expensive and on many occasions are hard to attract.

Hence off-shore shops tend to have a few more expensive people who can communicate well and a bunch of cheaper doers (usually CS students) struggling to comprehend even technical docs.

Compared to a native speaker docs takes longer to writer and their quality is lower. UI may, at times, carry awkward labels and messages and might need to be revisited on-shore, at extra cost.

Then there are some harder to communicate and more abstract business concepts that are hard to grasp outside the business, economic and cultural context.

It’s possible to overcome communication problems by use of collaboration software, choosing sensible communication hours and frequency, hiring an on-shore project manager who is able to speak off-shore language, keeping a tech writer on shore etc. But it all comes at a direct financial cost.

Security and Compliance

Apart from letting your source code sit at the off-shore hard drive there you might have little direct control over its fate you will inevitably hit testing and business support related issues. Both testing and support are likely to require access to live data or live systems containing sensitive info. Any personally identifiable info on individuals (at least in European Union, but there be should similar legislation in States) considered sensitive and needs to be protected. Passing it on into countries that might have less strict data protection laws constitutes a regulatory breach.

Ways round the problem include keeping business support on-shore or bringing off-shore people over for short periods of time, de-personalising test data, defining and enforcing security policy etc. It is needless to say that some companies struggle to manage their internal compliance and security risks, let alone off-shore: you'd need to educate and monitor devs who, because of the constant cost pressures, are very much inclined to cut corners.

A breach can attract a serious fine, negatively affect customer base, cause loss of intellectual property — you name it!

Control

When off-shore team is an external organisational entity it is very hard to control who they hire, who they put on your project, how they train developers (if at all), who they keep and whom they move to more lucrative projects, and, above all, what happens to your source code. Sometime it's even hard to control that developers put enough hours in, I don't mean any overtime, just the time you've paid for (technology factories are usually susceptible of this behaviour).

As the project matures a lot of control and negotiation power tends to drift to the off-shore location. An alternative is to change the horses, but it might cost you dearly. You can’t just oust individuals; you have to oust the entire team.

Availability of Information

Some of the core domain information and implied requirements are not going to be available to off-shore team, at the same time fearing to loose contract or be seen as incompetent they might dread to ask questions and will tend to focus on acquiring solutions on their own. Physical separation from the users might also be fairly difficult to overcome. Often the off-shore team just doesn’t feel the pain when something goes wrong and can’t imagine let alone see their app being used by any breathing creature.

On the other hand don't expect them to be quick reporting about any of their problems, since they might expect you to see it as a weakness, as a threat to securing a contract, receiving next payment or as potentially projecting a bad image of their abilities.

Real live examples?

• Estimation for the next piece of work increases threefold in comparison to the most recent module finished taking everyone on-shore by surprise and still the team does not seem to be very keen. After many questions we’re told reluctantly that the former piece took twice as long as it was planned and paid for, besides the team had to work evening and weekends. The were reluctant to tell since they percieved this as entirely their own issue.

• At some point during a private conversation it turns out that some of the worst newly discovered software issues are known and been identified during off-shore testing but the team didn’t want to highlight them since it could affect deadline. They were hoping to fix these later, quietly.

• The team didn’t have much real life exposure to technology X, but it was too late when they realised that they would need to use the technology extensively, so they didn’t wish to rock the boat and bring the issue forward, since it would affect timelines, costs etc but rather decided to push the solution towards using less relevant and more limited technology Y. Having had they mentioned the actual problem and the extra time and budget would have very likely been granted in the name of a better end result.

When off-shoring team is an external entity information just doesn’t flow as freely as it would be necessary to achieve best outcome. It makes it difficult for both parties to validate and verify decisions made by the opposite side.

Misaligned Interests

Whereas off-shoring customers are interested in lower cost, off-shoring providers want to make more or easier money than they would have made on the domestic market. They care about receiving next contract as long as it is easy enough and gives sufficient profit margin.

Some off-shore devs are not particularly worried about quality of code as long as they get their bills paid and gain valuable work experience in a sweatshop that will enable them to finish uni and move onto more exciting domestic projects there they can actually meet and talk to real users.

Counterarguments

Some say “we will keep QA on-shore and employ local BA’s and project manager to keep the off-shore development team on the short leash.”

Although any software where requirements evolve or subjective (so called e-type) when taken off-shore will definitely benefit from on-shore project manager or coordinator plus on-shore BA and QA, the extra people won’t provide a “silver bullet” solution to many problems.

These people on-shore will be very capable of explaining post-factum what went wrong and why it went wrong (same as in the case of the financial crisis or incorrect weather forecast for that matter). But most of them won’t see it coming. Because requirements evolve and cannot be plainly modelled on a piece of paper much smaller than the printout of the software source itself. Because no sane sweatshop is going to hand the code over until they received the payment (source is their only serious leverage!) and without the source QA is fairly superficial. Because the off-shore is not going to proactively share information that will help invalidate their solution (the interests are misaligned, remember, when you want quality they want payment). Because being able to point out an error or misspelled label is quite different from being able to write robust and elegant software with perfect English UI and no amount of errors will teach the off-shore team overnight how to produce quality. And the devs who can do robust software with perfect English UI don't need to work in off-shore sweatshop, they can chase much more attractive jobs worldwide.

Summary

Large companies that open their subsidiaries off-shore can tackle most of the issues and still get the benefit of cost saving. Often however for these companies it is worth to move the development of software closer to users, i.e. do localisation in the office actually based in the target country or move developing of manufacturing software closer to the actual factories etc.

Smaller companies looking at hiring 2-15 developers or these companies that have a strategically important software to produce would actually be much better off hiring as locally as possible.

Answer 15

It's scary, but offshoring can work. I know a manager who got a project done by getting bids from programmers all over the world. This project was severely underfunded, and would never have even happened if he hadn't be able to get it done on the cheap.

His bidding process led to him using some great programmers in Iceland. These guys were billing at about a tenth of what I bill at.

Apparently, when you have a government masquerading as a hedge fund, you end up with a country full of programmers who will code all day for a loaf of bread.

Answer 16

of course it can - you offshore all the project managers, programme consultants and outsourcing analysts you can find.

The one's who're left behind can then get the work done in peace :-)

---

serious answer: its never the managers who are outsourced, just the programmers. The mind-set required by someone thinking that is a good idea, is someone who thinks that programming is an easy job that can be performed by any cheap, low-skilled, 'coding resource'

Answer 17

I've seen it work in a few cases over my years. Let me elaborate a bit on each of these:

1) Seattle office + Russian partnership. Here, I was the lone developer in the U.S., while the rest were in Russia and we were building an ASP.Net version of an ASP site that went OK, though the company did go under eventually. In this case, there was often someone from the company over in Russia to keep things running smoothly where the initial idea was that the Russians would get a printing press in exchange for digital sheet music pages coming out of Russia which was still going but they also had some developers work on a few other things. There was some KGB stories as well as working where nuclear science was being researched in a city called Chelyabinsk.

2) Seattle office + Vancouver partner. Here, where I worked had acquired a Canadian company and was doing a shift in the order-entry back-end which involved the team I was in handling calls from a legacy CSR application called Clarity where a third party had been brought in to build the API my company would use so that things didn't change for the CSRs using Clarity. While it did a while to get done and require lots of conversations, it was ultimately done. So, to paint the picture, my company would build this API that would be taken by the 3rd party to fit onto the current CSR tools that the acquired company was using.

3) Canadian office + US and India. Now where I am we have some projects where the offshored are in the US and India to get the expertise to get the job done. This is still ongoing so I can't really say if it worked out well or not.

The first two would likely fall under an Agile approach as things changed fairly often yet we got through it.

Answer 18

Offshoring: does it EVER work? = Do mediocre programmers EVER create good software?

Would the answer really change based on the country of residence of the “average” programmer? I really doubt.

I tend to believe (thought I could be completely wrong) that Management gets quite “greedy” when offshoring projects and hires very mediocre programmers in the offshored countries in an attempt to cut cost further.

Meritocracy + Distance + Culture difference can all lead to a very ugly situation.

I believe a team of “excellent” programmers will create “excellent” software ANYWHERE.

Answer 19

hi all,

"Totophil" : I agree with many of his points.

As far as companies/countries go, you get what you pay for. By pay, I mean, how much references you've got about that company/team and whether you've visited their offshore office, etc.

It helps to read the book "My job went to India" -- http://www.amazon.com/Job-Went-India-Pragmatic-Programmers/dp/0976694018. The author points out what he learnt when he moved to India to work with the developers their and his experiences in recruiting, training and getting work done. Once you know what does NOT work, it helps to know WHAT WORKS and then be proactive in tracking the project/product's progress.

It does help to know that accents can be a bother -- you have to learn to speak slowly; Make a heavy habit of using wikis to share information; Have a shared source-code repository so that you can regularly monitor what's happening and keep a 2 way feedback loop.

I'm sure offshoring doesn't work for all types of personalities, companies and all types of projects/products BUT there's a good chance that if you've done your homework of screening the companies and meeting/evaluating their infrastructure AND letting them know that you've done your homework, you should be good.

Regarding those who say that it is NOT any cheaper, that is the case when there are many failed projects and finally you get a success. I'm NOT saying that right from word GO, things will be smooth; BUT if you've done your homework right from the beginning and have the right infrastructure/processes in place for dealing with issues, crises, conflicts, you should get atleast 50% cost saving, if not more.

BR,
~A

Answer 20

@Preets

Yes, greedy management IS in fact a problem. When you have two companies working together, you have two management. What you mentioned refers to one side of the coin, namely greedy customers.

What about greedy offshore companies? Most of the resources that we get cooked up their resume, and it become so much obvious when we are having meetings during the project. Granted, some of the developers are good. But its not an excuse for the rest so that they can cheat their way into the project.

My advice - conduct a really comprehensive interview to know them inside out. And have a good lie detector.

On whether offshoring could be done successfully, yes it can be done. But what you have here is trading cost with risk, which can be good compromise in some situation, bad in others.

If you decide to offshore parts of your development, be good at handling the risk. I guess that's all there is to it.

Answer 21

I am based in Singapore. I have had three jobs so far, and in all of them, my center was considered an offshore facility. Singapore is not a third world country (anymore, anyway), but most of the developers in the local office were either Indians or Chinese. I myself am an Indian citizen. In the first case, the company HQ was in Florida, in the second, in NYC. The third was an investment bank with centers all over the world, with prominent presence in NYC, London, and Tokyo. They had a major software development center in S'pore employing a lot of Indians imported from India.

My experience: the model works very well if there's strong local leadership, local hiring standards are high, and the processes are ironed out. Team members have to make a conscious effort to bridge the communication gap.