When I went to India last summer, I was struck by a couple of different things.

First of all, the people from India have great potential. I saw people learning a great deal there, becoming more entrepenurial, and becoming less likely to simply do as they are told, and more likely to think for themselves. A big factor that will change the game with India and other places is that the rapid 'first-worldization' of those economies is starting to create internal demand for those same resources, which in an ecomony growing 8% per year, will put upward pressure on rates in India.

Second, while India has a larger population, the lower-middle class or higher capable of producing a software engineer is really only a population of around 200M. The rest are, sadly, still worried about securing their next meal, which is a little more of a priority on Maslow's heirarchy than exploring the differences between C# and Ruby. The Indian base of software talent is about, roughly 80% of the size of the US base.

Third, a falling dollar, increases the relative costs of outsourcing, in addition to these other factors. Outsourcing to India or other countries with appreciating currencies against the dollar introduces an interesting form of Forex risk into your development budget.

Turnover is VERY high in India right now, with all this demand. Indian firms are struggling with putting together consistent teams for periods of time longer than a few weeks, especially of the coveted 10x developers everyone wants.

The infrastructure costs are significantly higher in India than in the US. There are huge tariffs on electronics goods - doubling the costs of computers that the programming occurs on.

Lastly, there is a cultural barrier to overcome, even if there isn't a language barrier. Having someone in India who has worked in the US generally helps, but to pretend that because we both use a language called English makes the communication issue a wash is pretty silly - there will be, and is, a significant cost to this. The subtle parts of our language, inflection and tone for example, are very different between our cultures, and to ignore this as a cost is silly.

That all said, there are projects that can operate in India, and there are success stories. But as you state, a careful analysis has to be done to make sure the hidden costs are revealed when you consider doing this kind of project. Many companies are discovering that, in fact, outsourcing is much more expensive than keeping things in house - and that the cost of switching back in forth is very dear indeed!

That article made me laugh, I couldn't believe that anyone would attempt to perform consulting in this manner (India or not).

With regards to India, you can't assign an entire project 100% to India. It won't be possible for another few decades. India does a fantastic job, the developers are awesome. But they fit a small slice of the whole development cycle. Trying to outsource a project like this will for sure set yourself up for failure and cause needless cost overruns. Knowing where they fit and how to make best use of the resource is where people will succeed.

With regard to the article, I see many many many problems that are going to cause this person's software project to fail miserably, no matter where it's being developed. The article really points out the same old problems that plague the entire industry, just in a different light.

Really, it's quite simple if you follow the rules, we all know them:

1. Management: Having a single liason that comes in and learns your company/processes, etc, is setting yourself up for failure from day one, offshore or not. You can't just hand everything over to this person. This person is expensive and kills the budget just even thinking about them. This person should exist in the *source* organization and serve as the domain expert, adding massive additional benefit. Send them to India to communicate with all consultants if need be, but don’t make them a funnel, make them connect people. Development projects do better when everyone knows more.

2. Planning: His justifications of cost increases really have nothing to do with India and originate from are the same old problem; lack of planning. Lack of planning is the biggest reason for failure on most software projects. This is *the* plague of the software industry, which is found more in corporate IT than anywhere else. This guy is a Magenic employee, so I'm guessing his sector of development is in corporate IT, which makes sense. There's more failure in software projects there. I don’t see us ISV’s as having the same issues as our development processes are better defined, I think from trying to appeal to a wider audience and thinking long term, instead of just finishing the current project.

3. Communication: I don’t think language and culture are barriers whatsoever. Everyone conducts business in English, CS courses are taught in English. Anyone that uses American slang without the least bit of sensitivity to a foreigner will fail and doesn’t belong on an offshore or domestic project. I really doubt that anyone involved in any software project today hasn’t had someone (if not most) on the team that is a non-native English speaker. The real issue is how to make sure that people understand what they’re supposed to be developing. Even if everyone on a team is from the same country and in the same office, communication is a challenge. Properly designed projects will eliminate a lot of miscommunication, and even then, the real challenge is how to communicate changes to the design from the team or customer feedback (at Beta and whatnot).

4. Experiment/Revise: It's a very risky proposition (insane, IMO) to try a new project by 100% offshoring it. Small project, just a few developers to fit a small portion, test test test test, identify problems early. Don’t dive into the ocean without testing the water. Learning how to effectively use a cheaper resource will save money.

I am intrigued by your statement that "After years of working through the various issues, and using a high level of process and formalization (he's a Six Sigma Black Belt and instructor), they have been able to get this all working." We are about to start an offshore dev project and I am very interested in using Six Sigma with it as it was very successful at my previous company, although not yet imlemented in development.

However, I am ALSO interested in using Agile as well if these two approaches are not at odds.

I am particularly concerned about the need for a "high level of process and formalization" as being closer to a CMMI approach and potentially bureaucratic. Do you feel these two approaches can be blended in order to achieve the best of all worlds?

Hi,

Read the article, agree with its concerns, and those of peeple making comments. But can't agree totally with the cost accounting that resulted in only -7% difference for "typical" projects. Would love if it was true, or better yet, if it showed there was +7% cost overrun. I too am a consultant competing for work against overseas companies. However, the only successful way I've found to compete, is to hire them myself for projects to reduce the total cost by 33% to 50%. But luckily, I'm working with firms charging between $15 and $25 as opposed to the $37 rate quoted in the article.

Yes its not easy working with offshore developers, but people have found ways to make it work, that's why they continue to do it.

Cheers,

Des Nolan