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 development 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 developers 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?

This question came from our site for professional and enthusiast programmers.

6

It can work rather well if the country that is being outsourced to is less than 8 hours diff and has strong engineering education but not great economy, say Czech Republic or Serbia (relative to New York) AND everyone on the team has at least 30k score on StackOverflow and they meet other criteria as well and you send one of your senior guys over there for a month or two AND you pay them very competitive salary. It helps if they also have 5+ years of experience working for real companies, so that they have seen the good, the bad and the ugly.
–
JobSep 11 '12 at 18:09

29 Answers
29

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, but it 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 the same language and it is almost always the language of the client. It is needless to say that off-shore developers with a good command of, let's 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 computer science students) struggling to comprehend even technical documentation.

Compared to a native speaker, documentation takes longer to write 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 the off-shore language, keeping a technical 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, where 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 information. Any personally identifiable information on individuals (at least in the European Union, but there be should similar legislation in United States), is to be 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 developers who, because of the constant cost pressures, are very much inclined to cut corners.

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

Control

When the 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 the off-shore team, at the same time fearing to lose the 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 application 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 the 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 perceived 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 the 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 the off-shoring team is an external entity, information just doesn’t flow as freely as it would be necessary to achieve the 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 the next contract as long as it is easy enough and gives sufficient profit margin.

Some off-shore developers 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 university and move onto more exciting domestic projects where they can actually meet and talk to real users.

Counterarguments

Some say “we will keep QA on-shore and employ local BA’s and a 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 an on-shore project manager or coordinator plus an 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 developers who can do robust software with a 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, that is, 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.

I disagree that communication is the least of all problems. IMO, it is the most significant problem because the feedback cycle is significantly increased. The more timezones in between the client and the developer, the harder it is to get timely feedback and the greater the odds of a delay in project completion or delivery of something not desired. Where using development teams in different timezones can work well is when the remote team can code to an narrowly defined testable interface.
–
ThomasFeb 11 '11 at 16:48

7

IMO the root of all other problems is misaligned interests. Without exception it's the case why the offshore stuff I've known first hand (from the provider's perspective!) failed. We only cared about delivering stuff quickly, quality be damned, and getting more projects. "Poor quality devs" are merely a consequence of this: the provider hires cheap, junior devs as a way of cutting costs. It DOES NOT mean non-English speaking coders are bad; it's just that the provider picks bad coders. There ARE excellent offshore devs; it's just that they aren't as cheap as US customers want.
–
Andres F.Sep 11 '12 at 18:32

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 outsourced system that I've seen actually work well was one that was a reverse engineering project. There were two old clunky Visual Basic 6.0/Sybase applications that were to be ported to be web applications. The outsourcing firm did a screen-by-screen report-by-report port to ASP.NET/SQL Server 2000 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 Visual Basic 6.0 application with a dated UI and an antiquated feature set that no one knew how to support was replaced with a clunky ASP.NET application with a dated UI and antiquated feature set that no one knew how to support. Mission accomplished.

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 it.

I tend to believe (though 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 costs 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.

I disagree. There's a well-known principle that "defect rates are proportional to distance in the org chart." What off-shoring does is to maximise org-chart distance, so an excellent off-shore team can never produce code that fits its purpose as well as an on-shore one.
–
regularfryFeb 11 '11 at 14:24

Are you implying that offshore programmers == mediocre programmers? Well, we are sorry to live away from your center of the universe.
–
SoskaFeb 11 '11 at 19:31

6

@dr. evil, +1! Mediocre programmers with a methodology will always deliver much better results than a motley crew of "rock star" sole hunters who naturally oppose to any kind of methodology. "Excellent" programmers can only be used in very small teams or for cleaning up a mess.
–
SK-logicFeb 12 '11 at 13:28

2

@Soska, No I am definitely not implying such a thing. If you read the entire answer, you will realize that it is the implementation of "offshoring" that I find flawed.
–
PreetsMay 24 '11 at 18:29

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"

I know plenty of people who work for Globant in my country and... let me say it this way. It's scary. They will hire almost anyone, regardless of English-speaking skills or any skills at all. Passing their interviews is a joke. So the conclusion at the very least is that Globant's quality varies wildly from country to country :-/
–
Andres F.Sep 11 '12 at 18:41

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 9 PM 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 think 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, and culture) and you'll be ahead of the game.

While the accounting angle is real, the financial engineering aspect reminds me of a ponzi scheme. The whole Opex vs Capex argument been the cause of more bad decisions than I can count.
–
BillManFeb 11 '11 at 15:23

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: it's 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'.

The way it works is if you DO Offshore the management as well. Think of it as opening a subsidiary in the country instead of "we'll hire this company to do this work on a temporary basis". Also: Offshoring != outsourcing. You can Offshore while still having it be part of your company, and you can also outsource without having it go out of the country. I've seen a successful project where the project was "Outsourced" to a company that was ~50 miles from our company.
–
LucianoFeb 11 '11 at 16:00

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.

Yes, it works. Most of my career I was working as an outsourced developer and most of our customers were happy. Some of our clients had a 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 are few techniques on how to make outsourcing work. 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 to be sure they are 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 the main job and even then there could be huge failure.

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.

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.

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 in another answer - 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.

>>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 yrs.. Couldn't agree more. Coz if "they" actually cared to do it well, it would involve too much effort and too little personal benefit
–
PreetsFeb 2 '09 at 16:35

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.

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 it's not working.

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

The fact that big companies are outsourcing is not proof that it works. Neither is repeat business. If you have "down-sized" all your internal knowledge you are left with little choice. I think the model does not work as a general proposition but can work if managed carefully.
–
SimonFeb 2 '09 at 12:33

As far as companies/countries go, you get what you pay for. By pay, I mean, how many 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. 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 and have a shared source-code repository so that you can regularly monitor what's happening and keep a two-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 at least 50% cost saving, if not more.

We do ours in Romania and it works really well. The quality vs price is far better than any other place I've been seen.

Can it work? Yes.

Does it always work? No.

Is it difficult to get it to work? Yes.

Does every manager in the "first world" think it's easy to get it to work? Yes.

I've had mixed experiences with people from everything from California, to NYC, to Pakistan and India. One thing that is true, you need a manager from your local side to be in front of the people you are outsourcing to. Otherwise management in the offshoring facility is extremely hard to execute on your goals.

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.

I have recently had an excellent experience with an offshore contractor. I hired a Flash programmer in Ukraine, through oDesk. I wrote detailed specifications, carefully monitored the results on a weekly basis, and required that I be provided a copy of the source every Friday. It was a small project (230 hrs), but it went well.

oDesk has an excellent environment for risk-free contracting. The contractors are tested and rated. You only pay a week at a time, and can pull the plug with minimal loss exposure. You can review each applicant's portfolio, and chat with them before committing to get a feel for their experience and responsiveness.

The stable of available contractors are top-notch. You just need to have detailed and well-documented specs. It's particularly good when you need expertise in an area where you don't have experience yourself.

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.

Yes, greedy management IS in fact a problem. When you have two companies working together, you have two management teams. 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 cook up their resume, and it become so obvious when we are having meetings during the project. Granted, some of the developers are good. But it's 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 situations, 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.

It seldomly works the way you think it does. If you do it, you should treat it tactically.

We calculate that 2 out of 3 offshore projects fail, but the price often makes up for that.

BTW. we only give out offshore projects of stuff we can't do ourselves. As we often experienced that offshored code was not reusable or refactorable, but instead an ugly mess of something, that worked most of the time. So keep it to something you won't have to touch or look at yourself.

Another good trick is to just try it out, and sometimes you get a gem in between who can do a certain type of project very well, and can hire these developers again if you need to do more in that field.

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

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.

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 third party to fit onto the current CSR tools that the acquired company was using.

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.

Because take away arbitrary borders, and that is what your question boils down to. The IT crowd has a firm belief in the enlightenment of telecommuting, but only if you're local. This makes little sense.

I know of one company that offshores their entire development team. A couple of years ago, I spotted a job advertisement that was in my "sweet spot" as they say, and so I applied. The job advertisement was basically a duplicate of the bullet points on my resume, yet I got the standard:

We're looking at more qualified candidates, blah blah blah.

I was somewhat taken aback, as having been in a hiring situation before I knew this is a rare combination of skillsets, so I emailed the guy and asked what gives... He says they don't hire North American programmers.

The question brings forth the well known problem of "Sampling Error" known to science.

I have worked on both sides (as a manager outsourcing and as an entrepreneur running offshore) and the only thing that comes to my mind is that one pilot project is not sufficient to judge the quality or feasibility of offshore development. The economies of scale do not come into picture.

As mentioned earlier the SWITCH companies rely on repeat work and that is working greatly for clients.

There are a lot of assumptions made while the client out sources their project (culture, work ethics, expertise, etc) which is not shared/known with the off shore team. The offshore team has to learn these things by trail and error method, this is a huge task. And the manager outsourcing does not consider it worth telling before-hand and creating a well laid out document detailing all these.

As mentioned in another answer in the thread, for porting and existing application to new technology went smoothly. Mainly because the offshore team had a reference which they can consult whenever there was a confusion.

As far as over-budget, under-featured or delayed is considered, the problem is universal to software development and out of scope of this question. So offshore development cannot be blamed for this.

If you want to test the feasibility give the offshore development companies a proper sampling. i.e. instead of jumping to conclusion after a single project, wait for second project. Check the performance metrics of second project with respect to the first one. Generally the second project is better performing as the offshore team has been acclimatized to the philosophies of the outsourcing company.

Offshore development is here to stay, mainly because of internet and cheap labor. It would be prudent if we do not make this mistake of comparing apples with oranges. If you want to compare an outsourced project, compare it with another outsourced project or the same outsourced project with different company.

Furthermore, it would be enlightening to all of us if you put some more pondering into the failure of your out-sourced project and share your findings.

Yes it does since many (large) companies recourse to offshoring/nearshoring/outsourcing and many (even large) companies make revenue out of it.

The main two reasons that offshore projects tend to fail more often than in-house ones from my POV are:

The people from the hiring companies responsible with offshore projects are those who are actually mediocre.

Brain drain from the offshore countries.

I am going to try to argument this statements bellow.

Are offshore programmers mediocre ones?

The assumption that programmers who are developing/maintaining code in offshore are mediocre programmers while the others are not is generally false. It can be asserted that are (on some degree) more mediocre but not that those in in-house projects are great while those in offshore are mediocre; actually generally speaking most programmers are mediocre no matter how they write the code.

A basic rule of sociology says that people are the same everywhere when observed as large groups; this obviously applies to programmers too. There is no reason to believe that in the US more people are born, with capabilities of being great programmers, than in India for example. The only way to measure a good programmer is the natural wish for learning new things in the domain and how these things work and brain capabilities. With a connection to Internet anyone with help from brain and eagerness of learning can know anything.

US programmers have advantage over Indian ones by being better educated (better universities) and invested more on; on the other hand many say that university does not really matter in the long term. Also they are better experienced since the software tradition is older in US and they worked on more interesting projects with larger budgets. But all of these do not really matter if the programmer does not like what s/he is doing or if the brain does not help, even if s/he graduated some Top 10 University or has worked on some kick-ass project; s/he will not be a great programmer but a mediocre one.

Brain drain from the offshore countries.

The main problem in the offshore place is offshore brain drain; many good programmers (not all) tend to leave the country and thus an offshore job for a better job (better salary, better working condition, more interesting project) working probably in an in-house project in a developed country. Probably a myth, but may be half true that the second most spoken language at Microsoft is Romanian. Speaking of language, offshore programmers speak at least two languages English, the native one and possibly the clients' if they are not from US/UK (German, French, Italian); this may say that they are not so mediocre, at least as people (not necessarily as programmers).

The people from the hiring companies responsible with offshore projects are those who are actually mediocre.

The great programmers that remain doing offshore programming may be arranged in a Surgical Team (somehow the way Fred Brooks says) and still do great jobs, but the problem comes from the other side. Suppose I am a higher manager and I have 11M $ to build to projects: one in house with a budget of 10M $ and one offshore with a budget of 1M $; I also have 2 lower-management/designers teams who are going to be responsible for each: one team is a great with lots of experience but the other not so great. How am I going to appoint them? Should I put the less experienced/mediocre project manager(s) and architect(s) to the in-house project which costs 10M $ or in the offshore one which costs 1M $ ? The answer is pretty simple: since offshore projects are not so expensive and thus not so risky as in-house ones they are going to be designed/managed/watched-over by more mediocre programmers/managers from the in-house company. The great programmers which remain in the developing countries for offshore programming often complain to their (offshore) managers that the clients are mediocre, they do not understand what are demanding, are having overrated estimates etc.